JSPatch 實現原理詳解 (整改版)

NO IMAGE

JSPatch 是一個 iOS 動態更新框架,只需在專案中引入極小的引擎,就可以使用就可以使用 JavaScript 呼叫任何 Objective-C 原生介面,獲得指令碼語言的優勢:為專案動態新增模組,或替換專案原生程式碼動態修復 bug。

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

基礎原理

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全域性作用域上建立一個同名變數,變數指向一個物件,物件屬性__isCls表明這是一個Class,__clsName儲存類名,在呼叫方法時會用到這兩個屬性。

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

所以呼叫 require('UIView') 後,就在全域性作用域生成了 UIView 這個變數,指向一個這樣一個物件:

{
__isCls: 1,
__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 物件大致是這樣的:

{
__isCls: 1,
__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 的 prototype 加上 __c 成員,這樣所有物件都可以呼叫到 __c,根據當前物件型別判斷進行不同操作:

Object.prototype.__c = 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;
}
}
; } va_end(args); [function callWithArguments:list]; }

這樣無論方法引數是什麼,有多少個,都可以通過 va_list的一組方法一個個取出來,組成 NSArray 在呼叫 JS 方法時傳回。很完美地解決了引數的問題,一直執行正常,直到我跑在 arm64 的機子上測試,一呼叫就 crash。查了資料,才發現 arm64 下 va_list 的結構改變了,導致無法上述這樣取引數。詳見這篇文章:https://blog.nelhage.com/2010…

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的實現函式。整個呼叫過程就結束了,整個過程圖示如下:

JSPatch方法替換

最後一個問題,我們把 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_getProtocolprotocol_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_stretobjc_msgSend 區別的文章:http://sealiesoftware.com/blo…),說得比較清楚,原理是一樣的,是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)

NSMethodSignaturedebugDescription 上打出了是否 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 / undefinedOC 都會轉為 nil,若傳遞包含 null / undefinedArray 給 OC,會轉為 NSNull

  • 從 OC 到 JS,nil 會轉為 nullNSNull 與普通 NSObject 一樣返回指標。

JSPatch 的流程上都是通過陣列的方式把引數從 JS 傳入 OC,這樣所有的 null / undefined 到 OC 就都變成了 NSNull,而真正的 NSNull 物件傳進來也是 NSNull,無法分辨從 JS 過來實際傳的是什麼,需要有種方式區分這兩者。

考慮過在 JS 用一個特殊的物件代表 nilnull / undefined 只用來表示 NSNull,後來覺得 NSNull 是很少手動傳遞的變數,而 null / undefined 以及 OC 的 nil 卻很常見,這樣做會給日常開發帶來很大不便。於是反過來,在 JS 用一個特殊變數 nsnull 表示 NSNull,其他 null / undefined 表示 nil,這樣傳入 OC 就可以分辨出 nilNSNull,具體使用方式:

@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 裡 falsethis 竟然不再是原來的 false,而是另一個 Boolean 物件,太特殊了:

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

總結

JSPatch 的原理以及一些實現細節就闡述到這裡,希望這篇文章對大家瞭解和使用 JSPatch 有幫助。接入 JSPatch 可以使用 JSPatch 平臺: jspatch.com