基于组件化 + MVP + Retrofit + RxKotlin + Dagger2实现的一款用Kotlin语言编写的影视类应用。
实现了两个功能：
- 1.自动切换library和Application
如果gradle.properties中配置了isRunAlone=true，也就是能够独立运行，那么点击运行按钮可以选择该模块自动运行,无需在build.gradle文件中配置。如果运行的是主module，不管其依赖的module是否可以独立运行，插件自动设置为library。实现真正的自动切换。
//不需要再通过变量来控制了
if(isHomeModule.toBoolean()){
apply plugin: 'com.android.library'
}else{
apply plugin: 'com.android.application'
}
//省略资源目录的配置
- 2.主Module在开发时不依赖业务模块，只要在运行打包时才依赖，彻底避免业务模块之间的耦合
通过在build.gradle配置，通过字节码插桩来实现的。
combuild {
applicationName = 'com.gfd.home.app.HomeApplication'
isRegisterAuto = false
}
主module依赖其他模块配置在该目录下的gradle.properties中配置：
debugComponent=Home,Crosstalk,Music,Player //debug时依赖的
compileComponent=Home,Crosstalk,Music,Player //release时依赖的
不需要在build.gradle中依赖了
api project(':Home')
api project(':Music')
......
这样主Module在开发时不再依赖具体的业务模块，只是使用业务模块提供的服务，所以业务模块需要实现Provider模块定义的接口，提供具体的业务。
interface IApplicationLoad {
/** 组件加载*/
fun registered()
/** 组件卸载*/
fun unregistered()
}
定义Music模块提供的服务
interface MusicService {
fun getMusicFragment(): BaseFragment
}
该文件夹存放的是业务模块的.aar包，在执行业务Module的
assembleRelease命令后会生成对应的.aar包，也可以上传到maven仓库。这样的话主Module只需要依赖.arr包。哪个业务Module改变只需要编译哪个生成对应的.aar包即可，实现真正的组件化。
如果项目中的module很多，gradle在编译的时候会去检测module的依赖链，gradle会帮助我们层层梳理module之间的关系，避免因为module之间相互引用而来带的问题。这些梳理工作和module的合并工作都会带来build的时间，会造成build十分缓慢，所以将稳定的module打包为aar，上传到公司的maven仓库，借此来加快build速度。
项目中用到的数据都是通过解析网站数据而来，所以没有固定的接口格式。因此没有封装统一的网络工具类，而使用三方库okhttp-OkGo来请求，便于解析数据。
采用smallestWidth适配
smallestWidth限定符适配和宽高限定符适配最大的区别在于，前者有很好的容错机制，如果没有对应dp文件夹，系统会向下寻找，比如离360dp最近的只有value-sw350dp，那么Android就会选择value-sw350dp文件夹下面的资源文件。这个特性就完美的解决了上文提到的宽高限定符的容错问题。
common.gradle：三方依赖库和版本管理，统一放在该文件中。
and_res_guard.gradle：微信开源工具AndResGuard资源文件"混淆"配置文件。
libbase.gradle：多Module build文件公共部分抽取。
releaseinfo.gradle：版本发布文档自动维护脚本
Common为公共库，主要包含一些基类和常用的工具类，Provider依赖于Common，是模块真正依赖的库。其中业务模块包括：Home，Music，User，Player。每个业务模块对应一个Module。主模块APP和业务模块都依赖Provider，主模块APP在开发阶段不再依赖具体的业务模块，彻底隔离业务模块之间的耦合。业务模块统一实现Provider中定义的接口，暴露需要提供的服务。
