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 方法名包含 $ 字符的，最終爲了代碼顏值，使用了雙下劃線 __ 表示。

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('clicked index ' + buttonIndex)
  }
})

實現方式比較簡單，先把 Protocol 名解析出來，當 JS 定義的方法在原有類上找不到時，再經過 objc_getProtocol 和 protocol_copyMethodDescriptionList runtime 接口把 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())