iOS版hotfix调研文档

最新推荐文章于 2024-06-23 09:38:56 发布

Treasure_Gin

最新推荐文章于 2024-06-23 09:38:56 发布

阅读量818

点赞数

分类专栏：移动端文章标签： ios 应用苹果 hotfix JSPatch

本文链接：https://blog.csdn.net/Treasure_Gin/article/details/78835310

版权

移动端专栏收录该内容

0 篇文章 0 订阅

订阅专栏

hotfix简介

对于iOS应用而言，app store的审核周期可能通常维持在1-2个星期。倘若一个线上的应用出现了一些bug，甚至是致命的崩溃，这时候假如按照苹果的套路乖乖重新发布一个版本，然后静静等待看似漫无期限的审核周期，最终结果就是：用户大量流失。因此，对于一些线上的bug，需要有及时修复的能力，这就是所谓的热修复（hotfix）。

由于苹果应用审核周期长，hotfix就是一个非常重要的角色。相比而言，Android的审核可能通常在1天之内就能完成，显得就不是那么重要了。

与热修复有点划不清界限的另一个词叫热更新，两者的手段是一样的，都是通过下发新文件来修改线上工程的运作，只不过热修复的目的是修复线上bug，而热更新的目的则是对线上产品进行临时的更新。

这里写图片描述

大致意思就是，苹果可能不允许动态下发可执行代码或者脚本文件，但通过苹果JavaScriptCore.framework或WebKit执行的代码除外。文档中说的是may not,所以….闹哪样。

iOS中的HotFix方案大致可以分为四种：
* WaxPatch（Alibaba）
* Dynamic Framework（Apple）
* React Native（Facebook）
* JSPatch（Tencent）

WaxPatch

迄今为止，脚本语言中运行速度最快的是Lua（我们所熟知的魔兽世界和移动端的愤怒的小鸟正是这门语言的产物），而WaxPatch也正是一个通过Lua语言编写的iOS框架，不仅允许用户使用 Lua 调用 iOS SDK和应用程序内部的 API, 而且使用了 OC runtime 特性调用替换应用程序内部由 OC 编写的类方法，从而达到HotFix的目的。

优点：是支持iOS6，因为在早期版本中和其竞争的JSPatch在iOS6中不支持内部引用JavaScriptCore.framework,所以在当时有着一些优势，同时由于语言运行速度优势，框架性能较为优越。

缺点：，但是缺点也是非常的明显，不符合Apple3.2.2的审核规则即不可动态下发可执行代码，但通过苹果JavaScriptCore.framework或WebKit执行的代码除外；同时Wax已经长期没有人维护了，即使现在是由阿里进行maintained，但框架的更新仍然十分缓慢，所以至今还是有很多OC方法不能用Lua实现，比如Wax不能很好的支持block；最后就是必须要内嵌一个Lua脚本的执行引擎才能运行Lua脚本,iOS并没有内置lua引擎，所以这样会增加包的体积；Wax并不支持arm64框架，线程安全也是需要考虑的地方。

WaxPatch配置：
源码：https://github.com/alibaba/wax
接入方法：http://blog.csdn.net/mcg890414/article/details/41047513
Demo：https://github.com/mmin18/WaxPatch

Dynamic Framework

静态库和动态库都是二进制文件，两者的区别在于，静态库在编译时就被链接进可执行文件，成为程序的一部分；而动态库并不被打包进程序，是在程序运行的时候被动态加载。前者相对于编译时，后者相对与运行时。

苹果在XCode6中开放了iOS的动态库，这样借助动态库可以做很多事，通过动态下发动态库可以实现应用版本升级的目的，也就是热更新。如果应用中相关模块本身就是用动态库实现的，出现了bug，还可以通过动态下发新的动态库来实现热修复。

实际中，更多的是用来热更新。因为要求事先在应用中写好加载动态库以及调用相关方法的代码，说明事先就预见了当前环境的可扩展性，这更符合热更新的动机。

但是有个最大的问题就是，按照苹果的说明是不允许动态下发可执行代码的，即便下发了也可能无法加载，但是比较矛盾的是，苹果在iOS8开放了NSBundle挂载动态库的接口，所以结果到底是怎么样并没有特别的明确，从技术上来说是可行的，但是在机制上因为应用下线需要承担很大的责任，所以并没有太多人敢去尝试这些，也就是即使当时通过了，也很有可能在后来本发现然后强制下线。

优点：可以将最终可执行文件体积缩小，将整个应用程序分模块，团队合作进行分工，影响比较小，同时多个应用程序共享内存中的同一份库文件，节省资源，还可以不重新编译链接可执行文件程序的前提下，更新动态库达到更新应用程序的目的，方便应用插件化。

缺点：缺点显而易见如果通过Dynamic Framework来实现bug的hotfix，这个方案首先不符合审核规定，只适用于公司内部的一些项目使用，这种方案其实并不适用于BugFix，更适合App线上的大更新。

