Gradle 4.1更新内容及注意事项

最新推荐文章于 2021-05-27 09:38:09 发布

weixin_33896069

最新推荐文章于 2021-05-27 09:38:09 发布

阅读量793

点赞数

CC 4.0 BY-SA版权

文章标签： java

原文链接：https://my.oschina.net/u/3389024/blog/1605822

本文详细介绍了Gradle 4.0版本的重要更新，包括废弃compile关键字，引入api和implementation关键字以提高构建效率，以及变体感知等新特性。此外还涉及了API变化、默认启用AAPT2等内容。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2019独角兽企业重金招聘Python工程师标准>>>

前言

进入2017年，Android Studio 版本更新至3.0，连带着com.android.tools.build:gradle 工具也升级到了3.0.0，在3.0.0中使用了最新的Gralde 4.0 里程碑版本作为gradle 的编译版本，该版本gradle编译速度有所加快，更加欣喜的是，完全支持Java 8。当然，对于Kotlin的支持在这个版本也更加完善。进入12月份，谷歌又将 com.android.tools.build:gradle 版本更新到了3.0.1(Gradle 4.1)，修复了一些 bug 并提升了启动速度，在这里我们直接拿最新的4.1版本的特性作为参照对象。

一. 废弃compile关键字

在 com.android.tools.build:gradle 3.0.0（即Gradle 4.0）版本中，compile关键字已经明确写明废弃了，但是google官方文档上说“还会保留一段时间，直到下个比较大的gradle tools版本发布”，所以现在使用compile暂时不会报错，取而代之的是 api 关键字（作用等同于compile关键字）和 implementaion 关键字。具体修改规则修改如下：

废弃的原因其实说起来很简单——就是为了加快工程的构建。

为了理解老版本Gradle 3.X构建系统的限制，这里假设有个工程使用了多层module依赖方式。如图所示：

对于最底部的基础module，其将会有两种可能的变化：

Implementation 变化：不会改动本module对外暴露的接口。
pplication binary interface (ABI)变化：将会改变本module对外暴露的接口。（本module指的是调用dependency的module）

注意：所有需要重新编译的module将会在以下用红色标出。

1. Implementation 变化（Gradle 4.X版本使用的依赖方式）

当本module依赖的ib(也可以是module)发生变化时，由于本module对外暴露的接口并不发生变化，在构建工程时gradle将会只重新编译本module，所有依赖于本module的module并不会发生编译。这种情况是没什么问题的。如图所示：

2. ABI变化（Gradle 3.X 使用的依赖方式）

当本module依赖的ib(也可以是module)发生变化时，本module向外暴露的接口发生了变化，那么所有直接依赖于本module的module将不得不重新编译。

接下来，这些上层module可能通过其本身的接口对外暴露了底层module的部分内容，即意味着本module暴露的接口也发生了变化，这会使得依赖于上层module的上上层module也需要重新编译。这就导致了一个连锁效应，因此，为了绝对的安全起见，gradle将不得不重新编译整个工程，使得编译时间变得较长。如图所示：

一点代码的改动可能会引起整个工程的重新编译，对构建效率的影响显而易见，而实际上Gradle 4.0之前的版本的确是如此处理的，根本原因就是gradle压根不知道暴露的接口可以通过一个接一个的依赖传递影响整个工程。

二. 新增加的api和implementation关键字

最新版的Gradle plugin需要你指出一个module的接口是否对外暴露其依赖lib的接口。基于此，可以让项目构建时，gradle可以判断哪个需要重新编译。因此，老版本的构建关键字compile被废弃了，而是改成了这两个：

api：同compile作用一样，即认为本module将会泄露其依赖的module的内容。
implementation：本module不会通过自身的接口向外部暴露其依赖module的内容。由此，我们可以明确的告诉gradle去重新编译一个module，若是这个使用的module的接口发生变化的话。

三. 其他关键字变化

provided关键字（对所有的build type以及favlors只在编译时使用，类似eclipse中的external-libs,只参与编译，不打包到最终apk） -> compileOnly
apk关键字（只会打包到apk文件中，而不参与编译） -> runtimeOnly

四. 新特性:变体感知

以前我们要创建不同版本的apk或者aar是使用productFlavor和buildType这两个维度。如果需要更多维度就需要Gradle Android的新机制 dimension(维度)：

比如app的debug会自动消费他依赖的library的debug变体(Variant). 这个是非常古老的一个遗留问题了,终于解决了；
需要为所有flavor指定dimension(维度)，不能直接匹配的需要提供matching fallbacks；
这里我们理解一下dimension，他指的是维度，也就是我们最终依靠这个维度去决定有哪些构建变体。同一个维度可以有多个productFlavor，也就是我们可以为多个productFlavor指定同一个维度。这样,每个维度下的Flavor数量的乘积就是最终构建变体(Variant)的数量(这里可以把buildType也认为是一个维度).

