Spring Cloud 2020 年路線圖發佈

JetBrains 發文介紹了其 IntelliJ 平臺 2020 年的路線圖。

文章主要介紹了當前 JetBrains 在改進 IntelliJ IDEA 和基於 IntelliJ 平臺的 IDE 方面所作的一些工做，主要包括性能和對現代開發工做流的支持兩個方面。

改進結果將會在明年發佈，其中一些會發布在春季的 2020.1 版本中。

性能

索引性能

與 IDE 性能有關的兩個主要痛點是啓動性能，索引耗時較長的工具被認爲是重量級的。JetBrains 表示，明年關注點將轉向索引性能方面。

針對此問題官方採起了多管齊下的方法。首先，支持使用預建的索引塊，這樣每一個用戶 IntelliJ 實例都沒必要執行索引java.lang.String類的工做。

計劃明年逐步提供支持，從 JDK 開始，而後涵蓋 Maven Central 的庫以及其它 IDE 中的解釋器和包。同時還在研究支持團隊或企業內項目源代碼的索引塊共享的方法，雖然這一塊目前尚未任何具體計劃。

其次，計劃經過在索引時提供更多的 IDE 操做來減小索引的破壞性。

第三，將檢測並通知用戶有關索引異常的信息，包括索引花費時間太長的文件、索引從新創建頻率過高的文件以及異常致使的索引重建，目的是提供解決這些問題並提升 IDE 在項目上的性能的清晰步驟。

同時也計劃支持進行舊性能優化，以確保索引系統不會執行任何沒必要要的工做而且不會產生可避免的開銷。

讀/寫鎖線程模型從新設計

UI 卡死（freeze，凍結）是一個很大的問題。今年雖然已經構建了用於報告此類卡死問題的基礎，並進行了架構更改以修復許多相關問題，好比文件系統事件的異步偵聽器，可是接下來的一年中，計劃邁出更大的一步：將須要寫鎖定的操做移出 UI 線程。

早在 IntelliJ IDEA 早期就作出了一項架構決定，該決定要求大多數操做須要修改 IDE 的內部數據結構才能在 UI 線程上運行，也就是包括基本操做（將字符插入文檔中）和大規模操做（從新命名具備數千種用法的方法）。

這種架構的好處是簡單的編程模型，可是明顯的缺點是 UI 響應能力在許多狀況下都會受到影響。

多年以來，官方一直在尋找方法來解決此架構的侷限性，主要是將大型操做拆分爲在後臺運行並應用於 UI 線程的部分。一個更基本的解決方案是徹底擺脫 UI 線程的要求，可是直到最近，還不知道如何在不對本身的代碼和第三方插件進行重大重寫的狀況下作到這一點。

不過如今，JetBrains 已經有了一個容許逐步遷移的架構解決方案，而且正在開始實施。明年將重構 IntelliJ 平臺的基本 UI 組件和 API，以採用新的線程模型。一旦新模型穩定而且能夠看到改進，將在全部 IDE 中切換到新模型，從而使 UI 平滑且沒有滯後。

無需重啓便可加載和卸載插件

該特性已經在 IntelliJ IDEA 2019.3 中預覽，它使開發者不用從新啓動就能夠安裝主題和鍵盤映射插件，無縫升級。2020.1 版本中會將此支持擴展到全部類型的插件。

計劃將爲大部分捆綁的插件提供支持，而且會爲第三方插件開發人員提供支持說明。

這項工做更有意義的地方在於，它的最終目標是 IDE 能夠根據開發者打開的每一個項目的大小自行調整大小，好比僅針對使用 Spring 的項目加載 Spring 插件，僅針對 Angular 項目加載 Angular 插件。

這樣若是不使用某項技術，那麼就不會看到與此相關的任何 UI 元素，也不會看到支持該技術的插件對性能或內存使用量產生任何影響。

工做流支持

協同編輯

協同編輯是問題跟蹤器中投票最高的請求，目前 JetBrains 也在跟進這一功能。在目前採用的方法中，將有一個主 IDE 在運行源代碼的計算機上運行，其餘用戶可以將其 IDE 做爲「瘦客戶機」鏈接到主 IDE，而無需直接進行源代碼訪問。

每一個鏈接的用戶都將具備本身的狀態，包括打開文件集與插入號位置等，而且能夠根據須要選擇「跟隨」另外一個用戶。

瘦客戶機用戶將有權訪問核心 IDE 功能，例如導航、補全和調試，但不能訪問完整的功能集，例如，在初始版本中，瘦客戶端可能沒法執行版本控制操做。

協同編輯支持基於 Rider 協議，所以極可能首先在 Rider 中發佈，而後擴展到其它 IDE。不過這是一項長期工做，IntelliJ IDEA 2020.1 版本中暫時仍是看不是相關成果的。

支持雲執行

至關長一段時間以來，許多 JetBrains 產品都支持在容器內運行和調試代碼，可是，在不一樣產品中這些功能的實現之間並無太多相關性，甚至基本功能（如 Docker 支持）的 UI 也不一致。

如今 JetBrains 引入了目標環境的概念，該概念提供了一種可雙向複製文件並在目標環境中啓動進程的方法。在 IntelliJ IDEA 2020.1 中，受支持的環境將包括本地計算機、Docker 容器和經過 ssh 鏈接的計算機。

在後續發行版中，計劃統一支持圍繞新架構的現有 Docker 和遠程解釋器。除此以外，還將提供更深刻的雲集成。

從新設計項目模型

項目模型是 IDE 表示項目結構的方式：哪些文件屬於該項目、它們如何相互依賴、使用哪些庫……項目模型有必定的侷限性，首先，它不支持任意混合不一樣類型的項目。

例如，AppCode 能夠打開 Xcode 項目，Rider 能夠打開 Visual Studio 解決方案，可是沒法在同一 IDE 框架中打開 Gradle 項目和 Xcode 項目。

其次，項目模型在目錄級別上工做，而不在文件級別上，而且它不能表示同一目錄中具備不一樣依賴項的不一樣文件，這使得很難將諸如 Bazel 之類的構建系統集成到 IDE 中，同時也給其它場景帶來了問題。

從新設計的項目模型（內部稱爲「工做區模型」）將消除這些限制。同時它還帶來了其它好處，例如在項目打開期間提升性能、與 Maven 和 Gradle 進行更順暢的同步以及更好的編程模型。

JetBrains 還表示接下來將發佈更多計劃信息，詳情查看： https://blog.jetbrains.com/idea/2019/12/intellij-platform-roadmap-for-2020