距離上次寫的《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 ", {
  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 @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 + (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)。