上篇文章笔者分享的组件化主要是项目内组件化，毕竟在一个项目中，组件间也是有一定的耦合性。例如跳转不用Arouter依然可以跳转，每个组件不单独开放接口，也不影响使用。所以项目内组件化和项目外组件还是有一定的差别。
组件化不是将大的工程拆分成几个子工程就叫组件化，组件化的本质，就是组件在没有依赖或者很少依赖的情况下和其他组件通信，可以独立存在的。独立存在的基础上，在让其他组件能正确且便捷的使用它。
这篇文章介绍下，将项目的各个组件单独抽出，然后单独扯一个git分支，独立开发。然后根据各个成型的组件，去开发定制产品。
组件的划分
要想单独开发每一个分支，就必须合理的拆分组件。笔者是给项目拆分了3类组件。分别是业务组件、公共业务组件、功能组件。
业务组件
不同业务的功能模块，具体和公司业务相关。例如我司的业务开门模块，论坛模块、新闻广告模块、电商模块、金豆集卡模块、物管模块等，每一个业务模块都可以划分成一个业务组件。
公共业务组件
公共的业务逻辑、公共的工具类，以及公共的ui，和通用的自定义view，能被放到这里面的代码，共性就是至少有2个组件都需要的。
功能组件
例如基础框架，网络组件，缓存组件，支付组件等，这些都是和公司业务没有关系，每一个项目如果需要都可以直接引入并且使用。
如何引入组件
本地aar引入
在项目使用aar时候，不管是否使用implementation或者api关键字，其相关依赖都不会被编译到aar文件中，导致aar自身需要的远程依赖查找不到。解决方法就是将aar需要的自身依赖在引入aar工程项目中再手动声明一遍，供aar使用，这样太不方便了，而且有额外工作量。
经过一番查找，发现码友们为了解决此问题，有人开发出来了一个 Gradle 插件 android-fat-aar（https://github.com/adwiv/android-fat-aar ）, 这种方式是抛弃 Android Studio 自带的打包 AAR 的方法，而是自己编写一个生成 AAR 的脚本。的确没有难道的程序员，但是唯一不好的就是，需要降低gradle版本，这一点也是我pass掉这种做法的原因，毕竟gradle的版本紧随谷歌爸爸有利无害。
远端仓库引入
如果将library打成aar上传到远端仓库呢？例如jitpack、jcenter、私服等。在尝试之后可以发现将aar传到远端仓库，之后远程依赖引用，项目引入aar之后也可以获取aar自身需要的远程依赖。为什么呢？因为aar在上传私服的时候，他会传一个.pom文件，而这个pom文件会有记录它的远程依赖库，所以在引入私服的aar时候就会将它的远程依赖库随着下载，供aar使用。私用远端仓库无疑是一个不错的选择。
但是仓库这么多，用哪个比较合适呢？jitpack的确方便，毕竟是github登录，个人账户，不适合公司项目。jcenter上传流程复杂，而且需要审核时间，这如果要上线岂不是还要等各组件审核通过，没比较把时间浪费在这。公司内部搭建nexus私服，上传简单，而且添加权限无需审核。具体如何通过Jcenter，或者私服可以参考笔者这两篇文章。
如何将Android studio中Library发布到Jcenter
https://blog.csdn.net/f917386389/article/details/52121809
如何将Android studio中Library发布到私服Nexus仓库
https://blog.csdn.net/f917386389/article/details/87741281
私服上传问题
1>嵌套依赖问题
如果被打成aar的library，自身除了有三方远程依赖库外，还有本地library依赖的外，上传私服就会报另外一种错误，就是查到不到依赖的本地library，奇怪不是pom文件都记录了它所依赖库吗，打开远端pom文件看到，相应的library的version为unspecified。
<dependency>
<groupId>shopcomponent</groupId>
<artifactId>mylibrary</artifactId>
<version>unspecified</version>
<scope>compile</scope>
</dependency>
</dependencies>
因为maven是通过在进行对库的管理，上传时候并没有版本，所以它也无法设置版本号。所以如果使用私服maven管理aar的时候，你需要将aar依赖的本地library先上传到私服maven，然后这个library在gradle去依赖，在将这个library打成aar传私服maven，然后通过方式去引入。
2>不同仓库类型使用
每一次修改代码都需要aar重新打包，上传，如果你没有变更版本号，就会报次错，因为release版本不运行相同版本存在。nexus私服为了解决这个不便，新增了不同类型的仓库。一个是release，一个是snapshot。其中snapshot适合我们平时开发时候，每次修改代码无须修改版本号，直接打包提交，也能成功上传，并且可以下载使用。
需要注意的是，要使用snapshot仓库不仅仅是更换仓库地址，而且需要将上传的aar的版本信息后面添加-SNAPSHOT才可以，切记！
3>Android Studio引入的External Libraries存放在本地什么地方？
有时间我们需要更新新的library版本，由于本地有缓存，点击同步不能下载下来，我们可以找到本地library手动删除，在去同步下载。
Mac系统默认下载到：
/Users/(用户名)/.gradle/caches/modules-2/files-2.1
Windows系统默认下载到：
C:\Users\(用户名)\.gradle\caches\modules-2\files-2.1
组件的整合
在做定制产品时候，需要将不同的业务组件整合到一块，不同的业务组件里面会包含相同的公共业务组件以及功能组件。之前想着用implementation取代api引入，因为在android studio3.0之后，implementation和api取代了compile，而且implementation不可以向上传递依赖。但是这个是有前提的，前提是都是本地引入，对于远端仓库引入library时，无论是implementation还是api依旧可以传递依赖。例如引入不同的业务组件，它们都包含公共业务组件以及功能组件，这时候gradle引入的私服仓库时候，它会自动去重，优先取第一个引入的。如果你强行要过滤某个组件，可以使用exclude关键字。
implementation ('com.zzti.fyg:logincomponent:0.0.1-SNAPSHOT',{
exclude group: 'com.zzti.fyg',module: 'basebusiness'
})
统一不同业务组件的buildTypes
每一个library 中的 build.gradle 文件设置都可以设置 buildTypes 代码，但通过 要上传到私服上的 aar 包只能是 release 版本，自然也无法获取到那些动态配置的常量值。例如切换线上线下地址，毕竟我们最后更换Build Variants是要手动切换，所以我的做法是由壳添加变量，然后传入basebusiness组件中，然后每一个业务组件接口请求都需要baseurl，这个baseurl都通过basebusiness组件中去获取。这样就可以通过更改壳的buildTypes，来更换所有业务组件的buildTypes变量。
