Android 组件化架构设计从原理到实战

组件化图解说明（文末有推荐的组件化项目）

1. 组件化概念

组件化开发：就是将一个app分成多个Module，每个Module都是一个组件（也可以是一个基础库供组件依赖），每一个业务模块彼此之间是没有任何关系的， 彼此的代码和资源都是隔离的，并且不能够相互引用，每一个都是平行关系。开发的过程中我们可以单独调试部分组件，组件间不需要互相依赖， 但可以相互调用，最终发布的时候所有组件以lib的形式被主app工程依赖并打包成1个apk。

1.1 组件化架构的优势

基于以上这些问题，现在的组件化架构希望可以解决这些问题提升整个交付效率和交付质量。 组件化架构通常具备以下优点：

1. 代码复用-功能封装成组件更容易复用到不同的项目中，直接复用可以提高开发效率。并且每个组件职责单一使用时会带入最小的依赖。
2. 降低理解复杂度-工程拆分为小组件以后，对于组件使用方我们只需要通过组件对外暴露的公开API去使用组件的功能，不需要理解它内部的具体实现。 这样可以帮助我们更容易理解整个大的项目工程。
3. 更好的解耦-在传统单一工程项目中，虽然我们可以使用设计模式或者编码规范来约束模块间的依赖关系，但是由于都存放在单一工程目录中缺少清晰 的模块边界依然无法避免不健康的依赖关系。组件化以后可以明确定义需要对外暴露的能力，对于模块间的依赖关系我们可以进行强约束限制依赖，更好 的做到解耦。对一个模块的添加和移除都会更容易，并且模块间的依赖关系更加清晰。
4. 隔离技术栈-不同的组件可以使用不同的编程语言/技术栈，并且不用担心会影响到其他组件或主工程。例如在不同的组件内可以自由选择使用Kotlin或Swift， 可以使用不同的跨平台框架，只需要通过规范的方式暴露出页面路由或者服务方法即可。
5. 独立开发/维护/发布-大型项目通常有很多团队。在传统单一项目集成打包时可能会遇到代码提交/分支合并的冲突问题。组件化以后每个团队负责自己的组件， 组件可以独立开发/维护/发布提升开发效率。
6. 提高编译/构建速度-由于组件会提前编译发布成二进制库进行依赖使用，相比编译全部源代码可以节省大量的编译耗时。同时在日常组件开发时只需要编译 少量依赖组件，相比单一工程可以减少大量的编译耗时和编译错误。

1.2 背景

随着项目逐渐扩展，业务功能越来越多，代码量越来越多，开发人员数量也越来越多。此过程中，你是否有过以下烦恼？

1. 项目模块多且复杂，编译一次要5分钟甚至10分钟？太慢不能忍？
2. 改了一行代码或只调了一点UI，就要run整个项目，再忍受一次10分钟？
3. 合代码经常发生冲突？很烦？
4. 被人偷偷改了自己模块的代码？很不爽？
5. 做一个需求，发现还要去改动很多别人模块的代码？
6. 别的模块已实现的类似功能，自己要用只能去复制一份代码再改改？
7. “这个不是我负责的，我不管”，代码责任范围不明确？
8. 只做了一个模块的功能，但改动点很多，所以要完整回归测试？
9. 做了个需求，但不知不觉导致其他模块出现bug？ 如果有这些烦恼，说明你的项目需要进行组件化了。

2. app空壳工程：

1. 配置整个项目的Gradle脚本，例如混淆、签名等；
2. app组件的build.gradle中可以配置极光推送JPUSH_PKGNAME和JPUSH_APPKEY，以及它的权限；
3. 业务组件管理（组装）；

2.1 业务组件：Main组件（module_main）：

• 属于业务组件，指定APP启动页面、主界面；

2.2 业务组件: 根据公司具体业务而独立形成一个个的工程（module_home/module_project/module_square/module_resource/module_mine）：

1. 这几个组件都是业务组件，根据产品的业务逻辑独立成一个组件；
2. 每个组件都应该是可独立运行的，没有必要把model封装到基础层。如果需要共用同一个model，那要么划分组件就不合理，要么通过ARouter从别的组件获取fragment的方式解决。 如果实在要把model封装到基础层，方便组件共享数据模型，那么必须新建一个库放在基础层（这里命名为library_login）不允许放library_common里，因为要保证基础层的库都服从单一职责。

2.3 library组件：就是功能组件（library_base/library_common/library_network/library_glide/library_room/library_mvp/library_mvvm......）：

1. 基础层的设定就是为了让组件放心地依赖基础层，放心地复用基础层的代码，以达到高效开发的目的。所以，不要让基础层成为你的代码垃圾桶。对基础层的要求有两个，对内和对外。 对外，命名要秒懂。这样在写组件的业务代码的时候，多想一下基础层里的代码，复用比造轮子更重要。 对内，要分类清晰。还有，封装到基础层的代码，其他组件不一定想用，不是说不写，而是说少写，以及分类清晰地写，所以在封装到基础层之前，先经过code review。
2. library_base和library_common组件是基础库；
3. library_network组件是网络请求库、library_glide组件是图片加载库、library_room组件是数据库、library_mvp组件是MVP基础库， library_mvvm组件是MVVM基础库等等；

2.4 组件化Application

• 如果功能module有Application，主module没有自定义Application，自然引用功能module的Application。如果功能module有两个自定义 Application，会编译出错，需要解决冲突。可以使用tools:replace="android:name"解决，因为App编译最终只会允许声明一个Application。

3. 组件化的核心就是解耦，所以组件间是不能有依赖的，那么如何实现组件间的页面跳转呢？

例如：在Square模块点击thread pool按钮需要跳转到mine模块的ThreadPoolActivity，两个模块之间没有依赖，也就说不能直接使用显示启动来打开 ThreadPoolActivity。 那么隐式启动呢？隐式启动是可以实现跳转的，但是隐式Intent需要通过AndroidManifest配置和管理，协作开发显得比较麻烦。 这里我们采用业界通用的方式—路由，比较著名的路由框架有阿里的ARouter、美团的WMRouter，它们原理基本是一致的。这里我们采用使用更广泛的ARouter： “一个用于帮助Android App进行组件化改造的框架——支持模块间的路由、通信、解耦”。 ARouter实现路由跳转集成请查看https://github.com/alibaba/ARouter。

4. 集成开发模式和组件开发模式转换

• 首先打开Android项目的gradle.properties文件

  

  ， 然后将isModule改为你需要的开发模式（true/false），然后点击Sync Project按钮同步项目；

• 

  在运行之前，请先按照图中选择一个能够运行的组件；

4.1 app空壳工程下的组件化isModule配置

4.2 module业务组件下的组件化isModule配置

5. 资源命名冲突

• 在组件化方案中，资源命名冲突是一个比较严重的问题，由于在打包时会进行res下的资源（包括drawable、layout、mipmap、raw、values下的资源文件。 请注意：values下的资源文件名不要改动，只需要改动文件内部的内容前缀

  

  ； drawable、layout、mipmap、raw下的资源文件都需要加前缀

  

  ）合并， 如果两个模块中res下的资源有两个相同名字的文件，那么最后只会保留一份，如果不知道这个问题的小伙伴，在遇到这个问题时肯定是一脸懵逼的状态。问题既然已经出现， 那我们就要去解决，解决办法就是每个组件res下的资源都用固定的命名前缀，这样就不会出现两个相同的文件的现象了，我们可以在build.gradle配置文件中去配置 前缀限定，如果不按该前缀进行命名，AS就会进行红色警告提示，配置如下：

android {
    resourcePrefix "前缀_"
}

如对此有疑问，请联系qq1164688204。

推荐组件化架构Android开源项目

项目功能介绍：原本是RxJava2和Retrofit2项目，现已更新使用Kotlin+RxJava2+Retrofit2+MVP架构+组件化

和 Kotlin+Retrofit2+协程+MVVM架构+组件化，添加自动管理token功能，添加RxJava2生命周期管理，集成极光推送、阿里云Oss对象存储和高德地图定位功能。

项目地址：https://gitee.com/urasaki/RxJava2AndRetrofit2