Cần có ý kiến phản hồi của nhà phát triển – Frame Timing API

Paul Lewis
Twitter Trang chủ

Trong vài năm qua, các trình duyệt đã có bước tiến lớn về mặt hiệu suất hiển thị, đặc biệt là trên thiết bị di động. Nếu trước đây bạn không hy vọng đạt được tốc độ khung hình mượt mà cho bất kỳ nội dung phức tạp nào từ xa, thì giờ đây ít nhất bạn đã đạt được điều đó nếu cẩn thận.

Tuy nhiên, đối với hầu hết chúng ta, có một sự ngắt kết nối giữa những gì chúng tôi có thể thử nghiệm một cách hợp lý trên các thiết bị của mình và những gì người dùng của chúng tôi trải nghiệm. Nếu họ không có được tốc độ 60 khung hình/giây mượt mà, thì trải nghiệm của họ sẽ bị suy giảm và cuối cùng họ sẽ chuyển đến nơi khác và chúng tôi sẽ chịu đau đớn. Đồng thời, W3C cũng đang thảo luận về một API mới có thể giúp chúng ta xem những gì người dùng nhìn thấy: Frame Timing API.

Jake Archibald và gần đây tôi đã quay video tổng quan về API, vì vậy nếu bạn muốn xem hơn thì hãy đọc:

Sử dụng Frame Timing API

Chắc chắn có rất nhiều việc bạn có thể làm với Frame Timing API và đặc biệt là bạn sẽ đo lường được những gì quan trọng đối với bạn và đối với dự án của bạn. Mặc dù vậy, sau đây là một số ý tưởng:

  • Theo dõi tốc độ khung hình/giây của hoạt ảnh JavaScript và CSS.
  • Theo dõi độ mượt của thao tác cuộn trang (hoặc có thể là danh sách cuộn vô hạn tiện lợi mà bạn có).
  • Tự động thu nhỏ hiệu ứng giải trí dựa trên tải hiện tại của thiết bị.
  • Kiểm thử hồi quy đối với các chỉ số hiệu suất trong thời gian chạy.

Quảng cáo chiêu hàng cô đọng

Dưới đây là giao diện của API hiện tại theo thông số kỹ thuật: với API này, bạn sẽ lấy dữ liệu về thời gian luồng của trình kết xuất, nơi JavaScript, kiểu và bố cục chạy. (Có thể bạn đã nghe thấy luồng kết xuất đồ hoạ có tên là luồng chính; nó cũng có tên khác.)

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

Mỗi bản ghi luồng kết xuất đồ hoạ mà bạn nhận lại có dạng như sau:

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

Về cơ bản, mỗi bản ghi là một đối tượng chứa số khung duy nhất, dấu thời gian có độ phân giải cao cho thời điểm khung hình bắt đầu và một bản ghi khác cho biết thời gian sử dụng của CPU. Với một mảng các giá trị này, bạn có thể xem từng giá trị startTime và tìm hiểu xem luồng chính có đạt tốc độ 60 khung hình/giây hay không; về cơ bản, "startTime của mỗi khung hình có tăng lên trong các đoạn khoảng 16 mili giây không?"

Nhưng hơn hết, bạn cũng nhận được cpuTime, vì vậy, bạn sẽ biết liệu mình có đang ở bên trong ranh giới 16 mili giây một cách thoải mái hay không, hay bạn có ở gần dây. Nếu cpuTime ở ngay gần ranh giới 16 mili giây, thì sẽ không còn nhiều chỗ cho những việc như thu gom rác và khi mức sử dụng CPU cao, mức tiêu thụ pin cũng sẽ cao hơn.

Ngoài luồng kết xuất đồ hoạ, bạn cũng có thể lấy dữ liệu về thời gian của luồng trình kết hợp, nơi diễn ra việc vẽ và kết hợp:

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

Mỗi sự kiện trong số này cũng quay lại với số khung nguồn mà bạn có thể sử dụng để liên kết lại với các sự kiện của luồng chính:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Do cách thức kết hợp thường hoạt động trong trình duyệt, nên mỗi bản ghi luồng của trình kết xuất có thể có một số bản ghi này. Vì vậy, bạn có thể sử dụng sourceFrameNumber để liên kết các bản ghi đó lại với nhau. Ngoài ra, còn có một số cuộc thảo luận về việc liệu có nên dành thời gian cho CPU trong các bản ghi này hay không, vì vậy nếu bạn cảm thấy mạnh mẽ lên tiếng về các vấn đề trong GitHub.

Thông tin khác

API này chưa được vận chuyển, nhưng hy vọng sẽ sớm có. Trong khi chờ đợi, dưới đây là một số việc bạn có thể đọc và làm: