插件化的过去、现在与未来

本篇主要是介绍一些背景和趋势以及笔者自己的思考,不涉及技术细节。

为什么需要插件化

插件化框架发展至今已经有六、七年的历史了,在当今技术日新月异的年代,算是已经淬炼了很久了,作为 Android 的开发者应该多多少少都听说过插件化。那么它为什么会诞生?或者说插件化是要解决什么问题呢?

可能有人会注意到一件有趣的事情,向来 Geek 的外国开发者好像对插件化并不怎么感兴趣,这样一套庞大的黑科技框架似乎只在国内被各大厂追捧。笔者觉得这与国内外的产品形态差异有关。老外总是喜欢做小而美的东西,总要与人不同。而在中国大家都喜欢大而全的万能平台,无论是用户还是企业都喜爱一站式服务的解决方案。也正是这样的原因,导致了国内的产品都很大,尤其在移动端这样轻量化的平台,软硬件迭代的速度跟不上迅速膨胀的业务需求。不信你打开淘宝,携程,美团众多 app 看一下,琳琅满目的各种频道铺满首页,模块与模块间的依赖错综复杂,项目体积早已爆炸,一个业务团队动辄上百人。随着项目的庞大,编译速度问题,庞大系统的健壮性问题,协作问题等等成为了企业增长的瓶颈。也正是在这样的背景下,催生了插件化这个中国特色产物。

插件化是什么

插件化框架其实是一组黑科技的聚合,最核心的诉求就是能够动态加载 APK,通俗来讲就是在 app 安装以后,能够在运行时加载其他 APK 中的代码。这样一来,只要将项目模块间的解耦做好,把各个模块打包成不同的 APK,用户在使用时,只需要安装主 app,而其他模块 APK 存放于服务端,然后在主 app 中使用时按需求去加载对应的功能 APK。一来解决了协作问题,不同的团队可以单独维护不同的模块,甚至是项目级别的代码隔离;二来由于功能模块是动态加载,就意味着可以动态更新,从而实现热更新,同时也减小了 app 体积,提升了一定用户体验。

由此可见,插件化的核心就是如何实现动态加载 APK。说起来简单,那么动态加载 APK 所带来的问题又是什么呢?

  • 我们首先要解决的是如何加载 APK 当中代码的问题。我们知道,在 JVM 上是通过ClassLoader来加载编译过的.class文件,那么这里就要搞清楚 Android 系统是如何使用 ClassLoader 来运行的。
  • 加载好代码,还有就是资源文件的加载。Android 使用AssetManager来管理资源文件(图片、布局文件、主题、颜色、文字等等),就算能够加载,这里还要考虑到资源冲突和资源共享的问题。
  • 代码和资源都加载好了,但由于不同的 APK 是运行在不同的进程中的,如果主应用需要和模块应用或者说插件之间交互通信,就又涉及到了跨进程通信的问题,Android 系统本身的各种系统 Service 和 Activity 的启动过程都涉及到了跨进程通信的问题,这就又需要深入到系统底层,弄清楚 Binder 机制到底是怎么回事。
  • 由于以上问题都涉及到需要使用反射对 framework 层进行 hack,而在国内各种厂家定制 Rom 的背景下,就产生了大量的兼容性问题,而这也是导致插件化框架不稳定最大的原因。要解决这个问题没有捷径,只能一个一个坑踩过去。
  • 最后,解决了所有技术上的问题,还剩下工程运维的问题需要解决,新的项目架构需要新的打包方式,服务端维护的插件模块也需要对应的部署、更新策略。

我将在后续的系列文章对以上问题分别进行详细地介绍。

现状

插件化发展到现在,众多大厂已经分分推出了自己的插件化框架阿里的Atlas,360的RePlugin,滴滴的VirtualAPK等等。在处理上述所涉及到的问题时,每家的方案都有异同点,也因此各有各的优劣势。并不能说哪一个是更好的,只能说他们各自都是最适合自己业务场景的产物,这也给了其他开发者选择框架时的参考,插件化框架一定要与自己项目的业务场景相结合,并不是越万能越好。具体方案间的对比可以参考这篇文章插件化方案对比 · dim’s blog

随想

插件化走过了百花齐放的阶段,沉淀到今天,可以说已经相当成熟了。但是要知道,无论是 Google Play 还是 Apple Store 其实都是不允许 app 热更新的,因为这样就能绕过商店的审核机制了。而且就在今年的 Google I/O 大会上,Google 宣布将要禁止对非 SDK 接口即隐藏 API 的访问。虽然禁止方案分为 浅灰名单,深灰名单和黑名单,但趋势一定是向着禁止 hook 修改系统 API 的方向发展的。黑科技对于技术爱好者来说自然是向往的,但也正是这种破坏生态的行为让很多人不愿意使用。无独有偶,今年 Google 还同时推出了 App Bundle,看起来就是官方的插件化解决方案,而且插件是托管在 Google Play 上的,现在还处于测试阶段,其稳定性有待验证。联想到前面禁止非官方 SDK 接口访问的情况,Google 的布局和其用意不禁令人深思。

我觉得插件化框架由商店平台提供绝对是正确的方向,相当于提供了标准化的方案提升用户体验,同时也提升了开发体验。这样的方案本应由商店提供,而不是 app 的开发者。但说到应用商店,国内险恶的环境又不禁令人唏嘘。哪怕国内的商店们纷纷提供这样的能力,会不会又会像推送方案一样让人头疼不已,想到前几年昙花一现的统一推送联盟,现在声音都没了,着实令人心寒。

那身处技术发展过程中的开发者们应该如何选择呢?无论如何插件化所要解决的问题是客观存在的,我觉得有这么几种可能:

  1. 放弃黑科技,采用组件化思路另辟蹊径。
  2. 在黑科技的道路上一黑到底,上有政策下有对策。一种绕过Android P对非SDK接口限制的简单方法 | Weishu’s Notes
  3. 大 Google 重返中国,统一 Android 生态(太阳从西边出来了,虽然可能性极低,但却是我最想看到的,我相信我不是一个人)。