JSPatch实现原理详解

  • Post author:
  • Post category:IT
  • Post comments:0评论

距离上次写的<JSPatch实现原理详解>有一个月的时间,在这段时间里JSPatch在不断地完善和改进,代码已经有很多变化,有一些修改值得写一下,作为上一篇的补充。

Special Struct

先说下_objc_msgForward,在上一篇提到为了让替换的方法走forwardInvocation,把它指向一个不存在的 IMP:class_getMethodImplementation(cls, @selector(__JPNONImplementSelector)),实际上这样实现是多余的,若class_getMethodImplementation找不到 class / selector 对应的 IMP,会返回_objc_msgForward这个 IMP,所以更直接的方式是把要替换的方法都指向_objc_msgForward,省去查找方法的时间。

接着出现另一个问题,如果替换方法的返回值是某些 struct,使用_objc_msgForward(或者之前的@selector(__JPNONImplementSelector))会 crash。几经辗转,找到了解决方法:对于某些架构某些 struct,必须使用_objc_msgForward_stret代替_objc_msgForward。为什么要用_objc_msgForward_stret呢,找到一篇说明objc_msgSend_stret和objc_msgSend区别的文章),说得比较清楚,原理是一样的,是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 = &amp;struct_var (in caller&#39;s stack frame)
    r4 = self
    r5 = _cmd, @selector(method:)
    r6 = arg
    (on exit) return value written into struct_var

objc_msgSend不知道 self / _cmd 的位置变了,所以要用另一个方法objc_msgSend_stret代替。原理大概就是这样。

上面说某些架构某些 struct 有问题,那具体是哪些呢?iOS 架构中非 arm64 的都有这问题,而怎样的 struct 需要走上述流程用xxx_stret代替原方法则没有明确的规则,OC 也没有提供接口,只有在一个奇葩的接口上透露了这个天机,于是有这样一个神奇的判断:

if ([methodSignature.debugDescription rangeOfString:@&quot;is special struct return? YES&quot;].location != NSNotFound)

在NSMethodSignature的debugDescription上打出了是否 special struct,只能通过这字符串判断。所以最终的处理是,在非 arm64 下,是 special struct 就走_objc_msgForward_stret,否则走_objc_msgForward。

内存泄露

先说下上一篇文章留下的一个问题,在从NSInvocation取返回值时,为什么这样取参数会 crash:

id arg;
[invocation getReturnValue:&amp;arg];

这是因为&arg传入-getArgument:atIndex:方法后arg就指向了返回对象,但并不持有它,不会对返回对象引用+1,但因为id arg在ARC下相当于__strong id arg,arg是strong类型局部变量,所以退出作用域时会调用一次release,不持有对象又对对象调release,会导致对象多 release 了一次,所以 crash。只要把arg类型改成__unsafe_unretained,表明只是指向对象但不持有它,退出作用域时不 release 就没问题了:

__unsafe_unretained id arg;
[invocation getReturnValue:&amp;arg];

还可以通过__bridge转换让局部变量持有返回对象,这样做也是没问题的:

id returnValue;
void *result;
[invocation getReturnValue:&amp;result];
returnValue = (__bridge id)result;

double release 的问题解决了,但这里还有个大坑:内存泄露。某天 github issue 上有人提对象生成后没有释放,几经排查,定位到还是这里NSInvocation getReturnValue的问题,当NSInvocation调用的是alloc时,返回的对象并不会释放,造成内存泄露,只有把返回对象的内存管理权移交出来,让外部对象帮它释放才行:

id returnValue;
void *result;
[invocation getReturnValue:&amp;result];
if ([selectorName isEqualToString:@&quot;alloc&quot;] || [selectorName isEqualToString:@&quot;new&quot;]) {
    returnValue = (__bridge_transfer id)result;
} else {
    returnValue = (__bridge id)result;
}

这里想不明白为什么,从开源 Cocotron 里对 NSInvocation 的实现来看,NSInvocation 并不持有返回的对象,调用方法也是直接用 msgSend,没什么特别的地方,让人怀疑这是 ARC 的 bug。

‘_’的处理

JSPatch 用下划线’_’连接OC方法多个参数间的间隔:

- (void)setObject:(id)anObject forKey:(id)aKey;
<==>
setObject_forKey()

那如果OC方法名里含有’_’,那就出现歧义了:

- (void)set_object:(id)anObject forKey:(id)aKey;
<==>
set_object_forKey()

没法知道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 方法名包含$字符的,最终为了代码颜值,使用了双下划线__表示。

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 的互传了。

nil的处理

区分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。

链式调用

第二个问题,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

新增方法

在 JS 给类添加 OC 上没有定义的方法,实现上有两个变化:

1.流程

原先的做法是把新增的方法指向一个静态的IMP,脱离了方法替换的流程,这样做的优点是调用新增方法时不需要走forwardInvocation的流程,提升性能,但缺点一是不能跟方法替换走一样的流程,需要额外的代码,二是参数个数有限制,由于不能用va_list可变参数的方式定义(详见上篇文章),所以需要对每种参数个数都单独定义一个方法,原来的实现中定义了5个方法,所以新增方法最多只能支持5个参数。权衡下,为了去除参数个数限制,最后还是改成了跟替换方法一样走forwardInvocation的流程。

2.Protocol

现在 JSPatch 已支持 Protocol,这样在新增 Protocol 里已定义的方法时,参数类型会按照 Protocol 里的定义去实现,Protocol 的定义方式跟 OC 上的写法一致:

defineClass("JPViewController: UIViewController <UIAlertViewDelegate>", {
  alertView_clickedButtonAtIndex: function(alertView, buttonIndex) {
    console.log(&#39;clicked index &#39; + buttonIndex)
  }
})

实现方式比较简单,先把 Protocol 名解析出来,当 JS 定义的方法在原有类上找不到时,再通过objc_getProtocol和protocol_copyMethodDescriptionListruntime 接口把 Protocol 对应的方法取出来,若匹配上,则按其方法的定义走方法替换的流程。

扩展

当前 JSPatch 还有两个问题:

  1. JS 无法动态调用C函数,只能通过手动在代码上给每个要调用的C函数封装成 JS 函数,像 dispatch 几个函数的实现一样。
  2. struct 类型只支持原生的 NSRange / CGRect / CGSize / CGPoint 这四个,其他 struct 类型无法在 OC / JS 间传递。

这两个问题都无法一次到位全部解决,C函数需要逐个添加,struct 需要逐个手动转为 NSDictionary,这些直接写在 JSPatch 里是不合适的,所以需要以扩展的形式给这些额外的需求提供支持。

扩展接口的设计上,我设想的效果是:

  1. 接口清晰
  2. 每个扩展独立存在,互不影响
  3. 不影响JPEngine的正常使用,尽量少暴露JPEngine的接口
  4. 扩展的接口可扩展,以后有其他扩展需求可以在其基础上添加
  5. 动态加载,扩展可能会给JS全局变量添加很多接口,最好能在真正使用到时才加载

最终的扩展接口:

@protocol JPExtensionProtocol <NSObject>
@optional
- (void)main:(JSContext *)context;

- (size_t)sizeOfStructWithTypeEncoding:(NSString *)typeEncoding;
- (NSDictionary *)dictOfStruct:(void *)structData typeEncoding:(NSString *)typeEncoding;
- (void)structData:(void *)structData ofDict:(NSDictionary *)dict typeEncoding:(NSString *)typeEncoding;
@end

@interface JPExtension : NSObject <JPExtensionProtocol>
+ (instancetype)instance;
- (void *)formatPointerJSToOC:(JSValue *)val;
- (id)formatPointerOCToJS:(void *)pointer;
- (id)formatJSToOC:(JSValue *)val;
- (id)formatOCToJS:(id)obj;
@end

@interface JPEngine : NSObject
+ (void)addExtensions:(NSArray *)extensions;
...
@end

所有扩展都需要继承JPExtension,-main:方法会在加载扩展的时候执行,可以在-main:方法里为当前 JSContext 添加 JS 方法,若要支持自定义的 struct 类型,需要实现JPExtensionProtocol的三个 struct 相关方法(参考了Robert的实现),JSPatch 会在参数转换时根据typeEncoding向扩展取得 struct<->NSDictionary 的互转。所有扩展都要继承JPExtension,基类提供了 OC<->JS 参数处理的几个方法,在添加 JS 方法传递参数时使用。JPEngine添加了加载扩展的接口+addExtensions:,其他接口没变。

效果上基本实现了我的设想:

  1. 接口还算清晰,struct 接口麻烦一点,但看过示例应该也容易理解。
  2. 每个扩展都是独立的,都可以添加自己想支持的 struct 类型,添加 JS 方法,互不影响
  3. JPEngine接口没有变化,参数处理和JPBoxing也没有暴露出来,都封装在JPExtension的方法里。
  4. 若以后有其他扩展需求,可以直接在JPExtension添加。
  5. 以接口+addExtensions:的方式添加扩展,不但可以在 OC 上使用,还可以在 JS 上动态加载:
require("JPEngine").addExtensions(require("JPCGTransform").instance())

——————

版权声明
:本文章在微信公众平台的发表权,已「独家代理」给指定公众帐号:iOS开发(iOSDevTips)。

发表回复