JSPatch 近期新特性解析
Posted 二进制小镇
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了JSPatch 近期新特性解析相关的知识，希望对你有一定的参考价值。
论坛“程序员吧”域名备案中！
将为大家提供视频、电子书、源码等优质学习资料！
JSPatch 在社区的推动下不断在优化改善，这篇文章总结下这几个月以来 JSPatch 的一些新特性，以及它们的实现原理。包括脱离锁的 performSelectorInOC 接口，支持可变参数方法调用，给新增方法指定类型的 defineProtocol 接口，支持重写 dealloc 方法，以及两个扩展 JPCleaner 和 JPLoader。
javascript 语言是单线程的，在 OC 使用 JavaScriptCore 引擎执行 JS 代码时，会对 JS 代码块加锁，保证同个 JSContext 下的 JS 代码都是顺序执行。所以调用 JSPatch 替换的方法，以及在 JSPatch 里调用 OC 方法，都会在这个锁里执行，这导致三个问题：
JSPatch替换的方法无法并行执行，如果如果主线程和子线程同时运行了 JSPatch 替换的方法，这些方法的执行都会顺序排队，主线程会等待子线程的方法执行完后再执行，如果子线程方法耗时长，主线程会等很久，卡住主线程。
某种情况下，JavaScriptCore 的锁与 OC 代码上的锁混合时，会产生死锁。
UIWebView 的初始化会与 JavaScriptCore 冲突。若在 JavaScriptCore 的锁里(第一次)初始化 UIWebView 会导致 webview 无法解析页面。
为解决这些问题，JSPatch 新增了 .performSelectorInOC(selector, arguments, callback) 接口，可以在执行 OC 方法时脱离 JavaScriptCore 的锁，同时又保证程序顺序执行。
举个例子：
defineClass('JPClassA', {
methodA: function() {
//run in mainThread
},
methodB: function() {
//run in childThread
var limit = 20;
var data = self.readData(limit);
var count = data.count();
return {data: data, count: count};
}
})
上述例子中若在主线程和子线程同时调用 -methodA 和 -methodB，而 -methodB 里self.readData(limit) 这句调用耗时较长，就会卡住主线程方法 -methodA 的执行，对此可以让这个调用改用 .performSelectorInOC() 接口，让它在 JavaScriptCore 锁释放后再执行，不卡住其他线程的 JS 方法执行：
defineClass('JPClassA', {
methodA: function() {
//run in mainThread
},
methodB: function() {
//run in childThread
var limit = 20;
return self.performSelectorInOC('readData', [limit], function(ret) {
var count = ret.count();
return {data: ret, count: count};
});
}
})
这两份代码在调用顺序上的区别如下图：
第一份代码对应左边的流程图，-methodB 方法被替换，当 OC 调用到 -methodB 时会去到 JSPatch 核心的 JPForwardInvocation 方法里，在这里面调用 JS 函数 -methodB，调用时 JavascriptCore 加锁，接着在 JS 函数里做这种处理，调用 reloadData() 函数，进而去到 OC 调用 -reloadData 方法，这时 -reloadData 方法是在 JavaScriptCore 的锁里调用的。直到 JS 函数执行完毕 return 后，JavaScriptCore 的才解锁，结束本次调用。
第二份代码对应右边的流程图，前面是一样的，调用 JS 函数 -methodB，JavaScriptCore 加锁，但 -methodB 函数在调用某个 OC 方法时(这里是reloadData())，不直接去调用，而是直接 return 返回一个对象 {obj}，这个{obj}的结构如下：
{
__isPerformInOC:1,
obj:self.__obj,
clsName:self.__clsName,
sel: args[0],
args: args[1],
cb: args[2]
}
JS 函数返回这个对象，JS 的调用就结束了，JavaScriptCore 的锁也就释放了。在 OC 可以拿到 JS 函数的返回值，也就拿到了这个对象，然后判断它是否 __isPerformInOC=1 对象，若是就根据对象里的 selector / 参数等信息调用对应的 OC 方法，这时这个 OC 方法的调用是在 JavaScriptCore 的锁之外调用的，我们的目的就达到了。
执行 OC 方法后，会去调 {obj} 里的的 cb 函数，把 OC 方法的返回值传给 cb 函数，重新回到 JS 去执行代码。这里会循环判断这些回调函数是否还返回 __isPerformInOC=1 的对象，若是则重复上述流程执行，不是则结束。
一直以来像 NSString 的 + (instancetype)stringWithFormat:(NSString *)format, … 这样参数个数可变的方法是不能在 JSPatch 动态调用的，原因是 JSPatch 调用 OC 方法时，是根据 JS 传入的方法名和参数组装成 NSInvocation 动态调用，而 NSInvocation 不支持调用参数个数可变的方法。
后来 @wjacker 换了种方式，用 objc_msgSend 的方式支持了可变参数方法的调用。之前一直想不到使用 objc_msgSend 是因为它不适用于动态调用，在方法定义和调用上都是固定的：
1.定义
需要事先定义好调用方法的参数类型和个数，例如想通过 objc_msgSend 调用方法
那就需要定义一个这样的c函数：
才能通过 new_msgSend 调用这个方法。而这个过程是无法动态化的，需要编译时确定，而各种方法的参数/返回值类型不同，参数个数不同，是没办法在编译时穷举写完的，所以不能用于所有方法的调用。
而对于可变参数方法，只支持参数类型和返回值类型都是 id 类型的方法，已经可以满足大部分需求，所以让使用它变得可能：
这样就可以用 new_msgSend1 调用固定参数一个，后续是可变参数的方法了。实际上在模拟器这个方法也可以支持固定参数是N个id的方法，也就是已经满足我们调用可变参数方法的需求了，但根据@wjacker 和 @Awhisper 的测试，在真机上不行，不同的固定参数都需要给它定义好对应的函数才行，官网文档对这点略有说明。于是，多了一大堆这样的定义，以应付1-10个固定参数的情况：
id (*new_msgSend2)(id, SEL, id,id,...) = (id (*)(id, SEL, id,id,...)) objc_msgSend;
id (*new_msgSend3)(id, SEL, id,id,id,...) = (id (*)(id, SEL, id,id,id,...)) objc_msgSend;
id (*new_msgSend4)(id, SEL, id,id,id,id,...) = (id (*)(id, SEL, id,id,id,id,...)) objc_msgSend;
...
2.调用
解决上述参数类型和个数定义问题后，还有调用的问题，objc_msgSend 不像 NSInvocation 可以在运行时动态添加组装传入的参数个数，objc_msgSend 则需要在编译时确定传入多少个参数。这对于1-10个参数的调用，不得不用 if else 写10遍调用语句，另外根据方法定义的固定参数个数不一样，还需要调用不同的 new_msgSend 函数，所以需要写10!条调用，于是有了这样的大长篇：gist。后来用宏格式化了一下，会好看一点：效果
JSPatch 为一个类新增原本 OC 不存在的方法时，所有的参数类型都会定义为 id 类型，这样实现是因为这种在 JS 里新增的方法一般不会在 OC 上调用，而是在 JS 上用，JS 可以认为一切变量都是对象，没有类型之分，所以全部定义为 id 类型。
但在实际使用 JSPatch 过程中，出现了这样的需求：在 OC 里 .h 文件定义了一个方法，这个方法里的参数和返回值不都是 id 类型，但是在 .m 文件中由于疏忽没有实现这个方法，导致其他地方调用这个方法时找不到这个方法造成 crash，要用 JSPatch 修复这样的 bug，就需要 JSPatch 可以动态添加指定参数类型的方法。
实际上如果在 JS 用 defineClass() 给类添加新方法时，通过某些接口把方法的各参数和返回值类型名传进去，内部再做些处理就可以解决上述问题，但这样会把 defineClass 接口搞得很复杂，不希望这样做。最终 @Awhisper 想出了个很好的方法，用动态新增 protocol 的方式支持。
首先 defineClass() 是支持 protocol 的：
这样做的作用是，当添加 Protocol 里定义的方法，而类里没有实现的方法时，参数类型不再全是 id，而是会根据 Protocol 里定义的参数类型去添加。
于是若想添加一些指定参数类型的方法，只需动态新增一个 protocol，定义新增的方法名和对应的参数类型，再在 defineClass() 定义里加上这个 protocol 就可以了。这样的不污染 defineClass() 的接口，也没有更多概念，十分简洁地解决了这问题。范例：
defineProtocol('JPDemoProtocol',{
stringWithRect_withNum_withArray: {
paramsType:"CGRect, float, NSArray*",
returnType:"id",
},
}
defineClass('JPTestObject : NSObject <JPDemoProtocol>', {
stringWithRect_withNum_withArray:function(rect, num, arr){
//use rect/num/arr params here
return @"success";
},
}
具体实现原理原作者已写得挺清楚，参见这里。
http://www.jianshu.com/p/564bdb35f3f3
之前 JSPatch 不能替换 -dealloc 方法，原因：
1. 按之前的流程，JS 替换 -dealloc 方法后，调用到 -dealloc 时会把 self 包装成 weakObject 传给 JS，在包装的时候就会出现以下 crash：
意思是在 dealloc 过程中对象不能赋给一个 weak 变量，无法包装成一个 weakObject 给 JS。
2. 若在这里不包装当前调用对象，或不传任何对象给 JS，就可以成功执行到 JS 上替换的 dealloc 方法。但这时没有调用原生 dealloc 方法，此对象不会释放成功，会造成内存泄露。
-dealloc 被替换后，原 -dealloc 方法 IMP 对应的 selector 已经变成 ORIGdealloc，若在执行完 JS 的 dealloc 方法后再强制调用一遍原 OC 的 ORIGdealloc ，会crash。猜测原因是 ARC 对 -dealloc 有特殊处理，执行它的 IMP（也就是真实函数）时传进去的 selectorName 必须是 dealloc，runtime 才可以调用它的 [super dealloc]，做一些其他处理。
到这里我到这里我就没什么办法了，后来 @ipinka 来了一招欺骗 ARC 的实现，解决了这个问题：
首先对与第一个问题，调用 -dealloc 时 self 不包装成 weakObject，而是包装成 assignObject 传给 JS，解决了这个问题。
对于第二个问题，调用 ORIGdealloc 时因为 selectorName 改变，ARC 不认这是 dealloc 方法，于是用下面的方式调用：
Class instClass = object_getClass(assignSlf);
Method deallocMethod = class_getInstanceMethod(instClass, NSSelectorFromString(@"ORIGdealloc"));
void (*originalDealloc)(__unsafe_unretained id, SEL) = (__typeof__(originalDealloc))method_getImplementation(deallocMethod);
originalDealloc(assignSlf, NSSelectorFromString(@"dealloc"));
做的事情就是，拿出 ORIGdealloc 的 IMP，也就是原 OC 上的 dealloc 实现，然后调用它时 selectorName 传入 dealloc，这样 ARC 就能认得这个方法是 dealloc，做相应处理了。
JPCleaner即时回退
有些 JSPatch 使用者有这样的需求：脚本执行后希望可以回退到没有替换的状态。之前我的建议使用者自己控制下次启动时不要执行，就算回退了，但还是有不重启 APP 即时回退的需求。但这个需求并不是核心功能，所以想办法把它抽离，放到扩展里了。
只需引入 JPCleaner.h，调用 +cleanAll 接口就可以把当前所有被 JSPatch 替换的方法恢复原样。另外还有 +cleanClass: 接口支持只回退某个类。这些接口可以在 OC 调用，也可以在 JS 脚本动态调用：
[JPCleaner cleanAll]
[JPCleaner cleanClass:@“JPViewController”];
实现原理也很简单，在 JSPatch 核心里所有替换的方法都会保存在内部一个静态变量 _JSOverideMethods 里，它的结构是 _JSOverideMethods[cls][selectorName] = jsFunction。我给扩展的基类 JPExtension 添加了个接口，把这个静态变量暴露给外部，遍历这个变量里保存的 class 和 selectorName，把 selector 对应的 IMP 重新指向原生 IMP 就可以了。详见源码。
JSPatch 脚本需要后台下发，客户端需要一套打包下载/执行的流程，还需要考虑传输过程中安全问题，JPLoader 就是帮你做了这些事情。
Vip会员群介绍
youyisiaApp
加入ios开发微信Vip群需知:
书籍来源：出于会员福利，为会员定制网络上没有且最新出版的iOS技术书籍，PDF高清版！
扩散性：资料不宜扩散，微信会员人数限制200人，发现扩散者取消会员资格，你懂的！
数量与质量：今年共享12本以上网络无法获取的新书，我认为有价值或会员自荐有价值的iOS新书！
交流平台：微信群高效的语音与文字交流平台，同时加入QQ千人iOS技术交流群！
现已更新大神班一期iOS 9全套视频！
有意思啊
iOS开发者长按关注
以上是关于JSPatch 近期新特性解析的主要内容，如果未能解决你的问题，请参考以下文章