转载

皮肤包项目的 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 了。

在上面的代码中,我还给任务声明了 groupdescription ,这是为了能在任务树中看到(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 中的皮肤包删掉。

到这里就大功告成了,完美解决上面提出的全部问题。

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

原文  http://blog.csdn.net/maosidiaoxian/article/details/79903063
正文到此结束
Loading...