JSPatch 實現原理詳解

JSPatch 是一個 iOS 動態更新框架，只需在項目中引入極小的引擎，就可以使用 JavaScript 調用任何 Objective-C 原生接口，獲得腳本語言的優勢：為項目動態添加模塊，或替換項目原生代碼動態修復 bug。

之前在博客上寫過兩篇 JSPatch 原理解析文章(1 2)，但隨着 JSPatch 的改進，有些內容已經跟最新代碼對不上，這里重新整理成一篇完整的文章，對原來的兩篇做整合和修改，詳細闡述 JSPatch 的實現原理和一些細節，以幫助使用者更好地了解和使用 JSPatch。

大綱

基礎原理 方法調用 1.require 2.JS接口 i.封裝 JS 對象 ii.`__c()`元函數 3.消息傳遞 4.對象持有/轉換 5.類型轉換 方法替換 1.基礎原理 2.va_list實現(32位) 3.ForwardInvocation實現(64位) 4.新增方法 i.方案 ii.Protocol 5.Property實現 6.self關鍵字 7.super關鍵字 擴展 1.Struct 支持 2.C 函數支持 細節 1.Special Struct 2.內存問題 i.Double Release ii.內存泄露 3.‘_’的處理 4.JPBoxing 5.nil 的處理 i.區分NSNull/nil ii.鏈式調用 總結 

基礎原理

JSPatch 能做到通過 JS 調用和改寫 OC 方法最根本的原因是 Objective-C 是動態語言，OC 上所有方法的調用/類的生成都通過 Objective-C Runtime 在運行時進行，我們可以通過類名/方法名反射得到相應的類和方法：

Class class = NSClassFromString("UIViewController"); id viewController = [[class alloc] init]; SEL selector = NSSelectorFromString("viewDidLoad"); [viewController performSelector:selector];

也可以替換某個類的方法為新的實現：

static void newViewDidLoad(id slf, SEL sel) {} class_replaceMethod(class, selector, newViewDidLoad, @"");

還可以新注冊一個類，為類添加方法：

Class cls = objc_allocateClassPair(superCls, "JPObject", 0); objc_registerClassPair(cls); class_addMethod(cls, selector, implement, typedesc);

對於 Objective-C 對象模型和動態消息發送的原理已有很多文章闡述得很詳細，這里就不詳細闡述了。理論上你可以在運行時通過類名/方法名調用到任何 OC 方法，替換任何類的實現以及新增任意類。所以 JSPatch 的基本原理就是：JS 傳遞字符串給 OC，OC 通過 Runtime 接口調用和替換 OC 方法。這是最基礎的原理，實際實現過程還有很多怪要打，接下來看看具體是怎樣實現的。

方法調用

require('UIView') var view = UIView.alloc().init() view.setBackgroundColor(require('UIColor').grayColor()) view.setAlpha(0.5)

引入 JSPatch 后，可以通過以上 JS 代碼創建了一個 UIView 實例，並設置背景顏色和透明度，涵蓋了 require 引入類，JS 調用接口，消息傳遞，對象持有和轉換，參數轉換這五個方面，接下來逐一看看具體實現。

1.require

調用 require('UIView') 后，就可以直接使用 UIView 這個變量去調用相應的類方法了，require 做的事很簡單，就是在JS全局作用域上創建一個同名變量，變量指向一個對象，對象屬性__clsName 保存類名，同時表明這個對象是一個 OC Class。

var _require = function(clsName) { if (!global[clsName]) { global[clsName] = { __clsName: clsName } } return global[clsName] }

所以調用 require('UIView') 后，就在全局作用域生成了 UIView 這個變量，指向一個這樣一個對象：

{
  __clsName: "UIView" }

2.JS接口

接下來看看 UIView.alloc() 是怎樣調用的。

i.封裝 JS 對象

對於這個調用的實現，一開始我的想法是，根據JS特性，若要讓 UIView.alloc() 這句調用不出錯，唯一的方法就是給 UIView 這個對象添加 alloc 方法，不然是不可能調用成功的，JS 對於調用沒定義的屬性/變量，只會馬上拋出異常，而不像 OC/Lua/ruby 那樣會有轉發機制。所以做了一個復雜的事，就是在require生成類對象時，把類名傳入OC，OC 通過runtime方法找出這個類所有的方法返回給 JS，JS 類對象為每個方法名都生成一個函數，函數內容就是拿着方法名去 OC 調用相應方法。生成的 UIView 對象大致是這樣的：

{
    __clsName: "UIView", alloc: function() {…}, beginAnimations_context: function() {…}, setAnimationsEnabled: function(){…}, ... }

實際上不僅要遍歷當前類的所有方法，還要循環找父類的方法直到頂層，整個繼承鏈上的所有方法都要加到JS對象上，一個類就有幾百個方法，這樣把方法全部加到 JS 對象上，碰到了挺嚴重的問題，引入幾個類就內存暴漲，無法使用。后來為了優化內存問題還在 JS 搞了繼承關系，不把繼承鏈上所有方法都添加到一個JS對象，避免像基類 NSObject 的幾百個方法反復添加在每個 JS 對象上，每個方法只存在一份，JS 對象復制了 OC 對象的繼承關系，找方法時沿着繼承鏈往上找，結果內存消耗是小了一些，但還是大到難以接受。

ii.__c()元函數

當時繼續苦苦尋找解決方案，若按 JS 語法，這是唯一的方法，但若不按 JS 語法呢？突然腦洞開了下，CoffieScript/JSX 都可以用 JS 實現一個解釋器實現自己的語法，我也可以通過類似的方式做到，再進一步想到其實我想要的效果很簡單，就是調用一個不存在方法時，能轉發到一個指定函數去執行，就能解決一切問題了，這其實可以用簡單的字符串替換，把 JS 腳本里的方法調用都替換掉。最后的解決方案是，在 OC 執行 JS 腳本前，通過正則把所有方法調用都改成調用 __c() 函數，再執行這個 JS 腳本，做到了類似 OC/Lua/Ruby 等的消息轉發機制：

UIView.alloc().init() -> UIView.__c('alloc')().__c('init')()

給 JS 對象基類 Object 加上 __c 成員，這樣所有對象都可以調用到 __c，根據當前對象類型判斷進行不同操作：

Object.defineProperty(Object.prototype, '__c', {value: function(methodName) { if (!this.__obj && !this.__clsName) return this[methodName].bind(this); var self = this return function(){ var args = Array.prototype.slice.call(arguments) return _methodFunc(self.__obj, self.__clsName, methodName, args, self.__isSuper) } }})

_methodFunc() 就是把相關信息傳給OC，OC用 Runtime 接口調用相應方法，返回結果值，這個調用就結束了。

這樣做不用去 OC 遍歷對象方法，不用在 JS 對象保存這些方法，內存消耗直降 99%，這一步是做這個項目最爽的時候，用一個非常簡單的方法解決了嚴重的問題，替換之前又復雜效果又差的實現。

3.消息傳遞

解決了 JS 接口問題，接下來看看 JS 和 OC 是怎樣互傳消息的。這里用到了 JavaScriptCore 的接口，OC 端在啟動 JSPatch 引擎時會創建一個 JSContext 實例，JSContext 是 JS 代碼的執行環境，可以給 JSContext 添加方法，JS 就可以直接調用這個方法：

JSContext *context = [[JSContext alloc] init]; context[@"hello"] = ^(NSString *msg) { NSLog(@"hello %@", msg); }; [_context evaluateScript:@"hello('word')"]; //output hello word 

JS 通過調用 JSContext 定義的方法把數據傳給 OC，OC 通過返回值傳會給 JS。調用這種方法，它的參數/返回值 JavaScriptCore 都會自動轉換，OC 里的 NSArray, NSDictionary, NSString, NSNumber, NSBlock 會分別轉為JS端的數組/對象/字符串/數字/函數類型。上述 _methodFunc 方法就是這樣把要調用的類名和方法名傳遞給 OC 的。

