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 teraz jest to możliwe, jeśli odpowiednio się postarasz.

Większość z nas ma jednak problem z testowaniem na własnych urządzeniach i znalezieniem odpowiednich wrażeń dla użytkowników. Jeśli nie uzyskają płynnej płynności 60 FPS, ich wrażenia będą gorsze, a ostatecznie odejdą i 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.

Niedawno nagraliśmy z Jakem Archibaldem film z ogólnym omówieniem interfejsu API. Jeśli wolisz oglądać niż czytać, obejrzyj ten film:

Zastosowania interfejsu Frame Timing API

Interfejs API Frame Timing API umożliwia Ci wiele działań, a co najważniejsze, możesz dzięki niemu 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 aktualnego obciążenia urządzenia.
  • testy regresji 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 procesor poświęcił na ten element. 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ż cpuTime, dzięki czemu wiesz, czy mieścisz się w granicach 16 ms, czy też mieścisz się w nich na styk. 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ż procesor jest mocno obciążony, 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ą połączyć. 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: