OCRunner 第零篇：从零教你写一个 iOS 热修复框架

为什么要热修复

在软件开发过程中，很难避免 BUG 的存在，尤其是对于一些达到一定规模的 App 因为协作模式错综复杂，就很容易带着问题上线。

一旦问题上线之后，问题就麻烦了，不仅需要重新打包、测试，而且还需要重新提交审核，而这种修复问题的方式往往是低效且漫长的。

因此，在开发一个 App 的过程中，稳定性的就变成了一个难题，唯一的原因就是不希望带着问题上线导致用户对 App 失去信任。

热修复就可以很好的解决这类棘手的问题，因此带着好奇之心，研究了一下热修复在 iOS 端的可行性，实现了一个较为完备的热修复框架，我把它叫做 OCRunner。

我也会在未来几个月，把我做 OCRunner 的一些经验总结成博文，在「老司机技术周报」的公众号上与大家分享。

已有的开源方案

采用 JavaScriptCore 的方案

*JSPatch*[1]通过下发 JavaScript 脚本，使用系统提供的 JavaScriptCore 执行 JavaScript 脚本，通过 JavaScript 代码解析代码中的类信息，动态调用相应的 Objective-C 函数，然后配合 libffi 修改 Runtime，最终实现热更新，奠定了 Objective-C 的热修复基础。

*TTPatch*[2]和 JSPatch 一样使用 JavaScriptCore 执行 JavaScript 脚本，但支持实时预览，这个是我超级喜欢的功能。

自实现脚本解释器的方案

*OCEval*[3]下发 Objective-C 源码解释执行，但支持的语法有限。作者lilidan[4]自己实现了 Objective-C 的词法分析器和语法分析器。其中的FunctionSearch的实现[5]也帮助了我许多。DynamicOC[6]将 OCEvel 的词法解析器和语法解析器使用 lex&yacc 实现。

*Mango*[7]作者设计了 Mango 的脚本语言（和 Objective-C 极为相似），使用 lex&yacc 生成语法树，然后再将 Mango 脚本的语法树解释执行。这也就是 OCRunner 的起源。

OCRunner[8]是我在 Mango 的基础之上优化后的一个方案。和 Mango 相同的是，采用lex&yacc生成语法树后解释执行、JSPatch 的 Runtime 的思想。但这一次，我们可以书写 Objective-C，然后直接动态执行它。同时也支持了许多特性：结构体、枚举、函数指针等。

其他库不足的问题:

支持不够完善：结构体、系统函数、枚举等。
语法问题：一些语法上的小问题，有时候无异于回炉重造，也是需要时间成本的。有时候一些奇怪的语法问题，或许都要花你一个下午的时间。
传输加解密: JSPatch 等均采用 RSA (非对称加密)对整个脚本进行加密，个人认为着实耗费性能了一些。

为什么要写 OCRunner

这次可以慢慢的讨论这个问题了~

19 年 4 月的时候，刚好在趋势榜上看见了Mango[9]项目，发现它是使用自定义的、和 Objective-C 语法非常相似的脚本语言（相当于自己创造一名语言吧，balabala），当时早已对编译相关的心驰神往，奈何一直没有一个合适的机会去学习，再加上当时的公司有热更新的需求，就想着试一试，看能不能写一个将 Objective-C 代码转换为 Mango 脚本的转换器（也想过能不能借此自己完成一个热更新库）。

19 年 4 月晚上 10 点正式开启了每天回家爆肝 lex&yacc 的升级打怪之路，各种各样的问题炸得我在锅里反复横跳（解决办法: 「 lex&yacc.pdf 」抱着啃），但最严重的的莫过于指针相关的，参考了好几个基于 lex&yacc 的开源编译器，才得以找到折中的解决办法。中间也发生了许多事情，从 19 年 7 月后，我休息了4个月。

20 年 3 月的时候，想着 oc2mango 做了那么久，得把翻译器做出来了才能给自己一个交代，肝了一段时间，正确的使用 yyless 后，问题相较之前已经少了很多。这个时候 oc2mango 翻译器也能正常使用了，虽然仍有一些小问题。这个时候翻译器的小目标也就完成了✌️。

当翻译器完成以后，我的野心变大了，我想试试我自己能不能完成一个像 Mango 一样的热更新库（内心戏：lex&yacc 就是从它那儿学来的，应该不难吧？