×

JSPatch技术文档

96
上官soyo
2015.12.13 22:18* 字数 2207

一、背景需求介绍

为什么我们需要一个热修复(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/

iOS开发
Web note ad 1