接上一篇  深刻淺出Android Gradle構建體系（二:項目構造）

構建義務(Build Tasks)

java和Android通用的義務
在build文件中應用了Android或者Java插件之后就會主動創(chuàng)建一系列可以運行的義務。
Gradle中有如下一下默認商定的義務:
1. assemble
該義務包含了項目中的所有打包相干的義務，比如java項目中打的jar包，Android項目中打的apk
2. check
該義務包含了項目中所有驗證相干的義務，比如運行測試的義務
3. build
該義務包含了assemble和check
4. clean
該義務會清空項目標所有的輸出，刪除所有在assemble義務中打的包
assemble, check 和 build 義務實際上并不做任何工作，它們其實只是為插件供給了一個鉤子，真正的工作都是由插件來完成的。
如許的話，開辟人員就不須要關懷我到底運行的是一個java項目照樣一個Android項目，也不消關懷我到底應用了哪些gradle插件，因為我都可聲調用這些商定的義務來完成構建。
比如應用findbugs插件會創(chuàng)建一個新的義務，并且使得check義務依附于這個新建的義務，如許每次履行check義務的時刻，都邑履行這個新建的義務。
在敕令行履行

gradle tasks

</pre>會列出所有重要的義務如不雅想看到全部的義務和它們的依附，可以運行：<pre name="code" class="java">gradle tasks --all

留意：Gradle會主動檢查一個義務的輸入和輸出。比如持續(xù)兩次運行build義務的，Gradle會申報所有的義務都已經(jīng)是最新剛運行過的了，不須要再次運行。如許的話，義務之間就算是有互相依附，也不會導致反復的履行。

Java項目常用的義務

Java plugin 重要創(chuàng)建了兩個義務：
1. jar
assemble義務會依附jar義務，看名字就知道這是負糶ヲjar包的義務。jar義務本身又會依附很多其他的義務，比如classes義務，classes義務會編譯java代碼
2. test
check義務會依附test義務，這個義務會運行所有的測試。測試代碼應用testClasses義務編譯，然則我們根本不消手動運行testClasses義務因為test義務已經(jīng)添加了對它的依附。
平日情況下，我們只要運行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(持續(xù)集成)辦事上.
膳綾擎兩個義務都邑履行 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 (還沒有實現(xiàn))
deviceCheck依附于那些實現(xiàn)了test擴大的插件所供給的義務
最后，Android gradle插件還供給了install和uninstall義務，用來安裝和卸載apk