项目发展到一定程度，就必须进行模块的拆分。模块化是一种指导理念，其核心思想就是分而治之、降低耦合。而在 Android 工程实践，目前有两种途径，一个是组件化，一个是插件化。
组件化开发
说起组件化少不了提起AS模块化的概念，其实两种方式的本质思想是一样的，都是为了代码重用和业务解耦。
模块化
模块(Module)，Android Studio提出的概念，它是根据不同关注点将原项目中共享的部分或业务抽取出来形成独立module，这就类似我们集成的第三方库的SDK。
Module包含两种格式: application， library。application格式的module就可以打包成一个apk，一个library可以形成一个aar包（类似java中的jar包）。在我们实际开发中，通常会抽取第三方库、使用封装的网络库、图片库、视频库、Utils工具类、自定义View 等到一个共有的common模块中，其他模块在配置Gradle依赖后，就能够调用这些API。它 相比于包来讲，模块更灵活，耦合更低，随意插拔，想引入哪个就引入哪个。根据不同的关注点，将一个项目的可以共享的部分抽取出来，形成独立的Module，就是模块化。
组件化
组件化是基于模块化的，组件化是建立在模块化思想上的一次演进，一个变种。组件化本来就是模块化的概念，但是组件化的核心是：模块角色的可转换性，可以在打包时是设置为library，开始调试运行是设置成application。
通俗的讲组件化就是基于可重用的目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件。 组件的出现是为了解决全局工程中有很多重复代码的问题，是为了复用，而且划分力度是相对较小的模块。组件化的另一个目的是为了解耦，把系统拆分成多个组件，分离组件边界和责任，便于独立升级和维护。
组件化开发的结构
图中从上向下分别为应用层、组件层，功能基础层
- 基础层： 基础层包含的是一些基础库以及对基础库的封装，比如常用的图片加载，网络请求，数据存储操作等等，它往往是一些功能性的，其他模块或者组件都可以引用同一套基础库，这样不但只需要开发一套代码，还解耦了基础功能和业务功能的耦合，在基础库变更时更加容易操作。
- 组件层： 基础层往上是组件层，组件层就包含就是根据我们应用划分的业务组件，例如登录模块，消息模块等。
- 应用层： 工程根据需要加入自己的业务组件。
组件化开发带来的优点：
- 业务模块分开，解耦的同时也降低了项目的复杂度，结构非常清晰。
- 开发调试时不需要对整个项目进行编译，每个模块可独立编译，提高了编译速度。
- 多人合作时可以只关注自己的业务模块，把某一业务当成单一项目来开发，可以提升开发，测试效率。
- 可以灵活的对业务模块进行组装和拆分。
- 避免重复造轮子，节省开发维护成本；
多个团队公用同一个组件，在一定层度上确保了技术方案的统一性。
总结：其实组件化更多的是适合于项目大 但是功能相对集中的一些项目。比如 一个金融类的App 里面只包含金融的功能，金融功能又会有 借贷，理财，线下交易，把这些模块抽成单独的组件。
插件化开发
插件化是将一个apk根据业务功能拆分成不同的子apk（也就是不同的插件），每个子apk可以独立编译打包，最终发布上线的是集成后的apk。在apk使用时，每个插件是动态加载的，插件也可以进行热修复和热更新。它也是属于模块化的一种体现。不过它的单位是apk，一个完整的项目。灵活性在于加载apk，按需下载，动态更新。
如果一个应用所有的功能是非常多的，比如滴滴、美团、支付宝，他们除了一些基础的业务功能，还有其他的业务功能，如果都打成一个apk，文件将非常大，用插件化的方式开发后，apk只包含基础的业务功能，使用过程中用户可以按需加载自己需要的功能模块。
插件化的开发并没有一个官方的插件化方案，它是国内提出的一种技术实现，利用虚拟机的类的加载机制实现的一种技术手段，往往需要hook一些系统api，而Google从Android9.0开始限制对系统私有api的使用，也就造成了插件化的兼容性问题，现在几个流行的插件化技术框架，都是大厂根据自己的需求，开源出来的，如滴滴的VirtualAPK，360的RePlugin等。
总结：插件化开发适合于项目超级大 但是功能相对不集中比如 一个支付宝App 里面即包含共享单车 也包含 电影票。这种与本业务完全不同的 可以做成插件的形式。
插件化和组件化的区别
| 技术 | 单位 | 实现内容 | 灵活性 | 特性 | 静动态 |
|---|---|---|---|---|---|
| 组件化 | 组件（module） | 解耦与加快编译， 隔离不需要关注的部分 | 按加载时机切换，是作为lib，还是apk；组件化能做的只是， 朋友圈已经有了，我想单独调试，维护，和别人不耦合。但是和整个项目还是有关联的。 | 组：每个组件，可以独立编译，开发；但本质上他不是完全独立的，例如一个登录模块，它是和整个项目有关联的，是项目的组成部分 | 编译期可以动态的添加和修改，运行时不具备 |
| 插件化 | apk(一个完整的应用) | 解耦与加快编译，同时实现热插拔也就是热更新 | 加载的是apk，可以动态下载，动态更新，比组件化更灵活；插件化是朋友圈就是一个app, 我需要整合了，把它整合进微信这个大的app里面 | 插：是独立的apk，每个插件可以作为一个完全独立的apk运行，也可以和其他插件集成为大apk。 | 编译期和运行时都可以动态的添加和修改，所以它比组件化更灵活 |
插件化和组件化的选择
理想的代码组织形式应该是插件化的方式，届时就具备了完备的运行时动态化，更灵活，各个插件的开发独立自主性更强。
但是目前还没有一个完美兼容的插件化方案。
选择插件化需要考虑两个方面：
- 兼容性。一是插件化不可避免的去 hook 一些系统的 api，也就不可避免地有兼容性的问题，因此每个插件化方案需要有专门的团队去负责维护；
- 开发节奏。二是从一个业务逻辑复杂的项目中去拆分插件化需要的时间可能是非常巨大的，同时把原有的项目集成到一个平台上，需要使用插件化的相关技术去修改，对Android四大组件的兼容性，对原来实现方式的适配都是一个挑战。
- 支持性。应用市场的支持：目前Google Play是不允许插件化的这种动态加载，增量更新方式的app上架的，因为这样会绕过审核，保不齐一些不良 App “挂羊头卖狗肉”，等用户下载、安装 App 之后，热更新出其他不良功能。目前国内市场还没明文规定。技术上的支持：一定程度上说，谷歌是不鼓励这种开发方式的，对私有api的限制以后会越来越严格，现有市场上的框架都是三年之前的。
大多数情况下，组件化都是一个不错甚至最佳的选择，它没有兼容性，可以更方便地拆分，并且几乎没有技术障碍，可以更顺利地去执行。特别是对急需拆分的产品来说，组件化是一个可退可守的方案，可以更快地执行下去，并且将来要是迁移到插件化，组件化拆分也是必经的一步。
最后
关于组件化方面的具体知识，推荐大家去看玉刚说的《Android 组件化最佳实践》和杨充的《Android组件化开发实践和案例分享》两位大佬的两篇文章，个人感觉讲的很全面，也容易理解。