1. 使用方式

//定义两个风味维度
flavorDimensions "api", "mode"

productFlavors {
  	demo {
  		//指定风味维度
        dimension "mode"
        ...
  	}
  	
  	full {
        dimension "mode"
        ...
  	}
  	
  	minApi24 {
         dimension "api"
         minSDKVersion '24'
         versionNameSuffix "-minApi24"
  	}
  	
  	minApi23 {
  		dimension "api"
         minSDKVersion '23'
         versionNameSuffix "-minApi23"
  	}
  	
  	minApi21 {
  		dimension "api"
         minSDKVersion '21'
         versionNameSuffix "-minApi21"
  	}
}

如上，配置完后，Gradle创建的构建变体数量等于每个风味维度（flavorDimension）中的风味(productFlavor)数量的乘积再乘以你配置的构建类型数量。以上面的构建配置为例，Gradle 可以创建的构建变体数量为：3(api) x 2(mode) x 2(release和debug) = 12。

在 Gradle 为每个构建变体或对应 APK 命名时，属于较高优先级风味维度的产品风味首先显示，之后是较低优先级维度的产品风味，再之后是构建类型。

以上面的构建配置为例，Gradle 可以使用以下命名方案创建总共 12 个构建变体：

构建变体：minApi24, minApi23, minApi21[Debug, Release]

对应 APK：app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk

例如构建变体：minApi24DemoDebug，对应 APK：app-minApi24-demo-debug.apk

这样，大家大致知道这个维度到底是个什么东西了吧。就是我们以前构建变体只有productFlavor和buildType这两个维度，现在可以定义任意多个维度了。

2. 过滤变体

如果有些变体不想要,可以通过setIgnore(true)过滤掉他,这样编译也快一些：

android {
    ...
    variantFilter { variant ->
          def names = variant.flavors*.name
          // To check for a certain build type, use variant.buildType.name == "<buildType>"
          if (names.contains("minApi21") && names.contains("demo")) {
              // Gradle ignores any variants that satisfy the conditions above.
              setIgnore(true)
          }
      }
    ...
}

3. 迁移工程

之前我们只有sit和pro两个flavor，那么我们只需要通过flavorDimensions定义一个名为mode的dimension,然后给这两个flavor都设置dimension为mode即可。这个dimension的名字也可以自己起，比如可以叫env表示是生产环境和测试环境。
如果之前没有定义productFlavor就没有必要修改了。

4. 构建变体的规则

优先级
构建变体 > 构建类型 > 产品风味 > 主源集 > 库依赖项
其中:
构建变体就是多个维度最终产生的组合拳.
我们把buildType也作为一个dimension,他称为构建类型.
而productFlavor中定义的dimension为产品风味.
主源集就是main目录下面的资源了
库依赖项当然是各种依赖库了.

例如:
1. src/demoDebug/（构建变体源集）
2. src/debug/（构建类型源集）
3. src/demo/（产品风味源集）
4. src/main/（主源集）

5. 构建变体时如何解决元素缺失问题

(1). 你的 Module App 包含了它所依赖的库没有的构建类型

如果依赖工程，不需要像以前那样:

sitReleaseCompile project(path:':lib',configuration:'sitRelease')
proReleaseCompile ...
...

只需要下方写法即可：

compile project(":lib")

他会自动按照构建类型去寻找。那要是找不到呢? 比如对应的lib中没有对应的构建类型怎么办?
比如我们给Module app的buildType增加一个jniDebuggable类型如下:

 jniDebug {
        jniDebuggable true
    }

而在app所依赖的lib中没有这个构建类型，那自动依赖就会报错。这时候，我们可以指定matchingFallbacks表示找不到对应的依赖时可以按配置中指定的顺序找到第一个可用的，如下:

 jniDebug {
    jniDebuggable true
    matchingFallbacks =['debug','release']
}

注意当依赖的库中包含了Module App没有的构建类型，则不会出现上述问题。

(2). 对于一个给定的存在于App和它所依赖的库中的风味维度，我们的主Module App包含了库中没有的风味

