快捷導(dǎo)航

Android App開發(fā)中Gradle構(gòu)建過程的配置方法

更新時(shí)間：2016年06月18日 17:41:45 作者：hi大頭鬼hi

這篇文章主要介紹了Android App開發(fā)中Gradle構(gòu)建過程的配置方法,包括在Gradle中配置manifest的方法,需要的朋友可以參考下

在build文件中使用了Android或者Java插件之后就會(huì)自動(dòng)創(chuàng)建一系列可以運(yùn)行的任務(wù)。
Gradle中有如下一下默認(rèn)約定的任務(wù):
1. assemble
該任務(wù)包含了項(xiàng)目中的所有打包相關(guān)的任務(wù)，比如java項(xiàng)目中打的jar包，Android項(xiàng)目中打的apk
2. check
該任務(wù)包含了項(xiàng)目中所有驗(yàn)證相關(guān)的任務(wù)，比如運(yùn)行測(cè)試的任務(wù)
3. build
該任務(wù)包含了assemble和check
4. clean
該任務(wù)會(huì)清空項(xiàng)目的所有的輸出，刪除所有在assemble任務(wù)中打的包
assemble, check 和 build 任務(wù)實(shí)際上并不做任何事情，它們其實(shí)只是為插件提供了一個(gè)鉤子，真正的事情都是由插件來完成的。
這樣的話，開發(fā)人員就不需要關(guān)心我到底運(yùn)行的是一個(gè)java項(xiàng)目還是一個(gè)Android項(xiàng)目，也不用關(guān)心我到底使用了哪些gradle插件，因?yàn)槲叶伎梢哉{(diào)用這些約定的任務(wù)來完成構(gòu)建。
比如使用findbugs插件會(huì)創(chuàng)建一個(gè)新的任務(wù)，并且使得check任務(wù)依賴于這個(gè)新建的任務(wù)，這樣每次執(zhí)行check任務(wù)的時(shí)候，都會(huì)執(zhí)行這個(gè)新建的任務(wù)。
在命令行執(zhí)行

gradle tasks

</pre>會(huì)列出所有主要的任務(wù)如果想看到全部的任務(wù)和它們的依賴，可以運(yùn)行：<pre name="code" class="java">gradle tasks --all
注意：Gradle會(huì)自動(dòng)檢查一個(gè)任務(wù)的輸入和輸出。比如連續(xù)兩次運(yùn)行build任務(wù)的，Gradle會(huì)報(bào)告所有的任務(wù)都已經(jīng)是最新剛運(yùn)行過的了，不需要再次運(yùn)行。這樣的話，任務(wù)之間就算是有相互依賴，也不會(huì)導(dǎo)致重復(fù)的執(zhí)行。
Java項(xiàng)目常用的任務(wù)
Java plugin 主要?jiǎng)?chuàng)建了兩個(gè)任務(wù)：
1. jar
assemble任務(wù)會(huì)依賴jar任務(wù)，看名字就知道這是負(fù)責(zé)打jar包的任務(wù)。jar任務(wù)本身又會(huì)依賴很多其他的任務(wù)，比如classes任務(wù)，classes任務(wù)會(huì)編譯java代碼
2. test
check任務(wù)會(huì)依賴test任務(wù)，這個(gè)任務(wù)會(huì)運(yùn)行所有的測(cè)試。測(cè)試代碼使用testClasses任務(wù)編譯，但是我們基本不用手動(dòng)運(yùn)行testClasses任務(wù)因?yàn)閠est任務(wù)已經(jīng)添加了對(duì)它的依賴。
通常情況下，我們只要運(yùn)行assemble和check任務(wù)就夠了。
想查看java插件提供的所有任務(wù)以及他們的依賴可以點(diǎn)這個(gè)[鏈接](http://gradle.org/docs/current/userguide/java_plugin.html)
Android項(xiàng)目常用的任務(wù)
和其他gradle插件一樣，Android插件也提供了一些默認(rèn)的任務(wù)，比如assemble，check，build，clean，同時(shí)它也提供了一些自己特有的任務(wù)，比如：
1. connectedCheck
運(yùn)行那些需要在真機(jī)或者模擬器上執(zhí)行的檢查任務(wù)，這些任務(wù)會(huì)并行地在所有連接的設(shè)備上運(yùn)行
2. deviceCheck
使用APIs連接遠(yuǎn)程設(shè)備執(zhí)行檢查.主要用于CI(持續(xù)集成)服務(wù)上.
上面兩個(gè)任務(wù)都會(huì)執(zhí)行 assemble 和 check任務(wù)。新加這兩個(gè)任務(wù)是很有必要的，這樣可以保證我們可以運(yùn)行那些不需要連接設(shè)備的檢查任務(wù)。
注意：build任務(wù)并不依賴于deviceCheck或者connectedCheck
一個(gè)Android項(xiàng)目通常至少會(huì)有兩種輸出：debug apk和release apk。對(duì)應(yīng)的gradle中有兩個(gè)任務(wù)可以分別輸出不同的apk：

assembleDebug
assembleRelease

這兩個(gè)任務(wù)又會(huì)依賴其他的任務(wù)來構(gòu)建一個(gè)apk。assemble任務(wù)依賴這兩個(gè)任務(wù)，調(diào)用assemble任務(wù)就會(huì)生成兩種apk。

小提示： Gradle支持在命令行使用camel風(fēng)格的縮寫來代替任務(wù)的名字，比如：

gradle aR

等同于

gradle assembleRelease

只要沒有其他任務(wù)的縮寫也是'aR'
check相關(guān)的任務(wù)的依賴：

check依賴lint
connectedCheck依賴 connectedAndroidTest和connectedUiAutomatorTest (還沒有實(shí)現(xiàn))
deviceCheck依賴于那些實(shí)現(xiàn)了test擴(kuò)展的插件所提供的任務(wù)

最后，Android gradle插件還提供了install和uninstall任務(wù)，用來安裝和卸載apk

自定義構(gòu)建過程之配置manifest
Android Gradle插件提供了大量的DSL來自定義構(gòu)建過程，下面就來講解如何在gradle中配置manifest。
DSL提供了配置以下Manifest條目的功能:

minSdkVersion
targetSdkVersion
versionCode
versionName
applicationId (更加方便有效的包名 -- [參考](http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename))
測(cè)試app的包名
Instrumentation test runner

示例：

android { 
  compileSdkVersion 19 
  buildToolsVersion "19.0.0" 
 
 
  defaultConfig { 
    versionCode 12 
    versionName "2.0" 
    minSdkVersion 16 
    targetSdkVersion 16 
  } 
}

android元素中的defaultConfig元素就是我們用來配置Manifest的地方。早期版本的Android插件使用packageName來配置manifest中的packageName屬性，從0.11.0開始，使用applicationId來代替packageName。這樣可以消除應(yīng)用的包名（其實(shí)就是應(yīng)用的id）和java的包名之間的混淆。

更強(qiáng)大的是build文件中描述的配置可以是動(dòng)態(tài)的，比如可以從文件或者自定義的邏輯中獲取版本名稱。

def computeVersionName() { 
  ... 
} 
 
 
android { 
  compileSdkVersion 19 
  buildToolsVersion "19.0.0" 
 
 
  defaultConfig { 
    versionCode 12 
    versionName computeVersionName() 
    minSdkVersion 16 
    targetSdkVersion 16 
  } 
}

注意：不要使用作用域中的getter方法名作為函數(shù)名，比如在defaultConfig{}作用域中調(diào)用getVersionName（）將會(huì)自動(dòng)調(diào)用defaultConfig.getVersionName()，而不會(huì)調(diào)用自定義的方法。
如果某個(gè)屬性的值沒有使用DSL設(shè)置，這個(gè)屬性將會(huì)使用某些默認(rèn)值，下表展示了默認(rèn)值的處理過程。
屬性名 DSL對(duì)象中的默認(rèn)值默認(rèn)值

Property Name	Default value in DSL object	Default value
versionCode	-1	value from manifest if present
versionName	null	value from manifest if present
minSdkVersion	-1	value from manifest if present
targetSdkVersion	-1	value from manifest if present
applicationId	null	value from manifest if present
testApplicationId	null	applicationId + “.test”
testInstrumentationRunner	null	android.test.InstrumentationTestRunner
signingConfig	null	null
proguardFile	N/A (set only)	N/A (set only)
proguardFiles	N/A (set only)	N/A (set only)

如果你想在build腳本中使用自定義的邏輯來查詢這些屬性，第二列中的值就很重要。比如，你可以編寫如下的代碼：

if (android.defaultConfig.testInstrumentationRunner == null) { 
  // assign a better default... 
}

如果屬性的值仍然是null，那么在構(gòu)建的時(shí)候，就會(huì)使用第三列的默認(rèn)值，但是DSL元素中并不包含這些默認(rèn)值，因此你不能在程序中查詢這些值。這樣做的目的是僅在必要的時(shí)候（構(gòu)建時(shí)）才會(huì)去解析manifest內(nèi)容。

您可能感興趣的文章: