iOS 动态化的故事

▲点击上方“ CocoaChina ”关注即可免费学习iOS开发

今天聊聊 iOS 动态化的故事。

问题

在开发模式上，web 的方式是比较先进的，有各种优点，包括跨平台/UI开发效率高，最重要的是可以时刻保证用户看到的程序是最新的，没有版本概念，整个系统时刻保持在掌握之中，而客户端开发模式相对 web 开发是一种倒退，客户端做不到这样的动态化，无法随时更新，目前一个客户端程序要更新成本是很高的，需要发布版本，也无法保证所有人都能更新到这个版本，这是最大的弱点，也是非常大的一块需求。

原因

为什么会有这种倒退，最主要原因是：苹果引领的体验优先规则。

在 iPhone 出现之前大家并不太在意一个软件的动画体验，一个 web 应用是很少有动画的，点一个按钮，一整块内容直接刷新，再点个链接整个页面变白刷新，PC上网页滚动都是一格格滚动的，而不是现在手机上那种顺滑流畅的滚动，PC客户端软件也一样，大家都觉得没什么问题，用得挺好，但苹果改变了这种情况，iPhone 刚推出时页面间切换的动画，60fps 的丝滑滚动，点击的即时响应，微软的人都惊呼是黑魔法，让人用了就上瘾，再也回不去，而 web 的方式还不足以像原生客户端那样支持这样的流畅性，做不到好的体验，无法被人接受，开发上优势再多也无法干过客户端，参考 facebook 初期用 web 技术构建 app 的惨状，没办法，服了苹果，大家只能按照苹果的方式干，做原生客户端。

当然这里还有手机环境网络不稳定，流量费贵的原因，但这些都可以在技术上通过缓存解决，最主要还是体验问题。

那发展到今天，这个体验问题解决了没有呢？没有，即使发展到今天手机性能已上天，但 web 做出来的东西体验仍然跟客户端有差别，大家也已经习惯了 APP 的方式，也被流畅的 APP 惯坏。现在 APP 里也有不少功能是 web实现，但大家都知道这是牺牲了一些性能体验去换取开发和发布效率，只是一种权衡。

解决方案

那这个问题怎么解决呢，现在业界有两种方案。

• 优化 web 性能

既然用 web 方式开发的劣势只是性能体验跟不上，那就优化性能吧。web 性能瓶颈在哪里？在那个有悠久历史的 webkit 引擎，它有各种历史问题，要改进它并不容易。我们要的是 web 的开发和发布方式，不需要 web 的全部，那能不能重新实现一个渲染引擎呢，这个引擎可以针对原生客户端优化，不需要兼容繁杂的 web 标准，不跟 web 那些历史问题扯上关系，于是就有了 React Native 和 Weex 这种方案，web 的方式开发，原生的方式渲染，拥有 web 优秀的开发和发布方式，又有不错的性能体验，看起来很完美，很有前途的方案。

一个方案能不能推广开让大家都使用，主要看成本和收益。目前 React Native 和 Weex 等这些方案的接入成本是很高的，一是它们本身就是大型框架，学习成本高，后期维护成本以及团队学习成本同样高。二是它们还不够成熟，还在继续填坑中，使用的过程可能要一起去填坑。收益上也不够理想，就目前状况它们能代替的是那些本来用 H5 实现的模块，换成这种方式实现后性能体验会更好，但也不能保证像原生那样好，很多场景需要深入框架进行优化。整个 APP 都使用这种方案构建还不靠谱，部分使用又无法使整个 APP 保持动态化，总体上来说收益也没有达到有绝对优势的程度，成本高收益低，推广起来会比较困难，还需期待其继续发展。

• 原生动态化

另一种是方案是，我可以放弃用 web 的开发方式，放弃 web 跨平台/UI开发简单的优越性，我想继续用原生的方式开发这个APP，但又希望这个 APP 随时可以更新，让程序时刻在自己掌握中，出了问题可以快速修复，还想要可以随时更新版本快速迭代，可以不？完全可以，用动态库就行了。

动态库

技术上要在 iOS 上做到原生动态化比 Android 更容易，iOS 开发语言 Objective-C 天生动态，运行时都能随意替换方法，运行时加载动态库又是项很老的技术，只要我把增量的代码和资源打包到一个 framework 里，动态下发运行时加载，修 bug，加功能都不在话下，性能完全无损，这件事就结束了。

但是呢。苹果把加载动态库的功能给封了，动态库必须跟随安装包一起签名才能被加载，无法通过别的途径签名后再下发。

为什么这么做呢，这又涉及到苹果另一个创举：审核模式（苹果的创举之多令人发指）。一个软件，要在一个平台上发布，需要先通过这个平台的人工审核，这个好像在苹果之前没见过有别人这样做过，windows 不用，mac 不用，各种 unix 不用，web 也不用，苹果为了对自己的平台有绝对控制权，搞了这样一个东西，审核模式就跟动态化冲突了，如果我一个 APP 可以不经过审核不断下发 framework 添加修改功能， 还需要苹果审核做什么？

因为这种限制，没法用最方便的方式进行动态更新了，整个 APP 发出去后就不受控制，有什么严重 bug，需要添加什么功能，都乖乖打个包提交给苹果审核，再等用户慢慢更新，对于急性子的中国人来说，这种事难以容忍。

绕道

苹果把动态库这扇门关了，我们可以绕个道从另一个门进，动态加功能可以缓缓，大家需求还不那么迫切，但修 bug 的需求就很急，很多公司 APP 的 crash 率是 KPI 来着，看着线上 crash 不断增多又毫无办法是很不爽的事，于是有了 waxPatch和 JSPatch 这种方案，曲线救国。

JSPatch 把 OC 手动翻译成 JS，在运行时通过 OC 的动态特性去调用和替换 OC 方法，实时修复 bug。修 bug 这个需求基本是满足了，虽然小绕了下道，但成本还是很低的，引擎本身也很小很轻量，接入对 APP 不会有任何负面影响，在关键时刻又可以帮大忙，成本低收益高，于是很容易推广开。