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
