Android

Ottimizzare un’app per smartphone: il codice non è tutto

Abbiamo intervistato Dekel Naar, Principal Engineer in Facebook, riguardo lo sviluppo di Facebook Lite e in generale dell’approccio alle ottimizzazioni delle app per smartphone.

Tom’s: avete parlato di ottimizzazione tramite Redex e ProGuard per ottimizzare il codice. Quanto questo tipo di ottimizzazione può fare in più rispetto un ottimo programmatore “umano”?

Facebook: quello che fanno gli ottimizzatori è “capire” il modo in cui i dati vengono gestiti, togliendo quello che non è necessario, qualcosa che gli umani non possono fare. Il loro beneficio è a doppia cifra, ma è difficile dire precisamente qual è la percentuale di ottimizzazione. C’è però un limite, perché non vogliamo che il codice sia troppo ottimizzato, al punto tale da diventare di difficile interpretazione e leggibilità da parte di programmatori. Il codice deve essere tale da poter essere gestito dai vari programmatori per lo sviluppo futuro e per essere manutenuto.

Tom’s: durante la vostra presentazione vi siete concentrati sul sistema operativo Android. Parlateci di iOS, è più difficile lavorare per i dispositivi Apple ? Cosa cambia?

Facebook: dopo aver lavorato a lungo su Android, ci siamo concentrati da mesi su iOS. Bisogna tenere in considerazione il mercato, prima di tutto. I dispositivi iOS hanno interessato, per molto tempo, solo la fascia alta di mercato, dove l’ottimizzazione delle applicazioni, come stiamo facendo con Facebook Lite, è meno importante. Ultimamente gli iPhone stanno penetrando nelle fasce più basse di mercato; ad esempio gli iPhone 5 stanno praticamente sparendo da mercati come quello statunitense, per finire nel mercato filippino. C’è quindi una sorta di riciclo che porta i dispositivi high-end di qualche anno fa all’interno di fasce di prezzo e prestazioni più basse.

Per questo abbiamo capito che esiste un’opportunità per Facebook Lite anche nel mercato iOS. Abbiamo Facebook Lite praticamente pronto per i dispositivi iOS, e lo introdurremo come test in 12 o 13 nazioni. Siamo ancora nella fase di ottimizzazione. Ad esempio ci siamo concentrando sui tempi di caricamento: siamo partiti da un tempo di avvio dell’applicazione (a freddo, quindi senza dati in memoria) di sei secondi, su un iPhone di fascia media (dal 5S al 6S); non eravamo soddisfatti di questi tempi, quindi abbiamo lavorato sul modo in cui i dati vengono gestiti e caricati, e a giugno abbiamo raggiunto l’obiettivo di caricamento in meno di 4 secondi, e ora siamo arrivati a 3.7 secondi.

Tom’s: Funzionamento base di Facebook Lite che avviene sul server, non aumenta la quantità di dati da gestire ? E avete detto che i dati costano.

Facebook: Intuitivamente c’è uno scambio di dati maggiore, ma in realtà la potenza del server rispetto allo smartphone è tale che può inviare solo una quantità di dati minima. L’invio della richiesta è pochissimi dati, e anche la risposta. Esempio: per un dispositivo effettuare un’operazione significa effettuare differenti richieste e operazioni al processore, che poi risponde con un risultato, e il sistema si attiva per attivare i singoli pixel dello schermo per mostrare quel risultato. Con una richiesta al server, semplicemente si invia la richiesta e la risposta è solo di “attivare quei pixel” mostrando il risultato. Il beneficio, in questo caso, è superiore rispetto a tutto quello che servirebbe per gestire l’operazione nel client. [Ndr.] Si fa riferimento all’approccio nella programmazione, in cui si valuta il ROI della funzione; in questo caso i benefici sono maggiori rispetto l’investimento, e per questo l’approccio “cloud” secondo Facebook funziona. 

Tom’s: si parla continuamente di machine learning e intelligenza artificiale. Questo approccio può avere un ruolo anche nell’ottimizzazione delle applicazioni ?

Facebook: già usiamo il machine learning oggi. Ad esempio, quando un utente clicca una storia, in molti casi quello che vorrà farà successivamente è guardare altre storie. In questo caso implementiamo quello che chiamiamo “pre-push” cioè mentre sta guardando una storia iniziamo a scaricare i dati di quelle successive, così da migliorare la reattività. È un approccio predittivo su quello che vuole fare l’utente, funziona come il pre-fetch, per semplificare l’idea.

Tom’s: ma questo approccio richiede lo scaricamento di più dati, quindi si scontra con la politica di ottimizzazione del traffico.

Facebook: esattamente. Quello che dobbiamo trovare è sempre il giusto bilanciamento, evitando di effettuare il pre-fetch di troppi dati, ma cercando nel contempo di migliorare l’esperienza. Con Facebook Lite siamo molto conservativi sotto questo punto di vista.

Tom’s: è possibile implementare l’AI all’interno dell’applicazione, rendendola più intelligente e, ad esempio, offrire agli utenti le funzioni che hanno bisogno in base alle proprie abitudini d’uso dell’applicazione ?

