作者：ghui
連結：https://www.zhihu.com/question/30432152/answer/48239946
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
Gradle是一個基于Apache Ant和Apache Maven概念的項目自動化建構工具。它使用一種基于Groovy的特定領域語言來聲明項目設定，而不是傳統的XML。目前其支援的語言限于Java、Groovy和Scala，計劃未來将支援更多的語言。
上面是維基上對Gradle的解釋,相信一個沒有接觸過建構的人是不大能看明白的,當初我也是.下面是我對Gradle通俗的了解:
軟體開發講究代碼複用,通過複用可以使工程更易維護,代碼量更少..... 開發者可以通過繼承,組合,函數子產品等實作不同程度上的代碼複用.但不知你有沒有想過,軟體開發也是一種工程作業,絕不僅僅是寫代碼,還涉及到工程的各種管理(依賴,打包,部署,釋出,各種管道的差異管理.....),你每天都在build,clean,簽名,打包,釋出,有沒有想過這種過程,也可以像代碼一樣被描述出來, 也可以被複用.
舉個例子
我是做Android開發的,你可知道國内有n個Android市場,n個手機品牌,n個手機尺寸......,一般公司都會針對不同的市場單獨發包用來統計不同管道的下載下傳量等情況,可能需要針對不同(品牌,尺寸等各種硬體資訊)的手機做一些特殊的處理,這個時候你可以針對不同的情況單獨建一個工程,或者更好一點你可以通過一些變量來控制,像這樣:
if(isMoto){do something}
else if(isHuawei){do something}
...
差異管理
但這兩種解決方法都有自己的缺點,特别是前一種有極大的代碼重複.後一種稍微好一點,但這種方式的差異是運作時的,不是靜态的,對于moto手機上的處理邏輯對華為手機來說一點作用也沒有,但這一段針對moto手機的處理邏輯也被裝到了華為手機上了,通過gradle的productFlavor與buildtype可以實作靜态級的差異控制可以參考如何通過Gradle實作一套代碼開發不同特性的APK · ByGhui
說到前面的多管道問題,不同的管道一般會對應不同的管道号,你當然可以通過修改一次打一個包這種純手工的方式來生成你的多管道包,但據聽說國内某團購網站的Android App有100多個管道.這裡出現了什麼?重複,反複的去打包而且這些包之前的差異很小(隻是管道号不同),和寫代碼一樣我們應該複用,通過Gradle可以實作一個指令打出所有的管道包,一個指令打出指定的管道包.再複雜一點,你可能需要不同的管道對應不同的簽名檔案,不同的icon,不同的伺服器位址...這些都可以通過Gradle來友善的實作.
依賴管理:
做軟體開發你可能需要依賴各種不同的jar,library.你當然可以通過将.jar/library工程下載下傳到本地再copy到你的工程中,但不知你是否聽說過國外有個叫中央倉庫的東西,在這個倉庫裡你可以找到所有你能想到以及你從來沒聽說過的jar,aar...The Central Repository Search Engine 這裡可以找到所有你需要的依賴,而你需要的隻是指定一個坐标,如下:
<img src="https://pic4.zhimg.com/8883d4b758b288a74eb4c104db854c5f_b.jpg" data-rawwidth="330" data-rawheight="24" class="content_image" width="330">剩下的依賴的尋找,下載下傳,添加到classpath等你都不需要去關心,通過這種方式來維護依賴的好處有以下幾點:
剩下的依賴的尋找,下載下傳,添加到classpath等你都不需要去關心,通過這種方式來維護依賴的好處有以下幾點:
- 依賴不會進入到你的版本控制倉庫中(預設會緩存到~/.gradle/下)
- 友善解除安裝裝載依賴(隻是一條坐标依賴,不需要删除即可)
- 友善的版本管理,如上圖中的2.3.3既是picasso的版本号,若改為+就表示從中央倉庫中下載下傳最新的版本
- 不同工程的相同依賴不會存在重複副本(隻在~/.gradle下存在一份)
項目部署
這方面我沒怎麼接觸過,但據我所知通過一些插件,可以實作自動将你的輸出(.jar,.apk,.war...)上傳到指定倉庫,自動部署...
羅哩羅嗦說了這麼多,不知大家有沒有了解
總結一下:
- Gradle是一種建構工具,它可以幫你管理項目中的差異,依賴,編譯,打包,部署......,你可以定義滿足自己需要的建構邏輯,寫入到build.gradle中供日後複用.
- Gradle不是一種程式設計語言,它不能幫你實作軟體中的任何實際功能
通俗的解釋肯定是不嚴謹的解釋,不妥之處歡迎讨論.