不以规矩，不成方圆。特别是多人协作开发时，如果没有统一的开发规范，势必会造成各种混乱。在实际开发中，常常会碰到的问题有：
- 引入的某个第三方库版本冲突；
- 不同组件里同名资源文件被覆盖；
- APP壳工程打包时AndroidManifest.xml合并发生错误；
往往单独的组件工程运行良好，但是集成到壳工程时就是不行，所以我们必须要严格遵守规范，尽可能减少这种问题的出现。以下是我在实际开发中采用的一些步骤规范：
1. 新建组件工程
我的每个组件都是一个单独的小工程，而不是像其他的方案那样，只有一个主工程，每个组件只是工程里的一个module，这种方式实质上还是单一工程模式。这样在代码权限管控，组件职责划分上就很明确了，每个工程是一个组件，每个组件有一个owner（也就是负责人）。
打开Android Studio（目前只采用该IDE来开发，其他IDE不考虑），点击"File -> New -> New Project..."，全新创建一个新的工程，工程名字以及包名根据实际业务来定。
2. 新建module
在刚创建好的工程中，点击"File -> New -> New Module... -> Android Library"，创建一个新的library module，接下来我们所有的组件业务代码都将在该module下面开发。
如图所示，我们所有的组件工程都包含2个module，一个是app，一个是library。在library里开发真正的业务功能，在app里只是一个组件的入口，或者是一些demo测试代码。
library module的包名设置规则：应用包名+ "." + 业务模块名，假设你的应用包名为com.ali.app，你要开发的业务组件为用户个人中心，则你的包名可定义为：com.ali.app.userinfo。注意不要与应用以及其他业务组件的包名发生冲突，如果你的团队足够大，甚至是跨业务部门，则组件包名的命名需要格外慎重，你可以加上你部门的代号，这样别人在使用该组件时，一眼就能知道该组件是谁谁谁开发的。
3. 资源名命名规则
所有资源文件的命名都需要以业务模块名为前缀，注意不要与其他业务模块前缀名冲突。假设我们在开发"登录"相关的业务，业务模块名为"login"，则相关资源文件命名例子：
- layout文件：login_activity_quicklogin.xml、login_activity_register.xml
- anim文件：login_slide_in.xml
- mipmap文件：login_btn_submit.png
- string：<string name="login_submit">提交</string>
包括但不限于以上这些资源文件，所有资源文件的命名都必须遵循该规则，否则可能在集成的时候会被冲突掉。当然还有一种方式是在build.gradle文件添加如下配置：
resourcePrefix "module_login"
这个在打包编译时会自动为所有资源加上前缀，但是不管加不加该配置，还是强烈建议资源命名增加前缀。
4. 第三方库依赖
在我们使用第三方依赖库时，需要特别注意依赖库的版本号。如果第三方依赖库在多个组件中都有使用，考虑将这些第三方依赖下沉到底层组件库中统一管理，防止版本号冲突。
5. 数据存储
- 尽量不要使用数据库来存储数据，特殊情况除外。某些ORM框架需要数据库表集中管理，这样不利于实行业务模块组件化。
- 使用SharedPreferences时，每个业务模块只管理自己模块需要的数据，SharedPreferences文件名需要通过业务前缀来区分，防止不同组件间数据发生冲突。
- 当某些数据需要全局共享时，可以考虑下沉到底层模块。
6. 组件生命周期管理
当业务组件需要在应用的Application.onCreate()里进行初始化时，我们要在该组件里引入生命周期管理。
7. 发布本地maven库
我的组件都是采用maven进行管理的，在壳工程集成时直接通过maven引用组件。
前期开发测试时，请先在本机发布maven库，这样方便随时修改更新。 在library module的根目录下新建一个maven_local.gradle文件：
maven_local.gradle文件的配置如下：
apply plugin: 'maven'
uploadArchives {
repositories.mavenDeployer {
pom.version = '1.0.0'
pom.artifactId = 'loginlocal'
pom.groupId = 'com.hjy.app'
repository(url: "file:///Users/hjy/.m2/repository/"
}
}
- version：maven库的版本号，初始版本都从1.0.0开始；
- groupId：maven库的组，你自己统一定义；
- artifactId：maven库的id，通常为业务模块名，为了与远程库区分，本地库请加local后缀；
- repository：其中"file:///Users/hjy/.m2/repository/"替换成自己本机的gradle缓存目录，在mac中gradle的缓存目录路径为~/.m2/repository/；
在library module的build.gradle里增加发布脚本的引用"apply from: './maven_push.gradle'"，然后点击"IDE右侧Gradle -> Gradle projects -> 业务module -> Tasks -> upload -> uploadArchives"，最后会生成并上传一个本地的maven库。
在本地测试时，你可以像下面这样直接引用本地maven组件库了。
在工程根目录下的build.gradle里增加你本地maven库地址：
allprojects {
repositories {
maven { url 'file:///Users/syl/.m2/repository/' }
}
}
然后你就可以直接通过maven引用你的组件库了：
compile 'com.hjy.app:loginlocal:1.0.0'
8. 发布远程maven库
如果你的组件库测试通过，最后需要将release版本发布在远程maven服务器上，在壳工程集成时，采用远程依赖的方式。与发布本地maven库相似，在library module的根目录下新建maven_push.gradle文件，然后在module的build.gradle里，将发布本地maven库的脚本切换成"apply from: './maven_push.gradle'"即可。
apply plugin: 'maven'
apply plugin: 'signing'
configurations {
deployerJars
}
repositories {
mavenCentral()
}
uploadArchives {
repositories {
mavenDeployer {
pom.version = '1.0.0'
pom.artifactId = 'login'
pom.groupId = 'com.hjy.app'
//请改为自己的maven服务器地址
snapshotRepository(url: 'http://127.0.0.1/nexus/repository/maven-snapshots/') {
authentication(userName: '***', password: '***')
}
repository(url: 'http://127.0.0.1/nexus/repository/maven-releases/') {
authentication(userName: '***', password: '***')
}
}
}
}
// type显示指定任务类型或任务, 这里指定要执行Javadoc这个task,这个task在gradle中已经定义
task androidJavadocs(type: Javadoc) {
// 设置源码所在的位置
source = android.sourceSets.main.java.sourceFiles
}
// 生成javadoc.jar
task androidJavadocsJar(type: Jar) {
// 指定文档名称
classifier = 'javadoc'
from androidJavadocs.destinationDir
}
// 生成sources.jar
task androidSourcesJar(type: Jar) {
classifier = 'sources'
from android.sourceSets.main.java.sourceFiles
}
// 产生相关配置文件的任务
artifacts {
archives androidSourcesJar
archives androidJavadocsJar
}
把repository里的url替换成你自己的maven服务器地址，用户名密码换成你自己的maven账号即可。
9. 文档要求
每个组件都要维护好说明文档，通常都是一个readme文件。一般包含以下说明：
- 组件的功能介绍；
- 组件怎么集成，以及注意事项；
- 组件功能使用说明；
- 组件历史版本记录；
尽量做到团队内任何一个成员，通过该文档就能使用组件，而不需要找到组件的开发人员来讲解。
10. 组件集成测试
前面说过，有一种组件开发模式，其工程结构如下图所示：
“Helloworld”是我们的应用壳工程，“ModuleA”、“ModuleB”、“ModuleC”分别是3个组件，有一种做法是通过配置文件，动态改边某个Module是library还是application，这样就可以直接打包调试运行某个组件（具体做法可以网上搜索）。但是我说过，这样没法做到代码权限管控，也没法做到开发人员职责划分，每个开发人员可以对任意的组件进行修改，这显然会造成混乱。所以我摒弃了这种模式，而是把每个组件都分割成单独的工程，集成测试时，通过maven引用来集成。
前面讲过，前期自己集成测试时，先发布本地maven库，在壳工程集成时如下所示：
//注册、登录
compile 'com.hjy.app:loginlocal:1.0.0'
//用户中心
compile 'com.hjy.app:userinfolocal:1.0.0'
//支付模块
compile 'com.hjy.app:paylocal:1.0.0'
每个组件的id都加了一个local后缀，这是为了区分我们代码引用的是本地的maven组件库，还是远程的正式maven组件库。
如果测试时，发现了bug，只需要把组件库本地重新发布一下，然后壳工程的gradle文件刷新同步一下就可，不用去改版本号，因为这只是你本地的库，不会与别人的发生冲突。
最后测试通过之后，我们会发布到自己的maven服务器上，这个时候壳工程的build文件如下所示：
//注册、登录
compile 'com.hjy.app:login:1.0.0'
//用户中心
compile 'com.hjy.app:userinfo:1.0.0'
//支付模块
compile 'com.hjy.app:pay:1.0.0'
注意，这里组件的id都去掉了local后缀，同时组件的版本号必须每发布一次升一次级，并做好版本变更记录。
系列文章
Android组件化开发实践（一）：为什么要进行组件化开发？
Android组件化开发实践（二）：组件化架构设计
Android组件化开发实践（三）：组件开发规范
Android组件化开发实践（四）：组件间通信问题
Android组件化开发实践（五）：组件生命周期管理
Android组件化开发实践（六）：老项目实施组件化
Android组件化开发实践（七）：开发常见问题及解决方案
Android组件化开发实践（八）：组件生命周期如何实现自动注册管理
Android组件化开发实践（九）：自定义Gradle插件
Android组件化开发实践（十）：通过Gradle插件统一规范
