前言
组件化是什么，是把一个功能完整的 App 或模块拆分成多个子模块, 表现在androidStudio项目工程里就是分多个module。每个子模块可以独立编译和运行, 模块之间可以任意组合成另一个新的 App 或模块, 每个模块不必须相互依赖但可以相互调起和通信。
组件化的意义，对于一个小型项目来说可能觉得多此一举，但是对于一个中型以上的项目，组件化还是非常有意义的。APP版本不断的迭代，新功能的不断增加，业务也会变的越来越复杂，的代码也变的越来越多，代码耦合严重，影响开发效率，增加项目的维护成本，编译代码的时间长，每修改一处代码后都要重新编译整个项目。组件化的出现就是解决以上问题，并且还具备自由组装成新的模块的优点。
我研究组件化主要还是为了技术储备和支持新业务的开发，对于主项目要使用的话，就相当于项目重构，比较费时费力，在各组都有KPI的情况下是不会给我们时间重构的，闲话不多说，下面介绍组件化框架和搭建过程中注意的问题。
组件化架构
直接上图：
架构介绍：
如图一共分了4层：应用层、业务组件、功能组件、基础组件。
- 应用层：我们的app壳工程，负责管理各个业务组件，和打包apk，没有具体的业务功能。
- 业务组件：具体业务而独立形成一个的工程，可以单独运行提供功能。
- 功能组件：APP的某些基础功能，可单独编译，但不会单独发布提供功能apk。
- 基础组件：开源的第三方的库。
Eventbus 是用来各层之间的通信，组件路由是用来实现组件之间的通信和调起。
网上有的文章有不同的分层发，有人分三层把业务组件和功能组件统称组件层。有人对业务组件进行细分，如Main组件。整体是一样的，关键大家能理解整个架构。
组件化项目结构介绍
直接上图：
大家看到有多个module，以app_开头的是可以单独打包发布的module，也就是app壳module，和业务组件module，module开头的是不单独打包发布的组件，就是功能组件。我们一一说明：
- app：app壳，就是我们主项目。
- app_radio:电台业务模块，可以单独作为电台app发布，也是app主项目的一个功能模块。
- module_core：项目的基础核心组件，说是基础，他是对基础组件的封装，包括架构图中的Glide、Retrofit、Rxjava等的封装，提供基础功能。说是核心，他是对项目基础架构的封装，这里使用的是MVP架构。
- module_commons：封装组件共用的类和资源，各组件模块解耦之后，避免不了一些共用的类和资源，比如实体类、错误页、dialog等。
- module_router：封装组件路由，实现组件调起和通信。
- module_share / module_playserservice：我们项目用到的功能组件，不是必要的。
网上有同学有不同的module分发，比如module_commons进一步细分公共的类module和资源module。大家可以根据实际情况细分。到这里大家会发现组件化的一个弊端，就是项目会有很多的module。
组件化搭建注意问题
组建如何单独编译
思路就是在build.gradle的区分是apply plugin: 'com.android.application'还是apply plugin: 'com.android.library'。具体实现：
在gradle.properties文件添加一个判断属性
isBuildAsModule=false
在build.gradle里根据属性加载不同插件：
if(isBuildAsModule.toBoolean()){
apply plugin: 'com.android.application'
}else{
apply plugin: 'com.android.library'
}
在两种情况下AndroidManifest.xml文件是有差别的。作为独立运行的app，有自己的Application，要加Launcher的入口intent，而作为library不需要。所以需要写两个不同的AndroidManifest.xml即可，通过isBuildAsModule加以区分。
if (isBuildAsModule.toBoolean()) {
manifest.srcFile 'src/main/module/AndroidManifest.xml'
} else {
manifest.srcFile 'src/main/library/AndroidManifest.xml'
}
这种方式同时避免了AndroidManifest.xml清单文件冲突问题。
其他需要区分两种编译模式，原理相同。
基础库和SDK版本号统一
这是多module开发需要解决的问题，不同module的依赖sdk版本不一致或者引入的库版本不一致会导致编译问题和兼容性问题。解决办法是在主项目最外层用一个config.xml文件来统一管理基础库和sdk的版本。config.xml部分代码如下：
def retrofit_version = '2.3.0'
def okhttp_version = '3.9.0'
def dagger_version = '2.11'
def autodispose_version = "0.5.1"
def support_version = '27.1.0'
def espresso_version = '2.2.2'
def glide_version = '4.6.1'
def butterknife_version = '8.8.1'
def routerVersion = "1.2.4"
def routerCompilerVersion = "1.1.4"
project.ext {
android = [
compileSdkVersion: 27,
buildToolsVersion: "27.0.3",
applicationId : "com.taihe.music.mvpsample",
minSdkVersion : 16,
targetSdkVersion : 27,
versionCode : 1,
versionName : "1.0"
]
dependencies = [
//android-support
"support-v4" : "com.android.support:support-v4:${support_version}",
"appcompat-v7" : "com.android.support:appcompat-v7:${support_version}",
..........
使用config.xml，时在最外层build.gradle配置config文件：
apply from: "config.gradle"
具体引入基础库的地方在各module的build.gradle文件里：
minSdkVersion rootProject.ext.android["minSdkVersion"]
targetSdkVersion rootProject.ext.android["targetSdkVersion"]
versionCode rootProject.ext.android["versionCode"]
versionName rootProject.ext.android["versionName"]
.....
//glide
api rootProject.ext.dependencies["glide"]
annotationProcessor rootProject.ext.dependencies["glide-compiler"]
组件之间资源名冲突
组件之间如果资源命名相同，就会产生冲突，解决这个问题最简单的办法就是在项目中制定资源文件命名规范，比如app_radio组件所有资源以radio_开头，所有开发人员必须遵守规范。
当然，gladle也给我提供了解决方案，就是在build.gradle中添加如下的代码：
resourcePrefix "radio_"
设置了这个属性后，所有的资源名必须以指定的字符串做前缀，否则会报错。而且这种形式只能限定xml里面的资源，并不能限定图片资源，我们仍然需要手动去修改资源名；所以不推荐使用这种方法来解决资源名冲突。
基础组件依赖问题
所有的基础组件我们封装在module_core中，这样就存在一个问题，我们项目依赖了module_core就默认依赖了所有的基础组件，但实际情况中我们是不需要依赖所有的，或者module_core中的基础组件和其他模块有冲突的情况。所以我们需要排除掉用不到和重复的库，Gradle支持两种排除方式，根据组件名排除或者根据包名排除，代码如下：
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar']) compile("com.jude:easyrecyclerview:$rootProject.easyRecyclerVersion") {
exclude module: 'support-v4'//根据组件名排除
exclude group: 'android.support.v4'//根据包名排除
}
}
组件之间跳转和通信
组件之间的页面调起，虽然我们可以使用intentFilter来实现Activity的隐式启动，但是逻辑上存在耦合，并且不支持Fragment，所以这里我们使用的是阿里的组件路由Arouter。它可以实现Activity和Fragment的调起，支持依赖注入和数据通信。这里我们只介绍Activty调起，详细使用可参考https://blog.csdn.net/zhaoyanjun6/article/details/76165252
我们以调起app_radio组件中的HomeActivity为例,HomeActivity类配置如下：
@Route(path = RouterConstants.RADIO_HOME_ACTIVITY)
public class HomeActivity extends BaseActivity<HomePresenter> implements HomeContract.View {
@BindView(R2.id.btnUserInfo)
Button button;
@BindView(R2.id.ivTest)
ImageView imageView;
........
调起HomeActivity的代码：
ARouter.getInstance()
.build(RouterConstants.RADIO_HOME_ACTIVITY)
.withObject("user", userModel)
.navigation()；
可以看出组件路由需要定义常量RouterConstants.RADIO_HOME_ACTIVITY来关联调起页面，withObject("user", userModel)是页面间传递的数据。
手动单独编译
组件化的一个优点就是可以单独编译，但是在开发过程发现有的时候修改了模块module里一些配置文体之后，编译主app，模块module不会重新编译，导致修改无效。所以在修改了配置文件之后最好手动编译module确保修改有效。单独编译的入口在下图：
动态变化网络baseUrl
module_core中我使用Retrofit+OKhttp封装的网络层，并对外提供配置接口，包括配置baseUrl，主module中Applicatuion中会完成这些配置。问题来了，如果其他模块使用baseUrl不同怎么处理。思路就是，对OkHttp进行修改，无非就是使用拦截器，幸好好心人提供了开源库RetrofitUrlManager可以解决该问题。详细参考，https://github.com/JessYanCoding/RetrofitUrlManager
动态修改baseurl的代码：
将OkHttpClient.Builder传给RetrofitUrlManager。
RetrofitUrlManager.getInstance().with(builder);
以app_radio配置baseUrl为例：
RetrofitUrlManager.getInstance().putDomain(RADIO_DOMAIN_NAME, RADIO_BASE_API);
RADIO_BASE_API为具体的baseUrl，RADIO_DOMAIN_NAME为对应的key。
具体使用Retrofit来定义请求接口时：
@Headers({DOMAIN_NAME_HEADER + RADIO_DOMAIN_NAME})
@GET("users/{user}")
Maybe<UserInfo> getUserInfo(@Path("user") String user);
这样就可以实现baseUrl的动态变化。同理如果其他的网络配置不同也是使用拦截器是形式来修改，大家可以参考RetrofitUrlManager的实现。
本文从整体上介绍了组件化的搭建问题，没有具体到基础库和框架的封装，也就是module_core的搭建和使用。想要熟悉整体框架或者使用，首先要熟悉第三方库的使用和原理，封装的过程就是改造的过程所以要了解基本原理；其次再熟悉module_core的封装代和使用，最后才是本文提到的组件化过程中的问题解决。
跟本文一样，大部分开源组件化项目，基础库用到了Dagger、Rxjava。这两个开源项目需要一定的学习成本，建议大家择情而定是否使用。
