组件化框架的 demo
apply plugin: 'com.android.application'
复制代码
apply plugin: 'com.android.library'
复制代码
业务 Module 划分太细,难以组织,依赖复杂;业务和基础库、公共库之间没有明显区分,组织混乱;
分层
如此一来,整个工程的结构被分为三层,日常开发基本只需要关注最后一层即可。工程架构变成了一个主模块挂载多个业务模块,共同依赖几个功能模块的模式,将这种结构称之为**"组件化"**结构。层次结构及依赖关系图:
理想情况下,主模块承载的业务能力应该尽可能的少,可以只作为整个应用的"壳儿",除应用的初始化配置及主 activity 外,尽量不包含其他业务。
主模块决定挂载哪些业务组件,在应用的初始化过程中进行配置。
组件间通信:接口
业务组件间依赖通过接口发生,实现类不发生直接依赖关系
把每个业务组件对外提供的接口统一存放,可以抽成一个单独模块,比如 service,其中 common 依赖 service
在应用启动时将所有组件的接口注册到接口管理器中,以便于在任何一个业务组件中,都可以访问到其他组件的接口,进而与之通信。当然,接口的实现类在对应的业务组件内。
组件间跳转:Router
目标:日常开发中,业务组件可以单独运行。这样,在针对某个组件修改需求时,可以只运行该组件就可以看到结果或者单步调试,提高编译速度,节省时间。应用打包时,业务组件依然一并输出到 app 中。
基本思想:既然业务组件即可以单独调试,又可以被主 Module 依赖,那么业务组件依赖的 Android 插件就需要动态配置。可以在 debug 模式下,每个组件不再依赖 'com.android.library',而是依赖 'com.android.application' 插件,release 模式下,组件依然依赖 'com.android.library' 插件。这样能够实现,在 debug 模式下,组件以 application 的形式存在,在 release 模式下,组件依然以 library 的方式打到同一个 apk 中。
实现方式:自定义 gradle 插件,根据项目的配置文件(如 当前是否为debug模式、哪个 module 是主module,哪些是组件),动态选择依赖模式 'com.android.library' 或 'com.android.application'
还要解决的问题
应用初始化配置
指定 launcher activity
同样,通过 gradle 的 sourceSets 的配置,也可以指定 manifest 文件,就可以在 manifest 中配置 launcher activity
sourceSets {
main {
if (Boolean.valueOf(rootProject.getProperties().get("isDebug"))) {
manifest.srcFile 'src/main/debug/AndroidManifest.xml'
java.srcDirs = ['src/main/java', 'src/main/debug/java']
res.srcDirs = ['src/main/res', 'src/main/debug/res']
}
}
}
复制代码
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。