這篇文章是針對在近期 JSPatch不斷地完善和改進(jìn)，對JSPatch實(shí)現(xiàn)原理詳解（一）的補(bǔ)充。

Special Struct

先說下 _objc_msgForward，在上一篇提到為了讓替換的方法走 forwardInvocation，把它指向一個不存在的 IMP: class_getMethodImplementation(cls, @selector(__JPNONImplementSelector))，實(shí)際上這樣實(shí)現(xiàn)是多余的，若 class_getMethodImplementation 找不到 class / selector 對應(yīng)的 IMP，會返回 _objc_msgForward 這個 IMP，所以更直接的方式是把要替換的方法都指向 _objc_msgForward，省去查找方法的時間。

接著出現(xiàn)另一個問題，如果替換方法的返回值是某些 struct，使用 _objc_msgForward（或者之前的 @selector(__JPNONImplementSelector))會 crash。幾經(jīng)輾轉(zhuǎn)，找到了解決方法：對于某些架構(gòu)某些 struct，必須使用 _objc_msgForward_stret 代替 _objc_msgForward。為什么要用 _objc_msgForward_stret 呢，找到一篇說明 objc_msgSend_stret 和 objc_msgSend 區(qū)別的文章），說得比較清楚，原理是一樣的，是C的一些底層機(jī)制的原因，簡單復(fù)述一下：

大多數(shù)CPU在執(zhí)行C函數(shù)時會把前幾個參數(shù)放進(jìn)寄存器里，對 obj_msgSend 來說前兩個參數(shù)固定是 self / _cmd，它們會放在寄存器上，在***執(zhí)行完后返回值也會保存在寄存器上，取這個寄存器的值就是返回值：

-(int) method:(id)arg; 
    r3 = self 
    r4 = _cmd, @selector(method:) 
    r5 = arg 
    (on exit) r3 = returned int 

普通的返回值(int/pointer)很小，放在寄存器上沒問題，但有些 struct 是很大的，寄存器放不下，所以要用另一種方式，在一開始申請一段內(nèi)存，把指針保存在寄存器上，返回值往這個指針指向的內(nèi)存寫數(shù)據(jù)，所以寄存器要騰出一個位置放這個指針，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 代替。原理大概就是這樣。

上面說某些架構(gòu)某些 struct 有問題，那具體是哪些呢？iOS 架構(gòu)中非 arm64 的都有這問題，而怎樣的 struct 需要走上述流程用 xxx_stret 代替原方法則沒有明確的規(guī)則，OC 也沒有提供接口，只有在一個奇葩的接口上透露了這個天機(jī)，于是有這樣一個神奇的判斷：

if ([methodSignature.debugDescription rangeOfString:@"
is special struct return? YES"].location != NSNotFound) 

在 NSMethodSignature 的 debugDescription 上打出了是否 special struct，只能通過這字符串判斷。所以最終的處理是，在非 arm64 下，是 special struct 就走 _objc_msgForward_stret，否則走 _objc_msgForward。

內(nèi)存泄露

先說下上一篇文章留下的一個問題，在從 NSInvocation 取返回值時，為什么這樣取參數(shù)會 crash：

id arg; 
[invocation getReturnValue:&arg]; 

這是因?yàn)?nbsp;&arg 傳入 -getArgument:atIndex: 方法后 arg 就指向了返回對象，但并不持有它，不會對返回對象引用+1，但因?yàn)?nbsp;id arg 在ARC下相當(dāng)于 __strong id arg，arg 是 strong 類型局部變量，所以退出作用域時會調(diào)用一次 release，不持有對象又對對象調(diào) release，會導(dǎo)致對象多 release 了一次，所以 crash。只要把 arg 類型改成 __unsafe_unretained，表明只是指向?qū)ο蟮怀钟兴?，退出作用域時不 release 就沒問題了：

__unsafe_unretained id arg; 
[invocation getReturnValue:&arg]; 

還可以通過 __bridge 轉(zhuǎn)換讓局部變量持有返回對象，這樣做也是沒問題的：

id returnValue; 
void *result; 
[invocation getReturnValue:&result]; 
returnValue = (__bridge id)result; 

