JSPatch 是一个 iOS 动态更新框架,只需在项目中引入极小的引擎,就可以使用
JavaScript 调用任何 Objective-C 原生接口,获得脚本语言的优势:为项目动态添加模块,或替换项目原生代码动态修复
bug。
之前在博客上写过两篇 JSPatch 原理解析文章( 1 2),但随着 JSPatch 的改进,有些内容已经跟最新代码对不上,这里重新整理成一篇完整的文章,对原来的两篇做整合和修改,详细阐述
JSPatch 的实现原理和一些细节,以帮助使用者更好地了解和使用 JSPatch。
基础原理
JSPatch 能做到通过 JS 调用和改写 OC 方法最根本的原因是 Objective-C 是动态语言,OC
上所有方法的调用/类的生成都通过 Objective-C Runtime 在运行时进行,我们可以通过类名/方法名反射得到相应的类和方法:
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); |
对于 Objective-C 对象模型和动态消息发送的原理已有很多文章阐述得很详细,这里就不详细阐述了。理论上你可以在运行时通过类名/方法名调用到任何
OC 方法,替换任何类的实现以及新增任意类。所以 JSPatch 的基本原理就是:JS 传递字符串给 OC,OC
通过 Runtime 接口调用和替换 OC 方法。这是最基础的原理,实际实现过程还有很多怪要打,接下来看看具体是怎样实现的。
方法调用
require('UIView') var view = UIView.alloc().init() view.setBackgroundColor(require('UIColor').grayColor()) view.setAlpha(0.5) |
引入 JSPatch 后,可以通过以上 JS 代码创建了一个 UIView 实例,并设置背景颜色和透明度,涵盖了
require 引入类,JS 调用接口,消息传递,对象持有和转换,参数转换这五个方面,接下来逐一看看具体实现。
1. require
调用 require('UIView') 后,就可以直接使用 UIView 这个变量去调用相应的类方法了,require
做的事很简单,就是在JS全局作用域上创建一个同名变量,变量指向一个对象,对象属性__isCls表明这是一个Class,__clsName保存类名,在调用方法时会用到这两个属性。
var _require = function(clsName) { if (!global[clsName]) { global[clsName] = { __isCls: 1, __clsName: clsName } } return global[clsName] } |
所以调用 require('UIView') 后,就在全局作用域生成了 UIView 这个变量,指向一个这样一个对象:
{ __isCls: 1, __clsName: "UIView" } ! |
2. JS接口
接下来看看 UIView.alloc() 是怎样调用的。
i. 封装 JS 对象
对于这个调用的实现,一开始我的想法是,根据JS特性,若要让 UIView.alloc() 这句调用不出错,唯一的方法就是给
UIView 这个对象添加 alloc 方法,不然是不可能调用成功的,JS 对于调用没定义的属性/变量,只会马上抛出异常,而不像
OC/Lua/Ruby 那样会有转发机制。所以做了一个复杂的事,就是在Require生成类对象时,把类名传入OC,OC
通过Runtime方法找出这个类所有的方法返回给 JS,JS 类对象为每个方法名都生成一个函数,函数内容就是拿着方法名去
OC 调用相应方法。生成的 UIView 对象大致是这样的:
{ __isCls: 1, __clsName: "UIView", alloc: function() {…}, beginAnimations_context: function() {…}, setAnimationsEnabled: function(){…}, ... } |
实际上不仅要遍历当前类的所有方法,还要循环找父类的方法直到顶层,整个继承链上的所有方法都要加到JS对象上,一个类就有几百个方法,这样把方法全部加到
JS 对象上,碰到了挺严重的问题,引入几个类就内存暴涨,无法使用。后来为了优化内存问题还在 JS 搞了继承关系,不把继承链上所有方法都添加到一个JS对象,避免像基类
NSObject 的几百个方法反复添加在每个 JS 对象上,每个方法只存在一份,JS 对象复制了 OC
对象的继承关系,找方法时沿着继承链往上找,结果内存消耗是小了一些,但还是大到难以接受。
ii. __c()元函数
当时继续苦苦寻找解决方案,若按 JS 语法,这是唯一的方法,但若不按 JS 语法呢?突然脑洞开了下,CoffieScript/JSX
都可以用 JS 实现一个解释器实现自己的语法,我也可以通过类似的方式做到,再进一步想到其实我想要的效果很简单,就是调用一个不存在方法时,能转发到一个指定函数去执行,就能解决一切问题了,这其实可以用简单的字符串替换,把
JS 脚本里的方法调用都替换掉。最后的解决方案是,在 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) } } |
_methodFunc() 就是把相关信息传给OC,OC用 Runtime 接口调用相应方法,返回结果值,这个调用就结束了。
这样做不用去 OC 遍历对象方法,不用在 JS 对象保存这些方法,内存消耗直降 99%,这一步是做这个项目最爽的时候,用一个非常简单的方法解决了严重的问题,替换之前又复杂效果又差的实现。
3.消息传递
解决了 JS 接口问题,接下来看看 JS 和 OC 是怎样互传消息的。这里用到了 JavaScriptCore
的接口,OC 端在启动 JSPatch 引擎时会创建一个 JSContext 实例,JSContext
是 JS 代码的执行环境,可以给 JSContext 添加方法,JS 就可以直接调用这个方法:
JSContext *context = [[JSContext alloc] init]; context[@"hello"] = ^(NSString *msg) { NSLog(@"hello %@", msg); }; [_context evaluateScript:@"hello('word')"]; //output hello word |
JS 通过调用 JSContext 定义的方法把数据传给 OC,OC 通过返回值传会给 JS。调用这种方法,它的参数/返回值
JavaScriptCore 都会自动转换,OC 里的 NSArray, NSDictionary, NSString,
NSNumber, NSBlock 会分别转为JS端的数组/对象/字符串/数字/函数类型。上述 _methodFunc
方法就是这样把要调用的类名和方法名传递给 OC 的。
4.对象持有/转换
结合上述几点,可以知道 UIView.alloc() 这个类方法调用语句是怎样执行的:
a.require('UIView') 这句话在 JS 全局作用域生成了 UIView 这个对象,它有个属性叫
__isCls,表示这代表一个 OC 类。
b.调用 UIView 这个对象的 alloc() 方法,会去到 __c() 函数,在这个函数里判断到调用者
__isCls 属性,知道它是代表 OC 类,把方法名和类名传递给 OC 完成调用。
调用类方法过程是这样,那实例方法呢?UIView.alloc() 会返回一个 UIView 实例对象给
JS,这个 OC 实例对象在 JS 是怎样表示的?怎样可以在 JS 拿到这个实例对象后可以直接调用它的实例方法
UIView.alloc().init()?
对于一个自定义id对象,JavaScriptCore 会把这个自定义对象的指针传给 JS,这个对象在
JS 无法使用,但在回传给 OC 时 OC 可以找到这个对象。对于这个对象生命周期的管理,按我的理解如果JS有变量引用时,这个
OC 对象引用计数就加1 ,JS 变量的引用释放了就减1,如果 OC 上没别的持有者,这个OC对象的生命周期就跟着
JS 走了,会在 JS 进行垃圾回收时释放。
传回给 JS 的变量是这个 OC 对象的指针,这个指针也可以重新传回 OC,要在 JS 调用这个对象的某个实例方法,根据第2点
JS 接口的描述,只需在 __c() 函数里把这个对象指针以及它要调用的方法名传回给 OC 就行了,现在问题只剩下:怎样在
__c() 函数里判断调用者是一个 OC 对象指针?
目前没找到方法判断一个 JS 对象是否表示 OC 指针,这里的解决方法是在 OC 把对象返回给 JS
之前,先把它包装成一个 NSDictionary:
static NSDictionary *_wrapObj(id obj) { return @{@"__obj": obj}; } ! |
让 OC 对象作为这个 NSDictionary 的一个值,这样在 JS 里这个对象就变成:
{__obj: [OC Object 对象指针]} |
这样就可以通过判断对象是否有 __obj 属性得知这个对象是否表示 OC 对象指针,在 __c 函数里若判断到调用者有
__obj 属性,取出这个属性,跟调用的实例方法一起传回给 OC,就完成了实例方法的调用。
5.类型转换
JS 把要调用的类名/方法名/对象传给 OC 后,OC 调用类/对象相应的方法是通过 NSInvocation
实现,要能顺利调用到方法并取得返回值,要做两件事:
a.取得要调用的 OC 方法各参数类型,把 JS 传来的对象转为要求的类型进行调用。 b.根据返回值类型取出返回值,包装为对象传回给
JS。
例如开头例子的 view.setAlpha(0.5), JS传递给OC的是一个 NSNumber,OC
需要通过要调用 OC 方法的 NSMethodSignature 得知这里参数要的是一个 float 类型值,于是把
NSNumber 转为 float 值再作为参数进行 OC 方法调用。这里主要处理了 int/float/bool
等数值类型,并对 CGRect/CGRange 等类型进行了特殊转换处理,剩下的就是实现细节了。
方法替换
JSPatch 可以用 defineClass 接口任意替换一个类的方法,方法替换的实现过程也是颇为曲折,一开始是用
va_list 的方式获取参数,结果发现 arm64 下不可用,只能转而用另一种 hack 方式绕道实现。另外在给类新增方法、实现property、支持self/super关键字上也费了些功夫,下面逐个说明。
1.基础原理
OC上,每个类都是这样一个结构体:
struct objc_class { struct objc_class * isa; const char *name; …. struct objc_method_list **methodLists; /*方法链表*/ }; |
其中 methodList 方法链表里存储的是 Method 类型:
typedef struct objc_method *Method; typedef struct objc_ method { SEL method_name; char *method_types; IMP method_imp; }; |
Method 保存了一个方法的全部信息,包括 SEL 方法名,type 各参数和返回值类型,IMP 该方法具体实现的函数指针。
通过 Selector 调用方法时,会从 methodList 链表里找到对应Method进行调用,这个
methodList 上的元素是可以动态替换的,可以把某个 Selector 对应的函数指针IMP替换成新的,也可以拿到已有的某个
Selector 对应的函数指针IMP,让另一个 Selector 跟它对应,Runtime 提供了一些接口做这些事,以替换
UIViewController 的 -viewDidLoad: 方法为例:
static void viewDidLoadIMP (id slf, SEL sel) { JSValue *jsFunction = …; [jsFunction callWithArguments:nil]; } Class cls = NSClassFromString(@"UIViewController"); SEL selector = @selector(viewDidLoad); Method method = class_getInstanceMethod(cls, selector); //获得viewDidLoad方法的函数指针 IMP imp = method_getImplementation(method) //获得viewDidLoad方法的参数类型 char *typeDescription = (char *)method_getTypeEncoding(method); //新增一个ORIGViewDidLoad方法,指向原来的viewDidLoad实现 class_addMethod(cls, @selector(ORIGViewDidLoad), imp, typeDescription); //把viewDidLoad IMP指向自定义新的实现 class_replaceMethod(cls, selector, viewDidLoadIMP, typeDescription); |
这样就把 UIViewController 的 -viewDidLoad 方法给替换成我们自定义的方法,APP里调用
UIViewController 的 viewDidLoad 方法都会去到上述 viewDidLoadIMP
函数里,在这个新的IMP函数里调用 JS 传进来的方法,就实现了替换 viewDidLoad 方法为JS代码里的实现,同时为
UIViewController 新增了个方法 -ORIGViewDidLoad 指向原来 viewDidLoad
的 IMP,JS 可以通过这个方法调用到原来的实现。
方法替换就这样很简单的实现了,但这么简单的前提是,这个方法没有参数。如果这个方法有参数,怎样把参数值传给我们新的
IMP 函数呢?例如 UIViewController 的 -viewDidAppear: 方法,调用者会传一个
Bool 值,我们需要在自己实现的IMP(上述的 viewDidLoadIMP)上拿到这个值,怎样能拿到?如果只是针对一个方法写
IMP,是可以直接拿到这个参数值的:
static void viewDidAppear (id slf, SEL sel, BOOL animated) { [function callWithArguments:@(animated)]; } |
但我们要的是实现一个通用的IMP,任意方法任意参数都可以通过这个IMP中转,拿到方法的所有参数回调JS的实现。
2.va_list实现(32位)
最初我是用可变参数 va_list 实现:
static void commonIMP(id slf, ...) va_list args; va_start(args, slf); NSMutableArray *list = [[NSMutableArray alloc] init]; NSMethodSignature *methodSignature = [cls instanceMethodSignatureForSelector:selector]; NSUInteger numberOfArguments = methodSignature.numberOfArguments; id obj; for (NSUInteger i = 2; i < numberOfArguments; i++) { const char *argumentType = [methodSignature getArgumentTypeAtIndex:i]; switch(argumentType[0]) { case 'i': obj = @(va_arg(args, int)); break; case 'B': obj = @(va_arg(args, BOOL)); break; case 'f': case 'd': obj = @(va_arg(args, double)); break; …… //其他数值类型 default: { obj = va_arg(args, id); break; } } [list addObject:obj]; } va_end(args); [function callWithArguments:list]; } |
这样无论方法参数是什么,有多少个,都可以通过 va_list的一组方法一个个取出来,组成 NSArray
在调用 JS 方法时传回。很完美地解决了参数的问题,一直运行正常,直到我跑在 arm64 的机子上测试,一调用就
crash。查了资料,才发现 arm64 下 va_list 的结构改变了,导致无法上述这样取参数。详见这篇文章:https://blog.nelhage.com/2010/10/amd64-and-va_arg。
3.ForwardInvocation实现(64位)
继续寻找解决方案,最后找到另一种非常 hack 的方法解决参数获取的问题,利用了 OC 消息转发机制。
当调用一个 NSObject 对象不存在的方法时,并不会马上抛出异常,而是会经过多层转发,层层调用对象的
-resolveInstanceMethod:, -forwardingTargetForSelector:,
-methodSignatureForSelector:, -forwardInvocation: 等方法,其中最后
-forwardInvocation: 是会有一个 NSInvocation 对象,这个 NSInvocation
对象保存了这个方法调用的所有信息,包括 Selector 名,参数和返回值类型,最重要的是有所有参数值,可以从这个
NSInvocation 对象里拿到调用的所有参数值。我们可以想办法让每个需要被 JS 替换的方法调用最后都调到
-forwardInvocation:,就可以解决无法拿到参数值的问题了。
具体实现,以替换 UIViewController 的 -viewWillAppear: 方法为例:
把UIViewController的 -viewWillAppear: 方法通过 class_replaceMethod()
接口指向 _objc_msgForward,这是一个全局 IMP,OC 调用方法不存在时都会转发到这个
IMP 上,这里直接把方法替换成这个 IMP,这样调用这个方法时就会走到 -forwardInvocation:。
为UIViewController添加 -ORIGviewWillAppear: 和 -_JPviewWillAppear:
两个方法,前者指向原来的IMP实现,后者是新的实现,稍后会在这个实现里回调JS函数。
改写UIViewController的 -forwardInvocation: 方法为自定义实现。一旦OC里调用
UIViewController 的 -viewWillAppear: 方法,经过上面的处理会把这个调用转发到
-forwardInvocation: ,这时已经组装好了一个 NSInvocation,包含了这个调用的参数。在这里把参数从
NSInvocation 反解出来,带着参数调用上述新增加的方法 -JPviewWillAppear:
,在这个新方法里取到参数传给JS,调用JS的实现函数。整个调用调用过程就结束了,整个过程图示如下:
最后一个问题,我们把 UIViewController 的 -forwardInvocation: 方法的实现给替换掉了,如果程序里真有用到这个方法对消息进行转发,原来的逻辑怎么办?首先我们在替换
-forwardInvocation: 方法前会新建一个方法 -ORIGforwardInvocation:,保存原来的实现IMP,在新的
-forwardInvocation: 实现里做了个判断,如果转发的方法是我们想改写的,就走我们的逻辑,若不是,就调
-ORIGforwardInvocation: 走原来的流程。
其他就是实现上的细节了,例如需要根据不同的返回值类型生成不同的 IMP,要在各处处理参数转换等。
4. 新增方法
i. 方案
在 JSPatch 刚开源时,是不支持为一个类新增方法的,因为觉得能替换原生方法就够了,新的方法纯粹添加在
JS 对象上,只在 JS 端跑就行了。另外 OC 为类新增方法需要知道各个参数和返回值的类型,需要在 JS
定一种方式把这些类型传给 OC 才能完成新增方法,比较麻烦。后来挺多人比较关注这个问题,不能新增方法导致
action-target 模式无法用,我也开始想有没有更好的方法实现添加方法。后来的解决方案是所有类型都用
id 表示,因为反正新增的方法都是 JS 在用(Protocol定义的方法除外),不如新增的方法返回值和参数全统一成
id 类型,这样就不用传类型了。
现在 defineClass 定义的方法会经过 JS 包装,变成一个包含参数个数和方法实体的数组传给OC,OC会判断如果方法已存在,就执行替换的操作,若不存在,就调用
class_addMethod() 新增一个方法,通过传过来的参数个数和方法实体生成新的 Method,把
Method 的参数和返回值类型都设为id。这里 JS 调用新增方法走的流程还是 forwardInvocation
这一套。
ii. Protocol
对于新增的方法还有个问题,若某个类实现了某 protocol,protocol方法里有可选的方法,它的参数不全是
id 类型,例如 UITableViewDataSource 的一个方法:
- (NSInteger)tableView:(UITableView *)tableView sectionForSectionIndexTitle:(NSString *)title atIndex:(NSInteger)index; |
若原类没有实现这个方法,在 JS 里实现了,会走到新增方法的逻辑,每个参数类型都变成 id,与这个 protocol
方法不匹配,产生错误。
这里就需要在 JS 定义类时给出实现的 protocol,这样在新增 Protocol 里已定义的方法时,参数类型会按照
Protocol 里的定义去实现,Protocol 的定义方式跟 OC 上的写法一致:
defineClass("JPViewController: UIViewController <UIAlertViewDelegate>", { alertView_clickedButtonAtIndex: function(alertView, buttonIndex) { console.log('clicked index ' + buttonIndex) } }) |
实现方式比较简单,先把 Protocol 名解析出来,当 JS 定义的方法在原有类上找不到时,再通过 objc_getProtocol
和 protocol_copyMethodDescriptionList runtime 接口把 Protocol
对应的方法取出来,若匹配上,则按其方法的定义走方法替换的流程。
5. Property实现
若要在 JS 操作 OC 对象上已定义好的 property,只需要像调用普通 OC 方法一样,调用这个对象的
get/set 方法就行了:
//OC @property (nonatomic) NSString *data; @property (nonatomic) BOOL *succ; ``` ``` //JS self.setSucc(1); var str = self.data(); |
[
若要动态给 OC 对象新增 property,则要另辟蹊径:
defineClass('JPTableViewController : UITableViewController', { dataSource: function() { var data = self.getProp('data') if (data) return data; data = [1,2,3] self.setProp_forKey(data, 'data') return data; } } |
JSPatch可以通过 -getProp:, -setProp:forKey: 这两个方法给对象动态添加成员变量。实现上用了运行时关联接口
objc_getAssociatedObject() 和 objc_setAssociatedObject()
模拟,相当于把一个对象跟当前对象self关联起来,以后可以通过当前对象self找到这个对象,跟成员的效果一样,只是一定得是id对象类型。
本来OC有 class_addIvar() 可以为类添加成员,但必须在类注册之前添加完,注册完成后无法添加,这意味着可以为在JS新增的类添加成员,但不能为OC上已存在的类添加,所以只能用上述方法模拟。
6. self关键字
defineClass("JPViewController: UIViewController", { viewDidLoad: function() { var view = self.view() ... }, } |
JSPatch支持直接在defineClass里的实例方法里直接使用 self 关键字,跟OC一样 self
是指当前对象,这个 self 关键字是怎样实现的呢?实际上这个self是个全局变量,在 defineClass
里对实例方法 方法进行了包装,在调用实例方法之前,会把全局变量 self 设为当前对象,调用完后设回空,就可以在执行实例方法的过程中使用
self 变量了。这是一个小小的trick。
7. super关键字
defineClass("JPViewController: UIViewController", { viewDidLoad: function() { self.super.viewDidLoad() }, } |
OC 里 super 是一个关键字,无法通过动态方法拿到 super,那么 JSPatch 的 super
是怎么实现的?实际上调用 super 的方法,OC 做的事是调用父类的某个方法,并把当前对象当成 self
传入父类方法,我们只要模拟它这个过程就行了。
首先 JS 端需要告诉OC想调用的是当前对象的 super 方法,做法是调用 self.super()时,__c
函数会做特殊处理,返回一个新的对象,这个对象同样保存了 OC 对象的引用,同时标识 __isSuper
= 1。
... if (methodName == 'super') { return function() { return {__obj: self.__obj, __clsName: self.__clsName, __isSuper: 1} } } ... |
再用这个返回的对象去调用方法时,__c 函数会把 __isSuper 这个标识位传给 OC,告诉 OC
要调 super 的方法。OC 做的事情是,如果是调用 super 方法,找到 superClass 这个方法的
IMP 实现,为当前类新增一个方法指向 super 的 IMP 实现,那么调用这个类的新方法就相当于调用
super 方法。把要调用的方法替换成这个新方法,就完成 super 方法的调用了。
static id callSelector(NSString *className, NSString *selectorName, NSArray *arguments, id instance, BOOL isSuper) { ... if (isSuper) { NSString *superSelectorName =
NSString stringWithFormat:@"SUPER_%@", selectorName]; SEL superSelector = NSSelectorFromString(superSelectorName); Class superCls = [cls superclass]; Method superMethod = class_getInstanceMethod(superCls, selector); IMP superIMP = method_getImplementation(superMethod); class_addMethod(cls, superSelector, superIMP, method_getTypeEncoding(superMethod)); selector = superSelector; } ... } |
扩展
1. Struct 支持
struct 类型在 JS 与 OC 间传递需要做转换处理,一开始 JSPatch 只处理了原生的 NSRange
/ CGRect / CGSize / CGPoint 这四个,其他 struct 类型无法在 OC /
JS 间传递。对于其他类型的 struct 支持,我是采用扩展的方式,让写扩展的人手动处理每个要支持的
struct 进行类型转换,这种做法没问题,但需要在 OC 代码写好这些扩展,无法动态添加,转换的实现也比较繁琐。于是转为另一种实现:
/* struct JPDemoStruct { CGFloat a; long b; double c; BOOL d; } */ require('JPEngine').defineStruct({ "name": "JPDemoStruct", "types": "FldB", "keys": ["a", "b", "c", "d"] }) |
可以在 JS 动态定义一个新的 struct,只需提供 struct 名,每个字段的类型以及每个字段对应的在
JS 的键值,就可以支持这个 struct 类型在 JS 和 OC 间传递了:
//OC @implementation JPObject + (void)passStruct:(JPDemoStruct)s; + (JPDemoStruct)returnStruct; @end |
//JS require('JPObject').passStruct({a:1, b:2, c:4.2, d:1}) var s = require('JPObject').returnStruct(); |
这里的实现原理是顺序去取 struct 里每个字段的值,再根据 key 重新包装成 NSDictionary
传给 JS,怎样顺序取 struct 每字段的值呢?可以根据传进来的 struct 字段的变量类型,拿到类型对应的长度,顺序拷贝出
struct 对应位置和长度的值,具体实现:
for (int i = 0; i < types.count; i ++) { size_t size = sizeof(types[i]); //types[i] 是 float double int 等类型 void *val = malloc(size); memcpy(val, structData + position, size); position += size; } |
struct 从 JS 到 OC 的转换同理,只是反过来,先生成整个 struct 大小的内存地址(通过
struct 所有字段类型大小累加),再逐渐取出 JS 传过来的值进行类型转换拷贝到这端内存里。
这种做法效果很好,JS 端要用一个新的 struct 类型,不需要 OC 事先定义好,可以直接动态添加新的
struct 类型支持,但这种方法依赖 struct 各个字段在内存空间上的严格排列,如果某些机器在底层实现上对
struct 的字段进行一些字节对齐之类的处理,这种方式没法用了,不过目前在 iOS 上还没碰到这样的问题。
2. C 函数支持
C 函数没法通过反射去调用,所以只能通过手动转接的方式让 JS 调 C 方法,具体就是通过 JavaScriptCore
的方法在 JS 当前作用域上定义一个 C 函数同名方法,在这个方法实现里调用 C 函数,以支持 memcpy()
为例:
context[@"memcpy"] = ^(JSValue *des, JSValue *src, size_t n) { memcpy(des, src, n); }; |
这样就可以在 JS 调用 memcpy() 函数了。实际上这里还有参数 JS <-> OC
转换问题,这里先忽略。
这里有两个问题:
a.如果这些 C 函数的支持都写在 JSPatch 源文件里,源文件会非常庞大。
b.如果一开始就给 JS 加这些函数定义,若要支持的 C 函数量大时会影响性能。
对此设计了一种扩展的方式去解决这两个问题,JSPatch 需要做的就是为外部提供 JS 运行上下文 JSContext,以及参数转换的方法,最终设计出来的扩展接口是这样:
@interface JPExtension : NSObject + (void)main:(JSContext *)context; + (void *)formatPointerJSToOC:(JSValue *)val; + (id)formatPointerOCToJS:(void *)pointer; + (id)formatJSToOC:(JSValue *)val; + (id)formatOCToJS:(id)obj; @end |
s
+main 方法暴露了 JSPatch 的运行环境 JSContext 给外部,可以自由在这个 JSContext
上加函数。另外四个 formatXXX 方法都是参数转换方法。上述的 memcpy() 完整的扩展定义如下:
@implementation JPMemory + (void)main:(JSContext *)context { context[@"memcpy"] = ^id(JSValue *des, JSValue *src, size_t n) { void *ret = memcpy([self formatPointerJSToOC:des], [self formatPointerJSToOC:src], n); return [self formatPointerOCToJS:ret]; }; } @end |
同时 JSPatch 提供了 +addExtensions: 接口,让 JS 端可以动态加载某个扩展,在需要的时候再给
JS 上下文添加这些 C 函数:
require('JPEngine').addExtensions(['JPMemory']) |
实际上还有另一种方法添加 C 函数的支持,就是定义 OC 方法转接:
@implementation JPCFunctions + (void)memcpy:(void *)des src:(void *)src n:(size_t)n { memcpy(des, src, n); } @end |
然后直接在 JS 上这样调:
require('JPFunctions').memcpy_src_n(des, src, n); |
这样的做法不需要扩展机制,也不需要在实现时进行参数转换,但因为它走的是 OC runtime 那一套,相比扩展直接调用的方式,速度慢了一倍,为了更好的性能,还是提供一套扩展接口。
细节
整个 JSPatch 的基础原理上面大致阐述完了,接下来在看看一些实现上碰到的坑和的细节问题。
1. Special Struct
上文提到会把要覆盖的方法指向_objc_msgForward,进行转发操作,这里出现一个问题,如果替换方法的返回值是某些
struct,使用 _objc_msgForward(或者之前的 @selector(__JPNONImplementSelector))会
crash。几经辗转,找到了解决方法:对于某些架构某些 struct,必须使用 _objc_msgForward_stret
代替 _objc_msgForward。为什么要用 _objc_msgForward_stret 呢,找到一篇说明
objc_msgSend_stret 和 objc_msgSend 区别的文章:http://sealiesoftware.com/blog/archive/2008/10/30/objcexplainobjcmsgSendstret.html),说得比较清楚,原理是一样的,是C的一些底层机制的原因,简单复述一下:
大多数 CPU 在执行 C 函数时会把前几个参数放进寄存器里,对 obj_msgSend 来说前两个参数固定是
self / _cmd,它们会放在寄存器上,在最后执行完后返回值也会保存在寄存器上,取这个寄存器的值就是返回值:
-(int) method:(id)arg; r3 = self r4 = _cmd, @selector(method:) r5 = arg (on exit) r3 = returned int |
普通的返回值(int/pointer)很小,放在寄存器上没问题,但有些 struct 是很大的,寄存器放不下,所以要用另一种方式,在一开始申请一段内存,把指针保存在寄存器上,返回值往这个指针指向的内存写数据,所以寄存器要腾出一个位置放这个指针,self
/ _cmd 在寄存器的位置就变了:
-(struct st) method:(id)arg; r3 = &struct_var (in caller's stack frame) r4 = self r5 = _cmd, @selector(method:) r6 = arg (on exit) return value written into struct_var |
不知道 self / _cmd 的位置变了,所以要用另一个方法 objc_msgSend_stret 代替。原理大概就是这样。
上面说某些架构某些 struct 有问题,那具体是哪些呢?iOS 架构中非 arm64 的都有这问题,而怎样的
struct 需要走上述流程用 xxx_stret 代替原方法则没有明确的规则,OC 也没有提供接口,只有在一个奇葩的接口上透露了这个天机,于是有这样一个神奇的判断:
if ([methodSignature.debugDescription rangeOfString: @"is special struct return? YES"].location != NSNotFound) |
在 NSMethodSignature 的 debugDescription 上打出了是否 special
struct,只能通过这字符串判断。所以最终的处理是,在非 arm64 下,是 special struct
就走 _objc_msgForward_stret,否则走 _objc_msgForward。
2. 内存问题
i. Double Release
实现过程中碰到一些内存问题,首先是 Double Release 问题。从 -forwardInvocation:
里的 NSInvocation 对象取参数值时,若参数值是id类型,我们会这样取:
id arg; [invocation getArgument:&arg atIndex:i]; |
但这样的写法会导致 crash,这是因为 id arg 在ARC下相当于 __strong id arg,若这时在代码显式为
arg 赋值,根据 ARC 的机制,会自动插入一条 retain 语句,然后在退出作用域时插入 release
语句:
- (void)method { id arg = [SomeClass getSomething]; // [arg retain] ... // [arg release] 退出作用域前release } |
但我们这里不是显式对 arg 进行赋值,而是传入 -getArgument:atIndex: 方法,在这里面赋值后
ARC 没有自动给这个变量插入 retain 语句,但退出作用域时还是自动插入了 release 语句,导致这个变量多释放了一次,导致
crash。解决方法是把 arg 变量设成 _unsafeunretained 或 __weak,让 ARC
不在它退出作用域时插入 release 语句即可:
__unsafe_unretained id arg; [invocation getReturnValue:&arg]; |
还可以通过 __bridge 转换让局部变量持有返回对象,这样做也是没问题的:
id returnValue; void *result; [invocation getReturnValue:&result]; returnValue = (__bridge id)result; |
ii. 内存泄露
Double Release 的问题解决了,又碰到内存泄露的坑。某天 github issue 上有人提对象生成后没有释放,几经排查,定位到还是这里
NSInvocation getReturnValue 的问题,当 NSInvocation 调用的是
alloc 时,返回的对象并不会释放,造成内存泄露,只有把返回对象的内存管理权移交出来,让外部对象帮它释放才行:
id returnValue; void *result; [invocation getReturnValue:&result]; if ([selectorName isEqualToString:@"alloc"] || [selectorName isEqualToString:@"new"]) { returnValue = (__bridge_transfer id)result; } else { returnValue = (__bridge id)result; } |
这是因为 ARC 对方法名有约定,当方法名开头是 alloc / new / copy / mutableCopy
时,返回的对象是 retainCount = 1 的,除此之外,方法返回的对象都是 autorelease
的,按上一节的说法,对于普通方法返回值,ARC 会在赋给 strong 变量时自动插入 retain 语句,但对于
alloc 等这些方法,不会再自动插入 retain 语句:
id obj = [SomeObject alloc]; //alloc 方法返回的对象 retainCount 已 +1,这里不需要retain id obj2 = [SomeObj someMethod]; //方法返回的对象是 autorelease,ARC 会再这里自动插入 [obj2 retain] 语句 |
而 ARC 并没有处理非显示调用时的情况,这里动态调用这些方法时,ARC 都不会自动插入 retain,这种情况下,alloc
/ new 等这类方法返回值的 retainCount 是会比其他方法返回值多1的,所以需要特殊处理这类方法。
3. ‘_’的处理
JSPatch 用下划线’’连接OC方法多个参数间的间隔:
- (void)setObject:(id)anObject forKey:(id)aKey; <==> setObject_forKey() |
setObject_forKey()
那如果OC方法名里含有'_',那就出现歧义了:
<code>- (void)set_object:(id)anObject forKey:(id)aKey; <==> set_object_forKey()</code>! |
没法知道 set_object_forKey 对应的 selector 是 set_object:forKey:
还是 set:object:forKey:。
对此需要定个规则,在 JS 用其他字符代替 OC 方法名里的 _。JS 命名规则除了字母和数字,就只有
$ 和 _,看起来只能用 $ 代替了,但效果很丑:
- (void)set_object:(id)anObject forKey:(id)aKey; - (void)_privateMethod(); <==> set$object_forKey() $privateMethod() |
于是尝试另一种方法,用两个下划线 __ 代替:
set__object_forKey() __privateMethod() |
但用两个下划线代替有个问题,OC 方法名参数后面加下划线会匹配不到
- (void)setObject_:(id)anObject forKey:(id)aKey; <==> setObject___forKey() |
实际上 setObject___forKey() 匹配到对应的 selector 是 setObject:_forKey:。虽然有这个坑,但因为很少见到这种奇葩的命名方式,感觉问题不大,使用$也会导致替换不了
OC 方法名包含 $ 字符的,最终为了代码颜值,使用了双下划线 __ 表示。
4.JPBoxing
在使用 JSPatch 过程中发现JS无法调用 NSMutableArray / NSMutableDictionary
/ NSMutableString 的方法去修改这些对象的数据,因为这三者都在从 OC 返回到 JS 时
JavaScriptCore 把它们转成了 JS 的 Array / Object / String,在返回的时候就脱离了跟原对象的联系,这个转换在
JavaScriptCore 里是强制进行的,无法选择。
若想要在对象返回 JS 后,回到 OC 还能调用这个对象的方法,就要阻止 JavaScriptCore
的转换,唯一的方法就是不直接返回这个对象,而是对这个对象进行封装,JPBoxing 就是做这个事情的:
@interface JPBoxing : NSObject @property (nonatomic) id obj; @end @implementation JPBoxing + (instancetype)boxObj:(id)obj { JPBoxing *boxing = [[JPBoxing alloc] init]; boxing.obj = obj; return boxing; } |
把 NSMutableArray / NSMutableDictionary / NSMutableString
对象作为 JPBoxing 的成员保存在 JPBoxing 实例对象上返回给 JS,JS 拿到的是 JPBoxing
对象的指针,再传回给 OC 时就可以通过对象成员取到原来的 NSMutableArray / NSMutableDictionary
/ NSMutableString 对象,类似于装箱/拆箱操作,这样就避免了这些对象被 JavaScriptCore
转换。
实际上只有可变的 NSMutableArray / NSMutableDictionary / NSMutableString
这三个类有必要调用它的方法去修改对象里的数据,不可变的 NSArray / NSDictionary /
NSString 是没必要这样做的,直接转为 JS 对应的类型使用起来会更方便,但为了规则简单,JSPatch
让 NSArray / NSDictionary / NSString 也同样以封装的方式返回,避免在调用
OC 方法返回对象时还需要关心它返回的是可变还是不可变对象。最后整个规则还是挺清晰:NSArray /
NSDictionary / NSString 及其子类与其他 NSObject 对象的行为一样,在 JS
上拿到的都只是其对象指针,可以调用它们的 OC 方法,若要把这三种对象转为对应的 JS 类型,使用额外的
.toJS() 的接口去转换。
对于参数和返回值是C指针和 Class 类型的支持同样是用 JPBoxing 封装的方式,把指针和 Class
作为成员保存在 JPBoxing 对象上返回给 JS,传回 OC 时再解出来拿到原来的指针和 Class,这样
JSPatch 就支持所有数据类型 OC<->JS 的互传了。
5. nil的处理
i. 区分NSNull/nil
对于"空"的表示,JS 有 null / undefined,OC 有 nil /
NSNull,JavaScriptCore 对这些参数传递处理是这样的:
从 JS 到 OC,直接传递 null / undefined 到 OC 都会转为 nil,若传递包含
null / undefined 的 Array 给 OC,会转为 NSNull。
从 OC 到 JS,nil 会转为 null,NSNull 与普通 NSObject 一样返回指针。
JSPatch 的流程上都是通过数组的方式把参数从 JS 传入 OC,这样所有的 null / undefined
到 OC 就都变成了 NSNull,而真正的 NSNull 对象传进来也是 NSNull,无法分辨从 JS
过来实际传的是什么,需要有种方式区分这两者。
考虑过在 JS 用一个特殊的对象代表 nil,null / undefined 只用来表示 NSNull,后来觉得
NSNull 是很少手动传递的变量,而 null / undefined 以及 OC 的 nil 却很常见,这样做会给日常开发带来很大不便。于是反过来,在
JS 用一个特殊变量 nsnull 表示 NSNull,其他 null / undefined 表示 nil,这样传入
OC 就可以分辨出 nil 和 NSNull,具体使用方式:
@implementation JPObject + (void)testNil:(id)obj { NSLog(@"%@", obj); } @end require("JPObject").testNil(null) //output: nil require("JPObject").testNil(nsnull) //output: NSNull |
这样做有个小坑,就是显示使用 NSNull.null() 作为参数调用时,到 OC 后会变成 nil:
require("JPObject").testNil(require("NSNull").null()) //output: nil |
这个只需注意下用 nsnull 代替就行,从 OC 返回的 NSNull 再回传回去还是可以识别到 NSNull。
ii.链式调用
第二个问题,nil 在 JS 里用 null / undefined 表示,造成的后果是无法用 nil
调用方法,也就无法保证链式调用的安全:
@implementation JPObject + (void)returnNil { return nil; }
@end [[JPObject returnNil] hash] //it’s
OK require("JPObject").returnNil().hash() //crash |
原因是在 JS 里 null / undefined 不是对象,无法调用任何方法,包括我们给所有对象加的
__c() 方法。解决方式一度觉得只有回到上面说的,用一个特殊的对象表示 nil,才能解决这个问题了。但使用特殊的对象表示
nil,后果就是在 js 判断是否为 nil 时就要很啰嗦:
//假设用一个_nil对象变量表示OC返回的nil var obj = require("JPObject").returnNil() obj.hash() //经过特殊处理没问题 if (!obj || obj == _nil) { //判断对象是否为nil就得附加判断是否等于_nil } |
这样的使用方式难以接受,继续寻找解决方案,发现 true / false 在 JS 是个对象,是可以调用方法的,如果用
false 表示 nil,即可以做到调用方法,又可以直接通过 if (!obj) 判断是否为 nil,于是沿着这个方向,解决了用
false 表示 nil 带来的各种坑,几乎完美地解决了这个问题。实现上的细节就不多说了,说"几乎完美",是因为还有一个小坑,传递
false 给 OC 上参数类型是 NSNumber* 的方法,OC 会得到 nil 而不是 NSNumber
对象:
@implementation JPObject + (void)passNSNumber:(NSNumber *)num { NSLog(@"%@", num); } @end require("JPObject").passNSNumber(false) //output: nil |
如果 OC 方法的参数类型是 BOOL,或者传入的是 true / 0,都是没问题的,这小坑无伤大雅。
题外话,神奇的 JS 里 false 的 this 竟然不再是原来的 false,而是另一个 Boolean
对象,太特殊了:
Object.prototype.c = function(){console.log(this === false)}; false.c() //output false |
总结
JSPatch的原理以及一些实现细节就阐述到这里,希望这篇文章对大家了解和使用 JSPatch 有帮助。
|