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

gradle tasks 

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

• assembleDebug
• assembleRelease

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

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

gradle aR 

等同于

gradle assembleRelease 

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

• check依賴lint
• connectedCheck依賴 connectedAndroidTest和connectedUiAutomatorTest (還沒有實現(xiàn))
• deviceCheck依賴于那些實現(xiàn)了test擴展的插件所提供的任務(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))
• 測試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)用的包名（其實就是應(yīng)用的id）和java的包名之間的混淆。

更強大的是build文件中描述的配置可以是動態(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（）將會自動調(diào)用defaultConfig.getVersionName()，而不會調(diào)用自定義的方法。
如果某個屬性的值沒有使用DSL設(shè)置，這個屬性將會使用某些默認值，下表展示了默認值的處理過程。
屬性名    DSL對象中的默認值   默認值

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

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

最新評論