Questo post è dedicato a tutti gli sviluppatori Windows Phone, a livelli più o meno professionali, per ricordare che l’arrivo di Tango potrebbe portare un’ondata di nuovi acquisti (e quindi nuovi utenti) grazie ai dispositivi di fascia bassa, e quindi sarebbe opportuno ottimizzare le vostre applicazioni seguendo alcuni consigli.

Siamo consapevoli che tutto questo non interesserà a molti utenti, ma speriamo di fare cosa gradita almeno per una piccola fetta d’utenza, seguendo la linea tracciata dal developer blog, con informazioni che vanno ad estendere le importantissime considerazioni sulle prestazioni fatte nella documentazione ufficiale presente su msdn.
Attenzione ai tempi di avvio
Non esiste cosa più fastidiosa del dover attendere a lungo per l’apertura di una applicazione, per questo Microsoft ha imposto un tempo massimo di 5 secondi entro il quale visualizzare la schermata principale come requisito fondamentale per passare la certificazione.
Fare un uso sapiente dei thread
Ogni buon programmatore in generale dovrebbe imparare ad usare i thread, perché eseguire all’interno del thread principale tutte le operazioni (specialmente l’I/O dalla memoria interna o dalla rete) blocca l’interfaccia, il che è molto fastidioso per l’utente. Su dispositivi poco potenti il mancato uso dei thread peggiora ulteriormente l’esperienza.
Quindi ogni volta che dovete effettuare operazioni lente create un nuovo thread. Inoltre se necessario inserite un barra di avanzamento indeterminata (cioè quella con i pallini che scorrono) ad alte performance (cioè eseguita anch’essa su un thread a parte) che potete trovare nel Silverlight Toolkit.
Evitare lo spreco di memoria
La RAM passa da 512 MB a 256 MB sui device di fascia bassa, quindi la nostra applicazione deve diventare più parsimoniosa nell’uso della memoria. L’applicazione non deve consumare oltre 90 MB di RAM, per garantire un minimo di multitasking e la reattività generale del telefono.
All’atto pratico bastano alcuni semplici accorgimenti:
  • Istanziate solo gli oggetti che vi servono e solo quando vi servono, facendone il dispose quando non dovete più usarli.
  • Evitate i loop nelle pagine, un tipico esempio è il tasto “home” che invece di tornare indietro crea una nuova istanza della home page (che quindi risulta istanziata due volte). Il metodo RemoveBackEntry può tornarvi molto utile.
  • Evitate di lasciare qualsiasi riferimento ad oggetti inutilizzati, perché impedireste al garbage collector di eliminarlo dalla memoria. In particolare Microsoft ricorda di stare attenti a togliere la sottoscrizione dagli event handler per gli oggetti static.

Ripensare le Live Tile
Una delle scelte che più fa rabbrividire è quella di aver inibito sui device con 256 MB di RAM una delle funzionalità chiave di Windows Phone, ovvero le Tiles animate. Se la vostra applicazione utilizza un background service per aggiornare la mattonella nel caso di dispositivi low-end verrà generata un’eccezione che causerà la morte del background agent.
L’unico tipo di “live” consentito è il polling di immagini da un server online, il che in qualche caso, con opportune strategie, può anche essere sufficiente. Il principio è togliere carico di lavoro al telefono e spostarlo nella cloud.
All’atto pratico noi programmatori dobbiamo catturare l’eccezione (anziché permettere che venga rilanciata all’esterno) e adottare quindi un diverso comportamento (polling o tile statica).
Stare attenti agli effetti grafici
Usate animazioni ed effetti grafici ottimizzati. Citavamo prima il loading con la progress bar ad alte performance, ma lo stesso discorso vale per il Tilt Effect (sempre offerto dal Silverlight Toolkit). Evitate di caricare l’app di troppe animazioni inutili, dannose per l’usabilità e pesanti per gli occhi e per le performance. Ricordo comunque che gli effetti andrebbero gestiti con le Storyboard, che scarica la computazione sulla GPU anziché sulla CPU, evitando di bloccare il thread principale.