一直听说Gradle神乎其神，但奈何才疏学浅无法领悟其精髓。
昨天忙里偷闲扒了几篇大神博客，有点想法总结一下。
心急的同学可以直接拉到最后一个大标题 ** 一些技巧 ** ヾ(≧O≦)〃嗷~
Gradle？
大概来说，这货就是一个自动化构建工具，跟ant差不多，如果没有它的话，编译android会是件很麻烦的事情。
如果你用的是AS，那么他会帮你自动安装，不用自己操心。
在使用AS建立 Android 项目的时候，会自动帮你生成Gradle文件，简单的项目其实可以忽略这东西的存在。
如图1所示，Progect在Android视图，每次我们新建项目的时候，会出现这三个Gradle文件，第一个是全局Gradle文件，一般不做修改，第三个是告诉编译器需要编译哪些模块，一般在Module Setting里修改之后自动更改。我们重点关注下第二个，也就是我们自己模块的Gradle文件。
ps：集成codetags的时候，官方文档要求修改全局gradle文件，我不知道这么做的必要性是什么。
几个常见配置
如果整个项目就只有一个module，那么这个Gradle文件就是最重要的一个，他关系到我们整个app的编译过程，以下是我们项目这个文件的大概样子
// 使用插件 声明是Android程序
apply plugin: 'com.android.application'
android {
// 编译SDK的版本
compileSdkVersion 25
// build tools的版本
buildToolsVersion "24.0.3"
defaultConfig {
// 应用包名
applicationId "com.zx.myapplication"
// 最小支持的sdk版本
minSdkVersion 23
// 目标sdk版本
targetSdkVersion 25
// 版本号
versionCode 1
// 版本名称
versionName "1.0"
}
// 签名信息
signingConfigs {
release {
storeFile file('D:/Java/test/test.jks')
storePassword "test"
keyAlias "test"
keyPassword "test"
}
debug {
}
}
buildTypes {
release {
// app名称替换
manifestPlaceholders = [app_name:"@string/app_name"]
//构建 release 使用 release签名
signingConfig signingConfigs.release
// 是否进行混淆
minifyEnabled false
// 混淆文件的位置
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
// 自动判断是测试环境还是生产环境
buildConfigField("boolean", "isRelease", "true")
}
debug {
// app名称替换
manifestPlaceholders = [app_name:"@string/app_name_debug"]
//构建 debug 使用 debug 签名
signingConfig signingConfigs.debug
// 自动判断是测试环境还是生产环境
buildConfigField("boolean", "isRelease", "false")
}
userdebug {
// app名称替换
manifestPlaceholders = [app_name:"@string/app_name_userdebug"]
//构建 userdebug 使用 release 签名
signingConfig signingConfigs.release
// 保留debug信息
debuggable true
// 自动判断是测试环境还是生产环境
buildConfigField("boolean", "isRelease", "false")
}
}
// 各种渠道，可以做一些多渠道区分
productFlavors {
qihu {
}
tengxun {
}
}
// 移除lint检查的error
lintOptions {
disable "ResourceType"
}
}
// 依赖信息
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
exclude group: 'com.android.support', module: 'support-annotations'
})
compile 'com.android.support:appcompat-v7:25.1.0'
testCompile 'junit:junit:4.12'
}
清单文件中被替换的部分长这个样子
<application
...
android:label="${app_name}"
...
<activity
...
</activity>
<application
这是一个gradle文件的例子，有详细注释。
当然，gradle文件也可以通过图二几个选项快速更改。
但是需要强调的是 ** buildTypes ** 节点。
AS项目在新建之初，在Gradle文件中，buildTypes节点下会默认生成一个release节点，方便用户配置正式版本的编译信息，此时debug虽然没有写出来，但它也是默认存在的，去图三的位置可以看到存在两个节点。
在当前例子中可以注意到，我在buildTypes中配置了三个节点，release，debug，userdebug。这三个节点分别代表了不同的构建版本，发布版，测试版以及用户测试版。
而 ** productFlavors ** 节点，用来配置多渠道信息，两个节点相加，就是 BuildVariants（构建变种版本）。
点击图2中的 ** select build variant ** 选项，在 如图3 弹出窗口选择后，可以直接通过 绿色箭头，Run 'app' 得到相应版本，或者在构建签名版本的时候，在Build->Generate Signed APK，填写签名信息之后，也可以看到Flavors多了我们添加的渠道。
一些技巧
- 在 ** buildTypes ** 的三个节点中，都有两句代码：
buildConfigField("boolean", "isRelease", "false")
signingConfig signingConfigs.release
第一句话的作用是在构建不同版本的时候（release/debug/userdebug），自动生成一个类型为 boolean ，变量名为 isRelease 的变量，然后在项目任意位置，可以通过 BuildConfig.isRelease 取得这个值。我会通过这个值来判断访问测试接口还是正式接口。
另外，上述判断版本也可以用其他字段实现，详见自己项目中的BuildConfig.class文件。
第二句话的作用是在构建不同版本的时候（release/debug/userdebug），使用不同的签名，比如测试签名无法调起 微信分享，必须使用正式签名。
在我的配置中，有一个 ** userdebug ** 节点，使用测试接口以及正式签名，这样就可以在测试环境下，调起微信分享。生产环境的时候使用 ** release ** 节点，可以防止由于疏忽把测试数据带入生产环境。
- 自定义build type节点，如** userdebug ** 节点如果需要打印输出信息，必须配置
userdebug {
...
// 保留debug信息
debuggable true
}
debug和release为默认节点，无需配置。
- 如果想让测试环境的APP跟生产环境的APP同时安装在手机上，可以使用
debug {
...
applicationIdSuffix ".debug"
}
这样可以改变debug包的ApplicationId，这句话的作用是在原有ApplicationId后面追加一个.debug，来达到区分APP的作用。
PS: 但是这么做的代价是依赖ApplicationId做唯一标识的三方库会无法使用，例如微信分享。在三方库管理平台上添加一次应用即可解决，添加的应用ApplicationId为 完整包名.debug。
特别感谢 stormzhang 大神，看他的博客收获良多。
个人理解，难免有错误纰漏，欢迎指正。转载请注明出处。