double release 的問題解決了，但這里還有個大坑：內(nèi)存泄露。某天 github issue 上有人提對象生成后沒有釋放，幾經(jīng)排查，定位到還是這里 NSInvocation getReturnValue 的問題，當(dāng) NSInvocation 調(diào)用的是 alloc 時，返回的對象并不會釋放，造成內(nèi)存泄露，只有把返回對象的內(nèi)存管理權(quán)移交出來，讓外部對象幫它釋放才行：

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 的實(shí)現(xiàn)來看，NSInvocation 并不持有返回的對象，調(diào)用方法也是直接用 msgSend，沒什么特別的地方，讓人懷疑這是 ARC 的 bug。

‘_’的處理

JSPatch 用下劃線’_’連接OC方法多個參數(shù)間的間隔：

- (void)setObject:(id)anObject forKey:(id)aKey; 
<==> 
setObject_forKey() 

那如果OC方法名里含有’_’，那就出現(xiàn)歧義了：

- (void)set_object:(id)anObject forKey:(id)aKey; 
<==> 
set_object_forKey() 

沒法知道 set_object_forKey 對應(yīng)的 selector 是 set_object:forKey: 還是 set:object:forKey:。

對此需要定個規(guī)則，在 JS 用其他字符代替 OC 方法名里的 _。JS 命名規(guī)則除了字母和數(shù)字，就只有 $ 和 _，看起來只能用 $ 代替了，但效果很丑：

- (void)set_object:(id)anObject forKey:(id)aKey; 
- (void)_privateMethod(); 
<==> 
set$object_forKey() 
$privateMethod() 

于是嘗試另一種方法，用兩個下劃線 __ 代替：

set__object_forKey() 
__privateMethod() 

但用兩個下劃線代替有個問題，OC 方法名參數(shù)后面加下劃線會匹配不到

- (void)setObject_:(id)anObject forKey:(id)aKey; 
<==> 
setObject___forKey() 

實(shí)際上 setObject___forKey() 匹配到對應(yīng)的 selector 是 setObject:_forKey:。雖然有這個坑，但因?yàn)楹苌僖姷竭@種奇葩的命名方式，感覺問題不大，使用 $ 也會導(dǎo)致替換不了 OC 方法名包含 $字符的，最終為了代碼顏值，使用了雙下劃線 __表示。

#p#

JPBoxing

在使用 JSPatch 過程中發(fā)現(xiàn)JS無法調(diào)用 NSMutableArray / NSMutableDictionary / NSMutableString 的方法去修改這些對象的數(shù)據(jù)，因?yàn)檫@三者都在從 OC 返回到 JS 時 JavaScriptCore 把它們轉(zhuǎn)成了 JS 的 Array / Object / String，在返回的時候就脫離了跟原對象的聯(lián)系，這個轉(zhuǎn)換在 JavaScriptCore 里是強(qiáng)制進(jìn)行的，無法選擇。

若想要在對象返回 JS 后，回到 OC 還能調(diào)用這個對象的方法，就要阻止 JavaScriptCore 的轉(zhuǎn)換，唯一的方法就是不直接返回這個對象，而是對這個對象進(jìn)行封裝，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 實(shí)例對象上返回給 JS，JS 拿到的是 JPBoxing 對象的指針，再傳回給 OC 時就可以通過對象成員取到原來的 NSMutableArray / NSMutableDictionary / NSMutableString 對象，類似于裝箱/拆箱操作，這樣就避免了這些對象被 JavaScriptCore 轉(zhuǎn)換。

實(shí)際上只有可變的 NSMutableArray / NSMutableDictionary / NSMutableString 這三個類有必要調(diào)用它的方法去修改對象里的數(shù)據(jù)，不可變的 NSArray / NSDictionary / NSString 是沒必要這樣做的，直接轉(zhuǎn)為 JS 對應(yīng)的類型使用起來會更方便，但為了規(guī)則簡單，JSPatch 讓 NSArray / NSDictionary / NSString 也同樣以封裝的方式返回，避免在調(diào)用 OC 方法返回對象時還需要關(guān)心它返回的是可變還是不可變對象。***整個規(guī)則還是挺清晰：NSArray / NSDictionary / NSString及其子類與其他 NSObject 對象的行為一樣，在 JS 上拿到的都只是其對象指針，可以調(diào)用它們的 OC 方法，若要把這三種對象轉(zhuǎn)為對應(yīng)的 JS 類型，使用額外的 .toJS() 的接口去轉(zhuǎn)換。

對于參數(shù)和返回值是C指針和 Class 類型的支持同樣是用 JPBoxing 封裝的方式，把指針和 Class 作為成員保存在 JPBoxing 對象上返回給 JS，傳回 OC 時再解出來拿到原來的指針和 Class，這樣 JSPatch 就支持所有數(shù)據(jù)類型 OC<->JS 的互傳了。

