剛剛去看了下 idea 官網，目前 IntelliJ IDEA 2020。1 EAP 版本已經發布，正式版本估計等等就快了，估計 3 月份左右吧；

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

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

改進結果將會在明年釋出，其中一些會發布在春季的 2020。1 版本中。

最後

，給大家分享一點福利，是我自己整理的一套Java文件資料，本文內容也包含其中，需要獲取的請點選下方文件 即可獲取！ 非常感謝大家的支援~

效能

索引效能

與 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 進行更順暢的同步以及更好的程式設計模型。

這裡大家可以關注一下我的個人專欄《Java 進階集中營》，每天會給大家即時分享一個最新的java技術資訊，有優秀的java技術內容，也歡迎分享在我的專欄。