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有任何期待或想法，歡迎在評論區留言~
閱讀更多 慧都科技 的文章
