转载

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

作者简介：孙源（@我就叫Sunny怎么了），滴滴出行 iOS 技术专家，多年专注于 iOS 开发，现就职于滴滴 App 架构组，在技术上做探索和深挖；善于刨根问底，对未知的东西兴趣强烈，代码风格强迫症；同时喜欢写博客(http://blog.sunnyxx.com/)，线上线下分享，贡献开源（forkingdog）累计 star 破万。

滴滴出行客户端App架构团队在对ReactNative、Weex进行调研尝试后发现并不适用于滴滴现有业务，由此自研了iOS动态化方案——DynamicCocoa，在这篇文章中，作者详细分享了它的背景以及具体功能实现。

方案诞生

动态化一直是App开发梦寐以求的能力，而在iOS环境下，Apple禁止了在MainBundle外加载和执行的自己的动态库，所以像Android一样下发原生代码的方案被堵死。

后来像ReactNative、Weex这样的基于Web标准的跨端方案出现，各大公司都有对其进行尝试，但对于滴滴现状，也许并不适合：

滴滴App强交互、以地图为主体、端特异性高；
客户端人员充足，跨技术栈学习和开发有较大成本；
大量固化Native代码，重写成本高。

所以我们思考，能不能做一套保持iOS原生技术栈、不重写代码就神奇的拥有动态化能力的方案呢？

于是，我们设计和实现了一个具有里程碑意义的iOS专属动态化方案：DynamicCocoa

DynamicCocoa初识

DynamicCocoa可以让现有的Objective-C代码转换生成中间代码（JS），下发后动态执行，相比其他动态化方案，优势在于：

使用原生技术栈：使用者完全不用接触到JS或任何中间代码，保持原生的Objective-C开发、调试方式不变；
无需重写已有代码：已有native模块能很方便的变成动态化插件；
语法支持完备性高：支持绝大多数日常开发中用到的语法，不用担心这不支持那不支持；
支持HotPatch：改完bug后直接从源码打出patch，一站式解决动态化和热修复需求。

不论是动态化还是HotPatch，我们都能让开发者“Write Cocoa,Run Dynamically”。

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

语法支持

DynamicCocoa能支持绝大部分日常使用的Objective-C/C语法，挑几个特殊的：

完整的Class定义：interface、category、classextension、method、property，最重要的是支持完备的ivar定义，保持和native完全一致的实例内存结构；
ARC：可以正确处理strong、weak、unsafe_unretained等对象的引用计数，对象的ivar也可以正确的释放；
C函数：支持C函数的定义与C函数的调用、内联函数的调用；
可变参数：支持C与OC的可变参数方法的调用，如NSLog；
struct：支持任意结构体的使用，无需额外处理；
block：支持创建和调用任意参数类型的block；
其他OC特性：如@selector、@protocol、@encode、for..in等；
其他C特性：支持使用宏、static变量、全局变量，取地址等。

举个例子，你可以放心的使用下面的写法，并能被正确的动态执行：

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

资源支持

一个功能模块，除了代码外，资源也是必不可少的，DynamicCocoa的动态bundle支持：

xib和storyboard；
xcassets；
不放在xcassets里的图片资源；
其他资源文件。

对于习惯于使用IB来开发UI的人来说，这将是一个很好的开发体验。

工具链支持

我们使用Ruby开发了一套命令行工具（类比为xcodebuild），大幅简化了配置开发环境、OC代码转换、资源处理、打包的复杂度，它可以：

解析XcodeProject：读取工程编译选项，保持和native编译参数一致；
增量编译：缓存JS转换结果，只重新转换修改过的文件，大幅提高build速度；
链接：分析类依赖，将多个JS按依赖顺序合并，提高文件读取速度；
资源编译：编译用到的xib、storyboard和xcassets；
打包：将JS、资源等打包成bundle。

对于开发者来说，就像pod命令一样，所有操作都可以通过这个命令完成。

动态插件开发流程

首先App中需要集成DynamicCocoaEngineSDK，用来执行下发的bundle开发到发布的流程如下图所示：

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

当然，DynamicCocoa只提供命令行工具和EngineSDK，可以完成本地打包、运行和测试，而线上发布后台、服务端、CDN等需要自行解决。

在滴滴内部，我们构建了开发、Review、线上回归测试、灰度、发布、回滚、统计的闭环系统，以服务的形式给内部接入。

HotPatch过程

HotPatch本质上是方法粒度上的动态化，所以在整个框架搭建起来后，HotPatch也不难实现，使用DynamicCocoa做热修复的最大优势是开发者依然只对源码负责，修改完bug后，打个patch包，修复成功后把源码改动直接push到代码仓库就行了。

假设我们发现了下面的bug：

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

然后在Native进行修复并自测：

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

自测完成后，在这个方法后面添加一个神奇的Annotation：

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

使用命令行工具在patch模式下进行打包，就能把所有标记了的method提取出来，分别转换成JS表示，打到一起进行发布。

除了修改一个方法外，patch模式还支持：

调用原方法；
新增一个方法；
新增一个property来辅助修复bug；
新增一个Class。

最后，开发者可以安心的把修改后的代码（甚至可以保留Annotation）gitpush，完成热修复工作。

打开黑箱

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

就像Objective-C是由Clang编译器和Objective-CRuntime共同实现一样，DynamicCocoa也是由对应的两部分构成：

在Clang的基础上，实现了一个OC源码到JS代码的转换器；
实现OC-JS互调引擎的DynamicCocoaSDK。

我们知道，Clang-LLVM的标准编译流程是从源代码经过预处理、词法解析、语法解析生成语法树，CodeGen生成LLVM-IR，进入编译器后端进行优化和汇编，最终生成目标文件(Mach-O)。

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

而我们既希望Clang帮助完成源码处理的步骤，又希望生成结果是JS表示形式，于是在Clang生成抽象语法树（AST）后，我们进行接管，实现了一个OC2JSCodeGen，遍历各个特定语法节点输出JS表示：

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

由于转换器和Clang前端标准编译流程相同，所以只要native代码能build，转换器就能build，这也是DynamicCocoa能让动态包和native保持严格一致的先决条件。

注：转换器是基于Clang开发的独立命令行工具，它的使用并不会对原有的Xcode工程产生任何影响。

另一部分是要集成进App的DynamicCocoaSDK，它的职责是为JS中间代码提供Runtime环境，实现OC-JS的互调引擎，能够加载动态bundle，提供便捷的API，整体架构如下：

滴滴 iOS 动态化方案 DynamicCocoa 的诞生与起航

其中一些有趣的点：

底层使用libffi来处理各个架构下的callingconventions，实现caller调用栈的构建和callee调用栈的解析，用于实现OC/C函数调用、动态imp、block等。
由于JS的弱类型，数值变量在做计算时很容易丢失类型信息，比如inta=1/2;在OC中表示整除，结果为0，但进入JS就都会按照double计算，结果为0.5，造成了不一致。所以DynamicCocoa接管了JS中的类型信息，强转或运算符都需要特殊处理。
为了实现block，我们构造了和nativeblock一致的内存结构，不论是JS创建的block还是native传进JS的block，都可以无差别的调用。
虽然runtime提供了动态创建OCClass的API，但只能创建MRC的Class，导致ARC下ivar并不会乖乖释放，我们深入到Class和实例真实内存结构中，给动态创建的类增加了ARC能力，并按照Non-FragileABI模拟真实ivar内存布局和ivarlayout编码，如果你重写了dealloc方法，DynamicCocoa甚至能够像native一样自动调用super。

DynamicCocoa带来的改变

DynamicCocoa动态化技术给App开发带来了很大的想象空间：