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
