Windows Phone e iOS più fluidi di Android: caccia ai motivi

Perché l'interfaccia di Android non è fluida quanto quella di iOS e Windows Phone? Una domanda che molti si saranno fatti in questi anni e su cui si discute in particolar modo in questi giorni. Ne hanno parlato Dianne Hackborn, Android Framework Engineer, e Andrew Munn, Software Engineer.

Tra i due post il più specifico è quello della Hackborn, che ricorda come Android storicamente usi la modalità software per renderizzare i contenuti di ogni finestra. Nell'interfaccia standard ci sono diversi elementi come la barra di stato, lo sfondo, il launcher in alto e il menù.

"Se una delle finestre aggiorna il proprio contenuto, per esempio quando viene evidenziata una voce, prima della versione 3.0 era il software a riprodurre i nuovi contenuti in quella finestra, ma nessuna delle altre finestre veniva ridisegnata e la ricomposizione di queste era fatta in hardware (con la GPU). Allo stesso modo, ogni movimento delle finestre, come il menù a scomparsa, è tutto gestito dall'hardware".

Per avere una fluidità elevata l'ideale sarebbe far lavorare tutto a 60 frame al secondo, non sempre ci si riesce perché molto dipende dal numero di pixel dello schermo e dalla velocità della CPU. "L'accelerazione hardware totale all'interno di una finestra è stata aggiunta con Android 3.0. […] Il cambiamento principale in Android 4.0 fa sì che le applicazioni rivolte a tale versione avranno l'accelerazione hardware abilitata di default", spiega la Hackborn.

L'accelerazione hardware però non è sempre la panacea di tutti i mali. "Per esempio i driver di PowerVR di dispositivi come Nexus S e Galaxy Nexus usano l'OpenGL con un processo che richiede 8 MB di RAM. Dato che l'overhead del nostro processo è circa 2 MB, la richiesta è elevata. Questa RAM è tolta ad altri compiti, come il numero di processi in background che si possono far funzionare e rallentando aspetti come il passaggio tra le app".

Secondo l'ingegnere Andrew Munn, che ha lavorato nel team Android e che da gennaio passerà in quello Windows Phone - anche se sostiene di essere un grande fan del sistema operativo di Google - tutto il rendering dell'interfaccia in iOS è affidato a un thread dedicato con priorità in tempo reale, mentre Android segue il tradizionale modello PC in cui il rendering avviene nel thread principale con priorità normale. Questo mina alla radice la possibilità di avere un sistema fluido in ogni situazione.

"Potete vederlo voi stessi. Prendete un iPad o un iPhone e aprite Safari. Iniziate a caricare una pagina complessa come Facebook. A metà del caricamento mettete il dito sullo schermo e muovetelo. Tutto il rendering si bloccherà istantaneamente. Il sito non si caricherà fino a quando non toglierete il dito. Questo perché il thread dell'UI intercetta tutti gli eventi e renderizza l'UI con priorità in tempo reale".

"Se ripetete questo test in Android noterete che il browser proverà sia ad animare la pagine che a renderizzare l'HTML, e a fare un buon lavoro con entrambi. Su Android, questo è un caso in cui un processore dual-core efficiente aiuta, ed è per questo che il Galaxy S II è famoso per la sua fluidità". Da notare che Munn è stato accusato di aver semplificato troppo la spiegazione sul fronte iOS e in effetti anche lui ammette che può essere andata così, ma lo scopo era farsi capire e fondamentalmente c'è riuscito.

Munn ritiene inoltre che un altro problema sia rappresentato dalla garbage collection. "Usando l'applicazione delle foto in Honeycomb o ICS potreste esservi chiesti come mai il frame rate è così basso. Il frame rate è limitato a 30 FPS". Far girare il tutto a 60 FPS porterebbe ad avere notevoli rallentamenti casuali dovuti alla garbage collection, "per cui limitare il frame rate a 30 FPS risolve il problema".

Munn punta il dito anche contro Tegra 2, disponibile in diversi prodotti Android, che ha problemi di bandwidth di memoria e non supporta le istruzioni NEON, l'equivalente delle SSE di Intel pensate per accelerare i calcoli multimediali. Infine la macchina virtuale Dalvik non è così matura quanto quella desktop e Java ha problemi noti con le prestazioni delle interfacce grafiche su desktop. Gran parte dei problemi nell'implementazione Dalvik non sono presenti, ma alcuni sì.

Come risolvere il tutto? Le future versioni di Android mitigheranno tanti problemi, ma probabilmente non si potrà agire su tutto, a meno che non s'intervenga alla radice. Questo però potrebbe voler dire scrivere tutte le applicazioni per il nuovo framework, oppure integrare il supporto alla modalità precedente. Un lavoro complesso e con insidie, che potrebbe avere ripercussioni sullo sviluppo delle altre caratteristiche del sistema operativo. Che cosa farà Google? E quanti di voi effettivamente notano nell'interfaccia grafica di Android rallentamenti rispetto ad iOS e Windows Phone?