Angular、React、Vue 和 Svelte 等網路架構可簡化複雜網路應用程式的編寫和維護作業。
不過，這些架構會在瀏覽器的應用程式模型上導入抽象層。事實上，開發人員使用這些抽象化功能編寫的程式碼，通常會轉譯為難以解讀、經過縮排和組合的程式碼。因此，開發人員要充分運用開發人員工具的功能來偵錯及剖析這些應用程式，可能會遇到困難。
舉例來說，使用開發人員工具的「效能」面板分析 Angular 應用程式時，您會看到以下內容：
以這種方式呈現資訊時，您可能很難找出程式碼集中的效能瓶頸。畢竟，這項工具缺少架構建構的背景資訊，且顯示的大部分資訊都是縮排程式碼。此外，您也很難區分與您編寫的程式碼直接相關的活動、架構內部項目，以及可能在同一頁面執行的其他第三方程式碼。
架構和抽象化作者的常見動機，是實作自己的開發人員工具擴充功能，以架構概念呈現剖析資料。使用特定架構建構應用程式時，這些工具在偵錯和剖析方面非常實用。不過，您通常會需要將架構自有剖析器中的架構資料，與開發人員工具「效能」面板中的瀏覽器執行階段資訊相互關聯。如果這兩種資料來源分別顯示在不同的工具中，就難以找出並修正瓶頸，尤其當應用程式變得更加複雜時更是如此。以下是 Angular DevTools Profiler 中的設定檔視覺化範例：
在理想情況下，開發人員會看到兩個資料來源在同一時間軸上，以相同脈絡對應顯示。
因此，我們與 Angular 團隊合作，使用 Performance 面板可擴充性 API，將 Angular 執行階段資料直接帶入「效能」面板。在本文中，我們將探討 API 的功能，以及 Angular 架構如何使用 API 達成這項目的。其他架構和抽象化項目可參考這項實作，藉由檢測自家工具並協助開發人員使用 Chrome 開發人員工具，改善開發人員體驗。
什麼是「效能」面板擴充性 API？
您可以使用 API，在「效能」面板追蹤記錄中加入自己的時間項目，與其他瀏覽器資料位於同一時間軸。有兩種機制可讓您執行這項操作：
- User Timing API
console.timeStampAPI
User Timing API
您可以使用 performance.mark 和 performance.measure 新增項目，如下所示：
// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();
// ... later in your code
performance.measure("Component rendering", {
start: renderStart,
detail: {
devtools: {
dataType: "track-entry",
track: "Components",
color: "secondary",
properties: [
["Render reason", "Props changed"],
["Priority", "low"]
],
}
}
});
這樣一來，時間軸就會新增「Components」軌，並顯示測量結果：
這個 API 可讓您將項目新增至「效能時間軸」緩衝區，同時在開發人員工具的「效能」面板 UI 中顯示這些項目。
如要進一步瞭解這項 API 和 devtools 物件，請參閱說明文件。
console.timeStamp API
這個 API 是 User Timing API 的輕量替代方案。沿用先前的範例，您可能會看到：
// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();
// ... later in your code
console.timeStamp(
"Component rendering",
/* start time */ renderStart,
/* end time (current time) */ undefined,
/* track name */ "Components",
/* track group name */ undefined,
/* color */ "secondary"
);
這個 API 提供高效能的應用程式檢測方法：與 User Timing API 替代方案不同，它不會建立緩衝資料。這個 API 專門用來將資料新增至開發人員工具的「效能」面板，也就是說，如果開發人員工具未記錄追蹤記錄，對 API 的呼叫就會是無運算 (不會執行任何動作)，因此速度會快上許多，適合用於對效能敏感的熱路徑。選擇使用位置引數，而非包含所有自訂參數的物件，也是為了盡可能簡化 API。
如要進一步瞭解如何使用 console.timeStamp 擴充「效能」面板，以及可傳遞的參數，請參閱文件。
Angular 如何整合開發人員工具擴充性 API
我們將瞭解 Angular 團隊如何使用擴充性 API 與 Chrome 開發人員工具整合。
避免使用 console.timestamp 造成額外負擔
從 20 版開始，您可以使用 Performance 面板擴充性 API，對 Angular 進行檢測。開發人員工具中效能資料的精細程度需要快速的 API，因此新增檢測的提取要求 (60217) 選擇使用 console.timeStamp API。這可避免應用程式執行階段效能受到剖析 API 潛在額外負荷的影響。
檢測設備資料
為清楚呈現 Angular 程式碼的執行情形，以及執行原因，啟動和算繪管道的多個部分都經過檢測，包括：
- 應用程式和元件的啟動程序。
- 建立及更新元件。
- 事件監聽器和生命週期掛鉤的執行作業。
- 許多其他功能 (例如動態建立元件和延遲封鎖算繪)。
顏色編碼
系統會使用顏色代碼，向開發人員指出特定測量項目所屬的類別。舉例來說，標記開發人員編寫的 TypeScript 程式碼執行項目的顏色，與 Angular 編譯器產生的程式碼顏色不同。
從下方的螢幕截圖中，您可以看到這會如何產生以藍色顯示的進入點 (例如變更偵測和元件處理)、以紫色顯示的產生程式碼，以及以綠色顯示的 TypeScript 程式碼 (例如事件監聽器和掛鉤)。
請注意，傳遞至 API 的顏色引數並非 CSS 顏色值，而是對應至與開發人員工具 UI 相符顏色的語意權杖。可能的值為 primary、secondary 和 tertiary,，以及各自的 -dark 和 -light 變體，以及 error 顏色。
曲目
撰寫本文時，所有 Angular 執行階段資料都會加入同一條軌跡 (標示為「🅰️ Angular」)。不過，您可以將多個軌跡新增至追蹤記錄，甚至將軌跡分組。舉例來說，假設對 console.timeStamp API 進行下列呼叫：
console.timeStamp("Component 1", componentStart1, componentEnd1, "Components", "Client", "primary");
console.timeStamp("Component 2", componentStart2, componentEnd2, "Components", "Client", "primary");
console.timeStamp("Hook 1", hookStart, hookEnd, "Hooks", "Client", "primary");
console.timeStamp("Fetch data base", fetchStart, fetchEnd, "Server", "primary");
資料會依軌跡分類，如下所示：
舉例來說，如果您有非同步活動、多個平行執行的工作，或活動群組夠明確，值得在 UI 的不同區域中區隔，使用個別軌跡就很有用。
這對 Angular 開發人員有何重要性
直接整合的目標是提供更直覺且全面的成效分析體驗。直接在「效能」面板中顯示 Angular 的內部效能資料，可為開發人員提供以下資訊：
- 提升可見度：在更廣泛的瀏覽器時間軸中，顯示元件轉譯、變更偵測週期等 Angular 專屬效能事件。
- 深入瞭解：提供 Angular 內部程序相關的豐富資訊，協助您更有效找出效能瓶頸。
啟用整合功能
自 Angular 第 20 版起，開發版本已正式提供擴充性 API。如要啟用這項功能，您必須在應用程式或開發人員工具控制台中執行全域公用程式 `ng.enableProfiling()`。如要進一步瞭解整合方式，請參閱 [Angular 說明文件](https://angular.dev/best-practices/profiling-with-chrome-devtools)
其他考量
以下是需要納入考量的幾項重要事項。
來源對應和壓縮程式碼：
來源對應是廣為採用的工具，旨在縮小已組合 / 壓縮程式碼與編寫對應程式碼之間的差距，因此...
來源對應不是應該解決已組合應用程式中程式碼經過壓縮的問題嗎？
雖然來源對應確實很有幫助，但如果剖析複雜的縮小版網頁應用程式，來源對應仍無法完全解決問題。來源對應可讓開發人員工具將經過壓縮的程式碼對應回原始碼，方便進行偵錯。不過，單純依賴來源對應表進行效能分析，仍可能存在一些限制。舉例來說，單靠來源對應，很難選擇以視覺化方式區隔架構內部和編寫的程式碼。另一方面，擴充性 API 則提供彈性，可達成這項區別，並以開發人員認為最方便的方式呈現。
Chrome 開發人員工具擴充功能：
使用 DevTools API 的 Chrome 擴充功能是廣泛使用的工具，可擴充開發人員工具。
既然有這個 API，是否就不需要或不建議使用專屬的剖析器 (例如 Chrome 開發人員工具擴充功能)？
不會。這個 API 的用途並非取代或阻礙專用剖析器 (例如 Chrome 開發人員工具擴充功能) 的開發。這些工具仍可提供專門功能、視覺化效果和工作流程，滿足特定需求。效能面板擴充性 API 的目標，是將自訂資料與效能面板中的瀏覽器視覺化效果無縫整合。
未來發展方向
擴充性 API 的前景。
使用更多架構和抽象化
我們很期待其他架構和抽象化採用這項 API，為開發人員提供更優質的剖析體驗。舉例來說，React 已為其架構實驗性採用了這項 API。這項工具會顯示用戶端和伺服器元件的轉譯作業，以及 React 排程 API 資料。如要進一步瞭解這項功能及如何啟用，請前往 React 頁面。
正式版建構作業
這個 API 的目標之一，是與一般架構和抽象化供應商合作，在正式版中採用及啟用插樁功能。這可能會對使用這些抽象化功能開發的應用程式效能造成重大影響，因為開發人員可以根據使用者的體驗，為應用程式建立設定檔。我們相信 console.timeStamp API 速度快且負擔低，因此能達成這個目標。不過，目前架構仍在實驗 API，並探究哪些類型的檢測對開發人員來說更具擴充性和實用性。