4.對象持有/轉換

結合上述幾點，可以知道 UIView.alloc() 這個類方法調用語句是怎樣執行的：

a.require('UIView') 這句話在 JS 全局作用域生成了 UIView 這個對象，它有個屬性叫__isCls，表示這代表一個 OC 類。 b.調用 UIView 這個對象的 alloc() 方法，會去到 __c()函數，在這個函數里判斷到調用者 __isCls 屬性，知道它是代表 OC 類，把方法名和類名傳遞給 OC 完成調用。

調用類方法過程是這樣，那實例方法呢？UIView.alloc() 會返回一個 UIView 實例對象給 JS，這個 OC 實例對象在 JS 是怎樣表示的？怎樣可以在 JS 拿到這個實例對象后可以直接調用它的實例方法 UIView.alloc().init()？

對於一個自定義id對象，JavaScriptCore 會把這個自定義對象的指針傳給 JS，這個對象在 JS 無法使用，但在回傳給 OC 時 OC 可以找到這個對象。對於這個對象生命周期的管理，按我的理解如果JS有變量引用時，這個 OC 對象引用計數就加1 ，JS 變量的引用釋放了就減1，如果 OC 上沒別的持有者，這個OC對象的生命周期就跟着 JS 走了，會在 JS 進行垃圾回收時釋放。

傳回給 JS 的變量是這個 OC 對象的指針，這個指針也可以重新傳回 OC，要在 JS 調用這個對象的某個實例方法，根據第2點 JS 接口的描述，只需在 __c() 函數里把這個對象指針以及它要調用的方法名傳回給 OC 就行了，現在問題只剩下：怎樣在 __c() 函數里判斷調用者是一個 OC 對象指針？

目前沒找到方法判斷一個 JS 對象是否表示 OC 指針，這里的解決方法是在 OC 把對象返回給 JS 之前，先把它包裝成一個 NSDictionary：

static NSDictionary *_wrapObj(id obj) { return @{@"__obj": obj}; }

讓 OC 對象作為這個 NSDictionary 的一個值，這樣在 JS 里這個對象就變成：

{__obj: [OC Object 對象指針]}

這樣就可以通過判斷對象是否有 __obj 屬性得知這個對象是否表示 OC 對象指針，在 __c 函數里若判斷到調用者有 __obj 屬性，取出這個屬性，跟調用的實例方法一起傳回給 OC，就完成了實例方法的調用。

5.類型轉換

JS 把要調用的類名/方法名/對象傳給 OC 后，OC 調用類/對象相應的方法是通過 NSInvocation 實現，要能順利調用到方法並取得返回值，要做兩件事：

a.取得要調用的 OC 方法各參數類型，把 JS 傳來的對象轉為要求的類型進行調用。 b.根據返回值類型取出返回值，包裝為對象傳回給 JS。

例如開頭例子的 view.setAlpha(0.5)， JS傳遞給OC的是一個 NSNumber，OC 需要通過要調用 OC 方法的 NSMethodSignature 得知這里參數要的是一個 float 類型值，於是把 NSNumber 轉為 float 值再作為參數進行 OC 方法調用。這里主要處理了 int/float/bool 等數值類型，並對 CGRect/CGRange 等類型進行了特殊轉換處理，剩下的就是實現細節了。

方法替換

JSPatch 可以用 defineClass 接口任意替換一個類的方法，方法替換的實現過程也是頗為曲折，一開始是用 va_list 的方式獲取參數，結果發現 arm64 下不可用，只能轉而用另一種 hack 方式繞道實現。另外在給類新增方法、實現property、支持self/super關鍵字上也費了些功夫，下面逐個說明。

1.基礎原理

OC上，每個類都是這樣一個結構體：

struct objc_class { struct objc_class * isa; const char *name; …. struct objc_method_list **methodLists; /*方法鏈表*/ };

其中 methodList 方法鏈表里存儲的是 Method 類型：

typedef struct objc_method *Method; typedef struct objc_ method { SEL method_name; char *method_types; IMP method_imp; };

Method 保存了一個方法的全部信息，包括 SEL 方法名，type 各參數和返回值類型，IMP 該方法具體實現的函數指針。

通過 Selector 調用方法時，會從 methodList 鏈表里找到對應Method進行調用，這個 methodList 上的的元素是可以動態替換的，可以把某個 Selector 對應的函數指針IMP替換成新的，也可以拿到已有的某個 Selector 對應的函數指針IMP，讓另一個 Selector 跟它對應，Runtime 提供了一些接口做這些事，以替換 UIViewController 的 -viewDidLoad: 方法為例：

static void viewDidLoadIMP (id slf, SEL sel) { JSValue *jsFunction = …; [jsFunction callWithArguments:nil]; } Class cls = NSClassFromString(@"UIViewController"); SEL selector = @selector(viewDidLoad); Method method = class_getInstanceMethod(cls, selector); //獲得viewDidLoad方法的函數指針 IMP imp = method_getImplementation(method) //獲得viewDidLoad方法的參數類型 char *typeDescription = (char *)method_getTypeEncoding(method); //新增一個ORIGViewDidLoad方法，指向原來的viewDidLoad實現 class_addMethod(cls, @selector(ORIGViewDidLoad), imp, typeDescription); //把viewDidLoad IMP指向自定義新的實現 class_replaceMethod(cls, selector, viewDidLoadIMP, typeDescription);

這樣就把 UIViewController 的 -viewDidLoad 方法給替換成我們自定義的方法，APP里調用 UIViewController 的 viewDidLoad 方法都會去到上述 viewDidLoadIMP 函數里，在這個新的IMP函數里調用 JS 傳進來的方法，就實現了替換 viewDidLoad 方法為JS代碼里的實現，同時為 UIViewController 新增了個方法 -ORIGViewDidLoad 指向原來 viewDidLoad 的 IMP，JS 可以通過這個方法調用到原來的實現。

方法替換就這樣很簡單的實現了，但這么簡單的前提是，這個方法沒有參數。如果這個方法有參數，怎樣把參數值傳給我們新的 IMP 函數呢？例如 UIViewController 的 -viewDidAppear: 方法，調用者會傳一個 Bool 值，我們需要在自己實現的IMP（上述的 viewDidLoadIMP）上拿到這個值，怎樣能拿到？如果只是針對一個方法寫 IMP，是可以直接拿到這個參數值的：

static void viewDidAppear (id slf, SEL sel, BOOL animated) { [function callWithArguments:@(animated)]; }

但我們要的是實現一個通用的IMP，任意方法任意參數都可以通過這個IMP中轉，拿到方法的所有參數回調JS的實現。

2.va_list實現(32位)

最初我是用可變參數 va_list 實現：

static void commonIMP(id slf, ...) va_list args; va_start(args, slf); NSMutableArray *list = [[NSMutableArray alloc] init]; NSMethodSignature *methodSignature = [cls instanceMethodSignatureForSelector:selector]; NSUInteger numberOfArguments = methodSignature.numberOfArguments; id obj; for (NSUInteger i = 2; i < numberOfArguments; i++) { const char *argumentType = [methodSignature getArgumentTypeAtIndex:i]; switch(argumentType[0]) { case 'i': obj = @(va_arg(args, int)); break; case 'B': obj = @(va_arg(args, BOOL)); break; case 'f': case 'd': obj = @(va_arg(args, double)); break; …… //其他數值類型 default: { obj = va_arg(args, id); break; } } [list addObject:obj]; } va_end(args); [function callWithArguments:list]; }

這樣無論方法參數是什么，有多少個，都可以通過 va_list的一組方法一個個取出來，組成 NSArray 在調用 JS 方法時傳回。很完美地解決了參數的問題，一直運行正常，直到我跑在 arm64 的機子上測試，一調用就 crash。查了資料，才發現 arm64 下 va_list 的結構改變了，導致無法上述這樣取參數。詳見這篇文章。

3.ForwardInvocation實現(64位)

繼續尋找解決方案，最后找到另一種非常 hack 的方法解決參數獲取的問題，利用了 OC 消息轉發機制。

當調用一個 NSObject 對象不存在的方法時，並不會馬上拋出異常，而是會經過多層轉發，層層調用對象的 -resolveInstanceMethod:, -forwardingTargetForSelector:, -methodSignatureForSelector:, -forwardInvocation: 等方法，其中最后 -forwardInvocation: 是會有一個 NSInvocation 對象，這個 NSInvocation 對象保存了這個方法調用的所有信息，包括 Selector 名，參數和返回值類型，最重要的是有所有參數值，可以從這個 NSInvocation 對象里拿到調用的所有參數值。我們可以想辦法讓每個需要被 JS 替換的方法調用最后都調到 -forwardInvocation:，就可以解決無法拿到參數值的問題了。

具體實現，以替換 UIViewController 的 -viewWillAppear: 方法為例：

1. 把UIViewController的 -viewWillAppear: 方法通過 class_replaceMethod() 接口指向_objc_msgForward，這是一個全局 IMP，OC 調用方法不存在時都會轉發到這個 IMP 上，這里直接把方法替換成這個 IMP，這樣調用這個方法時就會走到 -forwardInvocation:。

2. 為UIViewController添加 -ORIGviewWillAppear: 和 -_JPviewWillAppear: 兩個方法，前者指向原來的IMP實現，后者是新的實現，稍后會在這個實現里回調JS函數。

3. 改寫UIViewController的 -forwardInvocation: 方法為自定義實現。一旦OC里調用 UIViewController 的 -viewWillAppear: 方法，經過上面的處理會把這個調用轉發到 -forwardInvocation: ，這時已經組裝好了一個 NSInvocation，包含了這個調用的參數。在這里把參數從 NSInvocation 反解出來，帶着參數調用上述新增加的方法 -JPviewWillAppear:，在這個新方法里取到參數傳給JS，調用JS的實現函數。整個調用過程就結束了，整個過程圖示如下：

最后一個問題，我們把 UIViewController 的 -forwardInvocation: 方法的實現給替換掉了，如果程序里真有用到這個方法對消息進行轉發，原來的邏輯怎么辦？首先我們在替換 -forwardInvocation: 方法前會新建一個方法 -ORIGforwardInvocation:，保存原來的實現IMP，在新的 -forwardInvocation: 實現里做了個判斷，如果轉發的方法是我們想改寫的，就走我們的邏輯，若不是，就調 -ORIGforwardInvocation: 走原來的流程。

其他就是實現上的細節了，例如需要根據不同的返回值類型生成不同的 IMP，要在各處處理參數轉換等。

4.新增方法

i.方案

在 JSPatch 剛開源時，是不支持為一個類新增方法的，因為覺得能替換原生方法就夠了，新的方法純粹添加在 JS 對象上，只在 JS 端跑就行了。另外 OC 為類新增方法需要知道各個參數和返回值的類型，需要在 JS 定一種方式把這些類型傳給 OC 才能完成新增方法，比較麻煩。后來挺多人比較關注這個問題，不能新增方法導致 action-target 模式無法用，我也開始想有沒有更好的方法實現添加方法。后來的解決方案是所有類型都用 id 表示，因為反正新增的方法都是 JS 在用(Protocol定義的方法除外)，不如新增的方法返回值和參數全統一成 id 類型，這樣就不用傳類型了。

現在 defineClass 定義的方法會經過 JS 包裝，變成一個包含參數個數和方法實體的數組傳給OC，OC會判斷如果方法已存在，就執行替換的操作，若不存在，就調用 class_addMethod() 新增一個方法，通過傳過來的參數個數和方法實體生成新的 Method，把 Method 的參數和返回值類型都設為id。這里 JS 調用新增方法走的流程還是 forwardInvocation 這一套。

ii.Protocol

對於新增的方法還有個問題，若某個類實現了某 protocol，protocol方法里有可選的方法，它的參數不全是 id 類型，例如 UITableViewDataSource 的一個方法：

- (NSInteger)tableView:(UITableView *)tableView sectionForSectionIndexTitle:(NSString *)title atIndex:(NSInteger)index;

若原類沒有實現這個方法，在 JS 里實現了，會走到新增方法的邏輯，每個參數類型都變成 id，與這個 protocol 方法不匹配，產生錯誤。

這里就需要在 JS 定義類時給出實現的 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 對應的方法取出來，若匹配上，則按其方法的定義走方法替換的流程。

5.Property實現

若要在 JS 操作 OC 對象上已定義好的 property，只需要像調用普通 OC 方法一樣，調用這個對象的 get/set 方法就行了：

//OC
@property (nonatomic) NSString *data; @property (nonatomic) BOOL *succ;

//JS self.setSucc(1); var str = self.data(); 

若要動態給 OC 對象新增 property，則要另辟蹊徑：

defineClass('JPTableViewController : UITableViewController', { dataSource: function() { var data = self.getProp('data') if (data) return data; data = [1,2,3] self.setProp_forKey(data, 'data') return data; } }

JSPatch可以通過 -getProp:， -setProp:forKey: 這兩個方法給對象動態添加成員變量。實現上用了運行時關聯接口 objc_getAssociatedObject() 和 objc_setAssociatedObject() 模擬，相當於把一個對象跟當前對象self關聯起來，以后可以通過當前對象self找到這個對象，跟成員的效果一樣，只是一定得是id對象類型。

本來OC有 class_addIvar() 可以為類添加成員，但必須在類注冊之前添加完，注冊完成后無法添加，這意味着可以為在JS新增的類添加成員，但不能為OC上已存在的類添加，所以只能用上述方法模擬。

6.self關鍵字

defineClass("JPViewController: UIViewController", { viewDidLoad: function() { var view = self.view() ... }, }

JSPatch支持直接在defineClass里的實例方法里直接使用 self 關鍵字，跟OC一樣 self 是指當前對象，這個 self 關鍵字是怎樣實現的呢？實際上這個self是個全局變量，在 defineClass 里對實例方法進行了包裝，在調用實例方法之前，會把全局變量 self 設為當前對象，調用完后設回空，就可以在執行實例方法的過程中使用 self 變量了。這是一個小小的trick。

7.super關鍵字

defineClass("JPViewController: UIViewController", { viewDidLoad: function() { self.super().viewDidLoad() }, }

OC 里 super 是一個關鍵字，無法通過動態方法拿到 super，那么 JSPatch 的 super 是怎么實現的？實際上調用 super 的方法，OC 做的事是調用父類的某個方法，並把當前對象當成 self 傳入父類方法，我們只要模擬它這個過程就行了。

首先 JS 端需要告訴OC想調用的是當前對象的 super 方法，做法是調用 self.super()時，__c函數會做特殊處理，返回一個新的對象，這個對象同樣保存了 OC 對象的引用，同時標識__isSuper = 1。

...
if (methodName == 'super') { return function() { return {__obj: self.__obj, __clsName: self.__clsName, __isSuper: 1} } } ...

再用這個返回的對象去調用方法時，__c 函數會把 __isSuper 這個標識位傳給 OC，告訴 OC 要調 super 的方法。OC 做的事情是，如果是調用 super 方法，找到 superClass 這個方法的 IMP 實現，為當前類新增一個方法指向 super 的 IMP 實現，那么調用這個類的新方法就相當於調用 super 方法。把要調用的方法替換成這個新方法，就完成 super 方法的調用了。

static id callSelector(NSString *className, NSString *selectorName, NSArray *arguments, id instance, BOOL isSuper) { ... if (isSuper) { NSString *superSelectorName = [NSString stringWithFormat:@"SUPER_%@", selectorName]; SEL superSelector = NSSelectorFromString(superSelectorName); Class superCls = [cls superclass]; Method superMethod = class_getInstanceMethod(superCls, selector); IMP superIMP = method_getImplementation(superMethod); class_addMethod(cls, superSelector, superIMP, method_getTypeEncoding(superMethod)); selector = superSelector; } ... }

擴展

1.Struct 支持

struct 類型在 JS 與 OC 間傳遞需要做轉換處理，一開始 JSPatch 只處理了原生的 NSRange / CGRect / CGSize / CGPoint 這四個，其他 struct 類型無法在 OC / JS 間傳遞。對於其他類型的 struct 支持，我是采用擴展的方式，讓寫擴展的人手動處理每個要支持的 struct 進行類型轉換，這種做法沒問題，但需要在 OC 代碼寫好這些擴展，無法動態添加，轉換的實現也比較繁瑣。於是轉為另一種實現：

/*
struct JPDemoStruct {  CGFloat a;  long b;  double c;  BOOL d; } */ require('JPEngine').defineStruct({ "name": "JPDemoStruct", "types": "FldB", "keys": ["a", "b", "c", "d"] })

可以在 JS 動態定義一個新的 struct，只需提供 struct 名，每個字段的類型以及每個字段對應的在 JS 的鍵值，就可以支持這個 struct 類型在 JS 和 OC 間傳遞了：

//OC @implementation JPObject + (void)passStruct:(JPDemoStruct)s; + (JPDemoStruct)returnStruct; @end 

//JS require('JPObject').passStruct({a:1, b:2, c:4.2, d:1}) var s = require('JPObject').returnStruct(); 

這里的實現原理是順序去取 struct 里每個字段的值，再根據 key 重新包裝成 NSDictionary 傳給 JS，怎樣順序取 struct 每字段的值呢？可以根據傳進來的 struct 字段的變量類型，拿到類型對應的長度，順序拷貝出 struct 對應位置和長度的值，具體實現：

for (int i = 0; i < types.count; i ++) { size_t size = sizeof(types[i]); //types[i] 是 float double int 等類型 void *val = malloc(size); memcpy(val, structData + position, size); position += size; }

struct 從 JS 到 OC 的轉換同理，只是反過來，先生成整個 struct 大小的內存地址（通過 struct 所有字段類型大小累加），再逐漸取出 JS 傳過來的值進行類型轉換拷貝到這端內存里。

這種做法效果很好，JS 端要用一個新的 struct 類型，不需要 OC 事先定義好，可以直接動態添加新的 struct 類型支持，但這種方法依賴 struct 各個字段在內存空間上的嚴格排列，如果某些機器在底層實現上對 struct 的字段進行一些字節對齊之類的處理，這種方式沒法用了，不過目前在 iOS 上還沒碰到這樣的問題。

2.C 函數支持

C 函數沒法通過反射去調用，所以只能通過手動轉接的方式讓 JS 調 C 方法，具體就是通過 JavaScriptCore 的方法在 JS 當前作用域上定義一個 C 函數同名方法，在這個方法實現里調用 C 函數，以支持 memcpy() 為例：

context[@"memcpy"] = ^(JSValue *des, JSValue *src, size_t n) { memcpy(des, src, n); };

這樣就可以在 JS 調用 memcpy() 函數了。實際上這里還有參數 JS <-> OC 轉換問題，這里先忽略。

這里有兩個問題：

a.如果這些 C 函數的支持都寫在 JSPatch 源文件里，源文件會非常龐大。 b.如果一開始就給 JS 加這些函數定義，若要支持的 C 函數量大時會影響性能。

對此設計了一種擴展的方式去解決這兩個問題，JSPatch 需要做的就是為外部提供 JS 運行上下文 JSContext，以及參數轉換的方法，最終設計出來的擴展接口是這樣：

@interface JPExtension : NSObject + (void)main:(JSContext *)context; + (void *)formatPointerJSToOC:(JSValue *)val; + (id)formatPointerOCToJS:(void *)pointer; + (id)formatJSToOC:(JSValue *)val; + (id)formatOCToJS:(id)obj; @end

+main 方法暴露了 JSPatch 的運行環境 JSContext 給外部，可以自由在這個 JSContext 上加函數。另外四個 formatXXX 方法都是參數轉換方法。上述的 memcpy() 完整的擴展定義如下：

@implementation JPMemory + (void)main:(JSContext *)context { context[@"memcpy"] = ^id(JSValue *des, JSValue *src, size_t n) { void *ret = memcpy([self formatPointerJSToOC:des], [self formatPointerJSToOC:src], n); return [self formatPointerOCToJS:ret]; }; } @end

同時 JSPatch 提供了 +addExtensions: 接口，讓 JS 端可以動態加載某個擴展，在需要的時候再給 JS 上下文添加這些 C 函數：

require('JPEngine').addExtensions(['JPMemory'])

實際上還有另一種方法添加 C 函數的支持，就是定義 OC 方法轉接：

@implementation JPCFunctions + (void)memcpy:(void *)des src:(void *)src n:(size_t)n { memcpy(des, src, n); } @end

然后直接在 JS 上這樣調：

require('JPFunctions').memcpy_src_n(des, src, n);

這樣的做法不需要擴展機制，也不需要在實現時進行參數轉換，但因為它走的是 OC runtime 那一套，相比擴展直接調用的方式，速度慢了一倍，為了更好的性能，還是提供一套擴展接口。

細節

整個 JSPatch 的基礎原理上面大致闡述完了，接下來在看看一些實現上碰到的坑和的細節問題。

1.Special Struct

上文提到會把要覆蓋的方法指向_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。

2.內存問題

i.Double Release

實現過程中碰到一些內存問題，首先是 Double Release 問題。從 -forwardInvocation: 里的 NSInvocation 對象取參數值時，若參數值是id類型，我們會這樣取:

id arg;
[invocation getArgument:&arg atIndex:i];

但這樣的寫法會導致 crash，這是因為 id arg 在ARC下相當於 __strong id arg，若這時在代碼顯式為 arg 賦值，根據 ARC 的機制，會自動插入一條 retain 語句，然后在退出作用域時插入 release 語句：

- (void)method { id arg = [SomeClass getSomething]; // [arg retain] ... // [arg release] 退出作用域前release }

但我們這里不是顯式對 arg 進行賦值，而是傳入 -getArgument:atIndex: 方法，在這里面賦值后 ARC 沒有自動給這個變量插入 retain 語句，但退出作用域時還是自動插入了 release 語句，導致這個變量多釋放了一次，導致 crash。解決方法是把 arg 變量設成 __unsafe_unretained 或 __weak，讓 ARC 不在它退出作用域時插入 release 語句即可：

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

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

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

ii.內存泄露

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; }

這是因為 ARC 對方法名有約定，當方法名開頭是 alloc / new / copy / mutableCopy 時，返回的對象是 retainCount = 1 的，除此之外，方法返回的對象都是 autorelease 的，按上一節的說法，對於普通方法返回值，ARC 會在賦給 strong 變量時自動插入 retain 語句，但對於 alloc 等這些方法，不會再自動插入 retain 語句：

id obj = [SomeObject alloc]; //alloc 方法返回的對象 retainCount 已 +1，這里不需要retain id obj2 = [SomeObj someMethod]; //方法返回的對象是 autorelease，ARC 會再這里自動插入 [obj2 retain] 語句

而 ARC 並沒有處理非顯示調用時的情況，這里動態調用這些方法時，ARC 都不會自動插入 retain，這種情況下，alloc / new 等這類方法返回值的 retainCount 是會比其他方法返回值多1的，所以需要特殊處理這類方法。

3.‘_’的處理

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

4.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 的互傳了。

5.nil的處理

i.區分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。

ii.鏈式調用

第二個問題，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 

有人做出了解釋 #351

總結

JSPatch 的原理以及一些實現細節就闡述到這里，希望這篇文章對大家了解和使用 JSPatch 有幫助。

 

出處：https://github.com/bang590/JSPatch/wiki/JSPatch-%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86%E8%AF%A6%E8%A7%A3