Każdy inny ekran w tej aplikacji sam wybrałeś, żeby go otworzyć. Ten – nie. Dotknąłeś czegoś innego, a blokada cię złapała. Ta różnica całkowicie zmienia założenia inżynierskie. Ekran, o który poprosiłeś, może chwilę zajmować, zanim się pojawi – nikt nie sprawdza stopera. Ekran, który ci przerywa, ma jedną szansę, żeby nie sprawiać wrażenia, że telefon się zaciął, i musi to udowodnić w mniej niż jedną trzecią sekundy.
Jedyny pomiar, który się liczy
Nie chodzi o długość animacji wstępu – tylko o odstęp, zanim się zacznie. Drzwi, wejście, podłoga, sufit, tablica, szyld, zegar: sekwencja ma stały harmonogram, a każde z tych opóźnień zostało dobrane i ręcznie sprawdzone. Nic z tego nie ma znaczenia, jeśli samo dotknięcie ma przed sobą zacięcie. Piękne, 800-milisekundowe wejście stojące za 400-milisekundową pustą białą klatką czyta się jako „ta aplikacja jest wolna” i koniec – dopracowanie nigdy nie zostaje zauważone, bo wyrok zapada już na pustej klatce.
Więc prawdziwym celem nie jest „animacja wygląda płynnie”. Jest nim „coś się pojawia, zanim użytkownik zdąży się zastanowić, czy dotknięcie w ogóle zadziałało”. To mniej więcej ten sam budżet, co przy systemowym przełączaniu aplikacji – parę setek milisekund – i to o wiele surowsza granica niż ta, do której trzyma się większość przejść wewnątrz aplikacji.
Nigdy nie blokuj blokady
Klasa nie może czekać na sieć. Jakiekolwiek pytanie zostanie zadane, musi pochodzić z danych, które już leżały na urządzeniu, zanim dotknąłeś ekranu – pobranych i zapisanych w pamięci podręcznej wcześniej, na twoich warunkach, a nie zamawianych w chwili, gdy jesteś już zirytowany i patrzysz na kółko ładowania. Jeśli ta pamięć podręczna jest kiedykolwiek pusta, uczciwą porażką jest prostsza, statyczna karta z pytaniem – nie kółko ładowania przed nauczycielem, który jeszcze się nie pojawił.
Ta sama zasada dotyczy zasobów. Żądanie czcionki albo pobieranie obrazu na ścieżce krytycznej to zależność od tego, że sieć akurat w chwili przerwania działa szybko – czyli dokładnie wtedy, gdy masz najmniej cierpliwości. Hostowanie czterech czcionek tej strony u siebie to ten sam odruch zastosowany do aplikacji: nic, czego potrzebuje wstęp, nie powinno móc się wysypać tylko dlatego, że ktoś siedzi na słabym hotelowym Wi-Fi.
Gdzie naprawdę idą klatki
Tylko tanie właściwości animacji – pozycja i przezroczystość, czyli takie, które telefon może przesuwać bez przeliczania układu pod spodem, nigdy nic, co wymusza reflow w środku sekwencji. Klasa, która musi pojawiać się tak często, nie może sobie pozwolić choćby na jedną właściwość kosztowną na starszym urządzeniu, bo „starsze urządzenie” nie jest tu przypadkiem brzegowym – to spora część osób trzymających telefon dokładnie w chwili, gdy sięgają po coś zablokowanego.
Wniosek jest taki, że większość tego, co w intrze wygląda na ruch, to w rzeczywistości bardzo mało ruchu, dobrze wyreżyserowanego. Drzwi, które się otwierają, postać, która robi cztery kroki, tablica, która wjeżdża na miejsce – to nie jest dużo zmieniających się pikseli, to dużo *dobrze zgranych w czasie* zmieniających się pikseli, co jest tańszą sztuczką, niż wygląda z zewnątrz.
Czego wciąż nie jesteśmy pewni
Zimny start to uczciwa luka. Samo pierwsze przerwanie po restarcie telefonu albo po tym, jak aplikacja została zabita w tle, jest wolniejsze niż każde kolejne, bo nic nie jest jeszcze „rozgrzane” – żadnego zapisanego pytania, żadnych czcionek już sparsowanych, żadnego pakietu JS już rezydującego w pamięci. Nie mamy na to czystej łatki poza utrzymywaniem aplikacji jak najlżejszej i liczeniem na to, że system nie usunie jej z pamięci zbyt gorliwie. Jeśli twoja pierwsza dzisiejsza blokada wydaje się o odrobinę wolniejsza niż kolejne, właśnie dlatego – i nie jest to coś, co świadomie zignorowaliśmy.
Tania Androidowa końcówka to druga otwarta kwestia – to telefony, dla których to ma największe znaczenie, bo dwusekundowe zacięcie stanowi tam znacznie większy ułamek 300-milisekundowego budżetu niż na flagowcu. Budujemy pod tym ograniczeniem, nie pod urządzeniem, które akurat trzymamy w ręku.