Gradle使用小結

Gradle是CI過程工具，而不是系統。持續集成過程當中的構建、自動化測試、打包、發佈均可以使用Gradle來完成。而持續進程過程爲咱們下降各方面成本，提升產品信心，提升產品質量有着很是重要的做用（不要問我爲啥）。而咱們不少研發人員很是討厭CI過程，這一點的問題緣由是研發人員沒有從CI過程當中獲取任何利益，並且還增長了維護成本。關於這一點等有機會的時候和你們討論一下《怎麼統一研發，質量，測試，管理之間的利益》（統一各方面的利益以後衆志成城，萬衆一心，咱們的產品會更上一層樓)。

在使用Gradle過程當中發如今Gradle中的不少特性，不少原理都很特別。這裏說明幾個使用實踐。（這裏不與makefile，maven，ant進行對比）

1.關於Gradle的執行的過程：
不少介紹Gradle的地方，都說Gradle腳本是一種配置腳本。他們說這句話的緣由是由於在Gradle中提供了不少插件，啓用插件後直接調用方法閉包進行配置就能夠徹底完成項目須要的功能。因此，Gradle不少時候都是以配置文件的形式存在的。

但，Gradle的腳本不簡單是配置文件。從Gradle執行的三個步驟能夠看出：
1>Initialization：Gradle 支持單項目或者多項目構建，在該階段，Gradle認哪些項目會參與構建，而後爲每個項目建立 Project 對象
2>Configuration：這個階段就是配置 Initialization 階段建立的 Project 對象，全部的配置腳本都會被執行
3>Execution：這個階段 Gradle 會確認哪些在 Configuration 階段建立和配置的 Task 會被執行，哪些 Task會被執行取決於gradle命令的參數以及當前的目錄，確認以後便會執行

你們能夠從Gradle執行過程得出，Gradle的使用過程不止配置腳本那麼簡單。具體能夠看：
1>在初始化階段，Gradle沒有指定默認的初始化腳本，必須使用Gradle的命令行參數進行指定。這個過程可使用Gradle的Hook來完成相應的回調註冊，以控制整個Gradle執行過程。

參見：https://docs.gradle.org/current/userguide/init_scripts.html
https://docs.gradle.org/current/dsl/org.gradle.api.invocation.Gradle.html#org.gradle.api.invocation.Gradle:addListener(java.lang.Object)

2>在配置階段，執行的是相關的配置。好比說Project中的依賴管理閉包塊。屬性設置等都會直接執行。可是這個階段不會執行task內部的action。因此，這個階段才叫作配置階段。

3>在執行階段，會執行task的相關操做。在相對複雜的項目中不少時候須要在執行階段對項目構建進行動態配置，在這個階段能夠對項目中各類屬性在進行配置。可是，動態配置過程必須在使用這些配置以前完成，要不也沒有任何用處。

因此，從上面能夠得出，Gradle的執行過程不像咱們以前接觸過的CI工具那樣要不是純配置，要不是純動態。這一點是Gradle很大的特色。這種方式爲咱們很好的融合了配置 與 動態構建過程，平衡了兩方的優缺點。

2.Gradle配置過程
在腳本執行的時候，Gradle會配置一些特定類型的對象，這些對象就被稱爲腳本的 delegate 對象，也是構建領域的領域對象，下文簡稱 DO。
DO 的意義就在於腳本可使用被代理的對象的方法——這一點很是重要，是腳本中可調用方法的重要來源。
參見：https://www.muzileecoding.com/gradlestudy/gradle-advaced-do.html

只要是被委託對象有的方法，都是能夠直接調用的。並且還有一個比較複雜的方法查找過程，一層層的查找方法。因此，在查找在某一部分可使用的方法是一個比較麻煩的過程。而在Gradle中的文檔又寫的很晦澀會致使學習成本提高，效率下降等問題。不過通常狀況下直接查找DSL相關描述便可。

3.Gradle腳本模塊化
模塊化過程分兩個大類：配置模塊化 和 過程模塊化。
配置模塊化是將Gradle的腳本分模塊的寫道不一樣的腳本下，來提升Gradle腳本的可讀性與可維護性。具體方法：

apply from: 'other.gradle'

使用apply來引入其餘的腳本，可是，在真正使用過程當中發現被引入的腳本的委託對象好像不像通常腳本那樣。不能直接使用Project一些特定的屬性或者task，只能在主腳本中經過不一樣的方式進行調用。

過程模塊化是在被引入腳本中實現過程，方法，類等等，可是須要在主腳本里進行調用。這種方法可使用Gradle直接調用groovy腳本中的實現來完成，可是，沒有找到方法來使Gradle腳本調用groovy腳本。因此，這裏的過程模塊化仍是使用配置模塊化來進行引入。不過使用特殊的方式進行方法，類的導出。具體以下：

// Define methods as usual
def commonMethod1(param){
return true
}
def commonMethod2(param){
return true
}

// Export methods by turning them into closures
ext{
commonMethod1 = this.&commonMethod1
otherNameForMethod2 = this.&commonMethod2
}

在被引入腳本中使用ext進行導出，在主腳本中就能夠正常使用了。

參見：http://stackoverflow.com/questions/18715137/extract-common-methods-from-gradle-build-script
https://docs.gradle.org/current/userguide/organizing_build_logic.html#sec:configuring_using_external_script

4.關於Groovy
在Gradle腳本中可使用任意合法的Groovy語句。從Groovy的文檔能夠了解到Groovy是一種能夠在運行期和編譯器進行元編程的強大語言。元編程又是DSL的強大支撐。因此，Gradle才實現了這麼強大的DSL，讓咱們更容易理解Gradle。
參見：http://www.groovy-lang.org/metaprogramming.html

總結了一些Gradle的實踐，可是，這裏最主要的核心內容仍是怎麼提升程序的可理解性，可維護性，可測試性的內容。提升這些更是爲了下降成本。