IntelliJ IDEA 功能強、范圍廣，因此對資源有一定需求。根據您正在處理的項目，IDE 可能會出現滯后，這自然會令人沮喪。

打開項目時也許是開發者需要等待的最常見場景。IntelliJ IDEA 需要加載和同步項目、執行索引編制以及完成許多其他小任務才能啟用所有實用功能。

在這篇博文中，我們將介紹在新版本 IntelliJ IDEA 中為提高性能而采取的措施，這些措施縮短了代碼可交互時間并使 IDE 從啟動開始就具有更高的響應速度。

我們的使命：改進代碼可交互時間

對于 2023.2 之前的 IntelliJ IDEA 版本，IDE 必須等待項目的 Maven 或 Gradle 項目模型完全同步后才能開始編制索引。然后，在等待索引編制完成時，IDE 的所有智能功能都被禁用，包括代碼高亮顯示和導航。只有在索引編制完成后才能使用它們。

下面是相關組件的示意圖：

項目越大，同步項目和編制項目索引所需的時間越長。雖然這在意料之中，因為大型項目對于 IDE 來說更加復雜，但等待幾分鐘才能開始工作仍然有些糟糕。然而，由于加載項目時要執行的步驟太多，即使是較小的步驟也會花費大量時間，讓人感覺 IntelliJ IDEA 運行緩慢。沒人喜歡等待，尤其是您想要投入工作的時候。因此，我們將改善這種狀況作為一項高度優先的任務。為了衡量我們的進度，我們決定跟蹤我們所謂的“代碼可交互時間”– 從應用程序啟動或項目打開到可以在其中正常處理代碼的時間。我們的目標是盡可能縮短代碼可交互時間。

改進項目打開流和體驗

在 IntelliJ IDEA 中改進啟動和項目打開的問題實際上非常復雜，因為它取決于多個組件及其互連。不過，這種復雜性也有好處，因為它可以讓我們從多個角度解決問題。在等待技術改進方面的長期工作取得成果的同時，我們還調整了 IntelliJ IDEA 的索引編制方式，用戶已經可以體驗到在代碼可交互時間方面的顯著改進。

技術改進 >>

縮短代碼可交互時間的一個明顯方式是執行技術更新以提高 IDE 的性能 – 優化代碼和架構、使用更好的硬件、并行化等。IntelliJ IDEA 已有 20 多年的歷史，早期的一些架構和算法決策仍然存在于產品中。這方面的工作正在開展。我們投入了大量精力來適當監測、調查和優化性能瓶頸，并且已經取得了一些顯著成果。我們將應用程序的啟動應用程序性能指數 (Apdex) 提升到

頂級類別

，得分為 0.94，將多線程索引編制的速度提高了 25%，并消除了并行索引編制過程中不必要的鎖，減少了其他線程等待此類鎖的時間。但這將是一個漫長的過程，因為重構可能會對 IDE 中的其他子系統產生影響，需要經過較長時間的仔細評估。

在技術層面開展工作的同時，我們還決定另辟蹊徑來解決 IDE 的感知性能問題。

分階段同步索引編制 >>

IDE 不一定需要技術改進，用戶就能體驗到它的速度提升。

只要能夠更快開始工作，他們就會感受到性能改進

。通過研究，我們了解到許多用戶認為，當他們能夠看到項目結構和正確的代碼高亮顯示時，IDE 就可以開始用于工作了。所以，這就是我們努力的重點。IDE 必須執行幾個關鍵步驟才能使高亮顯示和導航正常運作，但我們想知道這些步驟是否真的需要按順序依次執行。2023.3 版本中一些很有前景的實驗表明，

將同步和索引編制過程分為幾個階段并以異步方式運行，可以讓用戶更快地開始與代碼交互。

因此，作為第一步，我們讓 IntelliJ IDEA 在實際從 Gradle 或 Maven 等底層構建工具獲取項目模型之前開始對項目目錄中的文件編制索引。這樣做的缺點是，不必要的文件也被編入索引，并且與構建工具同步后，需要重新編制索引。不過，根據我們的測試套件，整體代碼可交互時間（包括同步和完整索引編制）顯著縮短，在大型項目中的速度提高了 1.5 倍。但是，如果不加載項目模型，就無法正確建立項目各部分之間的關系、顯示正確的項目樹、高亮顯示或提供導航。為了解決這個問題，我們實現了所謂的分階段同步。我們讓 IDE 分階段獲取模型，而不是一次性從構建工具請求完整項目模型。目前有兩個階段。

階段 1：跳過依賴項解析

在第一階段，即項目加載過程的早期階段，IntelliJ IDEA 不會解析依賴項或連接到互聯網。它只是提供一個足夠精確的模型，讓 IDE 能夠顯示項目樹、對項目中最必要的部分編制索引，并提供一些必要的智能功能。顯然，這個階段之后一些依賴項可能仍然缺失，從而導致解析問題，甚至出現代碼即使正確也被標記為紅色的情況。IDE 實際上可以感知這些誤報錯誤，并通過抑制因缺少依賴項而導致的錯誤在個別語言支持級別解決這些問題。它還能正確處理帶有相應消息的導航嘗試。自 2024.2 版本起，此錯誤抑制適用于 Java，在 2024.3 版本中，支持已擴展到 Kotlin。Maven 中第一階段尤其快速，因為它的靜態 pom.xml 配置文件可以由 IDE 解析而無需啟動 Maven，同時還能提供足夠的知識來構建非常精確的模型。對于本質上動態且腳本非常靈活的 Gradle，IntelliJ IDEA 目前無法獨立解析腳本，這意味著它必須運行 Gradle 守護進程。通過僅向 Gradle 請求 sourceSets、必需語言級別和其他基本信息，我們加快了這一過程。不過，通過聲明式 Gradle 計劃，我們將來也許能夠帶來大幅改善。

階段 2：下載并解析依賴項

在第二階段，IntelliJ IDEA 下載所有插件和依賴項，正確解析所有配置，并為 IDE 提供完全準確的模型。然后，索引根據完整模型更新。通過這種兩階段方式，在依賴項下載和解析的同時，您可以更快獲得幾乎功能齊全的 IntelliJ IDEA 版本。

作為一項額外改進，我們使許多功能在索引尚未就緒時也能運行，進一步縮短了代碼可交互時間。最重要的是個別文件中的代碼高亮顯示、部分代碼解析和運行配置。當然，準備好底層索引會讓這些操作更快，但即使只有部分索引，它們也能可靠地工作。

結果

總體來看，整個流程現在是這樣的：

我們怎么知道是否值得？

根據項目，我們測試套件中的代碼可交互時間（或者更準確地說，以上架構中完全高亮顯示之前的時間）在第一次打開項目時速度最多能快上幾倍。

調查顯示，大約 30% 的用戶認為 IntelliJ IDEA 2024.2 讓他們能夠更快開始編碼。

后續計劃

雖然并非所有 IntelliJ IDEA 功能都能在編制項目索引時使用，但兩階段同步方式無疑加快了整體啟動性能，讓您更快地開始與代碼交互。此外，我們還使許多操作與沒有索引或只有部分索引的情況兼容。在 2024.2 版本中，大約 10% 的用戶確實在整個同步和索引編制過程完成之前編寫代碼。但我們的工作還沒有結束。

我們現在的目標是改進分階段同步，尤其是與 Gradle 的同步，進一步縮短代碼可交互時間。我們還在更新依賴項尚未解析時處理項目的用戶體驗。

同時，我們希望您能享受我們在縮短代碼可交互時間方面取得的成果。

本博文英文原作者：Kerry Beetge

關于 IntelliJ IDEA

JetBrains 的旗艦 IDE IntelliJ IDEA 專為高效的 JVM 開發而設計。憑借對語言和技術的深入了解以及符合人體工程學的用戶界面，IntelliJ IDEA 使開發成為愉悅的體驗！

免費的開源 IntelliJ IDEA 社區版和 IntelliJIDEA Edu 也可以用于學習和教學編程。

咨詢JetBrains授權合作伙伴-龍智，進一步了解 IntelliJ IDEA：

審核編輯 黃宇