JSPatch 是一個 iOS 動態更新框架,只需在項目中引入極小的引擎,就可使用就可使用 JavaScript 調用任何 Objective-C 原生接口,得到腳本語言的優點:爲項目動態添加模塊,或替換項目原生代碼動態修復 bug。html
以前在博客上寫過兩篇 JSPatch 原理解析文章(1 2),但隨着 JSPatch 的改進,有些內容已經跟最新代碼對不上,這裏從新整理成一篇完整的文章,對原來的兩篇作整合和修改,詳細闡述 JSPatch 的實現原理和一些細節,以幫助使用者更好地瞭解和使用 JSPatch。git
JSPatch 能作到經過 JS 調用和改寫 OC 方法最根本的緣由是 Objective-C 是動態語言,OC 上全部方法的調用/類的生成都經過 Objective-C Runtime 在運行時進行,咱們能夠經過類名/方法名反射獲得相應的類和方法:github
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 方法。這是最基礎的原理,實際實現過程還有不少怪要打,接下來看看具體是怎樣實現的。ruby
require('UIView') var view = UIView.alloc().init() view.setBackgroundColor(require('UIColor').grayColor()) view.setAlpha(0.5)
引入 JSPatch 後,能夠經過以上 JS 代碼建立了一個 UIView 實例,並設置背景顏色和透明度,涵蓋了 require 引入類,JS 調用接口,消息傳遞,對象持有和轉換,參數轉換這五個方面,接下來逐一看看具體實現。架構
調用 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
這個變量,指向一個這樣一個對象:jsp
{ __isCls: 1, __clsName: "UIView" }
接下來看看 UIView.alloc()
是怎樣調用的。函數
對於這個調用的實現,一開始個人想法是,根據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 對象的繼承關係,找方法時沿着繼承鏈往上找,結果內存消耗是小了一些,但仍是大到難以接受。
__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%,這一步是作這個項目最爽的時候,用一個很是簡單的方法解決了嚴重的問題,替換以前又複雜效果又差的實現。
解決了 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 的。
結合上述幾點,能夠知道 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,就完成了實例方法的調用。
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關鍵字上也費了些功夫,下面逐個說明。
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的實現。
最初我是用可變參數 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
的結構改變了,致使沒法上述這樣取參數。詳見這篇文章:https://blog.nelhage.com/2010...。
繼續尋找解決方案,最後找到另外一種很是 hack 的方法解決參數獲取的問題,利用了 OC 消息轉發機制。
當調用一個 NSObject 對象不存在的方法時,並不會立刻拋出異常,而是會通過多層轉發,層層調用對象的 -resolveInstanceMethod:
, -forwardingTargetForSelector:
, -methodSignatureForSelector:
, -forwardInvocation:
等方法,其中最後 -forwardInvocation:
是會有一個 NSInvocation 對象,這個 NSInvocation 對象保存了這個方法調用的全部信息,包括 Selector 名,參數和返回值類型,最重要的是有全部參數值,能夠從這個 NSInvocation 對象裏拿到調用的全部參數值。咱們能夠想辦法讓每一個須要被 JS 替換的方法調用最後都調到 -forwardInvocation:
,就能夠解決沒法拿到參數值的問題了。
具體實現,以替換 UIViewController 的 -viewWillAppear: 方法爲例:
把UIViewController的 -viewWillAppear:
方法經過 class_replaceMethod()
接口指向 _objc_msgForward
,這是一個全局 IMP,OC 調用方法不存在時都會轉發到這個 IMP 上,這裏直接把方法替換成這個 IMP,這樣調用這個方法時就會走到 -forwardInvocation:
。
爲UIViewController添加 -ORIGviewWillAppear:
和 -_JPviewWillAppear:
兩個方法,前者指向原來的IMP實現,後者是新的實現,稍後會在這個實現裏回調JS函數。
改寫UIViewController的 -forwardInvocation:
方法爲自定義實現。一旦OC裏調用 UIViewController 的 -viewWillAppear:
方法,通過上面的處理會把這個調用轉發到 -forwardInvocation:
,這時已經組裝好了一個 NSInvocation,包含了這個調用的參數。在這裏把參數從 NSInvocation 反解出來,帶着參數調用上述新增長的方法 -JPviewWillAppear:
,在這個新方法裏取到參數傳給JS,調用JS的實現函數。整個調用過程就結束了,整個過程圖示以下:
最後一個問題,咱們把 UIViewController 的 -forwardInvocation:
方法的實現給替換掉了,若是程序裏真有用到這個方法對消息進行轉發,原來的邏輯怎麼辦?首先咱們在替換 -forwardInvocation:
方法前會新建一個方法 -ORIGforwardInvocation:
,保存原來的實現IMP,在新的 -forwardInvocation:
實現裏作了個判斷,若是轉發的方法是咱們想改寫的,就走咱們的邏輯,若不是,就調 -ORIGforwardInvocation:
走原來的流程。
其餘就是實現上的細節了,例如須要根據不一樣的返回值類型生成不一樣的 IMP,要在各到處理參數轉換等。
在 JSPatch 剛開源時,是不支持爲一個類新增方法的,由於以爲能替換原生方法就夠了,新的方法純粹添加在 JS 對象上,只在 JS 端跑就好了。另外 OC 爲類新增方法須要知道各個參數和返回值的類型,須要在 JS 定一種方式把這些類型傳給 OC 才能完成新增方法,比較麻煩。後來挺多人比較關注這個問題,不能新增方法致使 action-target 模式沒法用,我也開始想有沒有更好的方法實現添加方法。後來的解決方案是全部類型都用 id 表示,由於反正新增的方法都是 JS 在用(Protocol定義的方法除外),不如新增的方法返回值和參數全統一成 id 類型,這樣就不用傳類型了。
如今 defineClass
定義的方法會通過 JS 包裝,變成一個包含參數個數和方法實體的數組傳給OC,OC會判斷若是方法已存在,就執行替換的操做,若不存在,就調用 class_addMethod()
新增一個方法,經過傳過來的參數個數和方法實體生成新的 Method,把 Method 的參數和返回值類型都設爲id。這裏 JS 調用新增方法走的流程仍是 forwardInvocation
這一套。
對於新增的方法還有個問題,若某個類實現了某 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 對應的方法取出來,若匹配上,則按其方法的定義走方法替換的流程。
若要在 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上已存在的類添加,因此只能用上述方法模擬。
defineClass("JPViewController: UIViewController", { viewDidLoad: function() { var view = self.view() ... }, }
JSPatch支持直接在defineClass裏的實例方法裏直接使用 self 關鍵字,跟OC同樣 self 是指當前對象,這個 self 關鍵字是怎樣實現的呢?實際上這個self是個全局變量,在 defineClass 裏對實例方法 方法進行了包裝,在調用實例方法以前,會把全局變量 self 設爲當前對象,調用完後設回空,就能夠在執行實例方法的過程當中使用 self 變量了。這是一個小小的trick。
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; } ... }
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 上還沒碰到這樣的問題。
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 的基礎原理上面大體闡述完了,接下來在看看一些實現上碰到的坑和的細節問題。
上文提到會把要覆蓋的方法指向_objc_msgForward
,進行轉發操做,這裏出現一個問題,若是替換方法的返回值是某些 struct,使用 _objc_msgForward
(或者以前的 @selector(__JPNONImplementSelector)
)會 crash。幾經展轉,找到了解決方法:對於某些架構某些 struct,必須使用 _objc_msgForward_stret
代替 _objc_msgForward
。爲何要用 _objc_msgForward_stret
呢,找到一篇說明 objc_msgSend_stret
和 objc_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)
在 NSMethodSignature
的 debugDescription
上打出了是否 special struct,只能經過這字符串判斷。因此最終的處理是,在非 arm64 下,是 special struct 就走 _objc_msgForward_stret
,不然走 _objc_msgForward
。
實現過程當中碰到一些內存問題,首先是 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;
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的,因此須要特殊處理這類方法。
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 方法名包含 $
字符的,最終爲了代碼顏值,使用了雙下劃線 __
表示。
在使用 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 的互傳了。
對於"空"的表示,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
JSPatch 的原理以及一些實現細節就闡述到這裏,但願這篇文章對你們瞭解和使用 JSPatch 有幫助。接入 JSPatch 可使用 JSPatch 平臺: jspatch.com。