1.架构演变
1.1 单工程模式
我们开发移动项目,我相信大多用的是单工程单任务的开发模式,二话不说,直接就开始写起,是不是这样呢? new Project -> 分包 -> 写起, 简单直接粗暴,但有效率,上手快,没有杂七杂八的处理方式。这是因为项目简单,业务单一。
2.1 模块化
Android Studio出来了,多出来了一个新的概念, Project, Module... 当时以包的形式分离的公共包common,现在成了AS中的Module。大家都知道,Module包含两种格式: application, library。也就是说,一个Module就是一个小的项目,也是AS概念中的模块。因此我们开始设计common模块, common_business模块,甚至db模块。模块的好处是什么? 相比于包来讲,模块更灵活,耦合更低,随意插拔,想引入哪个就引入哪个。根据不同的关注点,将一个项目的可以共享的部分抽取出来,形成独立的Module,就是模块化。模块化不只包含公共部分,当然也可以是业务模块。
2.2 组件化
模块化和组件化有什么区别? 到底有什么区别呢,其实很小;但并不是完全相同的概念。组件化是建立在模块化思想上的一次演进,一个变种。组件化本来就是模块化的概念。但是组件化的核心是什么? 是模块角色的可转换性。是的,就是可转换性。
组件化的核心是角色的转换。 在打包时, 是library; 在调试时, 是application。
怎么理解组件化的概念 ?
Module的模式分两种, application和library。 library就是引用库,如你抽取的common。 application就是一个apk, 是一个完整的项目。
在调试时,我只关心我负责的模块,我希望我的模块是一个单独的app,因为这样更小,业务更专一,相对来讲修改与调试就会越省时省心,编译就会越快。
2.3 插件化
插件化和组件化又有什么区别呢?插件化严格意义来讲,其实也算是模块化的观念。将一个完整的工程,按业务划分为不同的插件,都是分治法的一种体现。化整为零,相互配合。,越小的模块越容易维护。 插件化按理也算是模块化的一种体现,和组件化就不一个概念了。插件化和组件化区别如下:
(1)组件化的单位是组件(module)。 插件化的单位是apk(一个完整的应用)。
(2)组件化实现的是解耦与加快编译, 隔离不需要关注的部分。 插件化实现的也是解耦与加快编译,同时实现热插拔也就是热更新。
(3)组件化的灵活性在于按加载时机切换,分离出独立的业务组件,比如微信的朋友圈 插件化的灵活性在于是加载apk, 完全可以动态下载,动态更新,比组件化更灵活。组件化能做的只是, 朋友圈已经有了,我想单独调试,维护,和别人不耦合。但是和整个项目还是有关联的。 插件化可以说朋友圈就是一个app, 我需要整合了,把它整合进微信这个大的app里面
(4)
组件本来就是一个系统,你把微信分为朋友圈,聊天, 通讯录按意义上划为独立模块,但并不是真正意义上的独立模块。 插本来就是不同的apk, 你把微信的朋友圈,聊天,通讯录单独做一个完全独立的app, 需要微信的时候插在一起,就是一个大型的app了。 插件化的加载是动态的,这点很重要,也灵活的源泉
2. 架构的核心
所谓架构,无非两个方面: 分层和通信方式。 其实广义的架构也可以说是这两个方面:子模块(子系统)划分和通信。
2.1 子模块的划分
除了大家公认的common部分, 业务模块的划分尤为重要,相比于狭义上的架构,广义上的子系统的划分的关注点,很考验技术经验以及对业务的理解。
2.2 通信方式
模块化的通信方式,无非是相互引入;我抽取了common, 其他模块使用自然要引入这个module
组件化的通信方式,按理说可以划分为多种,主流的是隐式和路由。隐式的存在使解耦与灵活大大降低,因此路由是主流
插件化的通信方式,不同插件本身就是不同的进程了。因此通信方式偏向于Binder机制类似的进程间通信
3. 组件化方案
3.1 组件化基本技术知识
(1)反射与apt
(2)gradle与groovy
(3)路由机制
3.2 面临的问题
问题1:多业务模块下的统一配置
问题2:模式切换
问题2:Application分发
问题3:资源的冲突
注意:不同的业务模块禁止彼此依赖
3.3 统一配置
定义一个配置文件,统一存放需要配置的项。如下
ext {
isModule = false // 组件开关: true 组件 false 集成
defaultConfig = [
minSdkVersion : 14,
targetSdkVersion : 26,
versionCode : 1,
versionName : "1.0",
testInstrumentationRunner: "android.support.test.runner.AndroidJUnitRunner"
]
android = [
compileSdkVersion: 26
]
applicationId = [
app : "com.archer.componentsarchitecture",
card1: "com.archer.card1",
card2: "com.archer.card2"
]
supportLibrary = "26.1.0"
appcompatv7a = "com.android.support:appcompat-v7:${supportLibrary}"
resourcePrefixs =[
card1: "card1",
card2: "card2"
]
router = [
arouter: "com.alibaba:arouter-api:1.2.1.1",
processor: "com.alibaba:arouter-compiler:1.1.2.1"
]
}
在Project下创建一个config.gradle.ext是groovy提供的扩展参数,不可修改的。 以下可以随意定义自己的配置,如代码。这里说下两个概念:
- 占位符 ${supportLibrary} 占据一个位置,然后用{}里面的变量补充,达到一致配置的目的
- android = [
compileSdkVersion: 26
]
以上相当于定义了一个Map, 存放键值对,以Key: Value的形式,以,分隔。这是groovy的写法。android 为Map的名称,你可以用你自己的命名,但是注意不要和系统变量冲突
以上是统一变量的定义,配置文件config.gradle。 配置文件定义好了,那么如何引入呢?
1.在[Project]下的build.gradle引入配置文件
apply from: "config.gradle"
buildscript {
repositories {
google()
jcenter()
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.0.1'
//黄油刀
classpath "com.jakewharton:butterknife-gradle-plugin:8.4.0"
//数据库GreenDAO
classpath 'org.greenrobot:greendao-gradle-plugin:3.2.2'
}
allprojects {
repositories {
google()
jcenter()
maven { url 'https://jitpack.io' }
}
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}
2.在Module中引用是通过rootProject.ext.你定义的名称。但是每次这么用比较繁琐,推荐定义变量实现,如下
if (isModule) {
apply plugin: 'com.android.application'
} else {
apply plugin: 'com.android.library'
}
def cfg = rootProject.ext.defaultConfig
def drd = rootProject.ext.android
def app = rootProject.ext.applicationId
android {
compileSdkVersion drd.compileSdkVersion
defaultConfig {
if (isModule) {
applicationId app['card2']
}
minSdkVersion cfg.minSdkVersion
targetSdkVersion cfg.targetSdkVersion
versionCode cfg.versionCode
versionName cfg.versionName
testInstrumentationRunner cfg.testInstrumentationRunner
resourcePrefix rootProject.ext.resourcePrefixs['card2']
javaCompileOptions {
annotationProcessorOptions {
arguments = [ moduleName : project.getName() ]
}
}
}
调用Groovy map中的字段的两种方式: rootProject.ext.android.key和 rootProject.ext.android['key']
3.4 模式切换
组件化的思想是Module模式的切换。 上面已经说过,在打包时,业务module为library; 调试时,业务module成了application。
(1)如何切换module的模式呢 ?
定义一个Boolean变量作为开关。根据开关分别设置module的模式,如下
if (isModule) {
apply plugin: 'com.android.application'
} else {
apply plugin: 'com.android.library'
}
(2)两种模式的区别是什么?
1. applicationId (包的配置)
只存在于apply plugin: 'com.android.application'模式下
2. Manifest.xml(主页面的配置)
集成模式下,使用app模块下的Manifest.xml配置; 组件模式下,使用组件自己的Manifest.xml配置
3. Application
不同的组件肯定有自己的初始化的资源或框架,因此自定义的Application也是必要的。但是集成模式下,会造成重复的Application
全部配置如下:
// 自由控制模式转换
if (isModule) {
apply plugin: 'com.android.application'
} else {
apply plugin: 'com.android.library'
}
// 包名配置
defaultConfig {
if (isModule) {
applicationId app['card2']
}
}
// Manifest.xml application配置
sourceSets {
main {
if (isModule) {
// src/main下新建文件夹,存放组件模式下的Manifest.xml与Application
manifest.srcFile 'src/main/component/AndroidManifest.xml'
java.srcDirs = ['src/main/java', 'src/main/component/java']
} else {
// library模式下不需要Application
manifest.srcFile 'src/main/AndroidManifest.xml'
java.srcDirs 'src/main/java'
}
}
}
以上配置在相应Module中的build.gradle的android下
3.5 Application分发
application的分发,错误的做法是不同的组件下初始化自己的框架,工具等。正确的做法是在BaseApplication或统一实现公共模块如网络, 缓存, 数据库等的初始化,在各Module实现自己需要的初始化,来避免重复的初始化与冲突。
3.6 资源冲突
资源的冲突解决办法有两个:
1) 公共资源建议由公共模块管理
2) 模块私有资源,添加前缀限制 (只能解决xml冲突)
3)资源谨慎命名
资源命名只能在开发中加以注意, 通过以上共有资源和前缀极大可能的保证资源不会冲突,且不会重复浪费。至于万一的冲突,只能交给开发规范了。
4.总结
组件化的配置核心就是library和application的toggle。 真正实现的功能核心却是通信部分的路由实现部分