JSPatch技术文档

一、背景需求介绍

为什么我们需要一个热修复(hot-fix)技术？

• 工作中容易犯错、bug难以避免。
• 开发和测试人力有限。
• 苹果Appstore审核周期太长，一旦出现严重bug难以快速上线新版本。
• 作为生产力工具，用户有对稳定性和可靠性的需求。

二、JSPatch简介

JSPatch诞生于2015年5月，最初是腾讯广研高级iOS开发@bang的个人项目。
它能够使用JavaScript调用Objective-C的原生接口，从而动态植入代码来替换旧代码，以实现修复线上bug。
JSPatch在Github.com上开源后获得了3000多个star和500多fork，广受关注，目前已被应用在大量腾讯/阿里/百度的App中。

三、JSPatch与wax对比

JSPatch与Wax对比

最关键的是JSPatch可实现方法粒度的线上代码替换，能修复一切代码引起的Bug。
而Wax无法实现。

四、JSPatch实现原理

基础原理

Objective-C是动态语言，具有运行时特性，该特性可通过类名称和方法名的字符串获取该类和该方法，并实例化和调用。

Class class = NSClassFromString(“UIViewController");
id viewController = [[class alloc] init];  
SEL selector = NSSelectorFromString(“viewDidLoad");
[viewController performSelector:selector];

也可以替换某个类的方法为新的实现：

static void newViewDidLoad(id slf, SEL sel) {}
class_replaceMethod(class, selector, newViewDidLoad, @"");

还可以新注册一个类，为类添加方法：

Class cls = objc_allocateClassPair(superCls, "JPObject", 0);
objc_registerClassPair(cls);
class_addMethod(cls, selector, implement, typedesc);

Javascript调用

我们可以用Javascript对象定义一个Objective-C类：

{
  __isCls: 1,
  __clsName: "UIView"
}

在OC执行JS脚本前，通过正则把所有方法调用都改成调用 __c() 函数，再执行这个JS脚本，做到了类似OC/Lua/Ruby等的消息转发机制：

UIView.alloc().init()
->
UIView.__c('alloc')().__c('init')()

给JS对象基类 Object 的 prototype 加上 __c 成员，这样所有对象都可以调用到 __c，根据当前对象类型判断进行不同操作：

Object.prototype.__c = function(methodName) {
  if (!this.__obj && !this.__clsName) return this[methodName].bind(this);
  var self = this
  return function(){
    var args = Array.prototype.slice.call(arguments)
    return _methodFunc(self.__obj, self.__clsName, methodName, args, self.__isSuper)
  }
}

互传消息

JS和OC是通过JavaScriptCore互传消息的。OC端在启动JSPatch引擎时会创建一个 JSContext 实例，JSContext 是JS代码的执行环境，可以给 JSContext 添加方法。JS通过调用 JSContext 定义的方法把数据传给OC，OC通过返回值传会给JS。调用这种方法，它的参数/返回值 JavaScriptCore 都会自动转换，OC里的 NSArray, NSDictionary, NSString, NSNumber, NSBlock 会分别转为JS端的数组/对象/字符串/数字/函数类型。
对于一个自定义id对象，JavaScriptCore 会把这个自定义对象的指针传给JS，这个对象在JS无法使用，但在回传给OC时OC可以找到这个对象。对于这个对象生命周期的管理，如果JS有变量引用时，这个OC对象引用计数就加1 ，JS变量的引用释放了就减1，如果OC上没别的持有者，这个OC对象的生命周期就跟着JS走了，会在JS进行垃圾回收时释放。

方法替换

1. 把UIViewController的 -viewWillAppear: 方法通过 class_replaceMethod() 接口指向 _objc_msgForward，这是一个全局 IMP，OC 调用方法不存在时都会转发到这个 IMP 上，这里直接把方法替换成这个 IMP，这样调用这个方法时就会走到 -forwardInvocation:。

2. 为UIViewController添加 -ORIGviewWillAppear: 和 -_JPviewWillAppear: 两个方法，前者指向原来的IMP实现，后者是新的实现，稍后会在这个实现里回调JS函数。

3. 改写UIViewController的 -forwardInvocation: 方法为自定义实现。一旦OC里调用 UIViewController 的 -viewWillAppear: 方法，经过上面的处理会把这个调用转发到 -forwardInvocation: ，这时已经组装好了一个 NSInvocation，包含了这个调用的参数。在这里把参数从 NSInvocation 反解出来，带着参数调用上述新增加的方法 -JPviewWillAppear: ，在这个新方法里取到参数传给JS，调用JS的实现函数。整个调用过程就结束了，整个过程图示如下：

JSPatch方法替换

最后一个问题，我们把 UIViewController 的 -forwardInvocation: 方法的实现给替换掉了，如果程序里真有用到这个方法对消息进行转发，原来的逻辑怎么办？首先我们在替换 -forwardInvocation: 方法前会新建一个方法 -ORIGforwardInvocation:，保存原来的实现IMP，在新的 -forwardInvocation: 实现里做了个判断，如果转发的方法是我们想改写的，就走我们的逻辑，若不是，就调 -ORIGforwardInvocation: 走原来的流程。

五、JSPatch代码示例

JSPatch在OC上的调用十分简单

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 
[JPEngine startEngine]; 
NSString *sourcePath = [[NSBundle mainBundle] pathForResource:@"demo" ofType:@"js"]; 
NSString *script = [NSString stringWithContentsOfFile:sourcePath encoding:NSUTF8StringEncoding error:nil]; 
[JPEngine evaluateScript:script];
}

一个Javascript代码修复Objective-C的bug的示例:

@implementation JPTableViewController

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
  NSString *content = self.dataSource[[indexPath row]];  //可能会超出数组范围导致crash
  JPViewController *ctrl = [[JPViewController alloc] initWithContent:content];
  [self.navigationController pushViewController:ctrl];
}

