OCEval
需求
目前流行的 JSPatch/RN 基於JavaScriptCore提供了iOS的熱修復和動態化方案。但是都必須通過下發Javascript指令碼來呼叫Objective-C。 尤其是JSPatch,編寫大量的JS程式碼來呼叫OC的方法,開發效率較低(目前可以藉助語法轉換器),執行效率也會打折扣。 更好的方案是直接編寫Objective-C程式碼,來實現熱修復或者動態化方案。開發效率更高,程式碼的執行效率也更高。
在python和javascript等指令碼語言裡,有類似eval()函式來直接動態執行程式碼。所以我實現了OCEval 這個庫,讓我們能直接動態執行Objective-C程式碼。例子如下:
NSString *inputStr = @"return 1 + 3 <= 4 && [NSString string] != nil;";
NSNumber *result = [OCEval eval:inputStr]; // result: @(YES)
複製程式碼
為了實現跟JSPatch類似的熱修復功能,增加了方法替換。我們就可以通過下發Objective-C程式碼進行現有App的方法替換,來進行熱修復的功能。
//在新的imp裡直接呼叫舊的方法實現
NSString *viewDidLoad2 = @"{\
[originalInvocation invoke];\
";
[OCEval hookClass:@"ViewController"
selector:@"viewDidLoad"
argNames:@[]
isClass:NO
implementation:viewDidLoad2];
複製程式碼
OCEval甚至可以用來完整的編寫一個頁面或者App,並動態下發。我在iOS的Demo裡實現了一個簡單的頁面,具體見原始碼。
實現原理
C和C++的效能高,是因為編譯型語言在編譯期就已經生成了機器碼,執行時只需要執行機器碼所以執行效率高,但是動態性差。 js的效能差,是因為js的runtime引擎通常是在實際執行前進行的編譯的。優點是動態性好。 像Dart和python等等都可以編譯打包執行或者JIT(Just in time)執行。
不同於C和C++,Objective-C是動態化的語言,Objective-C的runtime利用訊息傳送和轉發可以動態地執行任何方法。 同時Objective-C又不同於javascript等完全動態化的語言。 因為大多數呼叫是在編譯期就已經決定的,編譯出可執行檔案(mach-O)。
所以在OCEval裡實現了一個輕量級的直譯器,動態地解釋Objective-C程式碼,同時利用OC的runtime訊息轉發來動態執行Objective-C的程式碼,就可以實現類似eval()函式的完全動態化方式。
直譯器
Objective-C在LLVM下的編譯過程:
原始碼 -> AST -> LLVM IR(中間語言) -> LLVM Bytecode -> ASM -> Native
LLVM的前端是Clang,Clang的工作是把原始碼變成AST語法生成樹。
Clang的前端編譯過程:
Preprocesser
: 包括#include #import等預處理, #if,#ifdef 等條件,#define等巨集定義Lexer
:詞法分析,把文字變成token(Tokenizer)Parser
:語法分析,把token變成AST
但是在OCEval裡,沒有做得那麼複雜,因為只是為了能夠執行。所以只實現了詞法分析和語法分析,得到語法生成樹AST。
Runtime
執行的時候遞迴下降地執行每一條指令。這裡利用的runtime主要是NSInvocation,利用methodSignature封裝方法的呼叫慣例,跟JSPatch/RN的最終呼叫方式如出一轍。
+ (id)invokeWithCaller:(id)caller selectorName:(NSString *)selectorName argments:(NSArray *)arguments
{
SEL selector = NSSelectorFromString(selectorName);
NSInvocation *invocation;
NSMethodSignature *methodSignature = [caller methodSignatureForSelector:selector];
invocation= [NSInvocation invocationWithMethodSignature:methodSignature];
[invocation setTarget:caller];
[invocation setSelector:selector];
NSUInteger numberOfArguments = methodSignature.numberOfArguments;
NSInteger inputArguments = [arguments count];
if (inputArguments > numberOfArguments - 2) {
id result = invokeVariableParameterMethod(arguments, methodSignature, caller, selector); //轉而呼叫objc_msgsend
return result;
}
return [self invokeWithInvocation:invocation argments:arguments];
}
複製程式碼
參考JSPatch,在類似[NSString stringWithFormat:]
這樣可變引數的方法裡使用objc_msgsend
。因為NSInvocation
不支援不確定的引數個數的情況。
效能
因為省去了跟JavascriptCore進行引數傳遞的過程,單個方法呼叫比JSPatch/RN快100%,耗時只有JSPatch一半,多個方法呼叫優勢更大,耗時可能只有30%以下。
NSInvocation的呼叫跟Native速度差不多。但是因為動態呼叫很麻煩,入參出參和呼叫慣例都需要動態定義,同時上下文引數在記憶體的傳遞也比較慢,所以整體是比原生慢很多(動態化必要的犧牲)。
稽核
我沒有嘗試過提交AppStore稽核,但是鑑於JSPatch屢次被拒絕,被拒絕的可能性極大。我們的App確實也沒有熱修復的需求。
感謝
感謝JSPatch,libff,Aspect
Github 連結在 OCEval