聊聊移动端的动态化之路

过去

2014年，中国和国外的 App 理念走上了截然不同的两条道路。在国外，一个 App 最多做两三件事，但在中国，一个 App 恨不得装下所有功能，这就是所谓的超级 App。

受到 65536 方法数的限制，国内各种插件化方案层出不穷。为了降低更新给用户带来的影响，国内又发明了热更新技术。

插件化和热更新太强大了，强大到给用户隐私和安全带来了威胁，用户无法控制或得知应用是否被偷偷的嵌入恶意代码，而隐私和安全在国外是一个禁区，不可越雷池一步，即使并没有造成实际危害，只是有这方面的风险，相关的技术就不可能被允许。

国内和国外在对待隐私上的态度不同，App 的形态上也有差异，从苹果和谷歌的角度，必须要加以限制这种动态化方案，坚定地推动 Web 技术。

现在

插件化没落的最大原因还是在于兼容性。

Android 碎片化严重，插件化框架需要不断兼容系统 API，随着隐私安全的愈发重要，谷歌开始收口整顿了，Android P 给了开发者们一个信号：别随便 hook 系统 API 了。插件化这条路注定无法一直走下去，于是开发者们另辟蹊径。

最开始是继续用 H5 混合开发的方式，例如老牌 Hybrid 框架 Cordova，但是性能不尽人意。

这时 Facebook 开发出了一个跨时代的框架：React-Native。它提供了一个全新的思路：通过 jscore 进行 js 解析，使用原生的 View 进行渲染，提供桥机制调用原生的能力。React-Native 是第一个真正的高性能的动态化框架，它的出现让 Web 前端和客户端的界限迅速变得模糊。

随之而来的是各大公司的自研框架，例如阿里的 Weex 和美团的 Picasso 框架。React-Native 只提供了 Android 和 iOS 的双端支持，Weex 扩展了思路，提供的 Web 端的支持，一个是 React 语法糖，一个是 Vue 语法糖。Picasso 又不一样，Picasso 是纯 TS，DSL 语法树，写法实在太简单，又准备在三端的基础上提供小程序端的支持。

通过 Dart 编写 APP，然后编译成机器码同时运行在 Android 和 iOS 上，做到了原生跨平台的 Flutter 也是今年移动端少数的几个比较火的热点之一。

支付宝的动态方式不同于以上所有，它是完全基于自己的 H5 容器进行 Hybrid 开发，不过由于内核也是自研的（UC 内核），所以性能各方面都比原生的 WebView 好，支付宝里非常多的页面都是基于 H5 容器开发的，包括支付宝小程序，这也算是一种动态化的方式吧，只不过研发成本太高：自研 WebView 内核。

未来

目前来看，动态化的三驾马车已经初步形成：

• React-Native 为首的 jscore（v8）桥通信动态化方案
• 自研 WebView 内核，H5 容器化方案
• Flutter

动态化改变了移动开发的方式，模糊了 Web 前端和客户端的界限，让越来越多的人认识了什么是 “大前端”，这将是未来 5 年内移动端的发展方向。

动态化方案的出现，不是为了替代谁，更多是为了给用户更好的体验，同时让业务可以更快的迭代，并在不断的尝试中，给用户带来更好的产品。