Android App開發中Gradle構建過程的配置方法_Android

在build檔案中使用了Android或者Java外掛程式之後就會自動建立一系列可以啟動並執行任務。
Gradle中有如下一下預設約定的任務:
1. assemble
該任務包含了項目中的所有打包相關的任務，比如java項目中打的jar包，Android項目中打的apk
2. check
該任務包含了項目中所有驗證相關的任務，比如運行測試的任務
3. build
該任務包含了assemble和check
4. clean
該任務會清空項目的所有的輸出，刪除所有在assemble任務中打的包
assemble, check 和 build 任務實際上並不做任何事情，它們其實只是為外掛程式提供了一個鉤子，真正的事情都是由外掛程式來完成的。
這樣的話，開發人員就不需要關心我到底啟動並執行是一個java項目還是一個Android項目，也不用關心我到底使用了哪些gradle外掛程式，因為我都可以調用這些約定的任務來完成構建。
比如使用findbugs外掛程式會建立一個新的任務，並且使得check任務依賴於這個建立的任務，這樣每次執行check任務的時候，都會執行這個建立的任務。
在命令列執行
  

gradle tasks 

 
</pre>會列出所有主要的任務如果想看到全部的任務和它們的依賴，可以運行：<pre name="code" class="java">gradle tasks --all 
注意：Gradle會自動檢查一個任務的輸入和輸出。比如連續兩次運行build任務的，Gradle會報告所有的任務都已經是最新剛運行過的了，不需要再次運行。這樣的話，任務之間就算是有相互依賴，也不會導致重複的執行。
Java項目常用的任務
Java plugin 主要建立了兩個任務：
1. jar
assemble任務會依賴jar任務，看名字就知道這是負責打jar包的任務。jar任務本身又會依賴很多其他的任務，比如classes任務，classes任務會編譯java代碼
2. test
check任務會依賴test任務，這個任務會運行所有的測試。測試代碼使用testClasses任務編譯，但是我們基本不用手動運行testClasses任務因為test任務已經添加了對它的依賴。
通常情況下，我們只要運行assemble和check任務就夠了。
想查看java外掛程式提供的所有任務以及他們的依賴可以點這個[連結](http://gradle.org/docs/current/userguide/java_plugin.html)
Android項目常用的任務
和其他gradle外掛程式一樣，Android外掛程式也提供了一些預設的任務，比如assemble，check，build，clean，同時它也提供了一些自己特有的任務，比如：
1. connectedCheck
運行那些需要在真機或者模擬器上執行的檢查任務，這些任務會並行地在所有串連的裝置上運行
2. deviceCheck
使用APIs串連遠程裝置執行檢查.主要用於CI(持續整合)服務上.
上面兩個任務都會執行 assemble 和 check任務。新加這兩個任務是很有必要的，這樣可以保證我們可以運行那些不需要串連裝置的檢查任務。
注意：build任務並不依賴於deviceCheck或者connectedCheck
一個Android項目通常至少會有兩種輸出：debug apk和release apk。對應的gradle中有兩個任務可以分別輸出不同的apk：

• assembleDebug
• assembleRelease

這兩個任務又會依賴其他的任務來構建一個apk。assemble任務依賴這兩個任務，調用assemble任務就會產生兩種apk。

小提示： Gradle支援在命令列使用camel風格的縮寫來代替任務的名字，比如：

gradle aR 

等同於

gradle assembleRelease 

只要沒有其他任務的縮寫也是'aR'
check相關的任務的依賴：

• check依賴lint
• connectedCheck依賴 connectedAndroidTest和connectedUiAutomatorTest (還沒有實現)
• deviceCheck依賴於那些實現了test擴充的外掛程式所提供的任務

最後，Android gradle外掛程式還提供了install和uninstall任務，用來安裝和卸載apk

自訂構建過程之配置manifest
Android Gradle外掛程式提供了大量的DSL來自訂構建過程，下面就來講解如何在gradle中配置manifest。
DSL提供了配置以下Manifest條目的功能:

• minSdkVersion
• targetSdkVersion
• versionCode
• versionName
• applicationId (更加方便有效包名 -- [參考](http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename))
• 測試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。這樣可以消除應用的包名（其實就是應用的id）和java的包名之間的混淆。

更強大的是build檔案中描述的配置可以是動態，比如可以從檔案或者自訂的邏輯中擷取版本名稱。

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

 注意：不要使用範圍中的getter方法名作為函數名，比如在defaultConfig{}範圍中調用getVersionName（）將會自動調用defaultConfig.getVersionName()，而不會調用自訂的方法。
如果某個屬性的值沒有使用DSL設定，這個屬性將會使用某些預設值，下表展示了預設值的處理過程。
屬性名稱    DSL對象中的預設值   預設值

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，那麼在構建的時候，就會使用第三列的預設值，但是DSL元素中並不包含這些預設值，因此你不能在程式中查詢這些值。這樣做的目的是僅在必要的時候（構建時）才會去解析manifest內容。