以 Runtime Spy 優化 Eclipse 啟動效能（下）：成功的「欺騙」藝術

前言：延遲載入的哲學

Runtime Spy 是 Eclipse Core Tools 核心組件之一，專為診斷外掛啟動效能而設計。承接第一部分的基礎介紹，本文將透過 IBM WebSphere Studio Application Developer 的實戰案例，深入剖析如何運用 Runtime Spy 識別並解決啟動瓶頸。核心策略只有一條：**盡可能延遲代碼執行**。

啟動優化的雙重目標

1. 極致延遲外掛啟動：善用 Eclipse 擴展點機制，靜態宣告資訊讓平台延遲載入代碼，直到使用者真正觸發動作時才啟動外掛。
2. 最小化啟動時的工作量：若無法延遲啟動，則精簡 Plugin.startup() 中的類別引用、減少 CPU 佔用、採用背景低優先權執行緒初始化（需妥善處理同步）。

這種「化整為零」的策略雖不減少總 CPU 時間，卻能大幅改善使用者感知效能——啟動階段無明顯卡頓，耗時操作分散至後續互動中。

Runtime Spy 透視圖四大視圖

• Activated Plugins：顯示已啟動外掛、啟動順序、耗時。目標：縮減列表條目。
• Loaded Classes：檢視特定外掛已載入的類別。目標：減少類別載入數量。
• Plugin Datasheet：統計外掛資源、擴展點數量等資訊。
• Stack Trace：追蹤外掛/類別被載入的呼叫堆疊，點擊 更新。

快速識別新啟動外掛技巧：在 Activated Plugins 全選（Ctrl+A）→ 執行操作 → 點擊刷新按鈕 → 未被選取者即為新啟動外掛。

案例偵察：WebSphere Studio 的啟動熱點

僅開啟 Runtime Spy 透視圖啟動 Studio，僅載入 22 個外掛，耗時約 3 秒（實測約 13 秒含 JVM 啟動與除錯開銷）。但按下刷新後，org.eclipse.ui.startup 擴展點觸發額外 11 個外掛啟動（圖 3），其中 cheatsheet、internet 等 Studio 專屬外掛赫然在列。

org.eclipse.ui.startup 是具爭議的 API：工作台開啟時強制啟動貢獻外掛，繞過延遲載入機制。雖提供「Startup」偏好設定頁讓使用者停用特定外掛貢獻（圖 5），但開發者應審慎使用——假設 IStartup.earlyStartup() 可能未被呼叫。

深入堆疊追蹤：subuilder 外掛的啟動真相

開啟 J2EE 透視圖後，外掛數從 22 飆升至 73，啟動時間暴增 20 秒。許多資料庫相關外掛（com.ibm.etools.sqlmodel.*、com.ibm.etools.subuilder 等）在未開啟任何 DB 視圖/編輯器時即被啟動。subuilder 更佔據 1828ms 啟動時間，位居啟動序列倒數第二。

其堆疊追蹤（圖 8）揭示關鍵路徑：

PartPane (管理分頁視圖)
→ 嘗試建立 J2EEView 實例
→ 呼叫 helper
→ IConfigurationElement.createExecutableExtension()  ← 關鍵觸發點

createExecutableExtension 是 Eclipse 擴展點處理的核心：當平台需實例化擴展點定義的 class 屬性類別時，會透過目標外掛的 ClassLoader 載入該類別，進而觸發外掛啟動。

破解之道：代理模式延遲實例化

對比標準 org.eclipse.ui.actionSets 擴展點：其 action 的 class 屬性指向 IWorkbenchWindowActionDelegate 實作，但平台實際建立的是**代理委派類別**，直到使用者真正點選選單項時才實例化真正的 Action 類別，完美延遲外掛啟動。

將同樣代理策略套用至 com.ibm.etools.rsc.sp 擴展點（清單 2），J2EE 透視圖開啟時間縮減近 7 秒。NewSQLSPAction 實例化與外掛啟動開銷並未消失，而是轉化為「隨用隨付」模式，貼近使用者預期付出成本的操作時刻。

結語：成功的「欺騙」

文章副標「成功的騙局」道盡優化本質：滿足使用者對「快」的期待，將不可避免的開銷轉移至使用者心理可接受的時刻。最容易優化的代碼，永遠是**永不執行**的代碼。Eclipse 的外掛架構賦予我們實現此目標的工具，Runtime Spy 則是尋找優化切入點的偵探。