@end

上述代码中取数组元素处可能会超出数组范围导致crash。如果在项目里引用了JSPatch，就可以下发JS脚本修复这个bug：

defineClass("JPTableViewController", {
  tableView_didSelectRowAtIndexPath: function(tableView, indexPath) {
    var row = indexPath.row()
    if (self.dataSource().length > row) {  //加上判断越界的逻辑
      var content = self.dataArr()[row];
      var ctrl = JPViewController.alloc().initWithContent(content);
      self.navigationController().pushViewController(ctrl);
    }
  }
}, {})

六、股单App的Hot-fix解决方案

1.版本更新策略

• 考虑到下一个提交的App版本已经修复了上一个版本的bug，所以不同的App版本对应的补丁版本肯定也不同。同一个App版本下，可以出现递增的补丁版本。
• 补丁为全量更新，即新版本补丁包括旧版补丁的内容，更新后新版补丁覆盖旧版补丁。

• 补丁分为可选补丁和必选补丁，必选补丁用于重大bug的修复，如果不更新必选补丁则App无法继续使用。如下图2中，补丁版本v1234对应各自版本的用户，补丁v3为必须更新，补丁v1，v2，v4为可选补丁，则v1，v2的用户必须更新到v4才可使用；而v3的用户可先使用，同时后台静默更新到v4.

  
  股单App补丁版本更新策略

2.安全策略

安全问题在于JS 脚本可能被中间人攻击替换代码。可采取以下三种方法，股单App目前采用的是第三种：

1.对称加密。如zip 的加密压缩、AES 等加密算法。优点是简单，缺点是安全性低，易破解。若客户端被反编译，密码字段泄露，则完成破解。
2.HTTPS。优点是安全性高，证书在服务端未泄露，就不会被破解。缺点是部署麻烦，如果服务器本来就支持 HTTPS，使用这种方案也是一种不错的选择。
3.RSA校验。安全性高，部署简单。

RSA校验

详细校验步骤如下:
1.服务端计算出脚本文件的 MD5 值，作为这个文件的数字签名。
2.服务端通过私钥加密第 1 步算出的 MD5 值，得到一个加密后的 MD5 值。
3.把脚本文件和加密后的 MD5 值一起下发给客户端。
4.客户端拿到加密后的 MD5 值，通过保存在客户端的公钥解密。
5.客户端计算脚本文件的 MD5 值。
6.对比第 4/5 步的两个 MD5 值（分别是客户端和服务端计算出来的 MD5 值），若相等则通过校验。

3.客户端策略

客户端具体策略如下图:
1.用户打开App时，同步进行本地补丁的加载。
2.用户打开App时，后台进程发起异步网络请求，获取服务器中当前App版本所对应的最新补丁版本和必须的补丁版本。
3.获取补丁版本的请求回来后，跟本地的补丁版本进行对比。
4.如果本地补丁版本小于必须版本，则提示用户，展示下载补丁界面，进行进程同步的补丁下载。下载完成后重新加载App和最新补丁，再进入App。
5.如果本地补丁版本不小于必须版本，但小于最新版本，则进入App，不影响用户操作。同时进行后台进程异步静默下载，下载后补丁保存在本地。下次App启动时再加载最新补丁。
6.如果版本为最新，则进入App。

股单App客户端hot-fix策略

七、参考资料和文献：

1.https://github.com/bang590/JSPatch
2.https://github.com/mmin18/WaxPatch
3.https://github.com/probablycorey/wax
4.https://github.com/alibaba/AndFix
5.http://blog.cnbang.net/tech/2879/
6.http://blog.cnbang.net/works/2767/
7.http://blog.cnbang.net/tech/2808/
8.http://blog.zhaiyifan.cn/2015/11/20/HotPatchCompare/