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

Paul Lewis

過去幾年來,瀏覽器在算繪效能方面大幅成長,尤其是在行動裝置上。過去你從未想過在遠端處理任何複雜的作業時,都能達到流暢的影格速率,但現在至少只要你照顧好,即可達成這個目標。

不過,對大多數人來說,我們在自己的裝置上可合理測試的項目和使用者體驗之間會有所落差。如果不流暢,60fps 呈現不順暢的影格效能,使用體驗受損,最終還會朝其他方向前進。另一方面,W3C 也正在討論全新的 API,協助我們瞭解使用者看到的內容:Frame Timing API

Jake Archibald 和我最近錄製了這個 API 的簡介影片,如果你偏好觀看說明內容,歡迎參閱:

使用 Frame Timing API

使用 Frame Timing API 的方式有許多種,最重要的是,您必須評估對您和專案來說的重要性。即使如此,以下還有一些想法:

  • 追蹤 JavaScript 和 CSS 動畫的每秒影格數。
  • 追蹤網頁捲動的流暢度 (或您擁有的十分之一無限捲動清單)。
  • 根據裝置目前負載,自動縮放顯示比例效果。
  • 執行階段效能指標的迴歸測試。

電梯簡報

API 目前的規格如下:您可以提取轉譯器執行緒時間的資料,其中執行 JavaScript、樣式和版面配置。(您可能已經聽說稱為「主執行緒」的轉譯器執行緒,跟另一個名稱相同)。

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

您取得的每個轉譯器執行緒記錄大致如下:

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

每筆記錄基本上都是一個物件,其中包含專屬的影格編號、影格開始時的高解析度時間戳記,以及該記錄使用的 CPU 作業時間。透過一系列的陣列,您可以查看每個 startTime 值,並瞭解主執行緒是否每秒 60 個影格。基本上,「每個影格的 startTime 會大約在 16 毫秒的區塊中嗎?」

但不只如此,您還可以取得 cpuTime,讓您瞭解自己是否在 16 毫秒的界線內,或是否靠近電線。如果 cpuTime 在 16 毫秒邊界附近沒有足夠的空間,例如開始收集垃圾、而 CPU 使用率偏高,那麼電池耗電量也會提高。

除了轉譯器執行緒之外,您也可以提取合成器執行緒時間的資料,其中發生繪製和合成作業:

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

這些每個畫面也都會附帶來源影格編號,您可以使用這組號碼與主要執行緒的事件建立關聯:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

由於合成方式通常在瀏覽器中運作,因此每個轉譯器執行緒記錄可能會有一些這些記錄,因此您可以使用 sourceFrameNumber 將這些記錄互相連結。我們也會進行一些討論,以指出這些記錄中是否也應需要 CPU 作業時間,因此如果你對於 GitHub 問題非常瞭解,

更多資訊

這個 API 尚未推出,但希望很快就能推出。在此期間,您可以先閱讀或執行以下事項: