我在做的一个项目需要有换肤功能,换肤的方案是采用第三方库 ThemeSkinning 的实现(在其基础上修复若干 bug)。皮肤的制作是把相关的资源放在一个 app module 中打包成 apk,当然资源的命名要和原有项目中的命名一致。目前的皮肤加载方式,是把皮肤包放到 assets 中去加载。这是背景一。
背景二,这个项目是我所接手过来的。虽然表面上是使用了皮肤加载库,但是项目中还有大量遗留的没有使用皮肤库的写死的代码,都是判断当前主题是哪一个,然后返回默认资源或者是指定皮肤的资源。这些代码都类似如下:
1 | String theme = ConfigUtil.getTheme(); |
而项目同时还在紧张地迭代,没有充分的时间去处理这些代码,只能是每次迭代中逐渐地修改。
原始情况
一开始,皮肤包的生成是在另一个项目中,制作一个皮肤包的步骤如下:
- 把资源拷贝到皮肤包项目;
- 打包皮肤包项目,生成 apk;
- 将 apk 文件拷贝到项目中的 assets 内的指定文件,并修改名字。
看似并不繁琐。但其实这个过程对我来说是很痛苦的,因为实际上,我遇到了以下问题:
- 更新资源时,需要在两个 Android Studio 中切换。
- 接手的项目质量比较差,资源命名很不规范,且不少资源单词拼错,每次修改时都需要切换项目同时修改,并且更新皮肤包。
- 每次要更新皮肤时,都需要打包,然后等打包完成,再拷贝。
- 由于是两个不同的项目,两边的修改历史是分开的,资源需要修改名称时是分别提交的,而不是作为一次原子性的提交,因此在修改历史上难以形成有较的追溯。
项目整合
基于上述所说的情况,我做了第一次整改。我将皮肤项目作为一个子模块,加到项目中。项目的布局如下:
1 | root project |
也就是在根项目下建立一个 skins 的文件夹,将皮肤包项目作为一个 app module 类似放于其中。以后如果有新增皮肤包的需求,可以在这一文件夹下继续建立皮肤包模块。
整合之后就解决其中的一些问题了。不用再打开两个 Android Studio,不用改一个资源提交两个项目,提交两次(一个项目一次)。项目资源和皮肤包资源可以一次修改并一起提交,提交历史能够形成良好的追溯。
皮肤包的半自动部署
由于背景二所提到的问题,没有足够的时间对皮肤相关代码进行重构及制作一个完整的皮肤包,所以每次只有逐渐处理遗留代码,并重新制作皮肤包。上面的项目整合并没有优化皮肤包的制作过程。这种重复的过程,理应交由脚本去做,于是我写了一个部署皮肤的任务。
这个任务实现起来也简单。因为皮肤包是在 app 模块的 assets目录下的一个固定目录中,所以其实只是把编译好的皮肤包的 apk 给复制过去并重命名一下就好了。这是整体的思路。
再详细拆解一下:
- app 项目可以通过
project(':app')
获得。 - 拿到 app 的 project 对象之后,通过
android.sourceSets.main.assets.srcDirs[0]
可以拿到项目中的 assets 目录。 - 部署皮肤的任务应该依赖于皮肤包的
assembleRelease
任务,这样我们就不用每次部署之前先去执行皮肤包的assembleRelease
任务。
代码如下:
1 | android.applicationVariants.all { variant -> |
这样就创建了自定义任务 deployReleaseSkin
了。
在上面的代码中,我还给任务声明了 group
及 description
,这是为了能在任务树中看到(Android Studio 右边的 Gradle 面板,或是通过 ./gradlew :skins:yourskin:tasks
命令打印出)。
不过上面的任务还是有些不足之处。首先我们的皮肤包是会提交到版本控制系统的,那么当皮肤包的源文件没有修改,并且 app 项目中的皮肤包也没有修改时,执行部署任务时就不需要重复更新。在翻了 Gradle 用户指南之后,我又对上面的自定义任务作了少量修改,让它支持 UP-TO-DATE
。修改很简单,只需要指定任务的输入及输出即可,完整代码如下:
1 | android.applicationVariants.all { variant -> |
最终的皮肤包全自动部署
上面的半自动部署,已经把最初所提的问题都解决了。但是在经过一段时间后,我又开始难以接受了。
首先,在 Android 3.1.0 当中,同步 Gradle 文档时会报错,提示 project(':app')
里没有 android
这个属性,尽管命令行里编译完全通过,并且不影响项目运行。只是在 Android Studio 的运行配置上,对皮肤包的项目会打一个红叉。最后我是给它加了个 try-catch
,使得在 Android Studio 中同步构建通过。
其次,每次修改了皮肤包之后,都需要手动执行部署任务让其更新,我相当不喜欢这种没有人生意义的重复操作。
再者,皮肤包的修改比较频繁,每次都要把新的皮肤包给提交到版本控制系统中。皮肤包是从项目代码中生成的,并且生成的成本不高,重新生成也不会有其他影响,从版本控制系统的使用原则来看,它理应被版本控制系统忽略。
所以,我需要实现皮肤包的全自动部署,它可以满足以下条件:
- 当皮肤有修改时,下次 app 编译,会生成新的皮肤包放到 assets 中。
- 当皮肤包没有修改时,不会重复生成。
- 皮肤包不需要提交到版本控制系统中。当 assets 中不包含时,它会生成并部署。
- 当去掉对某个皮肤包的依赖时,清理再构建,assets 只会包含所依赖的皮肤包。
上面的第 2 个和第 3 个条件,其实也就是 Gradle 任务的 UP-TO-DATE
的实现,在前面我们已经实现过了,所以只需要关注第 1 个和第 4 个问题。
在 Android Gradle 项目中,assets 是可以配置为多个目录的。所以我的想法是新增一个 assets 目录,专门用于放皮肤包。然后注入 app 的构建任务,在生成 assets 资源之前部署皮肤包到该目录。
首先我们新定义两个常量,分别表示另一个 assets 文件夹及其内部的 skins 文件夹的路径。如下:
1 | ext { |
然后修改皮肤包的部署任务,改为将皮肤包复制到新的 assets 目录。代码如下:
1 | android.applicationVariants.all { variant -> |
接着,修改 app 的 build.gradle
脚本,在 android{}
节点中对 sourceSets
进行配置,新增一个 assets 目录:
1 | sourceSets { |
然后在命令行执行一下我们的 app 的构建任务,找到生成 assets 资源的任务名称。这里执行的时候我们不需要真正的执行,所以要带上参数 -m
,表示以 dry run
模式执行。
1 | ./gradlew :app:assemble -m |
输出结果这里省略。
我们会看到,对于 debug 的构建类型,会包含一个 generateDebugAssets
任务,对于 release 的构建类型,会包含一个 generateReleaseAssets
的任务。如果是配置了 product flavor 的,任务名会是 generate + flavor 名称 + 构建类型 + Assets
。这个 generate.*Assets
就是我们要找的生成 assets 的任务了。所以接下来就是给它加上对部署皮肤包任务的依赖。代码如下:
1 | def deployTasks = project.rootProject.getTasksByName('deployReleaseSkin', true) |
最后,我们给 clean
任务新增一个删除我们额外定义的 assets 文件夹的操作。
1 | // 清理时自动删除生成外部资源的文件夹 |
对了,还得把原来 assets 中的皮肤包删掉。
到这里就大功告成了,完美解决上面提出的全部问题。
接下来就可以放心地修改皮肤包资源,大胆地进行代码整理优化重构而不用担心忘了部署皮肤包资源了。