dynamic framework配置：
接入方法：http://www.cnblogs.com/wfwenchao/p/5577789.html
Demo：https://github.com/zyc410703/dynamic-framework

React Native

简单地说，因为React Native是使用脚本语言来编写的，所谓脚本语言就是不需要编译就可以运行的语言，也就是“即读即运行”。我们在“读”之前将之替换成新版本的脚本，运行时执行的便是新的逻辑了，所以脚本本质上和图片资源一样，都是可以进行热更新的。

要实现React Native的脚本热更新，我们要知道它是如何去加载脚本的。在编写业务逻辑的时候，我们会有许多个js文件，打包的时候RN会将这些个js文件打包成一个叫index.ios.bundle（android的是index.android.bundle）的文件，所有的js代码(包括rn源代码、第三方库、业务逻辑的代码)都在这一个文件里，启动App时会第一时间加载bundle文件，所以脚本热更新要做的事情就是替换掉这个bundle文件。

实现hotfix思路方案：http://www.jianshu.com/p/2cb3eb9604ca
Demo：https://github.com/Microsoft/react-native-code-push

优点：React Native 是从 Web 前端开发框架 React 延伸出来的解决方案，主要解决的问题是 Web 页面在移动端性能低的问题，React Native 让开发者可以像开发 Web 页面那样用 React 的方式开发功能，同时框架会通过 JavaScript 与 Objective-C 的通信让界面使用原生组件渲染，让开发出来的功能拥有原生APP的性能和体验。

缺点：虽然有很多APP是使用React Native开发，但是SDK根据调研并没有发现，虽然这个框架十分很强大但是React Native并不是十分成熟，Android甚至才刚起步。
React Native支持用JavaScript进行开发，所以可以通过更改JS文件实现App的HotFix，但是这种方案的明显的缺点在于它只适合用于使用了React Native这种方案的应用。

React Natvie配置：
环境配置和开发学习：http://reactnative.cn/docs/0.39/getting-started.html

JSPatch

JSPatch是只需要在项目中引入极小的JSPatch引擎，就可以使用JavaScript语言调用Objective-C的原生接口，获得脚本语言的能力：动态更新iOS APP，替换项目原生代码、快速修复bug。

优点：目前前端开发和终端开发有融合的趋势，作为扩展的脚本语言，JavaScript是不二之选。
更符合Apple的规则。iOS Developer Program License Agreement里3.3.2提到不可动态下发可执行代码，但通过苹果JavaScriptCore.framework或WebKit执行的代码除外，JS正是通过JavaScriptCore.framework执行的，使用系统内置的JavaScriptCore.framework，无需内嵌脚本引擎，体积小巧，支持block，JavascriptCore.framework通过GC来对垃圾进行回收，支持armv7 armv7s arm64框架，这都是相比于wax有优势的地方

缺点：不支持iOS6及以下，因为JSPatch依赖于iOS7及以后的JavascriptCore.framework (这点现在可以忽略，因为微信最低的版本要求已经是iOS7)，调用OC方法的性能慢于lua wax，
启动JSPatch所占用的内存多于wax。

JSPatch源码：https://github.com/bang590/JSPatch
wiki：https://github.com/bang590/JSPatch/wiki
Demo：https://github.com/bang590/JSPatch/tree/master/Demo

由于是使用JavaScript语言调用Objective-C，所以很多语法问题较为明显，这也是在调研初期Demo编写中花费时间的，虽然有官方提供的转换工具，但工具的使用大多只能修改基本的语法，复杂的脚本编写还需要对相应语法和功能更加熟悉，包括官方提供的大量文档也都是如何让大家能更好的使用脚本编写去调用相应的Objective-C的方法，下面有一些经常会查阅的文档和网址方便使用学习：

代码转换工具：https://github.com/bang590/JSPatchConvertor
JS语法检查： http://jspatch.com/Tools/jslint

使用 JSPatch 有两个安全问题：
1. 传输安全：JS 脚本可以调用任意 OC 方法，权限非常大，若被中间人攻击替换代码，会造成较大的危害。
1. 执行安全：下发的 JS 脚本灵活度大，相当于一次小型更新，若未进行充分测试，可能会出现 crash 等情况对 APP 稳定性造成影响。

解决思路：http://blog.cnbang.net/tech/2879/

JSPatch平台

JSPatch 需要使用者有一个后台可以下发和管理脚本，并且需要处理传输安全等部署工作，JSPatch 平台帮你做了这些事，提供了脚本后台托管，版本管理，保证传输安全等功能，让你无需搭建一个后台，无需关心部署操作，只需引入一个 SDK 即可立即使用 JSPatch。
官方网址：http://jspatch.com
sdk下载：http://jspatch.com/Index/sdk
接入文档：http://jspatch.com/Docs/SDK

平台内部对JSPatch很多方法进行了系统的封装，同时提供了更多简便的方法来满足用户的需求，很多大量的文档和信息，多数是基于平台为基础的，其中对于安全问题就进行了让用户操作最为简单但同时又最为安全的处理：

这里写图片描述