還在用build.gradle嗎？試試build.gradle.kts吧

前言

雖然你們都寫了不少年的安卓了，我以前一直都有對於build.gradle有點疑惑和不解(這部分其實已經沒有了)。就好比爲啥android叫android？還有dependencies是啥？apply form和apply plugin有什麼區別。

仍是先說下Groovy吧，仍是老生常談我並不喜歡我Groovy，可是有時候我以爲Groovy也仍是很是不錯的。

 Groovy是Java虛擬機的敏捷和動態語言，以Java語言的優點爲基礎，添加了從Python、Ruby和Smalltalk等語言中借鑑的特性。提供流行的編程語言特性，學習成本幾乎爲零。提供靜態類型檢查的能力，並靜態地編譯成java字節碼，以得到健壯性和性能，與全部現有的Java類和庫無縫集成，能夠在任何可使用java的地方使用它。經過其強大的處理原語、OO能力和Ant DSL使編寫shell和構建腳本變得容易。在開發Web，GUI，數據庫或控制檯程序時經過減小框架性的代碼大大提升了開發者的效率。支持DSL（Domain Specific Languages領域定義語言）和其它簡潔的語法，讓代碼變得易於閱讀和維護。而且支持單元測試，能夠簡化測試。

build.gradle和咱們的編譯息息相關，並且編譯相關的對於一個安卓開發其實仍是很是重要，並且也是息息相關的。Groovy的動態化也是有取捨的，下面我略列下我在開發過程當中碰到的問題吧。

1. 由於是一門動態語言並且也沒有強類型判斷，因此並不會出現編譯報錯，只會運行到對應代碼的時候纔出現問題。
2. 沒有任何語法提示，不少時候除了系統生成那部分代碼，咱們的學習成本和調試成本其實很是高。
3. 只有你足夠強足夠牛逼的狀況下，你能夠經過remote的方式調試build.gradle，以後跟蹤AGP的源代碼，發現有那些能夠更改的點。

在寫Gradle腳本的時候，最痛苦的莫過於沒有任何提示，惟一的調試手段就是使用print方法打印調試日誌。若是咱們能使用Kotlin編寫Gradle腳本的時候，你會發現一切都變得有趣起來，嘴角開始微微上揚。

Gradle Kotlin DSL 1.0 Gradle官方其實在18年末就已經正式發佈了kts的第一個版本了。那麼話很少，爲何咱們不試試呢。

正文開始

要安利你們學新東西那麼就最好先給你們一點甜頭，我有糖尿病我先來滋醒你們。

1. 代碼提示，kts內全部都是基於kotlin代碼規範的，因此強類型語言的好處就是編譯沒經過的狀況下，你根本沒法運行。
2. 源代碼查看，原來Groovy的block其實在kts都是由拓展函數實現的，因此咱們能直接看到傳入的類是什麼，以及這個類有哪些參數以及方法。舉個例子Android的block塊內的參數我就都能看懂了。
3. 混編以及熱重載，kts能和gradle能同時編譯，這樣就可讓新的東西往新的架構上遷移，而舊的那部分就能夠不動了，這樣豈不是美滋滋。

咱們先看一段代碼吧

咱們先來對比下兩個基本內容相同的配置文件吧。

第一個是我截取的kts相關的，第二個則是我之前的一個項目採用的仍是build.gradle。從第一眼的影像中，咱們能夠簡單的比對出kts相關的代碼提示上真的就會好不少。

舉個例子各位大佬之前知道com.android.library中的android所表明的Extension究竟是什麼嗎？那麼和com.android.application下的有什麼不一樣嗎？我想知道他們的源代碼在哪裏怎麼辦？

靈魂三問以後我想問下各位有沒有啥本身的見解哦，起碼我在以前就算使用remote調試插件的時候，我也是靠猜想的方式去定位android所表明的Extension的。因此我在這邊想要的出來的結論就是，若是你對安卓的編譯感興趣的狀況下，能夠先試試從kts開始反向推倒下每一個字段所表明的含義是什麼？

從kts中，我發現com.android.application下的android的Extension是BaseAppModuleExtension,咱們全部定義的子屬性其實都是在這個實體類上的拓展而已，而com.android.library中的則是另一個實現類LibraryExtension,相對而言他的字段屬性就會更少一點，有興趣的大佬能夠自行跟蹤翻查源代碼。

雖然我在使用kts以前就知道了，由於自定義plugin的時候也會有對這部分的操做和使用。能夠參考下逮蝦戶X，哈哈哈。

這部份內容其實在你編寫自定義Plugin的時候仍是有很大機率會使用到的，好比你的插件能夠根據applicationId進行不一樣的代碼生成變化。

這裏我小展開下，你們不知道有沒有想過implementation內的exclude和禁止依賴傳遞的transitive究竟是什麼？

這裏我就給你們買個關子，有興趣的大佬能夠轉化下kts，本身跟蹤路徑，看看其中到底都是些什麼東西啊。

可是kts必定就比gradle好嗎？我我的見解並非啊，在最新的as中，其實對於gradle的源碼跟蹤其實就已經很是不錯了。還有就是相比較而言，由於groovy是一門動態化語言，因此其中的類型判斷也更爲簡單，並且groovy中的MethodMissing這個機制，能夠幫助咱們動態調用不少隱藏的api。

可是偏偏也就是由於這些對應的機制，有時候也會讓開發無從入手，由於也不是別的啥，就是菜看不懂呀！！而kts則有一個更有優點的地方就是代碼提示了！！！

還有一點就是kts，對於ext的支持簡直堪稱地獄，若是你有定義在全局的相似dep配置相關的，這部分改動真的可能要了你的老命。

這部分是真的徹底比不上groovy,若是有除了用buildSrc這種方式解決了的大佬，能夠告訴我下，讓我學習一下啊！！！

那麼還有必要學習嗎？

我最近的感受就是開發仍是能夠多嘗試一些新鮮的東西的，特別是這種東西若是不會破壞當前既有結構，並且能完美並存的東西，其實均可以去嘗試下。

畢竟如今這個狀況吧，你比別人多會一點相對來講仍是有些好處的。並且我我的見解就是稍微多掌握點這個能幫助各位老哥更好的瞭解和學習編譯流程相關的內容。

另外事先聲明，今天這篇文章吧，我以爲也就是一篇水文，就是給你們安利下我以爲有意思的東西，並無實際太多的乾貨內容。