例如，主Module App和库中都包含了一个mode的风味维度，我们的App中指定mode维度的是free和paid风味，而库中指定mode维度的是demo和paid风味，这时候我们就可以用`matchingFallbacks 来为App中的free指定可以替换的匹配项。如下：

android {
          defaultConfig{
          // Do not configure matchingFallbacks in the defaultConfig block.
          // Instead, you must specify fallbacks for a given product flavor in the
          // productFlavors block, as shown below.
        }
          flavorDimensions 'mode'
          productFlavors {
              paid {
                  dimension 'mode'
                  // Because the dependency already includes a "paid" flavor in its
                  // "mode" dimension, you don't need to provide a list of fallbacks
                  // for the "paid" flavor.
              }
              free {
                  dimension 'mode'
                  // Specifies a sorted list of fallback flavors that the plugin
                  // should try to use when a dependency's matching dimension does
                  // not include a "free" flavor. You may specify as many
                  // fallbacks as you like, and the plugin selects the first flavor
                  // that's available in the dependency's "mode" dimension.
                  matchingFallbacks = ['demo', 'trial']
              }
          }
      }

上述情况中，如果说库中包含了一个主Module App没有的产品风味，则不会出现上述问题。

(3). 库中包含了一个主Module App没有的风味维度

例如，库中声明了一个minApi的风味维度，但是你的App中只有mode维度，因此当你要构建freeDebug这个变种版本的App时，插件就不知道你是想用minApi23Debug还是用minApi25Debug变种版本的库，这时候我们可以在主Module App中的defaultConfig代码块通过配置missingDimensionStrategy来让插件从丢失的维度中指定默认的风味，当然你也可以在productFlavors代码块中覆盖先前的选择，因此每一个风味都可以为丢失的维度指定一个不同的匹配策略。

android {
	defaultConfig{
          // Specifies a sorted list of flavors that the plugin should try to use from
          // a given dimension. The following tells the plugin that, when encountering
          // a dependency that includes a "minApi" dimension, it should select the
          // "minApi23" flavor. You can include additional flavor names to provide a
          // sorted list of fallbacks for the dimension.
          missingDimensionStrategy 'minApi', 'minApi23', 'minApi25'
    }
    flavorDimensions 'mode'
    productFlavors {
        free {
            dimension 'mode'
            // You can override the default selection at the product flavor
            // level by configuring another missingDimensionStrategy property
            // for the "minApi" dimension.
            missingDimensionStrategy 'minApi', 'minApi25', 'minApi23'
        }
        paid {}
    }          
}

这里指的是如果如果依赖的工程中有这个minApi维度而主模块没有这个维度,则按照这个顺序选择依赖的flavor,比如优先选择minApi,如果没有minApi再选择minApi23.

当你的主Module App中包含了一个库中依赖项没有的风味维度时，则不会出现上述问题。例如，当库中依赖项不包含abi这个维度时，freeX86Debug版本将会使用freeDebug版本的依赖。

五. 其他变化

1. API的变化

尤其注意的是我们重命名打包的APK文件，以及输出路径。变化前：

applicationVariants.all { variant ->
	variant.outputs.each { output ->
		def outputFile = output.outputFile
		if (outputFile != null && outputFile.name.endsWith('.apk')) {
			if (variant.buildType.name == 'lotteryTest') {
				def fileName = "myApp_v${defaultConfig.versionName}_${releaseTime()}.apk"
				output.outputFile = new File(outputFile.parent, fileName)
			}
		}
	}
}

变化后：

applicationVariants.all { variant ->
	variant.outputs.all { output ->
		def outputFile = output.outputFile
		if (outputFile != null && outputFile.name.endsWith('.apk')) {
			if (variant.buildType.name == 'lotteryTest') {
				def fileName = "myApp_v${defaultConfig.versionName}_${releaseTime()}.apk"
				outputFileName = new File(fileName)
			}
		}
	}
}

即我们需要修改each() 和 outputFile() 方法为 all() 和 outputFileName

2. 默认启用AAPT2

在迁移的过程中，如果发现由于aapt2导致的异常，可以在gradle.properties中加入：

android.enableAapt2=false

3. 支持Java8新特性

Gradle带来全新的Java8支持方案desugar，启用十分简单，只需要配置下面代码：

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

如果你不想使用，也可以禁用，可以在gradle.properties中加入：

android.enableDesugar=false

记得删除上面的兼容Java8代码。

4. 移除Jack工具链，不再支持

android {
	...
	defaultConfig {
		...
		// Remove this block.
		jackOptions {
			enabled true
			...
		}
	}
}

5. 移除Retrolambda插件

在project中的build.gradle中移除：

buildscript {
	...
	dependencies {
		// Remove the following dependency.
		classpath 'me.tatarka:gradle-retrolambda:<version_number>'
	}
}

Module级build.gradle文件：

// Remove the following plugin.
apply plugin: 'me.tatarka.retrolambda'
...
// Remove this block after migrating useful configurations.
retrolambda {
	...
	// If you have arguments for the Java VM you want to keep,
	// move them to your project's gradle.properties file.
	jvmArgs '-Xmx2048m'
}