nil的處理

區(qū)分NSNull/nil

對于”空”的表示，JS 有 null / undefined，OC 有 nil / NSNull，JavaScriptCore 對這些參數(shù)傳遞處理是這樣的：

• 從 JS 到 OC，直接傳遞 null / undefined 到 OC 都會轉(zhuǎn)為 nil，若傳遞包含 null / undefined 的 Array給 OC，會轉(zhuǎn)為 NSNull。
• 從 OC 到 JS，nil 會轉(zhuǎn)為 null，NSNull 與普通 NSObject 一樣返回指針。

JSPatch 的流程上都是通過數(shù)組的方式把參數(shù)從 JS 傳入 OC，這樣所有的 null / undefined 到 OC 就都變成了 NSNull，而真正的 NSNull 對象傳進(jìn)來也是 NSNull，無法分辨從 JS 過來實(shí)際傳的是什么，需要有種方式區(qū)分這兩者。

考慮過在 JS 用一個特殊的對象代表 nil，null / undefined 只用來表示 NSNull，后來覺得 NSNull 是很少手動傳遞的變量，而 null / undefined 以及 OC 的 nil 卻很常見，這樣做會給日常開發(fā)帶來很大不便。于是反過來，在 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() 作為參數(shù)調(diào)用時，到 OC 后會變成 nil：

require("JPObject").testNil(require("NSNull").null())     //output: nil 

這個只需注意下用 nsnull 代替就行，從 OC 返回的 NSNull 再回傳回去還是可以識別到 NSNull。

鏈?zhǔn)秸{(diào)用

第二個問題，nil 在 JS 里用 null / undefined 表示，造成的后果是無法用 nil 調(diào)用方法，也就無法保證鏈?zhǔn)秸{(diào)用的安全：

@implementation JPObject 
+ (void)returnNil 
{ 
     return nil; 
} 
@end 
  
[[JPObject returnNil] hash]     //it’s OK 
  
require("JPObject").returnNil().hash()     //crash 

原因是在 JS 里 null / undefined 不是對象，無法調(diào)用任何方法，包括我們給所有對象加的 __c() 方法。解決方式一度覺得只有回到上面說的，用一個特殊的對象表示 nil，才能解決這個問題了。但使用特殊的對象表示 nil，后果就是在 js 判斷是否為 nil 時就要很啰嗦：

//假設(shè)用一個_nil對象變量表示OC返回的nil 
var obj = require("JPObject").returnNil() 
obj.hash()     //經(jīng)過特殊處理沒問題 
if (!obj || obj == _nil) { 
     //判斷對象是否為nil就得附加判斷是否等于_nil 
} 

這樣的使用方式難以接受，繼續(xù)尋找解決方案，發(fā)現(xiàn) true / false 在 JS 是個對象，是可以調(diào)用方法的，如果用 false 表示nil，即可以做到調(diào)用方法，又可以直接通過 if (!obj) 判斷是否為 nil，于是沿著這個方向，解決了用 false 表示 nil帶來的各種坑，幾乎***地解決了這個問題。實(shí)現(xiàn)上的細(xì)節(jié)就不多說了，說”幾乎***”，是因?yàn)檫€有一個小坑，傳遞 false給 OC 上參數(shù)類型是 NSNumber* 的方法，OC 會得到 nil 而不是 NSNumber 對象：

@implementation JPObject 
+ (void)passNSNumber:(NSNumber *)num { 
     NSLog(@"%@", num); 
} 
@end 
  
require("JPObject").passNSNumber(false) //output: nil 

如果 OC 方法的參數(shù)類型是 BOOL，或者傳入的是 true / 0，都是沒問題的，這小坑無傷大雅。

題外話，神奇的 JS 里 false 的 this 竟然不再是原來的 false，而是另一個 Boolean 對象，太特殊了：

Object.prototype.c = function(){console.log(this === false)}; 
false.c() //output false 

#p#

新增方法

在 JS 給類添加 OC 上沒有定義的方法，實(shí)現(xiàn)上有兩個變化：

1.流程

