Potrzeba opinii dewelopera – Frame Timing API

W ciągu ostatnich kilku lat przeglądarki poczyniły ogromne postępy w zakresie wydajności renderowania, zwłaszcza na urządzeniach mobilnych. Do tej pory nie mieliśmy nadziei na osiągnięcie płynnej liczby klatek w jakichkolwiek bardziej skomplikowanych aspektach, ale obecnie jest to przynajmniej możliwe, o ile się zadbasz.

W większości z nas istnieje jednak różnica między tym, co możemy przetestować na własnych urządzeniach, a wrażeniami użytkowników. Jeśli ich jakość 60 kl./s nie będzie płynna, stracisz możliwość korzystania z niej i uciekają się gdzie indziej. Poza tym W3C omawia nowy interfejs API, który mógłby pomóc zobaczyć to, co widzą użytkownicy: Frame Timing API.

Jake Archibald i ja niedawno nagraliśmy film z omówieniem interfejsu API. Jeśli wolisz, żeby go obejrzeć, obejrzyj te materiały:

Zastosowania interfejsu Frame Timing API

Za pomocą interfejsu Frame Timing API możesz zrobić wiele rzeczy, a przede wszystkim mierzyć to, co jest ważne dla Ciebie i Twojego projektu. Mamy jednak kilka pomysłów:

  • Śledzenie liczby klatek na sekundę w animacjach JavaScript i CSS.
  • Monitorowanie płynności przewijania strony (lub innej przydatnej listy z nieskończonym przewijaniem).
  • Automatyczne skalowanie efektów showbizu z bieżącym obciążeniem urządzenia
  • Testowanie regresji danych o wydajności środowiska wykonawczego.

Krótka prezentacja

Tak obecnie wygląda interfejs API w specyfikacji: za jego pomocą można pobierać dane o czasie wątków mechanizmu renderowania, w których działa JavaScript, style i układ. (być może zdarzyło Ci się słyszeć wątek mechanizmu renderowania o nazwie „główny wątek”, a jest to ta sama nazwa pod inną nazwą).

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

Zawartość wszystkich zapisanych wątków mechanizmu renderowania wygląda mniej więcej tak:

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

Zasadniczo każdy rekord jest obiektem, który zawiera unikalny numer klatki, sygnaturę czasową w wysokiej rozdzielczości (datę rozpoczęcia odtwarzania) i drugi czas, który określa wykorzystanie procesora. Dzięki tablicom możesz przyjrzeć się poszczególnym wartościom startTime i dowiedzieć się, czy wątek główny osiąga szybkość 60 kl./s. Czy w zasadzie „startTime każdej klatki zwiększa się o około 16 ms?”

Co więcej, oprócz tego otrzymujesz także urządzenie cpuTime, dzięki któremu dowiesz się, czy jesteś w zasięgu 16 ms, czy znajdujesz się w pobliżu przewodu. Jeśli cpuTime znajduje się prawie w pobliżu granicy 16 ms, nie będzie już miejsca na uruchomienie funkcji odśmiecania śmieci, a przy wysokim wykorzystaniu procesora zużycie baterii również będzie większe.

Oprócz wątku mechanizmu renderowania możesz też pobierać dane o czasie wątków kompozytora, w których odbywa się malowanie i komponowanie:

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

Każda z nich zawiera też numer ramki źródłowej, który pozwala powiązać ją ze zdarzeniami w wątku głównym:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Ze względu na sposób, w jaki komponowanie często działa w przeglądarkach, w jednym rekordzie wątku mechanizmu renderowania może być kilka takich rekordów. Do ich powiązania możesz użyć zasady sourceFrameNumber. Nie zapominaj też o tym, czy w tych rekordach powinno być w przypadku używania również czasu pracy procesora, więc jeśli chcesz wyrazić silną opinię o problemach z GitHubem.

Więcej informacji

Ten interfejs API nie jest jeszcze wysyłany, ale mamy nadzieję, że wkrótce tak się stanie. Tymczasem możesz przeczytać i zrobić te rzeczy: