需要開發人員意見回饋 - Frame Timing API

Paul Lewis
X 首頁

過去幾年，瀏覽器在算繪效能方面取得了巨大進展，特別是在行動裝置上。過去，您無法在任何複雜的遠端場景中，取得流暢的幀率，但現在只要稍加留意，就能達到這個目標。

不過，對於大多數人來說，我們在自己的裝置上合理測試的內容，與使用者實際體驗之間存在落差。如果他們無法獲得流暢的 60 張/秒，體驗就會受到影響，最終他們會轉往其他平台，我們也會因此受損。幸好，W3C 正在討論新的 API，可協助我們瞭解使用者看到的內容：Frame Timing API。

Jake Archibald 和我最近錄製了 API 的總覽影片，如果您偏好觀看影片，請參考以下內容：

Frame Timing API 的用途

您無疑可以透過 Frame Timing API 執行許多操作，但最重要的是，您可以評估對您和專案而言重要的項目。不過，以下提供一些想法：

  • 追蹤 JavaScript 和 CSS 動畫的 fps。
  • 追蹤網頁捲動的流暢度 (或您有趣的無限捲動清單)。
  • 根據裝置目前的負載量，自動縮減 Showbiz 特效。
  • 針對執行階段效能指標進行迴歸測試。

電梯簡報

以下是 API 目前在規格中的樣貌：您可以使用這個 API 擷取轉譯器執行緒時間的資料，也就是 JavaScript、樣式和版面配置執行的時間。(您可能聽過稱為主執行緒的轉譯器執行緒，這兩者是同一個東西，只是名稱不同)。

var rendererEvents = window.performance.getEntriesByType("renderer");

您收到的每個轉譯器執行緒記錄大致如下所示：

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

每個記錄基本上都是物件，其中包含專屬影格編號、高解析度時間戳記 (代表影格開始的時間)，以及另一個代表使用 CPU 時間的時間戳記。有了這些陣列，您就能查看每個 startTime 值，並找出主執行緒是否以 60fps 執行；也就是說，每個影格 startTime 是否以大約 16 毫秒的區塊上升。

但除了 cpuTime 之外，您還可以瞭解是否在 16 毫秒的邊界內，或是是否已達極限。如果 cpuTime 接近 16 毫秒邊界，就沒有太多空間可讓垃圾收集等功能啟動，而且由於 CPU 使用率偏高，電池消耗量也會增加。

除了轉譯器執行緒，您也可以擷取轉譯器執行緒時機的資料，也就是繪製和合成的時機：

var compositeThreadEvents = window.performance.getEntriesByType("composite");

每個事件也會傳回來源影格編號，您可以使用這項資訊連結至主執行緒的事件：

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

由於合成作業通常在瀏覽器中運作，因此每個轉譯器執行緒記錄可能會有多個這類記錄，因此您可以使用 sourceFrameNumber 將這些記錄連結在一起。我們也討論過是否應在這些記錄中加入 CPU 時間，因此如果您有強烈意見，歡迎在 GitHub 問題中提出。

更多資訊

這個 API 尚未推出，但希望很快就會推出。在此期間，您可以先採取下列行動：