基于零开始Android新项目11组件化实践.docVIP

从零开始的Android新项目11 - 组件化实践（1） 组件化是什么 组件化，相对于容器化（插件），是一种没有黑科技的相互隔离的并行开发方式。为了了解组件化，不得不先说一下插件化。 为什么我们需要插件化 现代 Android 开发中，往往会堆积很多的需求进项目，超过 65535 后，MultiDex、插件化都是解决方案。但方法数不是引入插件化的唯一原因，更多的时候，引入插件化有另外几个理由： - 满足产品经理随时上线的需求（注意，这在国外是命令禁止的，App store 和 Google Play 都不允许这种行为，支付宝因此被 Google Play 下架过，仔细想想，如果任何应用都能在线上替换原来的行为，审查还有什么用？）。 - 团队比较有钱，愿意养人做这个。技术人员觉得不做业务简直太棒了，可以安心研究技术。 - 并行开发，常见于复杂的各种东西往里塞的大型应用，比如 —— 手Q、手空、手淘、支付宝、大众点评、携程等等。这些团队的 Android 开发动辄是数百人，并分成好几个业务组，如此要并行开发便需要解耦各个模块，避免互相依赖。而且代码一多吧，编译也会很慢（我们公司现在的工程已经需要 5 - 6 分钟了，手空使用 ant 都需要 5 分钟，而 手Q 使用 ant 则需要 10 分钟，改成 gradle 的话姑且乘个2，都是几十分钟的级别）。插件化可以加快编译速度，从而提高开发效率。 其实真正的理由就只有第三个（我相信业务技术人员也不会真的想无休止地发版本，除了一些分 架构组/业务组 的地方，架构组会不考虑业务组的感受）。在知乎上，小梁也有对此作出回答：怎么将 Android 程序做成插件化的形式？，建议去读一下。 本篇里不多说插件化的工作原理，建议移步去别处学习，直接看源码也可以，像 atlas 这样 Hook 构成的插件框架可能阅读起来会有些困难，其他还好。 插件化的恶 躺不完的坑。 —— 即便是一些做了很多年的插件化框架，依然在不断躺坑，更何况是使用他们的开发者，简直是花式中枪。 发不完的版本。 —— 什么？赶不上？没事，迟些可以单独发版本。这回你可真是搬砖的码农了。 这个在我的插件里是好的呀。 —— 在各自的壳里运行很完美，然而集成后各种问题不断，甚至一启动就 ANR。 版本带来的问题。 —— 因为要动态发版本，所以每个插件自然需要有各种版本。什么？那个不对？肯定是你引用的版本错啦。更何况发版本本身就是个让人很心累的事情。 等等等等，不赘述。垃圾插件，还我青春。 组件化 VS 插件化 组件化带来的，是一个没有黑科技的插件化。应用了 Android 原有的技术栈以及 Gradle 的灵活性，失去的是动态发版本的能力，其他则做得比插件化更好。因为没有黑科技，所以不会有那么多黑科技和各种 hook 导致的坑，以及为了规避它们必须小心翼翼遵守的开发规范，几乎和没有使用插件化的 Android 开发一模一样。 而我们需要关心的，只是如何做好隔离，如何更好地设计，以及提高开发效率与产品体验。 Take Action Gradle 组件化的基本就是通过 gradle 脚本来做的。 通过在需要组件化的业务 module 中： if (isDebug.toBoolean()) { apply plugin: com.android.application } else { apply plugin: com.android.library } 并在业务 module 中放一个 perties： isDebug=false 如此，当我们设置 isDebug 为 true 时，则这个 module 将会作为 application module 编译为 apk，否则 为 library module 编译为 aar。 下面的 gradle 是我们的一个组件化业务 module 的完整 build.gralde： println isDebug.toBoolean() if (isDebug.toBoolean()) { apply plugin: com.android.application } else { apply plugin: com.android.library } apply plugin: me.tatarka.retrolambda apply plugin: com.neenbedankt.android-apt android { compileSdkVersion rootPpileSdkVersion buildToolsVersion rootProject.ext.buildToolsVersion defaultConfig {