gradle 实用技巧-六虎

前言

总结一些日常开发中非常有用的 gradle 脚本、自定义功能实现。

实现

以下实现基于 AGP 8.0.2 版本 ,AGP 的 API 隔三岔五就会迎来一波破坏性的变更，导致脚本和插件无法使用，因此这里需要关注一下版本。

输出打包后 apk 文件路径及 apk 大小。

Android Studio 最新版本 Run 之后，每次输出的 apk 并没有在这 app/build/outputs 文件夹下（不知道 Android 官方是出于什么考虑要更改这个路径），而是移动到了 build\intermediates\apk\{flavor}\debug\ 目录下。为了方便后续快速找到每次运行完成的 apk ，可以在每次打包后输出 apk 文件路径及大小，从而可以关注一下日常开发过程中自己的 apk 体积大概是一个什么样的范围。

static def getFileHumanSize(length) {
    def oneMB = 1024f * 1024f
    def size = String.valueOf((length / oneMB))
    def value = new BigDecimal(size)
    return value.setScale(2, BigDecimal.ROUND_HALF_UP)
}
/**
 * 打包完成后输出 apk 大小*/
android {
    applicationVariants.all { variant ->
        variant.assembleProvider.configure() {
            it.doLast {
                variant.outputs.forEach {
                    logger.error("apk fileName ==> ${it.outputFile.name}")
                    logger.error("apk filePath ==> ${it.outputFile}")
                    logger.error("apk fileSize ==> ${it.outputFile.length()} , ${getFileHumanSize(it.outputFile.length())} MB")
                }
            }
        }
    }
}

apk fileName ==> app-huawei-global-debug.apk
apk filePath ==> D:\workspace\MinApp\app\build\intermediates\apk\huaweiGlobal\debug\app-huawei-global-debug.apk
apk fileSize ==> 11987818 , 11.43 MB

可以看到 apk 的路径在 build/intermediates 目录下。当然，我们可以通过下面的方法修改这个路径，定义成我们习惯的路径。

gradle 自定义功能的模块化

日常开发中，会有很多关于 build.gradle 的修改和更新。日积月累，build.gradle 的内容越来越多，代码几乎要爆炸了。其实，可以用模块化的思路将每一个小功能单独抽取出来，这样不仅可以减少 build.gradle 的规模，同时小功能可以更加容易的复用。

比如上面定义的输出打包后 apk 文件路径及 apk 大小的功能，我们就可以把他定义在 report_apk_size_after_package.gradle 这样一个文件中，然后在要使用的 build.gradle 中导入即可。

比如我们要在 app module 中使用这个功能，那么就可以直接在其 build.gradle 文件中按照相对路径引入即可。

apply from: file("../custom-gradle/report_apk_size_after_package.gradle") // 打包完成后输出 apk 大小

修改 release 包的输出路径及文件名

输出 apk 后改名的需求，应该已经很普遍了。在最终输出的 apk 文件中，我们可以追加一些和代码相关的信息，方便通过 apk 文件名迅速确定一些内容。

def getCommit() {
    def stdout = new ByteArrayOutputStream()
    exec {
        commandLine "git"
        args "rev-parse", "--short", "HEAD"
        standardOutput = stdout
    }
    return stdout.toString().trim()
}
def getBranch() {
    def stdout = new ByteArrayOutputStream()
    exec {
        commandLine "git"
        args "rev-parse", "--abbrev-ref", "HEAD"
        standardOutput = stdout
    }
    return stdout.toString().trim()
}
def gitLastCommitAuthorName() {
    return "git log -1 --pretty=format:'%an'".execute(null, rootDir).text.trim().replaceAll("\'", "")
}
def gitLastCommitAuthorEmail() {
    return "git log -1 --pretty=format:'%ae'".execute(null, rootDir).text.trim().replaceAll("\'", "")
}
android {
    def i = 0
    applicationVariants.all { variant ->       
        if (variant.assembleProvider.name.contains("Debug")) {
            // 只对 release 包生效
            return
        }
        // 打包完成后复制到的目录
        def outputFileDir = "${rootDir.absolutePath}/build/${variant.buildType.name}/${variant.versionName}"
        //确定输出文件名
        def today = new Date()
        def path = ((project.name != "app") ? project.name : rootProject.name.replace(" ", "")) + "_" + variant.flavorName + "_" + variant.buildType.name + "_" + variant.versionName + "_" + today.format('yyyy_MM_dd_HH_mm') + "_" + getBranch() + "_" + getCommit() + "_" + gitLastCommitAuthorName() + ".apk"
        println("path is $path")
        variant.outputs.forEach {
            it.outputFileName = path
        }
        // 打包完成后做的一些事,复制apk到指定文件夹
        variant.assembleProvider.configure() {
            it.doLast {
                File out = new File(outputFileDir)
                copy {
                    variant.outputs.forEach { file ->
                        copy {
                            from file.outputFile
                            into out
                        }
                    }
                }
            }
        }
    }
}

打 release 包后的日志

let me do something after assembleHuaweiGlobalRelease
apk fileName ==> MiniApp_huaweiGlobal_release_1.0.0_2306292226_2023_06_29_22_26_master_b0c6937_rookie.apk
apk filePath ==> D:\workspace\MinApp\app\build\outputs\apk\huaweiGlobal\release\MiniApp_huaweiGlobal_release_1.0.0_2306292226_2023_06_29_22_26_master_b0c6937_rookie.apk
apk fileSize ==> 4959230 , 4.73 MB

通过上面的日志，可以看到 MiniApp_huaweiGlobal_release_1.0.0_2306292226_2023_06_29_22_26_master_b0c6937_rookie.apk 包含了 ProjectName、flavor、debug/release、打包时间、分支、commitId 即最后一个 commitor 邮箱这些信息。通过这样的信息，可以更加方便快速的定位问题和解决问题。

妙用 flavor 实现不同的功能

使用 flavor 可以定制代码的不同功能及组合。不用把所有内容一锅乱炖似的放在一起搞。比如 MiniApp 随着演示代码的增多，已经逐渐丧失了 Mini 的定位，Apk 大小已经来到了 22 MB之多。究其原因，就是把所有代码验证和功能都放在一起导致的，音视频、compose、C++ 代码全都混在一起。部分功能不常用，但是每次为了验证一部分小功能，却要连带编译这些所有功能，同时打出的 apk 包体积也变大了，从编译到安装，无形中浪费了很多时间。

因此，可以通过 flavor 将一些不常用的功能，定义到不同的 flavor 中，真正需要的时候，编译相应 flavor 的包即可。

首先我们可以从 type 维度定义两个 flavor

    flavorDimensions "channel", "type"
    productFlavors {
        xiaomi {
            dimension "channel"
        }
        oppo {
            dimension "channel"
        }
        huawei {
            dimension "channel"
        }
        global {
            dimension "type"
        }
        local {
            dimension "type"
        }
    }

在 type 维度，我们可以认为 global 是功能完整的 flavor，而 local 是部分功能缺失的 flavor 。那么具体缺失哪些功能呢？这就要从实际情况出发了，比如产品定义，代码架构及模块组合之类的。回到 Mini App 中，我们使用不同 flavor 的目标就是通过减少非常用功能模块，获得一个体积相对较小的 apk. 因此，可以做如下配置。

    if (source_code.toBoolean()) {
        globalImplementation project(path: ':thirdlib')
    } else {
        globalImplementation 'com.engineer.third:thirdlib:1.0.0'
    }
    globalImplementation project(path: ':compose')
    globalImplementation 'com.github.CarGuo.GSYVideoPlayer:GSYVideoPlayer:v8.1.8-release-jitpack'

如上我们只在 global 这个 flavor 依赖 thirdlib, compose, GSYVideoPlayer 这些组件。这样 local flavor 就不会引入这些组件，那么就会带来一个问题，local flavor 编译的时候没有这些组件的类，会出现找不到类的情况。

对于这种情况，我们可以在项目 src 和 main 同级的目录下，创建 local 文件夹，然后在其内部按照具体 Class 文件的路径创建相应的类即可。

package com.engineer.compose.ui
import com.engineer.BasePlaceHolderActivity
/**
 * Created on 2022/7/31.
 * @author rookie
 */
class MainComposeActivity : BasePlaceHolderActivity()


package com.engineer.third
import com.engineer.BasePlaceHolderActivity
/**
 * Created on 2022/7/31.
 * @author rookie
 */
class CppActivity : BasePlaceHolderActivity()

package com.engineer
import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity
import com.engineer.android.mini.ext.toast
/**
 * Created on 2022/8/1.
 * @author rookie
 */
open class BasePlaceHolderActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        "please use global flavor ".toast()
        finish()
    }
}

这里的思路其实很简单，类似于 leanCanary ，就是在不需要这个功能的 flavor 提供空实现，保证编译可以正常通过即可。缺什么类，建按照类的完整路径创建相应的 Class 文件，这样既保证了编译可以通过，同时在不需要次功能的 flavor 又减少无冗余的代码。

flavor 扩展

其实顺着上面的思路，基于不同 flavor 我们可以做更多的事情。基于 Java 虚拟机的类加载机制限制，相同的类只能有一个，因此我们无法做的事情是，通过 flavor 创建同名的类，去覆盖或重写其他 flavor 的逻辑，这种在编译阶段（其实是在创建同名类的阶段）就会报错。

但是，有些功能是可以被覆盖和定制的。比如包名、App 的名称、icon 之类。这些配置可以通过 AndroidManifest.xml/gradle 进行配置。可以在 local 目录下创建这个 flavor 特有的一些资源文件，这样就可以实现基于 flavor 的产品功能定制了。

比如最简单的修改 applicationId

        global {
            dimension "type"
        }
        local {
            dimension "type"
            applicationId "com.engineer.android.mini.x"
        }

