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:
- Przeczytaj dokument z wyjaśnieniem w repozytorium. Istotnych jest wiele niuansów dotyczących sposobu, w jaki najlepiej rejestrować dane klatki, aby miały one sens. Wyjaśnienie nakreśla pewne kwestie.
- Zobacz najnowszą wersję specyfikacji. Jest dość lekka i warto ją przeczytać.
- Zgłoś problemy dotyczące brakujących funkcji lub potencjalnych problemów. Wiesz, co chcesz mierzyć, więc jeśli uważasz, że jest coś, czego nie można zrobić za pomocą API, prześlij nam swoją opinię.