Moduły obsługi danych wejściowych mogą być przyczyną problemów z wydajnością aplikacji, bo mogą blokować dokończenie klatek i powodować dodatkowe, niepotrzebne prace związane z układem.
Obsługa danych wejściowych może być potencjalną przyczyną problemów z wydajnością w Twoich aplikacjach, ponieważ może blokować tworzenie klatek i wywoływać dodatkowe, niepotrzebne operacje układu.
Podsumowanie
- Unikaj długotrwałych procedur obsługi danych wejściowych, ponieważ mogą one blokować przewijanie.
- Nie wprowadzaj zmian stylu w obsługach danych wejściowych.
- Odbij moduły obsługi; zapisuj wartości zdarzeń i reaguj na zmiany stylu przy następnym wywołaniu zwrotnym requestAnimationFrame.
Unikaj długo działających modułów 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 dotykowe użytkownika i po prostu przenieść zawartość. Nie wymaga to działania wątku głównego, w którym wykonywane są zadania związane z JavaScriptem, układem, stylami lub renderowaniem.
Jeśli jednak dołączysz moduł obsługi danych wejściowych, taki jak touchstart, touchmove lub touchend, wątek kompozytora będzie musiał czekać na zakończenie działania tego modułu, ponieważ możesz wywołać funkcję preventDefault() i przerwać przewijanie dotykiem. Nawet jeśli nie wywołasz funkcji preventDefault(), kompozytor musi zaczekać, co spowoduje zablokowanie przewijania przez użytkownika, co może powodować zacinanie się i braki w klatkach.
Krótko mówiąc, musisz się upewnić, że wszystkie uruchomione przez Ciebie moduły obsługi danych wejściowych powinny działać szybko i umożliwić kompozytorowi wykonanie swojego zadania.
Unikaj zmian stylu w obsługach danych wejściowych
Moduły obsługi danych wejściowych, np. służące do przewijania i dotyku, są zaplanowane do uruchomienia tuż przed wywołaniami zwrotnymi requestAnimationFrame.
Jeśli wprowadzisz zmianę wizualną w jednym z tych modułów obsługi, na początku modułu requestAnimationFrame zostaną wprowadzone oczekujące zmiany stylu. Jeśli potem odczytasz właściwości wizualne na początku wywołania metody requestAnimationFrame, zgodnie z zaleceniem podanym w artykule „Unikaj dużych, złożonych układów i ich nadmiernego wczytywania”, spowodujesz wymuszony układ synchroniczny.
Odbijanie modułów obsługi przewijania
Rozwiązanie obu powyższych problemów jest takie samo: zawsze należy odrzucić zmiany wizualne przy następnym wywołaniu zwrotnym 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);
Dodatkową zaletą jest to, że moduły obsługi danych wejściowych są lżejsze, co jest niesamowite, ponieważ teraz nie blokujesz takich rzeczy jak przewijanie czy dotykanie kosztownego obliczeniowo kodu.