我們已顯著改善了IDE對Gradle Kotlin DSL指令碼(* .gradle.kts檔案)的支援，並希望在此部落格中與你分享詳細的資訊。這些更改將在Kotlin 1.3.70版本中體現，但你可以通過加入Kotlin 1.3.70 EAP(早期訪問計劃)來嚐鮮。
你可能遇到過以下情況。你有一個使用Gradle Kotlin DSL指令碼構建的專案，並開啟build.gradle.kts檔案去修改專案的構建邏輯，但是突然計算機的CPU彷彿抽風了，你的指令碼看起來像純文字(沒有高亮)，並且編寫指令碼時也沒有智慧提示。同時，首次開啟指令碼需要最多10秒程式碼才會高亮。
而現在若你開啟的指令碼來自匯入過的Gradle專案，那麼IDE會立即高亮該指令碼！
除此以外，我們設法加快了指令碼的高亮和解析過程，這在大型專案中體驗尤為明顯。現在，跨多個檔案使用各種IDE功能(例如buildSrc中的“找出所有引用”)應該可以更快地工作了。
確保你更新到了以下版本，以享受更多新的改進：
- Gradle version 6.0+
- IntelliJ IDEA version 2019.2+
- Kotlin plugin version 1.3.70+
如果使用預設專案嚮導建立新專案，則可以通過執行gradle wrapper --gradle-version=6.2來更新Gradle版本。從2020.1開始，IntelliJ IDEA將自動使用Gradle 6.0+版本建立專案。
請注意，如果你在舊版本Gradle或舊版本IntelliJ IDEA上使用最新的Kotlin外掛，則指令碼支援仍將以較慢的舊方式工作。
現在，我們想分享一些有關如何實現這一目標的技術細節。我們將討論此前IDE是如何工作以及發生了什麼變化。
指令碼配置
Gradle Kotlin DSL指令碼包含常規的Kotlin程式碼，這意味著所有Kotlin檔案都具有程式碼智慧提醒功能。例如，你可以導航到每一個使用過的函式呼叫宣告，並可以通過程式碼補全根據當前上下文中檢視可用的選項。但是，指令碼檔案與常規Kotlin檔案不同，指令碼檔案可以指定依賴項和應用的Gradle外掛，這會影響指令碼本身的解析。
例如，將應用程式外掛 應用於指令碼時，後續可以使用application進行配置：
顯然，你必須先應用相應的外掛才能使用application的功能。指令碼內部具有的這種依賴性使得IDE對指令碼檔案的支援不同於對常規Kotlin檔案的支援，而且更加複雜。
解析指令碼檔案所需的所有資訊都稱為指令碼配置。指令碼配置主要取決於指令碼的buildscript和plugins部分的內容。它包含諸如可在指令碼中使用的庫以及預設匯入之類的資訊。 IDE使用指令碼配置為指令碼檔案提供程式碼提示，例如高亮，補全，導航和重構。
有關指令碼配置的更多詳細技術資訊，請參閱指令碼支援的KEEP文件。
重新設計與Gradle守護程式的互動
對於Gradle指令碼，最新的指令碼配置由Gradle守護程式負責管理，該程式在後臺執行，並負責所有與Gradle相關的任務和活動。為了更新指令碼配置，IDE程式碼向Gradle守護程式傳送一個負責執行配置構建的請求，然後Gradle守護程式提供最新的配置。
在Kotlin 1.3.70以前的版本，由於Gradle和IntelliJ平臺都缺少更好的API，因此指令碼發生的變動都會請求並更新指令碼配置。這就是構建速度慢的原因。
從Kotlin 1.3.70開始，我們重新設計了Gradle守護程式請求指令碼配置的整個機制。現在指令碼配置會在第一次匯入Gradle專案時執行，然後儲存在IDE。當你修改buildscript或plugins部分時，將再次執行請求。我們計劃引入Load Script Configurations操作(稍後會詳細介紹)，從而避免在指令碼更改時自動執行請求。
得益於新的Gradle TAPI(可以在單個請求中獲取所有指令碼配置)(感謝Gradle團隊)，以及新的IntelliJ IDEA API(可以在專案匯入期間向Gradle請求其他資訊)，從而實現了這一改進(感謝Vlad Soroka)。
請注意，我們預計“專案匯入”不會產生額外的開銷。 Gradle在“專案配置”階段會編譯所有指令碼，因此Gradle中已經存在所有必要的資訊。只新增了檢索的新方案。
未來的計劃
更好的錯誤報告
新的Gradle API讓改進更進一步成為可能，並且可以提供更好的錯誤報告。你可能看過以下訊息：“This script caused build configuration to fail… Show Kotlin Gradle DSL Logs in Finder/Explorer”。你只能在Gradle守護程式輸出的獨立的日誌檔案中檢視錯誤。但現在，Gradle守護程式將直接返回有關錯誤的所有資訊，並且將像其他資訊一樣在build視窗中展示。
明確的“載入指令碼配置”操作
如上所述，為了獲得更好的效能，我們將不再自動執行更新指令碼配置的請求。在Kotlin 1.3.60中，新增新外掛後，如上示例中的application，開始你需要等待一段時間，直到新的指令碼配置載入成功。載入會在後臺自動進行，因此載入時你會收到通知以應用更改。你可能已經看到過這樣的訊息：“There’s a new script context available. Apply context”(“script context”現在稱為“Script Configuration”)。應用後，你可以立即使用application的功能，這得益於已載入的指令碼配置，其功能可以被順利解析。
我們計劃刪除在buildscript和plugin部分改動後對Gradle Daemon的請求：你需要在新增新外掛後顯式載入新的指令碼配置。在IntelliJ IDEA 2019.2中，你將使用標準的“Import Gradle Project”來執行相關操作。從IntelliJ IDEA 2020.1開始，我們將有一個體驗更加友好的“Load Gradle Changes”操作，其作用相同：它會載入Gradle專案結構的所有更改。
我們還計劃引入另一種操作，該操作可用於僅載入對指令碼配置的更改，而無需更新整個專案。我們希望它具有以下工作流程：
- 你新增了外掛 (例如
application). - IDE注意到相應指令碼的更改可能會影響指令碼配置，並建議載入(仍然由Gradle守護程式進行載入)。你會看到“Load Script Configurations”操作，但是在你手動執行之前，不會向Gradle守護程式的傳送任何請求。
- 僅在單擊此操作或完整的“ Load Gradle Changes”操作後，更改才被載入，同時你可以獲得新新增外掛的程式碼提示了，例如，你可以在指令碼中使用程式碼補全
application的函式。
我們尚未實施這些更新，但排期將至。這意味著還有時間向我們反饋。所描述的工作流程和新的“Load Script Configuration”操作是否足夠清晰？我們想知道你的想法！