Obsługa danych wejściowych może być przyczyną problemów z wydajnością w aplikacjach, ponieważ może blokować ukończenie klatek i powodować dodatkowe, niepotrzebne prace związane z układem.
Obsługa danych wejściowych może być przyczyną problemów z wydajnością w aplikacjach, ponieważ może blokować ukończenie klatek i powodować dodatkowe, niepotrzebne prace związane z układem.
Podsumowanie
- Unikaj długotrwałych procedur obsługi danych wejściowych, ponieważ mogą one blokować przewijanie.
- Nie wprowadzaj zmian stylu w procedurach obsługi danych wejściowych.
- Zastosuj odrzucanie powtórzeń w procedurach obsługi. Przechowuj wartości zdarzeń i zajmuj się zmianami stylu w następnym wywołaniu zwrotnym requestAnimationFrame.
Unikanie długotrwałych procedur obsługi danych wejściowych
W najszybszym możliwym przypadku, gdy użytkownik wchodzi w interakcję ze stroną, wątek kompozytora strony może przyjąć dane wejściowe dotyku użytkownika i po prostu przesunąć zawartość. Nie wymaga to żadnej pracy w wątku głównym, w którym wykonywane są JavaScript, układ, style i malowanie.
Jeśli jednak dołączysz procedurę obsługi danych wejściowych, np. touchstart, touchmove lub touchend, wątek kompozytora musi poczekać na zakończenie wykonywania tej procedury, ponieważ możesz wywołać preventDefault() i zatrzymać przewijanie dotykiem. Nawet jeśli nie wywołasz preventDefault(), kompozytor musi poczekać, a przewijanie użytkownika jest zablokowane, co może powodować przeskoki i pomijanie klatek.
Krótko mówiąc, musisz się upewnić, że wszystkie uruchamiane procedury obsługi danych wejściowych działają szybko i pozwalają kompozytorowi wykonywać swoją pracę.
Unikanie zmian stylu w procedurach obsługi danych wejściowych
Procedury obsługi danych wejściowych, takie jak przewijanie i dotyk, są zaplanowane do uruchomienia tuż przed wywołaniami zwrotnymi requestAnimationFrame.
Jeśli wprowadzisz zmianę wizualną w jednej z tych procedur obsługi, na początku requestAnimationFrame będą oczekiwać zmiany stylu. Jeśli następnie odczytasz właściwości wizualne na początku wywołania zwrotnego requestAnimationFrame, zgodnie z radą zawartą w artykule „Unikanie dużych, złożonych układów i thrashingu układu”, spowodujesz wymuszone synchroniczne układanie.
Odrzucanie powtórzeń w procedurach obsługi przewijania
Rozwiązanie obu opisanych powyżej problemów jest takie samo: zawsze należy odrzucać powtórzenia zmian wizualnych do następnego wywołania zwrotnego requestAnimationFrame:
function onScroll (evt) {
// Store the scroll value for laterz.
lastScrollY = window.scrollY;
// Prevent multiple rAF callbacks.
if (scheduledAnimationFrame)
return;
scheduledAnimationFrame = true;
requestAnimationFrame(readAndUpdatePage);
}
window.addEventListener('scroll', onScroll);
Ma to też dodatkową zaletę, ponieważ procedury obsługi danych wejściowych są lekkie, co jest świetne, bo nie blokujesz już takich rzeczy jak przewijanie czy dotyk w przypadku kodu wymagającego dużej mocy obliczeniowej.