Android组件化开发实践(三):组件开发规范

  1. 云栖社区>
  2. 博客>
  3. 正文

Android组件化开发实践(三):组件开发规范

云之崖 2018-09-26 20:54:00 浏览500 评论0

摘要: 不以规矩,不成方圆。特别是多人协作开发时,如果没有统一的开发规范,势必会造成各种混乱。在实际开发中,常常会碰到的问题有: 引入的某个第三方库版本冲突; 不同组件里同名资源文件被覆盖; 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下面开发。

img_807fe1526dc7cc267ea13ef95205ee12.png

如图所示,我们所有的组件工程都包含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. 数据存储

  1. 尽量不要使用数据库来存储数据,特殊情况除外。某些ORM框架需要数据库表集中管理,这样不利于实行业务模块组件化。
  2. 使用SharedPreferences时,每个业务模块只管理自己模块需要的数据,SharedPreferences文件名需要通过业务前缀来区分,防止不同组件间数据发生冲突。
  3. 当某些数据需要全局共享时,可以考虑下沉到底层模块。

6. 组件生命周期管理

当业务组件需要在应用的Application.onCreate()里进行初始化时,我们要在该组件里引入生命周期管理。

7. 发布本地maven库

我的组件都是采用maven进行管理的,在壳工程集成时直接通过maven引用组件。

前期开发测试时,请先在本机发布maven库,这样方便随时修改更新。 在library module的根目录下新建一个maven_local.gradle文件:


img_d83ecd58ed4f67d1154d922a216fa515.png

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文件。一般包含以下说明:

  1. 组件的功能介绍;
  2. 组件怎么集成,以及注意事项;
  3. 组件功能使用说明;
  4. 组件历史版本记录;

尽量做到团队内任何一个成员,通过该文档就能使用组件,而不需要找到组件的开发人员来讲解。

10. 组件集成测试

前面说过,有一种组件开发模式,其工程结构如下图所示:

img_9dc169287e0690e1c20729c6f22d0962.png

“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插件

【云栖快讯】阿里巴巴小程序繁星计划,20亿补贴第一弹云应用免费申请,限量从速!  详情请点击

网友评论