JSPatch 实现原理完整详（下篇）

Posted 2021-04-30 SegmentFault

【编者按】前些天为大家分享了 @bang 同学的整改版「JSPatch 实现原理详解」，其实今天扩展和细节才是整改版的重点，求不打小编，精彩现在继续。

扩展

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

+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/objc_explain_objc_msgSend_stret.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

objc_msgSend 不知道 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 变量设成 __unsafe_unretained 或 __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()

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

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
}

这样的使用方式难以接受，继续寻找解决方案，发现 t rue / 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 有帮助。

- EOF -

阅读原文 去发掘作者一系列 JSPatch 文章。

专业的开发者技术社区

多样化线上知识交流

丰富线下活动和给力工作机会