Potrzeba opinii dewelopera – Frame Timing API

W ciągu ostatnich kilku lat przeglądarki zrobiły ogromne postępy w zakresie wydajności renderowania, zwłaszcza na urządzeniach mobilnych. Wcześniej nie było szans na płynną liczbę klatek na sekundę w przypadku nawet najbardziej złożonych gier, ale dziś jest to możliwe, jeśli się postarasz.

Większość z nas ma jednak problem z testowaniem na własnych urządzeniach i znalezieniem sposobu, który będzie odpowiedni dla użytkowników. Jeśli nie uzyskają płynnej animacji 60 FPS, ich wrażenia będą gorsze, a w konsekwencji pójdą gdzie indziej, a my stracimy. W tym samym czasie W3C omawia nowy interfejs API, który może pomóc nam zobaczyć, co widzą użytkownicy: Frame Timing API.

Jake Archibald i ja nagraliśmy niedawno film z omówieniem interfejsu API. Jeśli wolisz oglądać niż czytać, obejrzyj ten film:

Zastosowania interfejsu Frame Timing API

Interfejs Frame Timing API umożliwia Ci wiele działań, a co najważniejsze, pozwala mierzyć to, co jest ważne dla Ciebie i Twojego projektu. Mimo to mamy kilka pomysłów:

  • śledzenie liczby klatek na sekundę animacji JavaScript i CSS;
  • Śledzenie płynności przewijania strony (lub może tej przydatnej listy z nieskończonym przewijaniem).
  • Automatyczne zmniejszanie efektów specjalnych na podstawie bieżącego obciążenia urządzenia.
  • testy regresji dotyczące danych o skuteczności w czasie działania.

Krótka prezentacja

Oto, jak wygląda specyfikacja interfejsu API: możesz z niego pobierać dane o czasie trwania wątku renderowania, w którym działają JavaScript, style i schemat. (być może słyszałeś/słyszałaś, że wątek renderowania nazywany jest wątkiem głównym; to ta sama rzecz, ale pod inną nazwą).

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

Każdy z rekordów wątku procesora renderowania wygląda mniej więcej tak:

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

Każdy rekord to obiekt zawierający unikalny numer kadru, znak czasu o wysokiej rozdzielczości z datą rozpoczęcia kadru oraz informację o tym, ile czasu procesora wykorzystał. Dzięki temu możesz sprawdzić każdą wartość startTime i sprawdzić, czy główny wątek działa z prędkością 60 FPS. Chodzi o to, czy wartość startTime każdego klatki rośnie co około 16 ms.

Oprócz tego otrzymujesz też wartość cpuTime, dzięki której dowiesz się, czy mieścisz się w granicach 16 ms, czy też nie. Jeśli cpuTime jest blisko granicy 16 ms, nie ma zbyt wiele miejsca na takie działania jak zbieranie elementów do usunięcia, a ponieważ wykorzystanie procesora jest wysokie, zużycie baterii będzie też wyższe.

Oprócz wątku renderowania możesz też pobierać dane dotyczące czasu trwania wątku kompozytora, w którym odbywa się malowanie i kompozycja:

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

Każde z nich ma też numer ramki źródłowej, który możesz wykorzystać do powiązania z zdarzeniami wątku głównego:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Ze względu na sposób, w jaki w przeglądarkach działa kompozytowanie, na każdy rekord wątku w renderowaniu może przypadać kilka takich rekordów. Możesz użyć sourceFrameNumber, aby je ze sobą powiązać. Trwają też dyskusje na temat tego, czy w tych rekordach powinien być też czas procesora. Jeśli masz zdecydowane zdanie na ten temat, podziel się nim na GitHubie.

Więcej informacji

Ten interfejs API nie jest jeszcze dostępny, ale mamy nadzieję, że wkrótce się to zmieni. Tymczasem możesz przeczytać i wypróbować te treści: