JSPatch實現原理詳解（二）
這篇文章是針對在近期 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())
