Andrew Munn è un ingegnere, oggi al lavoro sull’applicazione ufficiale di Facebook per Android, che nel 2011 ha dimostrato su Google+ perché l’interfaccia-utente del sistema operativo – a differenza delle equivalenti di iOS, Windows Phone, ecc. – “lagga”. È evidente che la valutazione di Munn sia datata, tant’è che analizzava le differenze fra Honeycomb e Ice Cream Sandwich, ed è stata molto criticata dagli altri sviluppatori. Ciò nonostante, alcuni aspetti del dibattito sono tuttora validi e ritengo sia opportuno considerarli.

Il significato del verbo “laggare”, un neologismo mutuato dalla lingua inglese, è «procedere a scatti»: lo conoscono bene i videogiocatori appassionati di First-Person Shooter (FPS) — non a caso, lo stesso acronimo di frame per second. L’occhio umano percepisce un movimento fluido attorno ai 30fps e, a frequenze superiori, elabora i movimenti a livello cerebrale… senza avvertire il passaggio tra un fotogramma e l’altro alla vista. Motivo per cui l’introduzione del 4K promette un framerate davvero elevato, con addirittura 120fps.

Perché Android “lagga” e gli altri sistemi operativi, invece, no? Partiamo dal presupposto che – rispetto alla versione 2.x – il problema è molto relativo, se non già risolto del tutto. Honeycomb ha introdotto l’accelerazione hardware dell’interfaccia-utente, attestando le animazioni di Android sui 60fps. Le ragioni per cui la User Interface (UI) potrebbe ancora subire un rallentamento, secondo Munn, derivano dalla gestione dei processi. Google non eseguirebbe l’interfaccia in tempo reale, ma in thread a una priorità inferiore.

La priorità dei processi determina la successione delle operazioni computate, facendo scendere il framerate a 30fps e mostrando delle animazioni meno fluide. La teoria che Munn voleva confutare – senza riuscirci granché – riguarda il fatto che i problemi di Android, laddove esistenti, derivino da Dalvik VM. Avevo già proposto una panoramica delle caratteristiche del sistema operativo, omettendo di specificare che Java non è proprio un linguaggio “nativo” quanto Objective-C e l’esecuzione del bytecode può produrre quegli scatti.

Una piccola precisazione. Il bytecode è un codice portabile, tipico – ma non esclusivo – delle Virtual Machine (VM) basate su Java, mentre il machine code di Objective-C s’avvicina maggiormente alle caratteristiche degli elaboratori elettronici. Significa che l’interpretazione del secondo è, in genere, più veloce: il progresso della tecnologia e l’adozione delle estensioni NEON su ARM hanno limitato il gap, però alcune app potrebbero tuttora “laggare”. È lo sviluppatore a determinarne la fluidità, sulla base dei propri sorgenti.

Insomma, oggi è difficile che la UI di Android in sé “lagghi”… ma alcune applicazioni – non ottimizzate adeguatamente o eseguite su device più datati – potrebbero comunque scendere sotto i 30fps. Io non sono d’accordo con Munn e ritengo che larga parte del problema derivi proprio da Dalvik VM, quindi dal bytecode di Java. La priorità dei processi c’entra fino a un certo punto, specie perché negli ultimi due anni la gestione è stata ridefinita e migliorata da Google. Potendo scegliere, avrei preferito un sistema con Objective-C.

Photo Credit: Lai Ryanne via Compfight (CC)