需求

随着android的发展，新技术和新概念层出不穷。不同的测试环境、不同的分发渠道、不同的依赖方式，再加上各大厂家“优秀”的插件化方案，这些给我们的开发工作带来了新的需求。我希望可以通过gradle这个令人又爱又恨的东西来解决这些问题。

实现

调整gradle的编译参数

gradle.properties中允许我们进行各种配置：

配置大内存：

org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

守护进程

org.gradle.daemon=true

并行编译

org.gradle.parallel=true

开启缓存：

android.enableBuildCache=true

开启孵化模式：

org.gradle.configureondemand=true

以上的配置需要针对自身进行选择，随意配置大内存可能会出现oom。如果想了解这样配置的原理，请移步官方文档。

写死库的版本

  1. dependencies {
  2.     compile 'com.google.code.gson:gson:2.+' // 不推荐的写法
  3. }

这样的写法可以保证库每次都是最新的，但也带来了不少的问题：

  • 每次build时会向网络进行检查，国内访问仓库速度很慢
  • 库更新后可能会更改库的内部逻辑和带来bug，这样就无法通过git的diff来规避此问题
  • 每个开发者可能会得到不同的最新版本，带来潜在的隐患

推荐写成固定的库版本：

  1. dependencies {
  2.     compile 'com.google.code.gson:gson:2.2.1'
  3. }

即使是jar包和aar，我也期望可以写一个固定的版本号，这样每次升级就可以通过git找到历史记录了，而不是简单的看jar包的hash是否变了。

全局设定编码

  1. allprojects {
  2.     repositories {
  3.         jcenter()
  4.     }
  5.  
  6.     tasks.withType(JavaCompile){
  7.         options.encoding = "UTF-8"
  8.     }
  9. }

支持groovy

