iOS ,不提交审核,修复某些线上bug以及线上更新

    zero
  • 发表于2018-08-28 17:21
  • 阅读(523)
安装本地所有补丁 --> 联网更新补丁信息,并安装有更新或新增加的补丁.注意此处的安装,指的是执行以下JS文件中的代码.此段代码会替换某个类的默认实现.当App运行到需要某个类的某个被JSPatch替换的方法时,会走JS定义的逻辑,而不再是源代码中默认的逻辑.可以看下DEMO.另外,我们的应用和示例中都使用了Objection这个依赖注入的库,你可能也要先温习下: [Objection,一个轻量级的Objective-C依赖注入框架

几种在线更新方案的对比: 为什么是JSPatch?

方案一: 申请"加急审核"

  • 方法: 提交应用时,选择"加急审核".
  • 优点: 操作简单,只需要重新上传应用即可;
  • 缺点:"加急审核",肯定是不能经常使用的.
  • 简评: 我想,这可能是大多数公司遇到紧急问题时,最常使用的方案.一个应用,每年是有若干次机会申请"加急审核",来缩短应用新版本的审核周期.通常审核周期是7天左右;"加急审核",通常只需要3天左右.

方案二: 使用 webview + Html5 页面

  • 方法: 特定的可能需要经常换的页面使用WebView来显示,内部使用Html5的内容来填充.当需要改变页面时,只需要改变下服务器接口返回的内容即可.
  • 优点: 对于内容的更新,足够灵活和迅速.
  • 缺点: 无法修复非HTML5页面的Bug;Html5 交互和UI通常逊色于原生页面.
  • 简评: 混合应用常用的方式,如PhoneGap等;对于大多数原生应用来说,此方案基本无适用性.

方案三: 编写基于ReactNative的应用

  • 方法: 使用 ReactNative 来编写应用或应用的部分页面,更多介绍参见: React Native 官方文档中文版
  • 优点: 原生UI,原生交互,支持服务器方式在线更新应用.
  • 缺点: 对于非ReactNative编写的页面无能为力.
  • 简评: 个人主观是很看好 ReactNative的,也在慢慢踩坑;但现实是大部分公司的已有项目是基于Objetive-C的,所以基于ReactNative的在线更新策略,目前对于大多说公司来说也并不具有可行性.

方案四: 基于JSPatch实现在线补丁式更新

  • 方法: 在自己的项目中引入JSPatch库,然后参见下文继续讨论的方案细节实施即可.JSPatch的入门使用,参见: http://www.ios122.com/2015/11/jspatch/
  • 优点: 支持操作所有工程中引入的CocoaTouch库与各种第三方库.可完全自由定义与重写已有代码的逻辑.
  • 缺点: JS语法操作API,语法转换有一定成本.
  • 简评: 大多数时候,我们需要的只是重写下某个方法,甚至某个判断,某个默认值,就可以很好地修复某个线上的Bug.所以,JSPatch,已经够用了.当然,如果是对于复杂的新功能的添加的话,建议还是提交审核吧.另外,不得不说一句,JSPatch + ReactNatvie 将来或许会成为一个很强力的组合,前者侧重于Bug的修复,后者侧重于复杂新需求的添加.本文接下来的篇幅将注重讨论基于JSPatch的线上Bug的即时修复方案.

关于使用JSPatch几个技术点的分析与实现.

基本实现原理

安装本地所有补丁 --> 联网更新补丁信息,并安装有更新或新增加的补丁.注意此处的安装,指的是执行以下JS文件中的代码.此段代码会替换某个类的默认实现.当App运行到需要某个类的某个被JSPatch替换的方法时,会走JS定义的逻辑,而不再是源代码中默认的逻辑.可以看下DEMO.另外,我们的应用和示例中都使用了Objection这个依赖注入的库,你可能也要先温习下: [Objection,一个轻量级的Objective-C依赖注入框架




转载自   http://www.tuicool.com/articles/JnAZrab    支持原创

你可能感兴趣的文章

相关问题

0 条评论

请先 登录 后评论
不写代码的码农
zero

1 篇文章

作家榜 »

  1. jeff 3 文章
  2. zero 1 文章
  3. Liang 1 文章
  4. ding 0 文章