Android 插件化技术发展到现在其实已经很成熟了，但是相应的问题，如果没有真正地去实践过，根本不了解其中有多少问题，会牵涉到多少技术细节，多少被外人膜拜的外表光鲜的技术大牛都被『插件化』这三个字折磨地死去活来，这对于 Android 整个生态的损害也让人无法忽视。

9月24日的 MDCC ，冯森林老师提出了一个很有意思的思路『组件化』。

我们首先要想一下，我们做插件化的目的是什么？

- 为了满足产品随时上线的需求？
- 为了修复因为我们对自己要求不严格而写出来的 bug ？
- 为了向人炫耀自己的技术实力？

很抱歉，如果是为了这些目的，那就真的太对不起自己是『开发者』这个如此高逼格的身份了。

做插件化真正的目的：是为了去适应并行开发，是为了解耦各个模块，是为了避免模块之间的交叉依赖，是为了加快编译速度，从而提高并行开发效率。

明确了这些，我们再来看插件化的结果，每个模块都支持独立运行测试，分为稳定的 release 版本和不稳定的 snapshot 版本，每个模块都高度解耦，没有交叉依赖，不会出现一个模块依赖了另一个模块，其中一个人改了这个模块的代码，对另一个模块造成影响。这时候，我们再看冯老师的『组件化』思想。

那么这个『组件化』是什么意思呢？我说下我自己的理解，可能不对，还请指教：
> 通过 gradle 配置的方式，将打 debug 包和 release 包分开。这样会有一个好处，开发一个模块，在 debug 的时候，可以打成一个 apk ，独立运行测试，可以完全独立于整个宿主 APP 的其他所有组件；待到要打 release 包的时候，再把这个模块作为一个 library ，打成 aar ，作为整个宿主 APP 的一部分。而 debug 和 release 的切换都是通过 gradle 配置，可以做到无缝切换。至于模块之间的跳转，可以用别名的方式，而不是用 Activity 和 Fragment 类名。这样所有的模块和宿主 APP 都是完全解耦的，彻底解决了并行开发的可能造成的交叉依赖等问题。

按照这个思路，我们再来看看一些其他的细节：

1. 在 Android 里有一个比较爽的一点是，作为 library 的时候，aar 里的引用依赖，在宿主 Application 里也有同样的引用依赖，并不会打包两份到宿主 Application 里；
2. 模块之间的跳转，除了使用别名的方式，我能想到的还有另外一种方式，同样是通过 gradle 脚本，将跳转用到的类打成一个 jar ，作为一个 API 服务提供给其他模块作为编译期依赖（provided）引入；
3. 各个 library 在 debug 的时候作为 apk ，要独立打包运行测试，这时就需要有一个启动 Activity ，而 library 是不需要的，我的想法是放置两个 AndroidManifest.xml ，使用 sourceSets 分别在 debug 和 release 的时候加载不同的 AndroidManifest.xml 。

怎么样？看上去是不是很像插件化 Atlas ？然而这个方案没有任何『黑科技』，不牵涉任何 hook ，跟 Atlas 的区别就是无需关心不同的 Context ，无需再关心类、资源怎么去加载，无需关心 Context 的安全问题，无需关心不同机型的兼容适配...技术成本可能连 Atlas 的十分之一都不到！

感兴趣的话，可以看看这个 slide 分享，地址在这儿[from-containerization-to-modularity](http://www.slideshare.net/oasisfeng/from-containerization-to-modularity)，我也写了个小 sample 去实现这个想法[ComponentizationApp](GitHub - liangzhitao/ComponentizationApp)。