In questo articolo parleremo di sviluppo software su Ultrabook, dei modelli e delle best-pratice tipiche delle applicazioni mobili, considerando le caratteristiche dei dispositivi, i consumi energetici e l'uso di sensori e strumentazione integrata.
Applicazioni mobility-ready
Il concetto di mobility, ovvero la capacità di fruire di tecnologia (hardware/software) in mobilità, porta con sé il problema del consumo energetico. Esaminando i dispositivi mobili oggi in commercio possiamo definire un set di fattori importanti, parte del concetto stesso di dispositivi "mobili":
- Dimensione: un laptop è detto "computer portatile", un tablet e uno smartphone sono ancora più "portatili" per le loro ridotte dimensioni.
- Connettività: il dispositivo, per abilitare scenari tipici di lavoro o divertimento in mobilità, deve fornire la possibilità di collegarsi ad internet.
- Durata della batteria: il fattore più importante di tutti, sul quale possono incidere la ricerca scientifica e l'impegno dei manufacturer, ma anche alcune buone pratiche di programmazione
È ovvio ribadire che senza una sostenibilità energetica di almeno 1 giornata, ogni smartphone sarebbe pressochè inutile, rendendo vani anche gli interessanti dispositivi e le tecnologie incluse in esso.
Questo problema, sentito dapprima nel mercato dei telefoni, si è poi fatto sentire nel mondo dei laptop, cercando di progettare architetture (a partire, ovviamente, dal consumo dei processori) che fossero Power-Efficient.
Power-Efficiency e complessità computazionale
Proviamo a semplificare utilizzando unità di misura volutamente unitarie: supponiamo che un ciclo CPU consumi 1Watt e che dobbiamo creare un software per cercare un valore in un vettore di 100 elementi, scoprirei che il mio consumo potrebbe variare da:
- Circa 100Watt, se scriviamo un ciclo che esamini tutti gli elementi che, malauguratamente, trovi l'elemento che cerchiamo solo alla fine. Questo algoritmo ha complessità N, da cui il massimo consumo di CPU e, conseguentemente, di batteria.
- Circa 7Watt, nel caso in cui implementiamo un'algoritmo di ricerca binaria, che ha complessità log2(N), con conseguente minimo consumo di CPU e batteria per un problema del genere.
Questo esempio, sebbene chiaramente provocatorio (l'incidenza di una ottimizzazione del genere è comunque trascurabile), aiuta a spiegare che il problema del consumo energetico è responsabilità del software che scriviamo. I produttori di hardware ci possono sì aiutare con batterie sempre più longeve ed efficenti e architetture hardware ottimizzate, ma se il software non è scritto bene, ne risulta uno sforzo vano.
Processi in background
Molto spesso ci troviamo ad affrontare problemi che coinvolgono processi di background. In prima istanza, dobbiamo essere consapevoli che i processi in background sono il problema numero uno del consumo energetico di un dispositivo.
Ad esempio, Windows Phone di Microsoft è un esempio di dispositivo che, avendo recepito i feedback del suo predecessore Windows Mobile, elimina il concetto di processo in background, implementando un sistema di sospensione/ripristino out-of-memory per il multi-tasking. I tablet moderni cercano di fare lo stesso, perchè il principio è sempre valido.
Connected standby
Chi abbia mai sviluppato applicazioni per Smarphone si è chiesto almeno una volta come mai un processo custom in background possa, in poche ore o addirittura minuti, consumare tutta la batteria quando, ad esempio, la perenne connessione GSM in ascolto continuo sul canale impatti molto di meno.
Non è difficile infatti immaginare una applicazione di monitoring in background che esaurisca le risorse energetiche solamente facendo operazioni di I/O sulla memoria interna. Invece la connessione GSM, che richiede l'utilizzo di una antenna (da sempre causa di importanti consumi), sembra essere più "leggera".
Questo principio è possibile implementando alcune operazioni a livello di hardware e poi ad un livello molto basso del sistema operativo. Tanto per banalizzare, è un pò come se un telefono fosse un palazzo e l'"ufficio" di gestione GSM si trovasse al primo piano, mentre l'ufficio di monitoraggio si trovasse all'ultimo piano. Le "persone" dell'ufficio relativo alle funzioni GSM per arrivare in strada farebbero meno fatica (solo un piano di scale) e consumerebbero meno energia, mentre le persone dell'ultimo piano consumerebbero inevitabilmente di più.
Nella storia dei telefoni, le funzioni di chiamata sono state "spostate" verso il basso mano mano che la tecnologia avanzava, rendendo il processo meno costoso in termini di risorse.
Il connected stand-by sfrutta le stesse dinamiche, per mantenere sempre attivi alcuni processi sul sistema ospitante. Questo compromesso hardware-software abilita nuovi scenari in cui il dispositivo, Ultrabook compreso, può entrare in connected stand-by ad un consumo ridottissimo, pur mantenendo "in attivo" alcune funzioni, come ad esempio la connessione dati.
Software orientato agli eventi
Un software che debba leggere da uno stream potrebbe implementare questo banale (e molto comune) algoritmo:
- Leggo un elemento dal buffer dello stream
- Se l'elemento è diverso da null (esiste un elemento) lancio il processing
- In ogni caso mi metto in sleep di N millisecondi
- Torno al punto 1
L'algoritmo, come il precedente relativo alla ricerca, non è ottimale: sebbene esistano strutture in quasi ogni sistema operativo per operare in ottica di notifica (piuttosto che di polling), stiamo interrogando ogni N millisecondi un buffer, anche se il dato potrebbe non essere disponibile per un timeframe decisamente maggiore.
La soluzione è agire con un modello event-based, in cui lo stream o un oggetto collegato notifichi l'applicazione al momento in cui venisse materializzato un dato nel buffer.
Utilizzo dei Timer nelle applicazioni
L'istituzione del Timer nelle applicazioni è ormai consolidata quanto abusata. Il timer serve oggi sia per regolare le dinamiche di una qualsiasi azione che faccia uso del polling, sia per impostare processi e flussi in modo che vengano eseguiti ad ogni iterazione di interesse.
È utile tuttavia approfondire come funzionano i timer di sistema. In Windows il timer di default del sistema operativo è tarato per scattare ogni 15,6ms. Questo fa sì che se noi impostassimo un timer a 50ms, esso in realtà scatterebbe alle quarta iterazione, ovvero al 62,4 millisecondo. Questo comportamento, nella maggior parte dei casi, non è rilevante nelle applicazioni consumer, lo è invece nelle applicazioni real-time. A tal proposito Windows mette a disposizione una API di sistema per modificare la durata di default del timer, portandola eventualmente fino a 1ms. Questa pratica tuttavia impatta molto sul consumo energetico ed è, per questo, motivo di attenzione.
Una delle maggiori novità in termini di Timer, introdotta in Windows 7, è il cosiddetto Timer Coalescing: una idea per cui un processo che si voglia avvalere di un timer, possa specificare quanta "tolleranza" possa esserci nel farlo scattare. In questo modo, se un processo dichiara un timer di 100ms con tolleranza 10ms, il sistema operativo potrà cercare di raggruppare i vari eventi di tick in gruppi di wake-up, ottimizzando così il consumo di risorse.
Strumenti per il monitoraggio
Intel consiglia, durante lo sviluppo software, di tenere sempre a portata di mano alcuni strumenti software in grado di farci capire quanto impatti il consumo energetico delle nostre applicazioni. Per fare ciò esistono:
I tre tool analizzano, sotto diversi aspetti, il consumo energetico del nostro sistema/applicazione.
Una serie di domande da porsi
Intel, avendo la fortuna di costruire fisicamente i sistemi utilizzati da mezzo mondo, ha ben chiaro quali siano le ottimizzazioni possibili sui suoi sistemi e ci esorta a porci alcune domande, tra cui:
- Il nostro software usa wait-loops?
- I polling sono efficenti, ovvero tendono a massimizzare l'intervallo di inattività?
- Per funzioni specifiche audio/video/media, si utilizzano librerie di più basso livello , se possibile?
- E le best-practice per la grafica?
- Gli algoritmi sono efficenti?
- L'accesso ai dati è minimizzato?
- Si usa correttamente il multi-threading per spezzare l'esecuzione sui vari core?
- Se si, i thread sono bilanciati?
Queste sono solo alcune delle domande che possano far scaturire riflessioni orientate all'ottimizzazione energetica (ed alcune sono anche ovvie), ma il principio è che, in mobilità, ogni "goccia" di energia è da salvaguardare.
Sensori: environment-based development
Anche se potrebbe sembrare un nuovo stile di sviluppo, lo sviluppo basato sull'ambiente è solo una invenzione dialettica per descrivere un ecosistema di applicazioni e strumenti di sviluppo orientati all'interazione del dispositivo con l'ambiente circostante. L'Ultrabook è il dispositivo in questione e l'ambiente circostante è un serie di fattori ambientali a cui siamo soggetti.
In un Ultrabook abbiamo la fortuna che ognuno di questi fattori abbia un corrispettivo trasduttore/attuatore, programmabile tramite API:
- Luce ambientale: l'intensità luminosa dell'ambiente circostante può essere usata per determinare le condizioni dell'ambiente. I moderni sistemi operativi utilizzano già nativamente il sensore di luminosità per attenuare/amplificare la luminosità dello schermo (in ambiente buio è preferibile uno schermo meno luminoso e viceversa). Le applicazioni che facciano uso di questo sensore per costruire interessanti tool sono tante, come ad esempio una sveglia software che, all'aumentare della luce ambientale, fino ad una certa soglia, smette di suonare.
- Rumore: un microfono integrato è un dispositivo ormai vecchio di decenni, che però può rilevare il rumore e comunicarlo all'API apposita che potrà fare le proprie valutazioni.
- Movimento/inerzia: con un accelerometro non riusciamo esattamente a stabilire un movimento (se questo viene fatto ad una velocità costante) ma possiamo tuttavia stabilire le variazioni di accelerazione che ci danno informazioni utili sulla direzione e sulla velocità. Nel momento in cui, ad esempio in un auto in moto, il dispositivo si trovasse fermo sul cruscotto, l'unico strumento per determinarne il moto sarebbe un geolocalizzatore. Un esempio di utilizzo dell'accelerometro in ambiente Ultrabook è la rilevazione di caduta.
- Posizione geografica: la geolocalizzazione oggi avviene tendenzialmente tramite GPS, cella GSM e segnali Wifi. Significa che, in presenza di un dispositivo GPS in un campo aperto, può avvenire la localizzazione precisa. In assenza di GPS la posizione può essere determinata triangolando le informazioni delle celle GSM ricevute e con gli SSID delle reti Wifi.
- Touch, gli Ultrabook con touchscreen abilitano alcuni scenari inediti: se lo schermo touch era appannaggio di Smartphone e Tablet, oggi anche un laptop può avvalersi di interfacce come quella di Windows 8.
L'elenco è ancora lungo e più sensori si integrano tra loro più si rende l'esperienza del dispositivo simile all'esperienza dell'utente che lo sta utilizzando.
L'ibrido laptop/tablet cui l'Ultrabook sta puntando è un inedito per il mercato e, sebbene siano ancora da inquadrare funzionalità per un laptop un pò azzardate, come l'accelerometro, la combinazione di elementi tipici di un laptop (la tastiera fisica integrata) con l'esperienza utente di un tablet (lo schermo touch) più una serie di must-have come la batteria e il processore i5/i7, si discosta dalla letteratura attuale, creando un fenomeno.
Riferimenti