这样，local 和 global 就有了各自不同的 applicationId, 这两种不同 flavor 的包就可以安装在同一台设备了。当然，现在这两个包的 label 和 icon 都是一样的，完全看不出区别。这里就可以利用 flavor 各自的文件夹，来定制各类资源和命名了。

flavor 过滤

不同维度的 flavor 会导致最终的 variant 变多。比如定义 product、channel、type 这些几个 dimension 的之后，后续新增的 flavor 会以乘积的形式增长，但是有些 flavor 又是我们不需要的，这个时候我们就可以过滤掉某些不需要的 flavor 。

比如以上面定义的 channel,type 这两个维度为例，在这两个维度下分别又扩展了 xiaomi/opop/huawei,global/local 这些 flavor 。按照规则会有 2x3x2=12 种 flavor，但实际情况可能不需要这么多，为了减少编译的压力，提升代码的可维护性，我们可以对 flavor 进行过滤。

    variantFilter { variant ->
        println "variant is ${variant.flavors*.name}"
        def dimens = variant.flavors*.name
        def type = dimens[1]
        def channel = dimens[0]
        switch (type) {
            case "global":
                if (channel == "xiaomi") {
                    setIgnore(true)
                }
                break
            case "local":
                if (channel == "oppo") {
                    setIgnore(true)
                }
                break
        }
    }

这样我们就成功的过滤掉了 xiaomiGlobal 和 oppoLocal 的 flavor ，一下子就去掉了 4 个 flavor 。

基于现有 task 定制任务

再回顾一下上面的 修改 release 包的输出路径及文件名 的代码实现，我们是在打包完成之后进行了 apk 文件的重命名。

        // 打包完成后做的一些事,复制apk到指定文件夹
        variant.assembleProvider.configure() {
            it.doLast {
                File out = new File(outputFileDir)
                copy {
                    variant.outputs.forEach { file ->
                        copy {
                            from file.outputFile
                            into out
                        }
                    }
                }
            }
        }

这里的 doLast 就是说，无论是否需要，每次都会在 assemble 这个 task 完成之后做一件事。这样在某些情况下显得非常的不灵活，尤其是当 doLast 闭包中要做的事情非常繁重的时候。这里的 copy 操作显然是比较轻量的，但是换做是其他操作，比如 apk 安全加固等操作，并不是每次必然需要的操作。这种情况下，就需要我们换一种方式去实现相应的逻辑了。

我们就以加固为例，一般情况下，我们需要对各个版本的 release 包进行加固。因此，我们可以基于现有的 assembleXXXRelease 这个 task 展开。

android {
    applicationVariants.all { variant ->
        if (variant.assemble.name.contains("Debug")) {
            // 只对 release 包生效
            return
        }
        def taskPrefix = "jiagu"
        def groupName = "jiagu"
        def assembleTask = variant.assembleProvider.name
        def taskName = assembleTask.replace("assemble", taskPrefix)
        tasks.create(taskName) {
            it.group groupName
            it.dependsOn assembleTask
            variant.assembleProvider.configure() {
                it.doLast {
                    logger.error("let me do something after $assembleTask")
                }
            }
        }
    }
}

添加上面的代码后，再执行一下 gradle sync ，我们就可以看到新添加的 jiagu 这个 group 和其中的 task 了。

这里使用创建 task 的一种方式，使用 create 和 dependsOn ，动态创建 task，并指定其依赖的 task 。

这样当我们执行 ./gradlew jiaguHuaweiLocalRelease 时就可以看到结果了。

> Task :app:assembleHuaweiLocalRelease
let me do something after assembleHuaweiLocalRelease

> Task :app:jiaguHuaweiLocalRelease
BUILD SUCCESSFUL in 56s
82 actionable tasks: 12 executed, 70 up-to-date

可以看到我们自定义的 task 已经生效了，会在 assembleXXXRelease 这个 task 完成之后执行。

关于 gradle 的使用，可以说是孰能生巧，只要逐渐熟悉了 groovy 的语法和 Java 语法之间的差异，那么就可以逐渐摸索出更多有意思的用法了。

本文源码可以参考 Github MiniApp

小结

可以看到基于 gradle 构建流程，我们仅仅通过编写一些脚本，可以做的事情还是很多的。但是由于 groovy 语法过于灵活，不像 Java 那样有语法提示，因此尝试一些新的语法时难免不知所措。面对这种情况，去看他的源码就好。通过源码，我们就可以知道某个类有哪些属性，有哪些方法。

gradle 实用技巧

前言

实现

输出打包后 apk 文件路径及 apk 大小。

gradle 自定义功能的模块化

修改 release 包的输出路径及文件名

妙用 flavor 实现不同的功能

flavor 扩展

flavor 过滤

基于现有 task 定制任务

小结

相关文章

[iOS开发]属性关键字

Compose中结合Paging实现上拉丝滑加载和下拉刷新

03-📝计算机网络核心知识|【MAC地址、IP地址的组成、IP地址的分类、CIDR、子网掩码、超网】

IDEA打开项目中所有文件都报错，甚至String都报错

作者信息