Introductie

Er lijkt soms geen limiet te zijn. Elke iOS app die u uitbrengt, lijkt soepel te draaien en lijkt ook de batterij niet onevenredig snel leeg te trekken. Maar in de meeste gevallen is dit ondanks hoe de app in elkaar zit, en niet dankzij. Daarmee bedoel ik: een iOS app ga je normaliter pas echt optimaliseren als het nodig is. Hebt u dit optimaliseren niet gedaan, dan is de kans dus groot dat het prima werkt ondanks dat u dit niet gedaan heeft.

Deze soepelheid is ook niet altijd even vanzelfsprekend. Soms zijn er zaken als traag reageren, geen of slechte respons op aanrakingen, of haperingen. Vandaag licht ik kort deze laatste toe. We hebben het hier over zogenaamde “scroll hitches” oftewel scrollhaperingen.

Scroll hitches

Aanschouw de volgende animatie:

Wat je ziet is dat de applicatie moeite heeft met het op een soepele manier voorbij laten vliegen van de informatie op het scherm. U zult dit vast wel eens in een iOS app hebben zien gebeuren, misschien zelfs in uw eigen app. Dit verklaren door de processor-snelheid van de iPhone is maar de helft van de waarheid.

Wat is er in het animatievoorbeeld aan de hand? Om dat uit te zoeken kijken we eerst even naar de technische definitie van een scroll hapering: we spreken hiervan als een frame (een beeld, een van de bijv. 60 per seconden) niet op tijd is voorbereid voor het tonen op het scherm. Met andere woorden, het element (dit kan een deel van het scherm zijn, bijvoorbeeld een tabel-rij in de animatie) wordt sneller ‘in beeld gescrolled’ dan dat de telefoon tijd heeft om uit te vinden hoe het er uit moet komen te zien. Het beeld is daarom niet op de verwachte tijd op het scherm te zien.

U moet u voorstellen dat een scherm bijvoorbeeld 60 keer per seconde ververst. Terwijl u met uw vinger de pagina verder scrollt, berekent de iPhone telkens opnieuw hoe het scherm er dan uit moet komen te zien. In bovenstaand voorbeeld ziet u dat dit goed gaat tot frame 3. Frame 3 blijft heel even hangen en lijkt uw vinger niet meer te volgen. De volgende verversing van het scherm gaat wel weer goed en de pagina lijkt daardoor opeens juist weer te ver te schieten (maar is correct t.o.v. de vingerpositie).

Als dit (te veel) gebeurt, geeft dit een nare, niet vloeiende gebruikerservaring.

Meten

Zonder verder teveel in detail te treden, kan je de tijd die je kwijt bent aan scrollhaperingen concretiseren door een formule toe te passen die de totale hoeveelheid tijd berekent die het extra kost voor een beeld om te verschijnen (t.o.v. dat het direct op tijd verschijnt). Als we deze extra tijd als deel van de totale scrolltijd nemen, de tijd dat men aan het scrollen is, geeft dit een indicatie van de haperintensiteit waarmee de gebruiker wordt geconfronteerd.

Gelukkig is er naast een wijze van berekenen, ook een manier om dit daadwerkelijk te meten. Zonder verder in detail te treden: we kunnen in Xcode, de software voor de iOS app developer waarmee apps worden gemaakt, deze haperingen meten.

In bovenstaand voorbeeld zien we door een blauw streepje aangegeven dat er een frame is overgeslagen. Door onze code efficiënter te maken en telkens opnieuw deze test uit te voeren, kunnen we zorgen dat deze scrollhaperingen niet meer voorkomen.

Conclusie

Het belangrijkste dat we moeten weten over scrollhaperingen is:

• Geen haperingen betekent tegenwoordig niet per se een efficiënte applicatie, maar vooral een snelle iPhone
• Wel haperingen betekent niet dat u hiermee moet leren leven (of wachten op een snellere iPhone).
• Er zijn namelijk statistieken beschikbaar voor de iPhone app ontwikkelaar om de oorzaak te achterhalen en de code efficiënter te maken.

De afbeeldingen en informatie is naar buiten gebracht door Apple tijdens de WWDC ’20 conferentie.