Chrome su Android dimezza gli scatti durante lo scorrimento: come ci riesce

La fluidità di Chrome su Android non dipende soltanto dalla potenza del SoC (System-on-a-Chip) o dalla frequenza dello schermo. Basta che un evento tattile arrivi con qualche millisecondo di ritardo, che un thread rimanga occupato più del previsto o che un messaggio tra processi attraversi troppi passaggi perché la pagina sembri incepparsi sotto il dito. Google sostiene di avere ridotto del 48% la frequenza degli scorrimenti irregolari intervenendo sul percorso che collega il touchscreen alla visualizzazione effettiva dei pixel.

Il problema prende il nome di scroll jank: durante lo scorrimento, uno o più fotogrammi non riflettono in tempo la nuova posizione della pagina. Lo schermo ripropone quindi per un ciclo il contenuto precedente, producendo quel piccolo scatto che l’occhio percepisce subito, soprattutto sui telefoni con pannelli ad alta frequenza.

I numeri aiutano a capire quanto siano ridotti i margini disponibili. Un display a 60 Hz aggiorna l’immagine ogni 16,7 millisecondi; a 90 Hz il tempo scende a circa 11,1 millisecondi, mentre a 120 Hz restano appena 8,3 millisecondi. Entro quella finestra Chrome deve ricevere il movimento del dito, stabilire quale elemento stia scorrendo, calcolare la nuova posizione, comporre il fotogramma, riempire un buffer grafico e consegnarlo ad Android. Essere molto veloci in media non basta: serve soprattutto evitare oscillazioni e ritardi sporadici.

Perché lo scorrimento di Chrome è più complesso di quello di un’app Android

Una normale applicazione Android può ricevere sullo stesso thread sia gli eventi di input sia il segnale VSync, ovvero il riferimento temporale che indica l’avvio di un nuovo ciclo di aggiornamento dello schermo. L’applicazione associa il movimento del dito al fotogramma da produrre e aggiorna l’interfaccia seguendo un percorso relativamente breve.

Chrome lavora in modo diverso: il browser separa le proprie attività fra più processi per limitare gli effetti di un crash, isolare i siti e ridurre i rischi di sicurezza. Il browser process gestisce l’interfaccia, le schede e numerose decisioni di coordinamento; i renderer elaborano HTML, CSS e JavaScript; il processo GPU si occupa della composizione e della produzione dei buffer grafici. L’isolamento offre vantaggi notevoli, ma rende più difficile mantenere tempi uniformi.

Quando il dito tocca lo schermo, l’evento deve inizialmente raggiungere Chrome, passare attraverso le attività di hit testing necessarie per individuare il bersaglio e arrivare al componente che calcola il nuovo offset di scorrimento. Il segnale VSync segue invece un percorso differente: raggiunge il thread del compositore Viz nel processo GPU e da lì concorre alla preparazione del fotogramma.

Input Vizard sposta gli eventi fuori dal thread più affollato

Una delle modifiche principali prende il nome di Input Vizard.

Storicamente, Android consegnava gli input delle applicazioni al thread principale. Nel caso di Chrome, però, il main thread svolge molte attività: gestione dell’interfaccia, navigazione, messaggi provenienti da altri processi e operazioni amministrative della scheda. Un compito prolungato poteva quindi trattenere anche il movimento del dito.

Google ha collaborato con il team Android per consentire l’instradamento degli eventi verso un processo differente: Chrome può ora ricevere sia l’input sia i segnali VSync sul thread del compositore Viz nel processo GPU. Il main thread del browser esce così dal percorso critico dello scorrimento.

Il vantaggio non consiste tanto nel rendere ogni operazione più rapida, quanto nell’eliminare una fonte di ritardi imprevedibili. Se il thread principale sta completando un’attività costosa, il compositore può comunque acquisire l’input e portare avanti l’aggiornamento visivo. Chrome si avvicina, almeno per questa operazione, al modello più semplice nel quale input e composizione convivono sullo stesso thread.

Chrome coordina input, predizione e messaggi per evitare gli scatti

Per rendere lo scorrimento più regolare, Chrome usa l’ultimo movimento del dito senza perdere la scadenza del fotogramma.

Il componente chiamato Input Framer attende quindi un evento tattile arrivato in ritardo per un massimo di circa un terzo del ciclo di aggiornamento: circa 5,6 millisecondi a 60 Hz e 2,8 millisecondi a 120 Hz. Se il campione non arriva in tempo, il browser stima la posizione successiva sulla base dei movimenti precedenti, evitando di mostrare per un altro ciclo una posizione ormai superata.

A diminuire ulteriormente i ritardi interviene Direct2Thread: alcuni messaggi critici raggiungono direttamente il thread destinatario, senza attraversare i consueti thread di input-output intermedi. Il vantaggio principale non consiste in un’accelerazione spettacolare del singolo passaggio, ma in tempi più regolari; su uno schermo a 120 Hz, dove ogni fotogramma dispone di appena 8,3 millisecondi, anche poche deviazioni possono produrre uno scatto visibile.

Anche la barra di Chrome può rallentare la pagina

Durante lo scorrimento verso il basso, i controlli del browser (si pensi ad esempio all’area contenente la barra di navigazione) si ritirano progressivamente per lasciare più spazio al sito. La pagina e la barra superiore appartengono però a superfici differenti e devono muoversi in modo sincronizzato: in precedenza, il main thread partecipava a ogni fotogramma di questa animazione.

La soluzione denominata Browser controls in Viz trasferisce il coordinamento al processo GPU: Viz applica l’offset di scorrimento anche alla rappresentazione grafica dei controlli senza consultare continuamente il thread principale. Se quest’ultimo incontra un’attività lunga, la barra e il contenuto possono continuare a muoversi insieme.

È un dettaglio che l’utente tende a non notare quando funziona bene: basta però che la barra e la pagina avanzino con tempi differenti perché l’intero browser sembri poco fluido, anche se il sito non ha alcuna responsabilità in termini di prestazioni.

Perché il 48% dichiarato da Google va letto con cautela

Il dato del 48% descrive la variazione della frequenza degli scorrimenti classificati come irregolari da Chrome; non significa che ogni pagina scorra il 48% più velocemente, né che il numero di fotogrammi al secondo sia aumentato della stessa percentuale. Google non presenta il risultato come un singolo benchmark ripetibile su qualsiasi telefono: si tratta dell’effetto cumulativo di più interventi valutati attraverso metriche interne ed esperimenti.

I benefici percepiti dipendono dal dispositivo, dalla versione di Android, dalla frequenza del display, dal carico della pagina e dalle funzioni che Google ha già attivato per quella configurazione. Alcune modifiche richiedono inoltre la collaborazione del sistema operativo, quindi non è detto che producano lo stesso effetto su versioni di Android molto vecchie.

Resta comunque rilevante il metodo adottato. Invece di inseguire soltanto il tempo medio di esecuzione, gli sviluppatori hanno analizzato l’intera catena temporale e rimosso progressivamente le fonti di variabilità.

Le modifiche descritte da Google, inoltre, riguardano soprattutto il browser e Android. Non eliminano ogni possibile esitazione.

Un sito può ancora compromettere lo scorrimento per via di codice JavaScript eseguito a lungo, listener touch non passivi, modifiche ripetute al layout, effetti CSS costosi, immagini sovradimensionate o elementi che richiedono continue operazioni di rasterizzazione.