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.
Moduły obsługi danych wejściowych mogą być przyczyną problemów z wydajnością aplikacji, mogą blokować ukończenie klatek i powodować dodatkowe i niepotrzebne pracy nad układem.
Podsumowanie
- Unikaj długo działających modułów obsługi danych wejściowych. mogą zablokować przewijanie.
- Nie wprowadzaj zmian stylu w modułach obsługi danych wejściowych.
- odbijanie modułów obsługi; zapisuj wartości zdarzeń i reaguj na zmiany stylu w 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 pracy przez wątek główny, w którym wykonuje się JavaScript, układ, style i malowanie.
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, 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 modułach obsługi 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 wtedy przeczytasz właściwości wizualne na początku wywołania zwrotnego requestAnimationFrame, zgodnie ze wskazówkami w artykule „Unikaj dużych, złożonych układów i thrashingu”, aktywujesz 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ą mało przejrzyste, co jest niesamowite, ponieważ teraz nie blokujesz takich elementów jak przewijanie czy dotykanie kosztownego obliczeniowo kodu.