Android Gradle 多维度实例

Posted 2023-02-19

参考技术A 上一篇文章 Just Enough Gradle for android 介绍了Gradle的一些基本知识，基本概念，理解这些有助于我们更加合理地使用Gradle。这篇文章聚焦于Gradle在Android项目中的实际使用。之所以叫做多维度实例，是想展示Gradle运用的灵活性，对于同一种需求，尽可能尝试用多种方式去实现。比较各种实现之间的思路、方式及优劣。

Gradle的Android插件默认定义了两种BuildTypes：debug和release。我们往往需要对这两种BuildTypes进行区分。

为了使debug版本和release版本的APP能同时装到手机上，它们需要有不同的applicationId。

BuildType和ProductFlavor都可以设置自己的applicationId、minSdkVersion、targetSdkVersion、versionName等，如果没有设置，则使用defaultConfig中的设置。

如今debug版和release版的APP都装到我们的手机里了，但是它们俩看上去长得一模一样，无论是应用图标还是名称都一样，实在不容易区分。给不同版本的APP起不一样的名字也许是最简单明了的区分方式了。
之所以有不同的BuildType就是为了可以对它们进行差异化设置。Android资源（即res文件下面的内容）的差异化设置非常简单。在与main平级的目录下增加debug文件夹，在相应的资源文件夹下设置app_name即可：

我们甚至可以为不同版本的APP设置不一样的应用图标（以及其它一切资源），步骤跟修改app_name是一样的，把图标放置在相应文件夹里即可。如果仅仅是为了区分debug版和release版的话，确实没必要。不过对于不同的ProductFlavor还是有用的，的确不同的ProductFlavor可能会用不同的应用图标。一般而言，BuildType主要是内部使用，如debug或者测试什么的；而ProductFlavor主要是外部使用，发布不同版本的APP，如免费版和付费版等。

其实，在build.gradle中可以直接定义资源，跟我们在res/values中定义是一样的：

debug和release版的APP，一般需要设置不同的接口地址，方便测试使用。我们可以使用如下的方式实现：

BuildConfig类是项目构建过程中生成的，默认情况下DEBUG只在BuildType为debug的时候为true，其它情况下都为false。当然也可以设置：

我们通过BuildConfig的DEBUG字段去决定使用哪个URL，能不能在BuildConfig中增加字段呢？例如直接增加一个BASE_URL字段，这样岂不是更加直接。当然可以：

利用buildConfigField方法定义新的字段，注意最后一个参数的写法'" http://example.com/api "'，buildConfigField的三个参数都是String类型，最后一个参数String的值会直接拿来赋值给我们定义的字段：

一顿操作之后，我们便可以直接引用我们定义的字段了：

这种方式比较直接，但是如果要修改BASE_URL的值则需要Sync Gradle。究竟使用哪种方式，看你的喜好了。

对于multiproject多工程（包含有多个module）而言，一个常见的需求就是在不同的Project之间“共享”一些属性。例如，指定统一的compileSdkVersion、buildToolsVersion、appcompat版本等。这可以通过额外属性来实现。

这种方式的确可以，但是并不推荐。因为gradle.properties主要是用来设置Gradle本身的属性的。

这样就可以在所有build.gradle中直接使用额外属性了：

插件对于Gradle而言是极其重要的，除了我们常用的Android Application插件和Android Library插件外，我们也可以自己定义插件。Gradle插件既可以是像Android Application这样的，实现了Plugin接口的插件（主要用来定义了Tasks，在多个Project中复用这些Tasks）；也可以是简单的groovy脚本文件（主要用来在多个Project中共享一些属性、方法等）。根据我们的需求，定义脚本插件即可。
可以在根目录定义versions.gradle文件：

然后在顶层build.gradle中将versions.gradle作为脚本插件，应用到所有Project中：

余下的步骤是一样的，可以在所有build.gradle中直接使用额外属性了。这种方式不同于在RootProject中定义额外属性，versions.gradle被应用在了所有的Project中，相当于在每个Project中都定义了额外属性，只是这些属性都是相同的。并且，这种方式也更加符合Gradle模块化的思想，是比较推荐的方式。
进一步的，我们可以在versions.gralde中定义更多东西：

在module中的build.gradle中：

我自己对Gradle的使用也比较有限，遇到更多Gradle的使用实例我再补充。

在android studio中build.gradle中使用flavor维度

我们可以使用构建gradle中的产品flavor字段构建多个应用程序变体。为什么味道尺寸？并且它是强制性的错误信息，“所有口味现在应该属于风味维度”

如果它有合理的用途，我们如何以及在哪里可以区分不同风味尺寸的配置？

我提到的所有其他博客和帖子都没有给我满意的答案，大多数人告诉我“你不需要它”。请多点亮一点。

答案

我最好将风味尺寸描述为一种分类风味的方式。

我能想到的一个用例就是这个。

• 您可以在等级的维度下获得免费且有偿的风味。
• 您有一种测试和产品风味，指向环境维度下的不同后端。

当你组装所有你最终为每个层和环境的版本，所以你可以测试免费/测试版本，免费/ prod版本等。

您不需要检查维度，只需将任何变量/条件代码放在风​​格中就像往常一样。

使用多个维度的示例

,,,
flavorDimensions "tier", "env"

productFlavors {
    paid {
        dimension "tier"
        ... add variables here
    }

    free {
        dimension "tier"
        versionName = android.defaultConfig.versionName + " free"
        ... add variables here
    }

    test {
         dimension "env"
         ... add variables here
    }

    prod {
         dimension "env"
         ... add variables here
    }
}
...