Android组件化开发实践（三）：组件开发规范-阿里云开发者社区

Android组件化开发实践（三）：组件开发规范

2018-09-26 3171

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 不以规矩，不成方圆。特别是多人协作开发时，如果没有统一的开发规范，势必会造成各种混乱。在实际开发中，常常会碰到的问题有：引入的某个第三方库版本冲突；不同组件里同名资源文件被覆盖；APP壳工程打包时AndroidManifest.xml合并发生错误；往往单独的组件工程运行良好，但是集成到壳工程时就是不行，所以我们必须要严格遵守规范，尽可能减少这种问题的出现。

不以规矩，不成方圆。特别是多人协作开发时，如果没有统一的开发规范，势必会造成各种混乱。在实际开发中，常常会碰到的问题有：

引入的某个第三方库版本冲突；
不同组件里同名资源文件被覆盖；
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组件化开发实践（三）：组件开发规范

1. 新建组件工程

2. 新建module

3. 资源名命名规则

4. 第三方库依赖

5. 数据存储

6. 组件生命周期管理

7. 发布本地maven库

8. 发布远程maven库

9. 文档要求

10. 组件集成测试

热门文章

最新文章

相关课程

相关电子书

相关实验场景