Facebook: abbiamo una visione che chiamiamo “the right Lite for the right user”, che consiste nel dare all’utente solo quello che vuole, quando lo vuole e nella maniera migliore. I passi per raggiugnere questo scopo sono molto incrementali. Al momento non stiamo investendo nel Machine Learning per questo scopo, ma sviluppiamo l’App in maniera modulare. In Facebook Lite  non integriamo tutte le funzioni per evitare di far scaricare all’utente dei dati che in realtà non usa. Ma quando richiede una funzione, cliccando sull’icona che l’attiva, in quel momento diciamo all’utente che stiamo preparando la funzione, e solo in quel momento scarichiamo i dati necessari per il funzionamento.

Tom’s: quando valutate una nuova funzione cercate sempre di non appesantire l’app, o comunque di implementarla nella maniera più efficiente possibile. È mai successo che abbiate trovate una funzione così interessante, da rompere le vostre stesse regole d’implementazione ?

Facebook: seguiamo delle regole, ma non è sempre e solo matematica. A volte bisogna anche avere delle discussioni e chiedersi “cosa comporta veramente per gli utenti ?”. Ad esempio quando abbiamo implementato le “reactions”, gli utenti le hanno accolte e utilizzate così tanto che  il beneficio di questa funzione vanno ben oltre il peso in dati per la loro implementazione.

Tom’s: avete mai messo sul piatto della bilancia la nazionalità dei differenti utenti ? Ad esempio, se in Italia viene usata maggiormente una funzione riguardante le foto, mentre negli Stati Uniti lo strumento più usato è quello video, è ovvio che in termini numerici l’Italia pesa molto meno, e i “desideri” degli italiani verrebbero messi in secondo piano. Sviluppare un’app che possa offrire una differente esperienza anche in base alle differenti persone è qualcosa di fattibile ?

Facebook: come detto abbiamo la visione della “giusta app per ogni utente”, ma è difficile inserire questa variabile nello sviluppo. Facebook è un’app “mondiale” con utenti che devono essere in grado di comunicare globalmente, con gli stessi strumenti. Modificare l’app per renderla differente per le differenti nazioni sarebbe molto complicato, inoltre non è detto che tutte le persone di una nazione abbiamo gli stessi desideri. Quello che vogliamo dare è un’esperienza solida per tutte le persone del mondo.

Tom’s: rendere le applicazioni più leggere significa solo avere meno funzioni, o è possibile ottimizzare il codice al punto tale da non fare a meno di funzioni?

Facebook: noi aggiungiamo sempre più funzioni, e negli ultimi due anni abbiamo ridotto le dimensioni generali per aggiungere più funzioni. Il modo per raggiugnere questo obiettivo è implementare nuove tecnologie che permettano di diminuire la grandezza delle applicazioni. Se, ad esempio, siamo in grado – come abbiamo fatto – di ridurre le dimensioni del 15%, possiamo poi permetterci di aggiungere una funzione che pesa l’1%, rimanendo ugualmente molto efficienti.

Tom’s: pensate che questo approccio con la singola applicazione modulare è l’unico approccio da seguire, o magari separare le applicazioni, come avete fatto con Messenger, possa essere un’altra strada da intraprendere?

Facebook: non penso che ci sia una strada giusta a una sbagliata, ogni strada ha i suoi pro e contro. Pensiamo che il nostro approccio, con l’app modulare, dove se si vuole fare lo streaming del video basta cliccare su un’icona e in poco tempo verrà scaricato il pezzo di software necessario per compiere quell’azione, sia migliore rispetto un messaggio del tipo “se vuoi fare streaming di video devi scaricare l’applicazione XY dal Play Store”.  Pensiamo che la modularità abbiamo più pro rispetto ai contro.

Tom’s: avete mostrato che quando un’applicazione viene ottimizzata e pesa meno, aumenta la quantità degli utenti che la installano e usano. Esiste un punto dove questa regola non funziona più ?

Facebook: si, c’è un punto dove non ha più senso, ma non sappiamo ancora qual è. Ad oggi Facebook Lite pesa 1.2 Mb, e con ogni miglioramento vediamo degli incrementi di utenza. Più riusciamo a ridurre le dimensioni, più funzioni possiamo aggiungere, e più utenti saranno interessati. Ricordiamo inoltre che non ci stiamo concentrando solo sulla riduzione di peso, ma anche sull’incremento generale delle prestazioni.

Tom’s: la vostra opinione, il futuro è delle App, dei siti mobile o delle Progressive Web App?

Facebook: è sempre difficile avere un’opinione sul futuro. Credo che la strategia della doppia app sia vincente. Probabilmente l’approccio React Native è quello migliore, poiché permette di adattare facilmente l’applicazione ai differenti dispostivi e avere la migliore esperienza. Probabilmente per noi di Facebook ha senso creare più applicazioni, ma per altre aziende ha più senso optare per una soluzione che, con il minimo sforzo, permetta di raggiungere più persone possibili. In generale, non credo che il web offra oggi la giusta rappresentazione di quella che potrebbe essere l’evoluzione futura.