原先的做法是把新增的方法指向一個靜態(tài)的 IMP，脫離了方法替換的流程，這樣做的優(yōu)點(diǎn)是調(diào)用新增方法時不需要走 forwardInvocation的流程，提升性能，但缺點(diǎn)一是不能跟方法替換走一樣的流程，需要額外的代碼，二是參數(shù)個數(shù)有限制，由于不能用 va_list 可變參數(shù)的方式定義（詳見上篇文章），所以需要對每種參數(shù)個數(shù)都單獨(dú)定義一個方法，原來的實(shí)現(xiàn)中定義了5個方法，所以新增方法最多只能支持5個參數(shù)。權(quán)衡下，為了去除參數(shù)個數(shù)限制，***還是改成了跟替換方法一樣走 forwardInvocation 的流程。

2.Protocol

現(xiàn)在 JSPatch 已支持 Protocol，這樣在新增 Protocol 里已定義的方法時，參數(shù)類型會按照 Protocol 里的定義去實(shí)現(xiàn)，Protocol 的定義方式跟 OC 上的寫法一致：

defineClass("JPViewController: UIViewController <UIAlertViewDelegate>", { 
  alertView_clickedButtonAtIndex: function(alertView, buttonIndex) { 
    console.log(&#39;clicked index &#39; + buttonIndex) 
  } 
}) 

實(shí)現(xiàn)方式比較簡單，先把 Protocol 名解析出來，當(dāng) JS 定義的方法在原有類上找不到時，再通過 objc_getProtocol 和 protocol_copyMethodDescriptionList runtime 接口把 Protocol 對應(yīng)的方法取出來，若匹配上，則按其方法的定義走方法替換的流程。

擴(kuò)展

當(dāng)前 JSPatch 還有兩個問題：

1. JS 無法動態(tài)調(diào)用C函數(shù)，只能通過手動在代碼上給每個要調(diào)用的C函數(shù)封裝成 JS 函數(shù)，像 dispatch 幾個函數(shù)的實(shí)現(xiàn)一樣。
2. struct 類型只支持原生的 NSRange / CGRect / CGSize / CGPoint 這四個，其他 struct 類型無法在 OC / JS 間傳遞。

這兩個問題都無法一次到位全部解決，C函數(shù)需要逐個添加，struct 需要逐個手動轉(zhuǎn)為 NSDictionary，這些直接寫在 JSPatch 里是不合適的，所以需要以擴(kuò)展的形式給這些額外的需求提供支持。

擴(kuò)展接口的設(shè)計(jì)上，我設(shè)想的效果是：

1. 接口清晰
2. 每個擴(kuò)展獨(dú)立存在，互不影響
3. 不影響JPEngine的正常使用，盡量少暴露JPEngine的接口
4. 擴(kuò)展的接口可擴(kuò)展，以后有其他擴(kuò)展需求可以在其基礎(chǔ)上添加
5. 動態(tài)加載，擴(kuò)展可能會給JS全局變量添加很多接口，***能在真正使用到時才加載

最終的擴(kuò)展接口：

@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 

所有擴(kuò)展都需要繼承 JPExtension，-main: 方法會在加載擴(kuò)展的時候執(zhí)行，可以在 -main: 方法里為當(dāng)前 JSContext 添加 JS 方法，若要支持自定義的 struct 類型，需要實(shí)現(xiàn) JPExtensionProtocol 的三個 struct 相關(guān)方法（參考了Robert的實(shí)現(xiàn)），JSPatch 會在參數(shù)轉(zhuǎn)換時根據(jù) typeEncoding 向擴(kuò)展取得 struct<->NSDictionary 的互轉(zhuǎn)。所有擴(kuò)展都要繼承 JPExtension，基類提供了 OC<->JS 參數(shù)處理的幾個方法，在添加 JS 方法傳遞參數(shù)時使用。JPEngine 添加了加載擴(kuò)展的接口 +addExtensions:，其他接口沒變。

效果上基本實(shí)現(xiàn)了我的設(shè)想：

1. 接口還算清晰，struct 接口麻煩一點(diǎn)，但看過示例應(yīng)該也容易理解。
2. 每個擴(kuò)展都是獨(dú)立的，都可以添加自己想支持的 struct 類型，添加 JS 方法，互不影響
3. JPEngine 接口沒有變化，參數(shù)處理和 JPBoxing 也沒有暴露出來，都封裝在 JPExtension 的方法里。
4. 若以后有其他擴(kuò)展需求，可以直接在 JPExtension 添加。
5. 以接口 +addExtensions: 的方式添加擴(kuò)展，不但可以在 OC 上使用，還可以在 JS 上動態(tài)加載：

require("JPEngine").addExtensions(require("JPCGTransform").instance())