《Gradle For Android（三）Gradle优化与灵活的使用技巧 》
转载请注明来自傻小孩b_移动开发（http://www.jianshu.com/users/d388bcf9c4d3）喜欢的可以关注我，不定期总结文章！您的支持是我的动力哈！
Gradle For Android 导读
前面两篇记录了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:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~"
}
}
4、lintOptions
程序在buid的时候，会执行lint检查，有任何的错误或者警告提示，都会终止构建，可以控制。
lintOptions {
abortOnError false
}
希望对有些开发者有帮助具体查看可以github上的demo，也欢迎加入开发交流群哈，详情看个人简介。下一篇是对gradle的混淆说明，欢迎读者阅读
DEMO
Gradle For Android（三）Gradle优化与灵活的使用技巧
傻小孩b mark共勉，写给在成长路上奋斗的你
网友评论