Gradle For Android（三）Gradle优化与灵活的使用技巧

前面两篇记录了Gradle基础依赖、多渠道打包以及签名配置，对于各位程序猿来说，应该再熟悉不过了~在开发路上，依然要好好对自己的知识作为总结，今天这一篇依然是讲述日常开发中gradle中的应用以及在某些场景的使用技巧。

目录

1、善用占位符

2、善用BuildConfig

3、保护信息安全，方便的全局设置

4、使用gradle.properties

5、常见配置

一、善用用占位符

上一篇在进行多渠道打包的时候，我们说过可以根据渠道不同，个性定制不同包名的apk。然后现在会有一个问题，在我们使用第三方平台，是必须根据包名与签名信息申请得到appkey，例如典型的地图开发appkey、友盟appkey，这些我们需要在AndroidManifest中配置meta-data，例如以下代码：

<meta-data
android:name="UMENG_CHANNEL"
android:value="dwqirhqifaosfjaofq2dasda" />

如果是这种固定的写法，当然不能解决我们根本的问题。因此我们需要根据渠道动态去修改这个value。Gradle组件提供了一个不错的功能，占位符，可以在gradle进行动态设置，举例：

//在渠道配置中...
xiaomi { //小米渠道
applicationId 'com.yuan.agradle1'//个性定制，小米市场包名不同

// 小米渠道配置appkey
manifestPlaceholders = [UMENG_CHANNEL_VALUE: 'xiaomi_appkey']
}
googlepaly { //google play 渠道
applicationId 'com.yuan.agradle2'

// googlepaly渠道配置appkey
manifestPlaceholders = [UMENG_CHANNEL_VALUE: 'googlepaly_appkey'
}

当然我们也可以一次性设置，例如如下：

productFlavors.all { flavor ->
manifestPlaceholders.put("UMENG_CHANNEL_VALUE","all_appkey")
}

二、善用BuildConfig

BuildConfig，是在我们module中的build.gradle配置正确，编译成功后，自动生成的配置文件，一般默认为一下代码;

package com.yuan.agradle;

public final class BuildConfig {
public static final boolean DEBUG = Boolean.parseBoolean("true");
public static final String APPLICATION_ID = "com.yuan.agradle4";
public static final String BUILD_TYPE = "debug";
public static final String FLAVOR = "baidu";
public static final int VERSION_CODE = 1;
public static final String VERSION_NAME = "1.0";
}

BuildConfig.java无法手动进行编译，但是他由Gradle进行动态控制。因此在作为app对Gradle的配置起到一个开关的重要作用。首先这里有两个关键字段：1.buildConfigField 2.resValue。

首先向看下配置的代码：

buildTypes {//表示构建类型 一般有release debug 两种

debug{
buildConfigField 'String','STATE_TEST','"debug"'/ildConfigField
resValue "string", "test_value", "AGradle_debug"//resValue
}

release { //release类型
minifyEnabled false
// 启用混淆
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

buildConfigField 'String','STATE_TEST','"release"' /ildConfigField
resValue "string", "test_value", "AGradle_release" //resValue
}

}

1、buildConfigField

buildConfigField 这个会根据gradle的配置，在原来默认的BuildConfig.java基础上，动态添加一个指定数据类型的value。当然，在程序中也是可以访问到的。使用的 规则：

buildConfigField 一共有3个参数，第一个是数据类型，就是你定义的常量值是一个什么类型，和Java的类型是对等的，这里是String。第二个参数是常量名，这里是 STATE_TEST。第三个参数是常量值。如此定义之后，就会在BuildConfig.java中生成一个常量名为 STATE_TEST的常量定义。默认配置的生成是：

buildConfigField 'String','STATE_TEST','"release"' /ildConfigField

BuildConfig.java 生成截图为：


buildconfig_1.png

2、resValue

buildConfigField主要改变了java常量，那么我们如何通过gradle动态配置管理资源文件，答案是肯定的。Gradle组件提供了resValue字段，用于动态生成value资源，在程序中也可以访问到，其中生成的目标存在generated.xml中，使用的规则与buildConfigField 类似，即类型+常量名+常量值，例如以下代码：

resValue "string", "test_value", "AGradle_release" //resValue

generated.xml生成截图：


Paste_Image.png

运行情况：

1、debug版本运行


debug_1.png

2、release版本运行


release_1.png

三、保护信息安全，方便的全局设置

在开发编译过程中，我们需要尽可能保证一些敏感性的文本信息安全，例如appkey、签名信息等。如今都比较推荐持续化构建，免去了程序猿处理编译打包的工作，一来能让程序猿更加专注开发、而来方便测试调试。例如目前流行的travis、jenkins等持续化构建环境。对于信息安全，很大程度签名密码等敏感信息由CI服务进行配置，而非纯文本凭证，这里CI我后期再说明，现在先讲述下全局设置。

1、新建一个全局配置的com_cfg.gradle，里面的内容为如下：

// 通用配置
ext {
// android
BUILD_SDK_VERSION = 23
BUILD_TOOLS_VERSION  =  "23.0.2"

//build config
MIN_SDK_VERSION  =  18
TARGT_SDK_VERSION  = 24
VERSION_CODE = 1
VERSION_NAME = "1.0"

//siging 这种不推荐喔
KEY_ALIAS = 'yuan'
KEY_PASSWORD = '888888'
KEY_FILEPATH = "../agradle.jks"
KEY_STORE_PASSWORD = '888888'

//appket
UMENG_CHANNEL_VALUE_XIAOMI =  'xiaomi_appkey'
UMENG_CHANNEL_VALUE_GOOGLE = 'googlepaly_appkey'
}

2、在project的build.gradle应用这个gradle配置

apply from: 'com_cfg.gradle'

3、application中的build.gradle使用ext中的自定义常量，例如：

compileSdkVersion BUILD_SDK_VERSION //SDK编译版本
buildToolsVersion  BUILD_TOOLS_VERSION//构建工具版本 对应buildTool

defaultConfig {
applicationId "com.yuan.agradle" //配置包名
minSdkVersion MIN_SDK_VERSION // 最小支持sdk版本
targetSdkVersion  TARGT_SDK_VERSION // 目标sdk版本
versionCode VERSION_CODE//版本号
versionName  VERSION_NAME //版本名称

testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

}

Ci服务器也是这种模式，通过终端命令行的形式将对于定义的常量，在gradle里面进行替换操作。这样全局设置有一个好处，假设project里面存在多个application module，这时候如果采用这种全局配置，可以达到一改应用多出的效果。当然，如果你有部分library module是想发布到jcenter，这时候可以定义一个针对library的配置文件，只需要要在library里面进行apply，这个可以完成独立的配置。不仅不会让本身的module更加笨重，并且配置会更清晰！

四、使用gradle.properties

这个跟第三个使用全局的gradle作用有点相似，区别就是全局的gradle是定义了ext，而gradle.properties则是直接提供配置参数。不过用法有点去吧喔，下面举例:

1、新建gradle.properties，并且写入一些配置参数

// android
BUILD_SDK_VERSION = 23
BUILD_TOOLS_VERSION  =  23.0.2

//build config
MIN_SDK_VERSION  =  18
TARGT_SDK_VERSION  = 24
VERSION_CODE = 1
VERSION_NAME = 1.0

2、module使用以及注意事项

////编译版本///////////////////////////////////////////////////////////////////////////////

compileSdkVersion BUILD_SDK_VERSION as int //SDK编译版本
buildToolsVersion  BUILD_TOOLS_VERSION//构建工具版本 对应buildTool

/////编译配置//////////////////////////////////////////////////////////////////////////////

defaultConfig {
applicationId "com.yuan.agradle" //配置包名
minSdkVersion MIN_SDK_VERSION as int // 最小支持sdk版本
targetSdkVersion  TARGT_SDK_VERSION as int// 目标sdk版本
versionCode VERSION_CODE as int//版本号
versionName  VERSION_NAME //版本名称

testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

}

很明显们看到了as int 关键字，这是因为本来gradle.properties配置信息是字符串的格式，如果我们输入的常量是整形的时候，我们必须通过as int 进行类型转化

五、常见配置

1、dexOptions

在Gradle 进行dex的可能会遇到内存不够用的情况，错误信息大概是java.lang.OutOfMemoryError: GC overhead limit exceeded。这个时候只需要配置dexOptions的javaMaxHeapSize大小即可：

dexOptions {  javaMaxHeapSize "2g" }

2、Java Compilation options

指定jdk版本,影响所有task编译Java源代码

android {
compileOptions {
sourceCompatibility = "1.7" //JavaVersion.VERSION_1_7
targetCompatibility = "1.7" //JavaVersion.VERSION_1_7
}
}

3、aapt options，影响所有使用aapt的task

android {
aaptOptions {
noCompress 'foo', 'bar'
ignoreAssetsPattern "!.svn:!.git:!.ds_store:!*.scc:.*:

_*:!CVS:!thumbs.db:!picasa.ini:!*~"
}
}

4、lintOptions

程序在buid的时候，会执行lint检查，有任何的错误或者警告提示，都会终止构建，可以控制。

lintOptions {
abortOnError false
}