Android Studio已经成为现在Android 开发的主要工具,在开发过程中学习使用gradle显得格外重要,本篇博客,我们一起学习gradle打包的一些知识。
1.安装JDK,并配置JAVA_HOME环境变量。因为Gradle是用Groovy编写的,而Groovy基于JAVA。另外,Java版本要不小于1.5. 2.下载。地址是:http://www.gradle.org/downloads
选择Download,选择相应的complete版本即可
3.解压。如果你下载的是gradle-xx-all.zip的完整包,它会有以下内容: 二进制文件 用户手册(包括PDF和HTML两种版本) DSL参考指南 API手册(包括Javadoc和Groovydoc) 样例 源代码,仅供参考使用。
4.配置环境变量。配置GRADLE_HOME到你的gradle根目录当中,然后把%GRADLE_HOME%/bin(linux或mac的是$GRADLE_HOME/bin)加到PATH的环境变量。
配置完成之后,运行gradle -v,检查一下是否安装无误。如果安装正确,它会打印出Gradle的版本信息,包括它的构建信息,Groovy, Ant, Ivy, 当前JVM和当前系统的版本信息。
另外,可以通过GRADLE_OPTS或JAVA_OPTS来配置Gradle运行时的JVM参数。不过,JAVA_OPTS设置的参数也会影响到其他的JAVA应用程序。
Projects和tasks 先介绍两个概念,projects和tasks,它们是Gradle中的两个重要概念。 任何一个Gradle构建,都是由一个或多个projects组成的。Project就是你想要用Gradle做什么,比如构建一个jar包,构建一个web应用。Project也不单指构建操作,部署你的应用或搭建一个环境,也可以是一个project。 一个project由多个task组成。每个task代表了构建过程当中的一个原子性操作,比如编译,打包,生成javadoc,发布等等这些操作。
编写第一个构建脚本 新建一个文件build.gradle,然后添加以下代码:
task hello {
doLast {
println 'Hello, Gradle!'
}
}
这是一个非常简单的构建脚本,它定义了一个叫hello的task,task的内容是在最后打印出“Hello, Gradle!”。 输入命令gradle hello来执行它:
Gradle是领域驱动设计的构建工具,在它的实现当中,Project接口对应上面的project概念,Task接口对应上面的task概念,实际上除此之外还有一个重要的领域对象,即Action,对应的是task里面具体的某一个操作。一个project由多个task组成,一个task也是由多个action组成。 当执行gradle hello的时候,Gradle就会去调用这个hello task来执行给定操作(Action)。这个操作其实就是一个用Groovy代码写的闭包,代码中的task是Project类里的一个方法,通过调用这里的task方法创建了一个Task对象,并在对象的doLast方法中传入println 'Hello, Gradle!'这个闭包。这个闭包就是一个Action。 Task是Gradle里定义的一个接口,表示上述概念中的task。它定义了一系列的诸如doLast, doFirst等抽象方法,具体可以看gradle api里org.gradle.api.Task的文档。
在上面执行了gradle hello后,除了输出“Hello, Gradle!”之外,我们发现像“:hello”这样的其他内容。这其实是Gradle打印出来的日志,如果不想输出这些内容,可以在gradle后面加上参数 -q。即:gradle -q hello。
快速定义任务 上面的代码,还有一种更简洁的写法,如下:
task hello << {
println 'Hello, Gradle!'
}
task hello << { println ‘Hello, Gradle!’ } 代码即脚本 Gradle脚本是采用Groovy编写的,所以也像Groovy一样,以脚本方式来执行代码,如下面例子:
task upper << {
String someString = 'myName'
println "Original: " + someString
println "Upper case: " + someString.toUpperCase()
}
执行结果如下,它将定义的字符串转为大写:
D:\testGradle>gradle -q hello
Hello, Gradle!
D:\testGradle>gradle -q upper
Original: myName
Upper case: MYNAME
我们在写Gradle脚本的时候,可以像写Groovy代码一样。而Groovy是基于Java的,兼容Java语法 任务依赖 我们可以通过以下方式创建依赖:
task hello << {
print 'Hello, '
}
task intro(dependsOn: hello) << {
println "Gradle!"
}
定义一个任务hello,输出“Hello, ”,然后定义一个任务intro,并依赖hello,输出“Gradle!”。结果是打印出“Hello, Gradle!”,如下:
D:\testGradle>gradle -q intro
Hello, Gradle!
另外,被依赖的task不必放在前面声明,在后面也是可以的,这一点在后面将会用到。
动态任务 借助于强大的Groovy,我们还可以动态地创建任务。如下代码: 我们还可以动态地创建任务。如下代码:
4.times { counter ->
task "task$counter" << {
println "I'm task number $counter"
}
}
我们定义了4个task,分别是task0, task1, task2, task3。我们来执行task1,如下:
D:\testGradle>gradle -q task1
I'm task number 1
任务操纵 在Gradle当中,任务创建之后可以通过API进行访问,这是Gradle与Ant的不同之处。 增加依赖 还是以上面的例子,但是我们添加一行代码,如下:
4.times { counter ->
task "task$counter" << {
println "I'm task number $counter"
}
}
task1.dependsOn task0, task3
然后还是执行 gradle -q task1
gradle -q task1
I'm task number 0
I'm task number 3
I'm task number 1
它先执行了task0和task3,因为task1依赖于这两个。
增加任务行为
task hello << {
println 'Hello, Gradle!'
}
hello.doFirst {
println 'I am first.'
}
hello.doLast {
println 'I am last.'
}
hello << {
println 'I am the the last'
}
执行后的输出:
gradle -q hello
I am first.
Hello, Gradle!
I am last.
I am the the last
短标记法 如果你对groovy有一定了解,那你也许会注意到,每个task都是一个构建脚本的属性,所以可以通过“$”这种短标记法来访问任务。如下:
task hello << {
println 'Hello, Gradle!'
}
hello.doLast {
println "Greetings from the $hello.name task."
}
执行结果:
gradle -q hello
Hello, Gradle!
Greetings from the hello task.
注意,通过这种方法访问的任务一定是要已经定义的。
增加自定义属性
task myTask {
ext.myProperty = "myValue"
}
task printTaskProperties << {
println myTask.myProperty
}
输出结果:
gradle -q printTaskProperties
myValue
定义默认任务
defaultTasks 'clean', 'run'
task clean << {
println 'Default Cleaning!'
}
task run << {
println 'Default Running!'
}
task other << {
println "I'm not a default task!"
}
执行结果:
gradle -q
Default Cleaning!
Default Running!
DAG配置
Gradle使用DAG(Directed acyclic graph,有向非循环图)来决定任务执行的顺序。通过这一特性,我们可以实现依赖任务做不同输出。 如下代码:
task distribution << {
println "We build the zip with version=$version"
}
task release(dependsOn: 'distribution') << {
println 'We release now'
}
gradle.taskGraph.whenReady {taskGraph ->
if (taskGraph.hasTask(release)) {
version = '1.0'
} else {
version = '1.0-SNAPSHOT'
}
}
执行结果如下:
gradle -q
Default Cleaning!
Default Running!
D:\testGradle>gradle -q distribution
We build the zip with version=1.0-SNAPSHOT
D:\testGradle> gradle -q release
We build the zip with version=1.0
We release now
在上面的脚本代码中,whenReady会在release任务执行之前影响它,即使这个任务不是主要的任务(即不是通过命令行传入参数来调用)。
--------------接下来是Android Gradle打包的小技巧-----------
把配置中的${app_label}替换为@string/app_name
android{
defaultConfig{
manifestPlaceholders = [app_label:"@string/app_name"]
}
}
如果只想替换debug版本:
android{
buildTypes {
debug {
manifestPlaceholders = [app_label:"@string/app_name_debug"]
}
release {
}
}
}
更多的需求是替换渠道编号:
android{
productFlavors {
// 把dev产品型号的apk的AndroidManifest中的channel替换dev
"dev"{
manifestPlaceholders = [channel:"dev"]
}
}
}
对于签名相关的信息,直接写在gradle当然不好,特别是一些开源项目,可以添加到gradle.properties:
RELEASE_KEY_PASSWORD=xxxx
RELEASE_KEY_ALIAS=xxx
RELEASE_STORE_PASSWORD=xxx
RELEASE_STORE_FILE=../.keystore/xxx.jks
然后在build.gradle中引用即可:
android {
signingConfigs {
release {
storeFile file(RELEASE_STORE_FILE)
storePassword RELEASE_STORE_PASSWORD
keyAlias RELEASE_KEY_ALIAS
keyPassword RELEASE_KEY_PASSWORD
}
}
}
如果不想提交到版本库,可以添加到local.properties中,然后在build.gradle中读取。
多渠道打包的关键之处在于,定义不同的product flavor, 并把AndroiManifest中的channel渠道编号替换为对应的flavor标识:
android {
productFlavors {
dev{
manifestPlaceholders = [channel:"dev"]
}
official{
manifestPlaceholders = [channel:"official"]
}
// ... ...
wandoujia{
manifestPlaceholders = [channel:"wandoujia"]
}
xiaomi{
manifestPlaceholders = [channel:"xiaomi"]
}
"360"{
manifestPlaceholders = [channel:"360"]
}
}
注意一点,这里的flavor名如果是数字开头,必须用引号引起来。 构建一下,就能生成一系列的Build Variant了:
devDebug
devRelease
officialDebug
officialRelease
wandoujiaDebug
wandoujiaRelease
xiaomiDebug
xiaomiRelease
360Debug
360Release
其中debug, release是gradle默认自带的两个build type, 下一节还会继续说明。选择一个,就能编译出对应渠道的apk了。
前面说到默认的build type有两种debug和release,区别如下:
// release版本生成的BuildConfig特性信息
public final class BuildConfig {
public static final boolean DEBUG = false;
public static final String BUILD_TYPE = "release";
}
// debug版本生成的BuildConfig特性信息
public final class BuildConfig {
public static final boolean DEBUG = true;
public static final String BUILD_TYPE = "debug";
}
现在有一种需求,增加一种build type,介于debug和release之间,就是和release版本一样,但是要保留debug状态(如果做过rom开发的话,类似于user debug版本),我们称为preview版本吧。 其实很简单:
android {
signingConfigs {
debug {
storeFile file(RELEASE_STORE_FILE)
storePassword RELEASE_STORE_PASSWORD
keyAlias RELEASE_KEY_ALIAS
keyPassword RELEASE_KEY_PASSWORD
}
preview {
storeFile file(RELEASE_STORE_FILE)
storePassword RELEASE_STORE_PASSWORD
keyAlias RELEASE_KEY_ALIAS
keyPassword RELEASE_KEY_PASSWORD
}
release {
storeFile file(RELEASE_STORE_FILE)
storePassword RELEASE_STORE_PASSWORD
keyAlias RELEASE_KEY_ALIAS
keyPassword RELEASE_KEY_PASSWORD
}
}
buildTypes {
debug {
manifestPlaceholders = [app_label:"@string/app_name_debug"]
}
release {
manifestPlaceholders = [app_label:"@string/app_name"]
}
preview{
manifestPlaceholders = [app_label:"@string/app_name_preview"]
}
}
}
另外,build type还有一个好处,如果想要一次性生成所有的preview版本,执行assemblePreview即可,debug和releae版本同理。
上面我们在不同的build type替换${app_label}为不同的字符串,这样安装到手机上就能明显的区分出不同build type的版本。 除此之外,可能还可以配置一些参数,我这里列几个我在工作中用到的:
android {
debug {
manifestPlaceholders = [app_label:"@string/app_name_debug"]
applicationIdSuffix ".debug"
minifyEnabled false
signingConfig signingConfigs.debug
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
release {
manifestPlaceholders = [app_label:"@string/app_name"]
minifyEnabled true
shrinkResources true
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
preview{
manifestPlaceholders = [app_label:"@string/app_name_preview"]
applicationIdSuffix ".preview"
debuggable true // 保留debug信息
minifyEnabled true
shrinkResources true
signingConfig signingConfigs.preview
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
这些都用的太多了,稍微解释一下:
// minifyEnabled 混淆处理
// shrinkResources 去除无用资源
// signingConfig 签名
// proguardFiles 混淆配置
// applicationIdSuffix 增加APP ID的后缀
// debuggable 是否保留调试信息
// ... ...
随着产品渠道的铺开,往往一套代码需要支持多个产品形态,这就需要抽象出主要代码到一个Library,然后基于Library扩展几个App Module。 相信每个module的build.gradle都会有这个代码:
android {
compileSdkVersion 22
buildToolsVersion "23.0.1"
defaultConfig {
minSdkVersion 10
targetSdkVersion 22
versionCode 34
versionName "v2.6.1"
}
当升级sdk、build tool、target sdk等,几个module都要更改,非常的麻烦。最重要的是,很容易忘记,最终导致app module之间的差异不统一,也不可控。 强大的gradle插件在1.1.0支持全局变量设定,一举解决了这个问题。 先在project的根目录下的build.gradle定义ext全局变量:
ext {
compileSdkVersion = 22
buildToolsVersion = "23.0.1"
minSdkVersion = 10
targetSdkVersion = 22
versionCode = 34
versionName = "v2.6.1"
}
然后在各module的build.gradle中引用如下:
Android {
compileSdkVersion rootProject.ext.compileSdkVersion
buildToolsVersion rootProject.ext.buildToolsVersion
defaultConfig {
applicationId "com.xxx.xxx"
minSdkVersion rootProject.ext.minSdkVersion
targetSdkVersion rootProject.ext.targetSdkVersion
versionCode rootProject.ext.versionCode
versionName rootProject.ext.versionName
}
}
然后每次修改project级别的build.gradle即可实现全局统一配置。
默认android studio生成的apk名称为app-debug.apk或者app-release.apk,当有多个渠道的时候,需要同时编出50个渠道包的时候,就麻烦了,不知道谁是谁了。 这个时候,就需要自定义导出的APK名称了,不同的渠道编出的APK的文件名应该是不一样的。
android {
// rename the apk with the version name
applicationVariants.all { variant ->
variant.outputs.each { output ->
output.outputFile = new File(
output.outputFile.parent,
"lol-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase())
}
}
}
当apk太多时,如果能把apk按debug,release,preview分一下类就更好了(事实上,对于我这样经常发版的人,一编往往就要编四五十个版本的人,debug和release版本全混在一起没法看,必须分类),简单:
android {
// rename the apk with the version name
// add output file sub folder by build type
applicationVariants.all { variant ->
variant.outputs.each { output ->
output.outputFile = new File(
output.outputFile.parent + "/${variant.buildType.name}",
"lol-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase())
}
}
}
现在生成了类似于lol-dev-preview-v2.4.0.0.apk这样格式的包了,preview的包自然就放在preview的文件夹下,清晰明了。
混淆能让反编译的代码可读性变的很差,而且还能显著的减少APK包的大小。
第一个技巧
相信很多朋友对混淆都觉得麻烦,甚至说,非常乱。因为添加混淆规则需要查询官方说明文档,甚至有的官方文档还没说明。当你引用了太多库后,添加混淆规则将使一场噩梦。 这里介绍一个技巧,不用查官方文档,不用逐个库考虑添加规则。 首先,除了默认的混淆配置(android-sdk/tools/proguard/proguard-android.txt), 自己的代码肯定是要自己配置的: 接下来是麻烦的第三方库,一般来说,如果是极光推的话,它的包名是cn.jpush, 添加如下代码即可:
dontwarn cn.jpush.**
-keep class cn.jpush.** { *; }
其他的第三库也是如此,一个一个添加,太累!其实可以用第三方反编译工具(比如jadx:https://github.com/skylot/jadx ),打开apk后,一眼就能看到引用的所有第三方库的包名,把所有不想混淆或者不确定能不能混淆的,直接都添加又有何不可:
#####################################
######### 第三方库或者jar包 ###########
#####################################
-dontwarn cn.jpush.**
-keep class cn.jpush.** { *; }
-dontwarn com.squareup.**
-keep class com.squareup.** { *; }
-dontwarn com.octo.**
-keep class com.octo.** { *; }
-dontwarn de.**
-keep class de.** { *; }
-dontwarn javax.**
-keep class javax.** { *; }
-dontwarn org.**
-keep class org.** { *; }
-dontwarn u.aly.**
-keep class u.aly.** { *; }
-dontwarn uk.**
-keep class uk.** { *; }
-dontwarn com.baidu.**
-keep class com.baidu.** { *; }
-dontwarn com.facebook.**
-keep class com.facebook.** { *; }
-dontwarn com.google.**
-keep class com.google.** { *; }
## ... ...
第二个技巧
一般release版本混淆之后,像友盟这样的统计系统如果有崩溃异常,会记录如下:
java.lang.NullPointerException: java.lang.NullPointerException
at com.xxx.TabMessageFragment$7.run(Unknown Source)
这个Unknown Source是很要命的,排除错误无法定位到具体行了,大大降低调试效率。 当然,友盟支持上传Mapping文件,可帮助定位,mapping文件的位置在:
project > module
> build > outputs > {flavor name} > {build type} > mapping.txt
如果版本一多,mapping.txt每次都要重新生成,还要上传,终归还是麻烦。 其实,在proguard-rules.pro中添加如下代码即可:
-keepattributes SourceFile,LineNumberTabl
当然apk包会大那么一点点(我这里6M的包,大个200k吧),但是再也不用mapping.txt也能定位到行了,为了这种解脱,这个代价是值的!
假如想把当前的编译时间、编译的机器、最新的commit版本添加到apk,而这些信息又不好写在代码里,强大的gradle给了我创造可能的自信:
android {
defaultConfig {
resValue "string", "build_time", buildTime()
resValue "string", "build_host", hostName()
resValue "string", "build_revision", revision()
}
}
def buildTime() {
return new Date().format("yyyy-MM-dd HH:mm:ss")
}
def hostName() {
return System.getProperty("user.name") + "@" + InetAddress.localHost.hostName
}
def revision() {
def code = new ByteArrayOutputStream()
exec {
commandLine 'git', 'rev-parse', '--short', 'HEAD'
standardOutput = code
}
return code.toString()
}
上述代码实现了动态的添加了3个字符串资源: build_time、build_host、build_revision, 然后在其他地方可像如引用字符串一样使用如下:
// 在Activity里调用
getString(R.string.build_time)
getString(R.string.build_host)
getString(R.string.build_revision)
为了调试方便,我们往往会在debug版本留一个显示我们想看的界面,如何进入到一个界面,我们可以仿照android开发者选项的方式,点七下才显示,我们来实现一个:
private int clickCount = 0;
private long clickTime = 0;
sevenClickView.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
if (clickTime == 0) {
clickTime = System.currentTimeMillis();
}
if (System.currentTimeMillis() - clickTime > 500) {
clickCount = 0;
} else {
clickCount++;
}
clickTime = System.currentTimeMillis();
if (clickCount > 6) {
// 点七下条件达到,跳到debug界面
}
}
});
release版本肯定是不能暴露这个界面的,也不能让人用am在命令行调起,如何防止呢,可以在release版本把这个debug界面的exported设为false。