Java開發人員請注意！IntelliJ IDEA 2020.1平臺路線圖您知道嗎

IntelliJ IDEA 2019.3提供了重大的性能和可用性改進，包括更快的啓動，主題和鍵盤映射插件的安裝更容易，加強的VCS工做流以及增長了對微服務框架，MongoDB等的支持。可是，這遠遠不夠！咱們想介紹一下咱們當前在改進IntelliJ IDEA和基於IntelliJ平臺的其餘IDE方面所作的一些工做。這些努力的結果將在明年發佈，其中一些將在2020.1春季發佈。它們圍繞兩個主要主題：性能和對現代開發工做流的支持。

性能

索引表現

與咱們的IDE的性能有關的兩個主要痛點是啓動性能（索引耗時較長的工具被認爲是重量級的）。在今年，咱們作了不少工做來加快啓動速度，明年，咱們將注意力轉向索引性能。

咱們針對此問題採起了多管齊下的方法。首先，咱們使使用預建的索引塊成爲可能，這樣星球上的每一個IntelliJ實例都沒必要執行相同的索引java.lang.String類的工做。咱們計劃在這一年中逐步提供支持，從JDK開始，而後涵蓋Maven Central的庫以及其餘IDE中的解釋器和包。咱們還在研究支持團隊或企業內項目源代碼的索引塊共享的方法，可是目前咱們尚未任何具體計劃。

其次，咱們計劃經過在編制索引期間提供更多的IDE操做來減小編制索引的破壞性。

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

固然，咱們計劃投資進行良好的舊性能優化，以確保索引系統不會執行任何沒必要要的工做而且不會產生可避免的開銷。

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

用戶凍結的另外一個主要問題是UI凍結。今年，咱們構建了用於報告此類凍結的基礎結構，並進行了體系結構更改以修復許多凍結問題（例如，文件系統事件的異步偵聽器）。在接下來的一年中，咱們計劃邁出更大的一步，將須要寫鎖定的操做移出UI線程。

早在IntelliJ IDEA的早期，就作出了一項架構決定，該決定要求大多數操做修改IDE的內部數據結構才能在UI線程上運行。這意味着基本操做（將字符插入文檔中）和大規模操做（從新命名具備數千種用法的方法）。這種架構的好處是簡單的編程模型，可是明顯的缺點是UI響應能力在許多狀況下都會受到影響。

多年以來，咱們一直在尋找方法來解決此體系結構的侷限性，主要是將大型操做拆分爲在後臺運行並應用於UI線程的部分。一個更基本的解決方案是徹底擺脫UI線程的要求，可是直到最近，咱們還不知道如何在不對本身的代碼和第三方插件進行重大重寫的狀況下作到這一點。如今，咱們有了一個容許逐步遷移的體系結構解決方案，而且咱們正在開始實施它。

明年，咱們將重構IntelliJ平臺的基本UI組件和API，以採用新的線程模型。一旦新模型穩定而且能夠看到改進，咱們將在全部IDE中切換到新模型，從而使UI平滑且沒有滯後。

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

對於此功能，您已經在IntelliJ IDEA 2019.3中看到了先睹爲快的預覽，該預覽使您無需從新啓動便可安裝主題和鍵盤映射插件。在2020.1中，咱們計劃將此支持擴展到全部類型的插件。咱們將爲大部分捆綁的插件提供加載和卸載功能，而無需重啓，而且會爲第三方插件開發人員提供支持說明。在此階段，最重要的用戶利益將是無縫插件升級，而無需從新啓動IDE。

這項工做的最終目標（對於2020.1以後的版本）是擁有一個IDE，該IDE能夠根據您在其中打開的每一個項目的大小自行調整大小。僅針對使用Spring的項目加載Spring插件，僅針對Angular項目加載Angular插件，依此類推。若是您不使用某項技術，那麼您將看不到與此相關的任何UI元素，也不會看到支持該技術的插件對性能或內存使用量產生任何影響。

工做流程支持

協同編輯

協做編輯是問題跟蹤器中投票最高的請求，咱們很高興地宣佈咱們正在對此進行努力。在咱們目前採用的方法中，將有一個主IDE在運行源代碼的計算機上運行，其餘用戶將可以將其IDE做爲「瘦客戶機」鏈接到主IDE，而無需直接源代碼訪問。每一個鏈接的用戶都將具備本身的狀態（打開文件集，插入號位置，完成變體列表等），而且能夠根據須要選擇「跟隨」另外一個用戶。

「客戶機」用戶將有權訪問核心IDE功能，例如導航，完成和調試，但不能訪問完整的功能集。（例如，在初始版本中，瘦客戶端可能沒法執行版本控制操做。）請注意，目前尚不肯定爲瘦客戶端設置的完整功能，所以咱們將沒法回答有關什麼時候或是否支持特定功能。

協做編輯支持基於Rider協議，所以極可能首先在Rider中發佈，而後擴展到其餘IDE。不管如何，請不要期望在IntelliJ IDEA 2020.1中發佈有關此方向的任何工做–這是一項長期的工做。

還請注意，咱們當前的協做編輯方法基於咱們本身的協議，而且不支持與非JetBrains IDE的互操做性。

咱們正在考慮將「瘦客戶機」方法擴展到協做編輯以外的其餘方案的可能性，例如在雲中運行IDE後端，可是咱們還不許備宣佈該領域的具體計劃。

雲執行支持

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

如今，咱們介紹目標環境的通常概念，該概念提供了一種向其複製文件或向其複製文件並在其中啓動進程的方法。在IntelliJ IDEA 2020.1中，受支持的環境將包括您的本地計算機，Docker容器或經過ssh鏈接的計算機。目標環境的選擇最初可用於Java和Go運行配置。

在後續發行版中，咱們計劃統一圍繞新架構的現有Docker和遠程解釋器支持。除此以外，咱們還將提供更深刻的雲集成，所以您能夠說該過程須要在雲中的新VM上運行，而無需指定要鏈接的特定計算機的詳細信息。

從新設計項目模型

項目模型是IDE表示項目結構的方式–哪些文件屬於該項目，它們如何相互依賴，使用哪些庫，等等。多年來，IntelliJ IDEA的項目模型爲咱們提供了很好的服務，可是它具備必定的侷限性。首先，它不支持任意混合不一樣類型的項目。例如，AppCode能夠打開Xcode項目，Rider能夠打開Visual Studio解決方案，可是沒法在同一IDE框架中打開Gradle項目和Xcode項目。其次，項目模型在目錄級別上工做，而不在文件級別上工做，而且它不能表示同一目錄中具備不一樣依賴項的不一樣文件。這使得很難將諸如Bazel之類的構建系統集成到IDE中，並在其餘場景中提出了挑戰。

從新設計的項目模型（咱們內部稱爲「工做區模型」）將消除這些限制。它還帶來了其餘好處，例如在項目打開期間提升性能，與Maven和Gradle進行更順暢的同步以及更好的編程模型。咱們將從將內部實現更改成工做區模型開始，一旦這種狀況穩定下來，咱們將繼續添加用戶可見的功能，例如在同一IDE框架中組合任意類型的項目。

摘要

這篇文章中描述的工做只是咱們團隊一直在努力的一小部分，咱們計劃在假期後發佈有關計劃的更多信息。固然，全部這些均可能會發生變化，而且上述某些工做極可能不會發布，可是咱們會爲您提供其餘很棒的東西。

若是您對IntelliJ IDEA2020.1有任何期待或想法，歡迎在評論區留言~