在根目录的build.gradle中：

  1. apply plugin: 'groovy'
  2.  
  3. allprojects {
  4.     // ...
  5. ｝
  6.  
  7. dependencies {
  8.     compile localGroovy()
  9. }

设置java版本

如果是在某个module中设置，那么就在其build.gradle中配置：

  1. android {
  2.     compileOptions {
  3.         sourceCompatibility JavaVersion.VERSION_1_7
  4.         targetCompatibility JavaVersion.VERSION_1_7
  5.     }
  6. }

如果想要做全局配置，那么就在根目录的build.gradle中配置：

  1. allprojects {
  2.     repositories {
  3.         jcenter()
  4.     }
  5.     tasks.withType(JavaCompile) {
  6.         sourceCompatibility = JavaVersion.VERSION_1_7
  7.         targetCompatibility = JavaVersion.VERSION_1_7
  8.     }
  9. }

当我们在使用Gradle Retrolambda Plugin的时候，就会用到上述的配置（未来迁jack的时候也或许会用到）。

将密码等文件统一配置

密码和签名这类的敏感信息可以统一进行存放，不进行硬编码。在gradle.properies中，我们可以随意的定义key-value。
格式：

key value

例子：

  1. STORE_FILE_PATH ../test_key.jks
  2. STORE_PASSWORD test123
  3. KEY_ALIAS kale
  4. KEY_PASSWORD test123
  5. PACKAGE_NAME_SUFFIX .test
  6. TENCENT_AUTHID tencent123456

配置后，你就可以在build.gradle中随意使用了。

  1. signingConfigs {
  2.     release {
  3.         storeFile file(STORE_FILE_PATH)
  4.         storePassword STORE_PASSWORD
  5.         keyAlias KEY_ALIAS
  6.         keyPassword KEY_PASSWORD
  7.     }
  8. }

上述仅仅是应对于密码等信息的存放，其实你可以将这种方式用于插件化（组件化）等场景。

设置本地项目依赖

facebook的react native因为更新速度很快，jcenter的仓库已经无法达到实时的程度了（估计是官方懒得提交），所以我们需要做本地的库依赖。

先将库文件放入一个目录中：

接着配置maven的url为本地地址：

  1. allprojects {
  2.     repositories {
  3.         maven {
  4.             // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
  5.             url "$rootDir/module_name/libs/android"
  6.         }
  7.     }
  8. }

路径都是可以随意指定的，关键在于$rootDir这个参数。

设置第三方maven仓库

maven仓库的配置很简单，关键在于url这个参数，下面是一个例子：

  1. allprojects {
  2.     repositories {
  3.         maven {
  4.             url 'http://repo.xxxx.net/nexus/'
  5.             name 'maven name'
  6.             credentials {
  7.                 username = 'username'
  8.                 password = 'password'
  9.             }
  10.         }
  11.     }
  12. }

其中name和credentials是可选项，视具体情况而定。如果你用jitpack的库的话就需要用到上面的知识点了。

  1. allprojects {
  2.     repositories {
  3.         jcenter()
  4.         maven {
  5.             url "https://jitpack.io"
  6.         }
  7.     }
  8. }

删除unaligned apk

每次打包后都会有unaligned的apk文件，这个文件对开发来说没什么意义，所以可以配置一个task来删除它。

  1. dependencies {
  2.     compile fileTree(include: ['*.jar'], dir: 'libs')
  3.     // ...
  4. }
  5.  
  6. android.applicationVariants.all { variant ->
  7.     variant.outputs.each { output ->
  8.         // 删除unaligned apk
  9.         if (output.zipAlign != null) {
  10.             output.zipAlign.doLast {
  11.                 output.zipAlign.inputFile.delete()
  12.             }
  13.         }
  14.     }
  15. }

更改生成文件的位置

如果你希望你库生成的aar文件都放在特定的目录，你可以采用下列配置：

  1. android.libraryVariants.all { variant ->
  2.     variant.outputs.each { output ->
  3.         if (output.outputFile != null && output.outputFile.name.endsWith('.aar')) {
  4.             def name = "${rootDir}/demo/libs/library.aar"
  5.             output.outputFile = file(name)
  6.         }
  7.     }
  8. }

apk等文件也可以进行类似的处理（这里再次出现了${rootDir}关键字）。

lint选项开关

lint默认会做严格检查，遇到包错误会终止构建过程。你可以用如下开关关掉这个选项，不过最好是重视下lint的输出，有问题及时修复掉。

  1. android {
  2.     lintOptions {
  3.         disable 'InvalidPackage'
  4.         checkReleaseBuilds false
  5.         // Or, if you prefer, you can continue to check for errors in release builds,
  6.         // but continue the build even when errors are found:
  7.         abortOnError false
  8.     }
  9. }

引用本地aar

有时候我们有部分代码需要多个app共用，在不方便上传仓库的时候，可以做一个本地的aar依赖。

  1. 把aar文件放在某目录内，比如就放在某个module的libs目录内
  2. 在这个module的build.gradle文件中添加： 
    1. repositories {
    2.  flatDir {
    3.      dirs 'libs' //this way we can find the .aar file in libs folder
    4.  }
    5. }
  3. 之后在其他项目中添加下面的代码后就引用了该aar 
    1. dependencies {
    2.  compile(name:'aar的名字（不用加后缀）', ext:'aar')
    3. }

如果你希望把aar放在项目的根目录中，也可以参考上面的配置方案。在根目录的build.gradle中写上：

  1. allprojects {
  2.    repositories {
  3.       jcenter()
  4.       flatDir {
  5.         dirs 'libs'
  6.       }
  7.    }
  8. }

依赖项目中的module和jar

工程可以依赖自身的module和jar文件，依赖方式如下：

  1. dependencies {
  2.     compile project(':mylibraryModule')
  3.     compile files('libs/sdk-1.1.jar')
  4. }

这种的写法十分常用，语法格式不太好记，但一定要掌握。

根据buildType设置包名

  1. android {
  2.     defaultConfig {
  3.         applicationId "com" // 这里设置了com作为默认包名
  4.     }
  5.  
  6.     buildTypes {
  7.         release {
  8.             applicationIdSuffix '.kale.gradle' // 设置release时的包名为com.kale.gradle
  9.         }
  10.         debug{
  11.             applicationIdSuffix '.kale.debug' // 设置debug时的包名为com.kale.debug
  12.         }
  13.     }

这对于flavor也是同理：

  1. android {
  2.     productFlavors {
  3.         dev {
  4.             applicationIdSuffix '.kale.dev'
  5.         }
  6.     }
  7. }

这种写法只能改包名后缀，目前没办法完全更改整个包名。

替换AndroidManifest中的占位符

我们在manifest中可以有类似{appName}这样的占位符，在module的build.gradle中可以将其进行赋值。

  1. android{
  2.     defaultConfig{
  3.         manifestPlaceholders = [appName:"@string/app_name"]
  4.     }
  5. }

flavors或buildType也是同理：

  1. debug{
  2.     manifestPlaceholders = [
  3.         appName: "123456",
  4.     ]
  5. }

ShareLoginLib中就大量用到了这个技巧，下面是一个例子：

[代码地址]

  1.  
  2.  
  3.     
  4.         
  5.         
  6.

我现在希望在build时动态改变tencentAuthId这个的值：

[代码地址]

  1. release {
  2.     minifyEnabled false
  3.     shrinkResources false // 是否去除无效的资源文件
  4.     proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
  5.     signingConfig signingConfigs.release
  6.     applicationIdSuffix '.liulishuo.release'
  7.     manifestPlaceholders = [
  8.             // 这里的tencent123456是暂时测试用的appId
  9.             "tencentAuthId": "tencent123456",
  10.     ]
  11. }

定义全局变量

先在project根目录下的build.gradle定义全局变量:

  1. ext {
  2.     minSdkVersion = 16
  3.     targetSdkVersion = 24
  4. }

然后在各module的build.gradle中可以通过rootProject.ext来引用：

  1. android {
  2.     defaultConfig {
  3.         minSdkVersion rootProject.ext.minSdkVersion
  4.         targetSdkVersion rootProject.ext.targetSdkVersion
  5.     }
  6. }

这里添加rootProject是因为这个变量定义在根目录中，如果是在当前文件中定义的话就不用加了（详见定义局部变量一节）。

动态设置额外信息

假如想把当前的编译时间、编译的机器、最新的commit版本添加到apk中，利用gradle该如何实现呢？此需求中有时间这样的动态参数，不能通过静态的配置文件做，动态化方案如下：

  1. android {
  2.     defaultConfig {
  3.         resValue "string", "build_time", buildTime()
  4.         resValue "string", "build_host", hostName()
  5.         resValue "string", "build_revision", revision()
  6.     }
  7. }
  8. def buildTime() {
  9.     return new Date().format("yyyy-MM-dd HH:mm:ss")
  10. }
  11. def hostName() {
  12.     return System.getProperty("user.name") + "@" + InetAddress.localHost.hostName
  13. }
  14. def revision() {
  15.     def code = new ByteArrayOutputStream()
  16.     exec {
  17.         commandLine 'git', 'rev-parse', '--short', 'HEAD'
  18.         standardOutput = code
  19.     }
  20.     return code.toString()
  21. }

上述代码实现了动态添加了3个字符串资源: build_time、build_host、build_revision, 在其他地方可像引用字符串一样使用：

  1. getString(R.string.build_time)  // 输出2015-11-07 17:01
  2. getString(R.string.build_host)  // 输出jay@deepin，这是我的电脑的用户名和PC名
  3. getString(R.string.build_revision) // 输出3dd5823, 这是最后一次commit的sha值

上面讲到的是植入资源文件，我们照样可以在BuildConfig.class中增加自己的静态变量。

  1. defaultConfig {
  2.     applicationId "kale.gradle.demo"
  3.     minSdkVersion 14
  4.     targetSdkVersion 20
  5.  
  6.     buildConfigField("boolean", "IS_KALE_TEST", "true") // 定义一个bool变量
  7.  
  8.     resValue "string", "build_time", "2016.11.17" // 上面讲到的植入资源文件
  9. }

在sync后BuildConfig中就有你定义的这个变量了。

  1. public final class BuildConfig {
  2.   public static final boolean DEBUG = Boolean.parseBoolean("true");
  3.   public static final String APPLICATION_ID = "kale.gradle.test";
  4.   public static final String BUILD_TYPE = "debug";
  5.   public static final String FLAVOR = "";
  6.   public static final int VERSION_CODE = 1;
  7.   public static final String VERSION_NAME = "1.0.0";
  8.  
  9.   // Fields from default config.
  10.   public static final boolean IS_KALE_TEST = true;
  11. }

如果有带引号的string，要记得转义：

 buildConfigField "String", "URL_ENDPOINT", "\"http://your.development.endpoint.com/\""

init.with

如果我们想要新增加一个buildType，又想要新的buildType继承之前配置好的参数，init.with()就很适合你了。

  1. buildTypes {
  2.         release {
  3.             zipAlignEnabled true
  4.             minifyEnabled true
  5.             shrinkResources true // 是否去除无效的资源文件
  6.             proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
  7.             signingConfig signingConfigs.release
  8.         }
  9.         rtm.initWith(buildTypes.release) // 继承release的配置
  10.         rtm {}
  11.     }

多个flavor

flavor可以定义不同的产品场景，我们在之前的文章中已经多次讲到了这个属性，下面就是一个在dev的时候提升支持的android最低版本的做法。

  1. productFlavors {
  2.     // 自定义flavor
  3.     dev { 
  4.         minSdkVersion 21
  5.     }
  6. }

flavor的一大优点是可以通过as来动态的改变这个值，不用硬编码：

如果你定义了不同的flavor，可以在目录结构上针对不同的flavor定义不同的文件资源。

  1. productFlavors{
  2.      dev {}
  3.      dev2 {}
  4.      qihu360{}
  5.      yingyongbao{}
  6.  }

定义局部变量

有时候一个库会被引用多次，或者一个库有多个依赖，但这些依赖的版本都是统一的。我们通过ext来定义一些变量，这样在用到的时候就可以统一使用了。

  1. ext {
  2.     leakcanaryVersion = '1.3.1'
  3.     scalpelVersion = "1.1.2" // other param
  4. }
  1. debugCompile "com.squareup.leakcanary:leakcanary-android:$leakcanaryVersion"
  2. releaseCompile "com.squareup.leakcanary:leakcanary-android-no-op:$leakcanaryVersion"

exlude关键字

我们经常会遇到库冲突的问题，这个在多个部门协作的大公司会更常见到。将冲突的库通过exclude来做剔除是一个好方法。

  1. 剔除整个组织的库 
    1. compile ('com.facebook.fresco:animated-webp:0.13.0') {
    2.  exclude group: 'com.android.support' // 仅仅写组织名称
    3. }
  2. 剔除某个库
  1. compile('com.android.support:appcompat-v7:23.2.0') {
  2.     exclude group: 'com.android.support', module: 'support-annotations' // 写全称
  3.     exclude group: 'com.android.support', module: 'support-compat'
  4.     exclude group: 'com.android.support', module: 'support-v4'
  5.     exclude group: 'com.android.support', module: 'support-vector-drawable'
  6. }

聚合依赖多个库

有时候一些库是一并依赖的，剔除也是要一并剔除的，我们可以像下面这样进行统一引入：

  1. compile([
  2.         'com.github.tianzhijiexian:logger:2e5da00f0f',
  3.         'com.jakewharton.timber:timber:4.1.2'
  4. ])

这样别的开发者就知道哪些库是有相关性的，在下掉库的时候也比较方便。

剔除task

Gradle每次构建时都执行了许多的task，其中或许有一些task是我们不需要的，可以把它们都屏蔽掉，方法如下：

  1. tasks.whenTaskAdded { task ->
  2.     if (task.name.contains('AndroidTest') || task.name.contains('Test')) {
  3.          task.enabled = false
  4.     }
  5. }

这样我们就会在build时跳过包含AndroidTest和Test关键字的task了。

ps：有时候我们自己也会写一些task或者引入一些gradle插件和task，通过这种方式可以简单的进行选择性的执行（下文会将如何写逻辑判断）。

通过逻辑判断来跳过task

我们上面有提到动态获得字段的技巧，但有些东西是在打包发版的时候用，有些则是在调试时用，我们需要区分不同的场景，定义不同的task。我下面以通过“用git的commit号做版本号”这个需求做例子。

  1. def cmd = 'git rev-list HEAD --first-parent --count'
  2. def gitVersion = cmd.execute().text.trim().toInteger()
  3.  
  4. android {
  5.   defaultConfig {
  6.     versionCode gitVersion
  7.   }
  8. }

因为上面的操作可能比较慢，或者在debug时没必要，所以我们就做了如下判断：

  1. def gitVersion() {
  2.   if (!System.getenv('CI_BUILD')) { // 不通过CI进行build的时候返回01
  3.     // don't care
  4.     return 1
  5.   }
  6.   def cmd = 'git rev-list HEAD --first-parent --count'
  7.   cmd.execute().text.trim().toInteger()
  8. }
  9.  
  10. android {
  11.   defaultConfig {
  12.     versionCode gitVersion()
  13.   }
  14. }

这里用到了System.getenv()方法，你可以参考java中System下的getenv()来理解，就是得到当前的环境。

引用全局的配置文件

在根目录中建立一个config.gradle文件：

  1. ext {
  2.     android = [
  3.             compileSdkVersion: 23,
  4.             applicationId    : "com.kale.gradle",
  5.     ]
  6.  
  7.     dependencies = [
  8.             "support-v4": "com.android.support:appcompat-v7:24.2.1",
  9.     ]
  10. }

然后在根目录的build.gradle中引入apply from: "config.gradle"，即：

  1. // Top-level build file where you can add configuration options common to all sub-projects/modules.
  2. apply from: "config.gradle" // 引入该文件
  3.  
  4. buildscript {
  5.     repositories {
  6.         jcenter()
  7.     }
  8.     dependencies {
  9.         classpath 'com.android.tools.build:gradle:2.2.2'
  10.     }
  11.     // ...
  12. }

之后就可以在其余的gradle中读取变量了：

  1. defaultConfig {
  2.     applicationId rootProject.ext.android.applicationId // 引用applicationId
  3.     minSdkVersion 14
  4.     targetSdkVersion 20
  5. }
  6.  
  7. dependencies {
  8.     compile rootProject.ext.dependencide["support-v7"] // 引用dependencide
  9. }

区分不同环境下的不同依赖

我们除了可以通过buildtype来定义不同的依赖外，我们还可以通过写逻辑判断来做：

  1. dependencies {
  2.     //根据是不同情形进行判断
  3.     if (!needMultidex) {
  4.         provided fileTree(dir: 'libs', include: ['*.jar'])
  5.     } else {
  6.         compile 'com.android.support:multidex:1.0.0'
  7.     }
  8.     // ...
  9. }

动态改变module种类

插件化有可能会要根据环境更改当前module是app还是lib，gradle的出现让其成为了可能。

  1. if (isDebug.toBoolean()) {
  2.     apply plugin: 'com.android.application'
  3. } else {
  4.     apply plugin: 'com.android.library'
  5. }

接下来只需要在gradle.properties中写上：

isDebug = false

需要说明的是：根据公司和插件化技术的不同，此方法因人而异。

定义库的私有混淆

有很多库是需要进行混淆配置的，但让使用者配置混淆文件的方式总是不太友好，consumerProguardFiles的出现可以让库作者在库中定义混淆参数，让混淆配置对使用者屏蔽。
ShareLoginLib中的例子：

  1. apply plugin: 'com.android.library'
  2.  
  3. android {
  4.     compileSdkVersion 24
  5.     buildToolsVersion '24.0.2'
  6.  
  7.     defaultConfig {
  8.         minSdkVersion 9
  9.         targetSdkVersion 24
  10.         consumerProguardFiles 'consumer-proguard-rules.pro' // 自定义混淆配置
  11.     }
  12.  
  13.     buildTypes {
  14.         release {
  15.             minifyEnabled false
  16.             proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
  17.         }
  18.     }
  19. }

realm也用到了这样的配置：

打包工具会将*.pro文件打包进入aar中，库混淆时候会自动使用此混淆配置文件。

以consumerProguardFiles方式加入的混淆具有以下特性：

  • *.pro文件会包含在aar文件中
  • 这些pro配置会在混淆的时候被使用
  • 此配置针对此aar进行混淆配置
  • 此配置只对库文件有效，对应用程序无效

如果你对于consumerProguardFiles有疑问，可以去ConsumerProGuardFilesTest这个项目了解更多。

指定资源目录

  1. android {
  2.     sourceSets {
  3.         main {
  4.             manifest.srcFile 'AndroidManifest.xml'
  5.             java.srcDirs = ['src']
  6.             resources.srcDirs = ['src']
  7.             aidl.srcDirs = ['src']
  8.             renderscript.srcDirs = ['src']
  9.             assets.srcDirs = ['assets']
  10.             if (!IS_USE_DATABINDING) { // 如果用了databinding
  11.                 jniLibs.srcDirs = ['libs']
  12.                 res.srcDirs = ['res', 'res-vm'] // 多加了databinding的资源目录
  13.             } else {
  14.                 res.srcDirs = ['res']
  15.             }
  16.         }
  17.  
  18.         test {
  19.             java.srcDirs = ['test']
  20.         }
  21.  
  22.         androidTest {
  23.             java.srcDirs = ['androidTest']
  24.         }
  25.     }
  26. }

通过上面的配置，我们可以自定义java代码和res资源的目录，一个和多个都没有问题，更加灵活（layout文件分包也是利用了这个知识点）。

定义多个Manifest

  1. sourceSets {
  2.     main {
  3.         if (isDebug.toBoolean()) {
  4.             manifest.srcFile 'src/debug/AndroidManifest.xml'
  5.         } else {
  6.             manifest.srcFile 'src/release/AndroidManifest.xml'
  7.         }
  8.     }
  9. }

根据flavor也可以进行定义：

  1. productFlavors {
  2.     hip {
  3.         manifest.srcFile 'hip/AndroidManifest.xml'
  4.     }
  5.  
  6.     main {
  7.         manifest.srcFile '/AndroidManifest.xml'
  8.     }
  9. }

总结

gradle的最佳实践是最好写也是相当难写的。好写之处在于都是些约定俗成的配置项，而且写法固定；难写之处在于很难系统性的解释和说明它在实际中的意义。因为它太灵活了，可以做的事情太多了，用法还是交给开发者来扩展吧。
当年从eclipse切到android studio时，gradle没少给我添麻烦，也正是因为这些麻烦和不断的填坑积累，给我了上述的多个实践经验。
从写demo到正式项目，从正式项目做到开发库，从开发库做到组件化，这一步步的走来都少不了gradle这个魔鬼。今天我将我一年内学到的和真正使用过的东西分享在此，希望大家除了获益以外，还能真的将gradle视为敌人和友人，去多多了解这个家伙。