组件化：
组件化：
本文章编写前参考于：顾老师的有道云笔记
为什么组件化？
随着APP版本不断的迭代，新功能的不断增加，业务也会变的越来越复杂，APP业务模块的数量有可能还会继续增加，而且每个模块的代码也变的越来越多，这样发展下去单一工程下的APP架构势必会影响开发效率，增加项目的维护成本，每个工程师都要熟悉如此之多的代码，将很难进行多人协作开发，而且Android项目在编译代码的时候电脑会非常卡，又因为单一工程下代码耦合严重，每修改一处代码后都要重新编译打包测试，导致非常耗时，最重要的是这样的代码想要做单元测试根本无从下手，所以必须要有更灵活的架构代替过去单一的工程架构。
组件化与模块化区别？
模块化 vs 组件化
当你看到这的时候,想必心理一阵恶寒:模块化?组件化?到底是什么鬼?有啥区别.
有这种感觉才是对的,模块化和组件化本质思想是一样的,都是”大化小”,两者的目的都是为了重用和解耦,只是叫法不一样.如果非要说区别,那么可以认为模块化粒度更小,更侧重于重用,而组件化粒度稍大于模块,更侧重于业务解耦.
组件化优缺点
组件化开发的好处是显而易见:系统级的控制力度细化到组件级的控制力度,一个复杂系统的构建最后就是组件集成的结果.每个组件都有自己独立的版本,可以独立的编译,测试,打包和部署
产品组件化后能够实现完整意义上的按需求进行产品配置和销售,用户可以选择使用那些组件,组件之间可以灵活的组建.
配置管理,开发,测试,打包,发布完全控制到组建层面,并带来很多好处.比如一个组件小版本进行升级,如果对外提供的接口没有发生任何变化,其他组件完全不需要再进行测试.
但是组件化的实施对开发人员和团队管理者提出了更高水平的要求.相对传统方式,在项目的管理和组织上难度加大,要求开发人员对业务有更深层次上的理解.
组件化的核心是角色的转换。 在打包时， 是library; 在调试时， 是application。
如何配置组件化？
application属性，可以独立运行的Android程序，也就是我们的APP
apply plugin: ‘com.android.application’
library属性，不可以独立运行，一般是Android程序依赖的库文件
apply plugin: ‘com.android.library’
如何组件化
1.新建多个Module
2.在gradle.properties文件中设置每个Module是否需要单独编译的变量
是否需要单独编译 true表示需要，false表示不需要
每个子module的build.gradle中需要将
apply plugin: 'com.android.application'
修改成
if(fengchen_one.toBoolean()){
apply plugin: 'com.android.application'
}else{
apply plugin: 'com.android.library'
}
根据刚才的每个module都有的布尔值变量来设置是application还是library
同理在下面defaultConfig中设置applicationId
defaultConfig {
if(fengchen_one.toBoolean()) {
//applicationId 中方的是包名
applicationId "com.example.home"
}
4每个子module中的清单文件也需要改造
清单文件需要分成两份，放在两个不同的文件夹中
其中debug版清单文件就是普通的清单文件，作为module单独编译时使用
而release版本则是module作为library时使用的
其中去掉了
android:name=".homeApplication" 和 入口Activity
5清单文件编好后在每个子module的build.gradle中还需要配置如何使用清单文件
在Android中配置
sourceSets {
main {
if (fengchen_one.toBoolean()) {
manifest.srcFile 'src/main/debug/AndroidManifest.xml'
} else {
manifest.srcFile 'src/main/release/AndroidManifest.xml'
}
}
}
6各个子module配置好后需要在容器app中配置build.gradle完成对子module的依赖
if (!fengchen_one.toBoolean()) {
implementation project(':home')
}