皮肤包项目的 Gradle 脚本演化

我在做的一个项目需要有换肤功能，换肤的方案是采用第三方库 ThemeSkinning 的实现（在其基础上修复若干 bug）。皮肤的制作是把相关的资源放在一个 app module 中打包成 apk，当然资源的命名要和原有项目中的命名一致。目前的皮肤加载方式，是把皮肤包放到 assets 中去加载。这是背景一。
背景二，这个项目是我所接手过来的。虽然表面上是使用了皮肤加载库，但是项目中还有大量遗留的没有使用皮肤库的写死的代码，都是判断当前主题是哪一个，然后返回默认资源或者是指定皮肤的资源。这些代码都类似如下：

    String theme = ConfigUtil.getTheme();
    if (theme.equals(Constant.SKIN_ORANGE)) {
        return ResourcesCompat.getColor(getActivity().getResources(), R.color.color_orange_theme, null);
    } else {
        return ResourcesCompat.getColor(getActivity().getResources(), R.color.default_theme, null);
    }

而项目同时还在紧张地迭代，没有充分的时间去处理这些代码，只能是每次迭代中逐渐地修改。

原始情况

一开始，皮肤包的生成是在另一个项目中，制作一个皮肤包的步骤如下：

1. 把资源拷贝到皮肤包项目；
2. 打包皮肤包项目，生成 apk；
3. 将 apk 文件拷贝到项目中的 assets 内的指定文件，并修改名字。

看似并不繁琐。但其实这个过程对我来说是很痛苦的，因为实际上，我遇到了以下问题：

• 更新资源时，需要在两个 Android Studio 中切换。
• 接手的项目质量比较差，资源命名很不规范，且不少资源单词拼错，每次修改时都需要切换项目同时修改，并且更新皮肤包。
• 每次要更新皮肤时，都需要打包，然后等打包完成，再拷贝。
• 由于是两个不同的项目，两边的修改历史是分开的，资源需要修改名称时是分别提交的，而不是作为一次原子性的提交，因此在修改历史上难以形成有较的追溯。

项目整合

基于上述所说的情况，我做了第一次整改。我将皮肤项目作为一个子模块，加到项目中。项目的布局如下：

root project
  ⊢ app module
  ⊢ library module
  ∟ skins (folder)
     ∟ skin module

也就是在根项目下建立一个 skins 的文件夹，将皮肤包项目作为一个 app module 类似放于其中。以后如果有新增皮肤包的需求，可以在这一文件夹下继续建立皮肤包模块。
整合之后就解决其中的一些问题了。不用再打开两个 Android Studio，不用改一个资源提交两个项目，提交两次（一个项目一次）。项目资源和皮肤包资源可以一次修改并一起提交，提交历史能够形成良好的追溯。

皮肤包的半自动部署

由于背景二所提到的问题，没有足够的时间对皮肤相关代码进行重构及制作一个完整的皮肤包，所以每次只有逐渐处理遗留代码，并重新制作皮肤包。上面的项目整合并没有优化皮肤包的制作过程。这种重复的过程，理应交由脚本去做，于是我写了一个部署皮肤的任务。
这个任务实现起来也简单。因为皮肤包是在 app 模块的 assets目录下的一个固定目录中，所以其实只是把编译好的皮肤包的 apk 给复制过去并重命名一下就好了。这是整体的思路。
再详细拆解一下：

• app 项目可以通过 project(':app') 获得。
• 拿到 app 的 project 对象之后，通过 android.sourceSets.main.assets.srcDirs[0] 可以拿到项目中的 assets 目录。
• 部署皮肤的任务应该依赖于皮肤包的 assembleRelease 任务，这样我们就不用每次部署之前先去执行皮肤包的 assembleRelease 任务。

代码如下：

android.applicationVariants.all { variant ->
    if (variant.buildType.name == "release") {
        def variantName = variant.name.capitalize()
        def releaseDir = new File(project(':app').android.sourceSets.main.assets.srcDirs[0], "skin")
        Task deployTask = task "deploy${variantName}Skin"(dependsOn: "assemble${variantName}") {
            group = 'install'
            description "Copy the output apk to target folder and rename it for ${variant.name}"
        }
        deployTask.doLast {
            copy {
                from variant.outputs[0].outputFile
                into releaseDir
                rename {
                    "${project.name}.skin"
                }
            }
        }
    }
}

这样就创建了自定义任务 deployReleaseSkin 了。
在上面的代码中，我还给任务声明了 group 及 description，这是为了能在任务树中看到(Android Studio 右边的 Gradle 面板，或是通过 ./gradlew :skins:yourskin:tasks 命令打印出）。

不过上面的任务还是有些不足之处。首先我们的皮肤包是会提交到版本控制系统的，那么当皮肤包的源文件没有修改，并且 app 项目中的皮肤包也没有修改时，执行部署任务时就不需要重复更新。在翻了 Gradle 用户指南之后，我又对上面的自定义任务作了少量修改，让它支持 UP-TO-DATE。修改很简单，只需要指定任务的输入及输出即可，完整代码如下：

android.applicationVariants.all { variant ->
    if (variant.buildType.name == "release") {
        def variantName = variant.name.capitalize()
        def releaseDir = new File(project(':app').android.sourceSets.main.assets.srcDirs[0], "skin")
        Task deployTask = task "deploy${variantName}Skin"(dependsOn: "assemble${variantName}") {
            group = 'install'
            description "Copy the output apk to target folder and rename it for ${variant.name}"
            inputs.files(variant.outputs[0].outputFile)
            outputs.dir releaseDir
        }
        deployTask.doLast {
            copy {
                from variant.outputs[0].outputFile
                into releaseDir
                rename {
                    "${project.name}.skin"
                }
            }
        }
    }
}

最终的皮肤包全自动部署

上面的半自动部署，已经把最初所提的问题都解决了。但是在经过一段时间后，我又开始难以接受了。

首先，在 Android 3.1.0 当中，同步 Gradle 文档时会报错，提示 project(':app') 里没有 android 这个属性，尽管命令行里编译完全通过，并且不影响项目运行。只是在 Android Studio 的运行配置上，对皮肤包的项目会打一个红叉。最后我是给它加了个 try-catch，使得在 Android Studio 中同步构建通过。
其次，每次修改了皮肤包之后，都需要手动执行部署任务让其更新，我相当不喜欢这种没有人生意义的重复操作。
再者，皮肤包的修改比较频繁，每次都要把新的皮肤包给提交到版本控制系统中。皮肤包是从项目代码中生成的，并且生成的成本不高，重新生成也不会有其他影响，从版本控制系统的使用原则来看，它理应被版本控制系统忽略。

所以，我需要实现皮肤包的全自动部署，它可以满足以下条件：

1. 当皮肤有修改时，下次 app 编译，会生成新的皮肤包放到 assets 中。
2. 当皮肤包没有修改时，不会重复生成。
3. 皮肤包不需要提交到版本控制系统中。当 assets 中不包含时，它会生成并部署。
4. 当去掉对某个皮肤包的依赖时，清理再构建，assets 只会包含所依赖的皮肤包。

上面的第 2 个和第 3 个条件，其实也就是 Gradle 任务的 UP-TO-DATE 的实现，在前面我们已经实现过了，所以只需要关注第 1 个和第 4 个问题。

在 Android Gradle 项目中，assets 是可以配置为多个目录的。所以我的想法是新增一个 assets 目录，专门用于放皮肤包。然后注入 app 的构建任务，在生成 assets 资源之前部署皮肤包到该目录。

首先我们新定义两个常量，分别表示另一个 assets 文件夹及其内部的 skins 文件夹的路径。如下：

ext {
    // external assets
    EXTERNAL_ASSETS='externalAssets'
    // skin assets to deploy the skin files that generated by skin module
    SKIN_ASSETS=EXTERNAL_ASSETS+'/skin'
}

然后修改皮肤包的部署任务，改为将皮肤包复制到新的 assets 目录。代码如下：

android.applicationVariants.all { variant ->
    if (variant.buildType.name == "release") {
        def variantName = variant.name.capitalize()
        def releaseDir = project(':app').file(SKIN_ASSETS)
        Task deployTask = task "deploy${variantName}Skin"(dependsOn: "assemble${variantName}") {
            group = 'install'
            description "Copy the output apk to target folder and rename it for ${variant.name}"
            inputs.files(variant.outputs[0].outputFile)
            outputs.dir releaseDir
        }
        deployTask.doLast {
            copy {
                from variant.outputs[0].outputFile
                into releaseDir
                rename {
                    "${project.name}.skin"
                }
            }
        }
    }
}

接着，修改 app 的 build.gradle 脚本，在 android{} 节点中对 sourceSets 进行配置，新增一个 assets 目录：

    sourceSets {
        main {
            assets.srcDirs = ['src/main/assets', EXTERNAL_ASSETS]
        }
    }

然后在命令行执行一下我们的 app 的构建任务，找到生成 assets 资源的任务名称。这里执行的时候我们不需要真正的执行，所以要带上参数 -m，表示以 dry run 模式执行。

./gradlew :app:assemble -m

输出结果这里省略。
我们会看到，对于 debug 的构建类型，会包含一个 generateDebugAssets 任务，对于 release 的构建类型，会包含一个 generateReleaseAssets 的任务。如果是配置了 product flavor 的，任务名会是 generate + flavor 名称 + 构建类型 + Assets。这个 generate.*Assets 就是我们要找的生成 assets 的任务了。所以接下来就是给它对加上部署皮肤包任务的依赖。代码如下：

def deployTasks = project.rootProject.getTasksByName('deployReleaseSkin', true)
project.tasks.whenTaskAdded { task ->
    if (task.name.matches('generate.*Assets')) {
        deployTasks.each {
            task.dependsOn it
        }
    }
}

最后，我们给 clean 任务新增一个删除我们额外定义的 assets 文件夹的操作。

// 清理时自动删除生成外部资源的文件夹
tasks.findByName('clean').doLast {
    project.file(EXTERNAL_ASSETS).deleteDir()
}

对了，还得把原来 assets 中的皮肤包删掉。
到这里就大功告成了，完美解决上面提出的全部问题。

接下来就可以放心地修改皮肤包资源，大胆地进行代码整理优化重构而不用担心忘了部署皮肤包资源了。