OCEval-動態執行ObjectiveC的熱修復方案

soyo發表於2018-12-27

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

相關文章