android funziona(va) usando il modello di java.
I programmi sono scritti usando linguaggi di programmazione, questi linguaggi però servono per fornire uno strumento comodo agli sviluppatori di scrivere programmi, ma per essere eseguiti devono essere convertiti in linguaggio macchina da quel che si chiama un compilatore, che legge il sorgente e lo trasforma in una serie di istruzioni hardware da passare al processore. Questo vuol dire che mentre i sorgenti sono universali, il codice compilato dipende da che processore usi. Ed è il motivo per il quale ci sono le versioni diverse delle applicazioni per 32 e 64 bit ad esempio, le versioni 64 bit sono compilate per processori a 64 bit che hanno un set di istruzioni diverso da quello a 32.
Questa roba ha 2 limiti: 1, devi compilare il tuo programma in maniera diversa per ogni sistema operativo e per ogni versione del processore, 2 intuitivamente un i7 ha delle features che un pentium 1 non ha, e benchè ci sia retrocompatibilità tra tutti i processori (x86 in questo caso) un i7 offre, ad esempio, tutta una serie di istruzioni aggiuntive che permettono ad un compilatore che sa di dover compilare un programma solo per un i7 di ottimizzare il codice macchina in maniera molto efficace. Ma se devo distribuire il mio programma non posso distribuire 100 versioni ognuna per un processore diverso.
.net e java hanno rivoluzionato questo modello di funzionamento. .net lo vediamo nella prossima puntata.
In java tu non compili il tuo codice in codice macchina, ma lo compili in bytecode che è una via di mezzo. Questo bytecode viene poi eseguito su una jvm, una java virtual machine, regolarmente installata sul tuo pc. L'idea è sostanzialmente di distribuire solo le jvm diverse per ogni architettura, e poi ogni programma viene eseguito dalla jvm che traduce al volo il bytecode e in codice macchina. I programmi java non si installano e non vanno compilati per diverse piattaforme, si prendono e si eseguono, sia che tu sia su windows, linux, osx, usi intel o arm.
Ora, dato che stiamo parlando di mettere un layer tra l'hardware e il tuo programma, le prime jvm erano lente abbestia (creavano tanto overhead), motivo per cui molti programmatori vecchi odiano/odiavano java.
Le jvm moderne invece hanno ottime performance e fanno due cose, O eseguono direttamente il bytecode emulando un processore traducendo come detto al volo bytecode in linguaggio macchina, oppure compilano al volo il codice in maniera ottimizzata per l'hw sottostante e lo fanno eseguire direttamente dall'hw. La jvm decide in maniera automatica quando fare una cosa o un'altra, a seconda di quanto invochi parti del programma.
Mo, android è basato su questo modello, ma in art han cambiato le cose. Hanno eliminato la parte di interpretazione a runtime del bytecode, e han forzato la compilazione del bytecode in linguaggio macchina specifico per ogni particolare hardware nel momento dell'installazione. Quindi se in dvstocazzo tu salvavi del bytecode, mo ti scarichi il bytecode dallo store e art te lo compila in codice macchina. Questo porta a dei vantaggi nelle performance (mentre sarà più lento installare le app, anche se parliamo di roba impercettibile), ma è un cambiamento enorme.
