这篇文章是针对在近期 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 = &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。
内存泄露
先说下上一篇文章留下的一个问题，在从 NSInvocation 取返回值时，为什么这样取参数会 crash：
- id arg;
- [invocation getReturnValue:&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:&arg];
还可以通过 __bridge 转换让局部变量持有返回对象，这样做也是没问题的：
- id returnValue;
- void *result;
- [invocation getReturnValue:&result];
- returnValue = (__bridge id)result;
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;
- }
这里想不明白为什么，从开源 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 方法名包含 $字符的，最终为了代码颜值，使用了双下划线 __表示。
#p#
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
#p#
新增方法
在 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('clicked index ' + buttonIndex)
- }
- })
实现方式比较简单，先把 Protocol 名解析出来，当 JS 定义的方法在原有类上找不到时，再通过 objc_getProtocol 和 protocol_copyMethodDescriptionList runtime 接口把 Protocol 对应的方法取出来，若匹配上，则按其方法的定义走方法替换的流程。
扩展
当前 JSPatch 还有两个问题：
- JS 无法动态调用C函数，只能通过手动在代码上给每个要调用的C函数封装成 JS 函数，像 dispatch 几个函数的实现一样。
- struct 类型只支持原生的 NSRange / CGRect / CGSize / CGPoint 这四个，其他 struct 类型无法在 OC / JS 间传递。
这两个问题都无法一次到位全部解决，C函数需要逐个添加，struct 需要逐个手动转为 NSDictionary，这些直接写在 JSPatch 里是不合适的，所以需要以扩展的形式给这些额外的需求提供支持。
扩展接口的设计上，我设想的效果是：
- 接口清晰
- 每个扩展独立存在，互不影响
- 不影响JPEngine的正常使用，尽量少暴露JPEngine的接口
- 扩展的接口可扩展，以后有其他扩展需求可以在其基础上添加
- 动态加载，扩展可能会给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:，其他接口没变。
效果上基本实现了我的设想：
- 接口还算清晰，struct 接口麻烦一点，但看过示例应该也容易理解。
- 每个扩展都是独立的，都可以添加自己想支持的 struct 类型，添加 JS 方法，互不影响
- JPEngine 接口没有变化，参数处理和 JPBoxing 也没有暴露出来，都封装在 JPExtension 的方法里。
- 若以后有其他扩展需求，可以直接在 JPExtension 添加。
- 以接口 +addExtensions: 的方式添加扩展，不但可以在 OC 上使用，还可以在 JS 上动态加载：
- require("JPEngine").addExtensions(require("JPCGTransform").instance())
