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

Paul Lewis

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

不過,對於大多數人來說,我們在自己的裝置上合理測試的內容,與使用者實際體驗之間存在落差。如果他們無法獲得流暢的 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 尚未推出,但希望很快就會推出。在此期間,您可以先採取下列行動: