iOS动态化与热技术方案.pdfVIP

43-剖析使App具有动态化和热更新能力的方案

你好，我是今天，我来和你聊聊iOS开发中的动态化和热更新方案。

热更新能力的初衷是，能够及时修复线上问题，减少Bug对用户的。而动态化的目的，除了修复线上问题

外，还要能够灵活更新App版本。

要实现动态化，就需要具备在运行时动态执行程序的能力。同时，实现了动态化，也就具备了热更新能力。

通常情况下，实现动态化的方案有三种，分别是JavaScriptCore解释器方案、代码转译方案、自建解释器方

案。接下来，我就和你详细说说这三种方案。

JavaScriptCore解释器方案

iOS系统内置的JavaScriptCore，是能够在App运行过程中解释执行的解释器。

JavaScriptCore了易用的原生语言接口，配合iOS运行时的方法替换能力，出现了使用JavaScript

语言修复线上问题的JSPatch，以及把JavaScriptCore作为前端和原生桥梁的ReactNative和Weex开发框

架。这些库，让App具有了动态化能力。

但是，对于原生开发者来说，只能解释执行JavaScript语言的解释器JSPatch、ReactNative等，我们用起

来不是很顺手，还是更用原生语言来开发。那么，有没有办法能够解决语言栈的问题呢？

代码转译方案

DynamicCocoa方案将Objective-C转换成JavaScript代码，然后下发动态执行。这样一来，原生开发者只

要使用原生语言去开发调试即可，避免了使用JavaScript开发不畅的问题，也就解决了语言栈的问题。

当然，语言之间的转译过程需要解决语言差异的问题，比如Objective-C是强类型，而JavaScript是弱类

型，这两种语言间的差异点就很多。但，好在JavaScriptCore解释执行完后，还会对应到原生代码上，所以

我们只要做好各种情况的规则匹配，就可以解决这个问题。

上，语言转译可以使用现有的成熟工具，比如类C语言的转译，可以使用LLVM套件中Clang的

LibTooling，通过重载HandleTranslationUnit()函数，使用RecursiveASTVistor来遍历AST，获取代码的完

整信息，然后转换成新语言的代码。

在这里，我无法穷尽两种编程语言间的转译，但是如果你想要快速了解转译过程的话，方法就是看一

个实现的雏形。

比如，我以前用Swift写过一个Lisp语言到C语言转译的雏形。你可以点击这个，查看具体的代码。通

过这个代码，你能够了解到完成转译依次需要用到词法分析器、语法分析器、遍历器、转换器和代码生成

器。它们的实现分别对应LispToC里的JTokenizer.swif、JParser.swift、JTraverser.swift、

JTransformer.swift和CodeGenerator.swift。

再比如，你可以查看SwiftRewrite项目的完整转译实现。SwiftRewriter使用Swift开发，可以完成

Objective-C到Swift的转换。

自建解释器方案

可以发现，我面提到的JSPatch、ReactNative等库，到最后能够具有动态性，用的都是系统内置的

JavaScriptCore来解释执行JavaScript语言。

虽然直接使用内置的JavaScriptCore非常方便，但却限制了对性能的优化。比如，系统限制了第App对

JavaScriptCoreJIT（即时编译）的使用。再比如，由于JavaScript使用的是弱类型，而类型推断只能在

LLInt这一层进行，无法得到足够的优化。

再加上JSContext多线程的处理也没有原生多线程处理得高效、频繁的JavaScriptCore和原生间的切换、内

存管理方式不一致带来的风险、线程管理不一致的风险、消息转发时的解析转换效率低下等等，使得

JavaScriptCore作为解释器的方案，始终无法比拟原生。

虽然通过引入前端技术栈和利用转译技术能够满足大部分动态化和热修复的需求，但一些对性能要求高的团

队，还是会考虑使用性能更好的解释器。

如果想要不依赖系统解释器实现动态化和热修复，我们可以集成一个新的解释器，毕竟解释器也是用代码写