Sembra essere nata sotto una cattiva stella la macchina virtuale posta alla base della piattaforma Android, sviluppata dall’omonima azienda, poi acquisita dalla ben più famosa Google.
Che non brilli per velocità è un fatto abbastanza noto agli addetti ai lavori, ma percepibile anche dalla normale utenza, che trova soddisfazioni su configurazioni hardware più elevate rispetto al vasto parco hardware sul quale gira.
D’altra parte Dalvik non è stata concepita per essere votata alle prestazioni, quanto piuttosto all’efficienza in termini di memoria utilizzata, grazie ad alcuni intelligenti accorgimenti (tutti i file binari generati a partire dal sorgente vengono accorpamenti in un unico eseguibile, mentre le costanti comuni a tutti i file sono “raggruppate” in modo da essere presenti una sola volta in memoria).
Infatti inizialmente, come capita quando si realizza una virtual machine (VM d’ora in poi), il progetto verteva esclusivamente sull’interpretazione, bytecode dopo bytecode, del codice dell’applicazione, con tempi d’esecuzione decisamente bassi rispetto a soluzioni similari, ma che supportavano già la cosiddetta compilazione JIT (Just-In-Time) nel codice macchina dell’architettura ospite.
In realtà Dalvik strizzava l’occhio anche alla velocità, in quanto il progettista ha pensato bene di scegliere di implementarla come VM basata sui registi anziché sullo stack, consentendo al contempo di compattare ancora meglio il codice (occupando, quindi, meno spazio).
Queste due filosofie sono da sempre contrapposte, ed è ancora oggetto di discussione quale delle due sia migliore dal punto di vista puramente prestazionale, anche se personalmente propendo per la prima (avendo anche potuto toccare con mano i risultati col mio progetto WPython).
Anche se Android è un progetto del 2003, la prima versione è stata commercializzata soltanto nel 2008 con la VM esclusivamente interpretata, mentre bisogna aspettare il 2010 per poter avere una versione di Dalvik che fa finalmente uso di un compilatore JIT, portando a un miglioramento delle prestazioni che in alcuni casi arriva quasi al 500%.
Nonostante i buoni propositi, i risultati sono ancora distanti dalla concorrenza (per non parlare poi dello stato dell’arte rappresentato dalla JDK in versione server), come provano alcuni benchmark pubblicati da Oracle un po’ di mesi dopo il rilascio di Android 2.2.
Nello specifico, è stata testata la versione “Embedded” della Java VM 1.6 della casa madre, anche se a completamento dei test sarebbe stato auspicabile veder pubblicata anche l’occupazione di memoria, visto che parliamo di dispositivi mobile (che non ne mettono a disposizione una quantità elevata), e il tempo di avvio (non si può attendere troppo tempo per far partire un’applicazione).
Di recente è apparso un progetto che ha fatto decisamente scalpore, poiché si tratta di una riscrittura di Android in C#, facendo uso di appositi strumenti che si occupano del grosso del lavoro, analizzando i file Java e convertendoli nell’equivalente in C#, a cui si è aggiunto un po’ di lavoro manuale per sistemare alcune parti.
Si tratta di XobotOS, nato da un’idea del team di Xamarin, azienda fondata da Miguel de Icaza, che si occupa del ben noto progetto Mono, alternativa open source al più famoso framework .NET.
I risultati hanno dell’incredibile: Dalvik viene letteralmente stracciata nei test che sono stati utilizzati (e messi a disposizione per chi volesse riprodurli), con XobotOS che va ben oltre le 2-3 volte più veloce del precedente con la JVM 1.6 embedded, arrivando a toccare anche le 10 volte.
Anche Mono, come la JVM, fa uso di una VM basata sullo stack, al contrario di Dalvik che è basata sui registri, ma con un compilatore JIT questo dettaglio non è molto importante, a meno che non viene dimostrato che è proprio la struttura di quest’ultima VM a porre un freno alla bontà del JIT e del codice che da esso viene generato.
Alla luce di questi risultati credo sia importante per Google ripensare pesantemente Dalvik perché, nonostante tutto il tempo che è passato, questa VM non si dimostra ancora competitiva con quanto offerto dalla concorrenza.
Sun, com’è noto, ha parecchia esperienza in questo campo, con tutto il lavoro svolto su quella di Java. Ma Xamarin? Mono è un progetto relativamente giovane, iniziato nel 2001 e la cui prima versione è stata rilasciata nel 2004. Android è un progetto iniziato nel 2003, e la cui prima versione (commerciale) è stata rilasciata nel 2008.
E’ difficile credere che Google non possa mettere a disposizione sufficienti risorse per migliorare lo stato della VM di Android, se consideriamo gli sforzi profusi in quella Javascript per il suo browser, ma soprattutto il fatto che Mono è stato portato avanti da una piccola squadra di sviluppatori.
Sarà necessario rimboccarsi le maniche, andando prima a confrontare le implementazioni della JVM e di Mono, cogliere le differenze di rilievo (quelle che incidono sulle prestazioni) rispetto a Dalvik, e cercare di aggiornare e migliorare quest’ultima in modo da rendersi finalmente competitiva.
Si potrebbe anche pensare di prendere a piene mani dalla JVM, o magari di prelevarla in blocco e adattarla a Dalvik, ma visti i recenti trascorsi con Oracle, non credo che Google abbia voglia di trovarsi con un altro contenzioso legale.
Passare a Mono / XobotOS è da escludere del tutto: troppa diversa la piattaforma, che mal si concilia con l’enorme parco software già sviluppato per Android, che non si può certo ricompilare.
Tra l’altro non è ancora chiaro il futuro di XobotOS. Nel blog si parla di mettere a disposizione degli sviluppatori Android questa nuova piattaforma, ma non è pensabile che si possa sostituire completamente la già esistente VM. Al più XobotOS potrebbe girare come applicazione “nativa”, sfruttando l’NDK di Android per avviarsi, per poi rendersi completamente indipendente da Dalvik, ma appare una complicazione inutile visto che esiste già MonoDroid.
Se il limite dovesse rivelarsi proprio la struttura di Dalvik, si potrebbe anche realizzare una nuova VM pensata appositamente per offrire prestazioni migliori. Il problema rimarrebbe il parco software installato, ma una buona soluzione di compromesso potrebbe essere quella di convertire al volo il pacchetto .dex nel nuovo formato, ed eseguire quest’ultimo.
D’altra parte è ciò che avviene già quando si genera il file .dex, che contiene tutto il codice dell’applicazione Android. Si parte dai normalissimi file Java che vengono prodotti dalla compilazione dei sorgenti, che vengono poi accorpati e il cui bytecode Java convertito infine in quello specifico di Dalvik.
In questo modo le nuove applicazioni potrebbero sfruttare al meglio la nuova VM, generando codice appositamente ottimizzato, mentre quelle vecchie potrebbero continuare a girare senza problemi tramite la già citata operazione di conversione (trasparente all’applicazione stessa).
E’ bene tenere presente anche un’altra cosa: la poca memoria a disposizione dei dispositivi mobile non è più un problema che possa fungere da deterrente nell’impiego di nuove soluzioni che potrebbero essere più esigenti da questo punto di vista. Sono motivazioni che potevano andare bene un po’ di anni fa, ma certamente non oggi, dove alcuni smartphone hanno addirittura 1GB di memoria centrale, e… l’asticella che continua ad alzarsi.
Si tratta, in ogni caso, di idee che vengono fuori dall’esperienza accumulata in questo settore, ma che potrebbero non essere applicabili allo specifico contesto, per cui sono da prendere sempre con le pinze.
Un traduttore dal bytecode .dex a linguaggio IL (Mono/.Net) in teoria dovrebbe essere relativamente semplice da realizzare, perchè non si ha a che fare con linguaggi di alto livello ma una sorta di linguaggio macchina molto elementare e RISC-like.
il progetto è molto interessante, ma sarà destinato all’oblio, perchè dubito che i grossi produttori (Samsung in primis) siano disposti a rivolgersi ad un progetto semi-hobbistico dopo tutti gli investimenti fatti (congiuntamente a Google con cui ha una partnership milionaria).
Sono tra i pochi a dire che le risorse hardware richieste da Android sono troppo elevate (ed uno dei motivi è proprio Dalvik), ma tutti se ne fregano e le tendenza ormai è quella di avere dispositivi portatili con Dual Core e Quad core, solo con lo scopo di far girare app, la cui funzione principale spesso è solo quella di collegarsi alla rete.
Si continua a criticare Symbian (solo perché così decide la moda), che invece dal punto di vista della risorse era un valido esempio da prendere in considerazione.
Infatti per le prestazioni la tendenza che si ha con Android è proprio quella di rivolgersi ad hardware sempre più potente…
@Antonio: la penso come te. Soltanto un’acquisizione di Xamarin da parte di Google potrebbe offrire sufficienti garanzie, ma Android è ormai molto diffuso così com’è ed è difficile pensare a uno stravolgimento dell’architettura.
Mah, se velocizzassero veramente la VM o incoraggiassero l’uso di codice nativo poi come farebbero a vendere i padelloni quad core?
Non bisogna dimenticare che mentre altri OS come iOS hanno come obiettivo l’espansione del loro ecosistema, l’obiettivo di Android (che al momento è praticamente in mano ai produttori di device) è vendere terminali.
In quest’ottica si spiegano molte strane lacune, dalla frammentazione, alla mancanza di aggiornamenti, alle prestazioni decenti solo sui top gamma, imo.
Credo che sia interesse anche dei produttori che il sistema abbia buone prestazioni senza richiedere hardware potente, che… consuma.
In ambito mobile è fondamentale poter risparmiare energia per far durare di più la batteria, che a meno di future soluzioni rivoluzionare rimane il grosso tallone d’Achille.
Il codice nativo è meglio lasciarlo perdere, perché lavorarci è un inferno. Java è di gran lunga più produttivo, ed è bene che continui a essere utilizzato per applicazioni che non richiedano espressamente l’NDK. Certo, C# sarebbe stato molto meglio, ma ormai è tardi…
A volte ho l’impressione che la non ottimizzazione degli OS sia quasi voluta per giustificare la rincorsa ad hardware sempre più performante, e dare quindi la possibilità alle case costruttrici di giustificare l’acquisto di nuovi terminali. Era successo per i pc, sta succedendo per gli smartphone. Non mi meraviglio che google non dedichi risorse per ottimizzare la VM. Tanto l’utilizzatore comune non ha neanche conoscenza di queste problematiche.
è da tempo che si parla anche in casa android di VM migliori sempre basate sulla Dalvik già da prima dall’introduzione del JIT però a quanto pare nn se n’è mai fatto niente!
ma il sistema realizzato da xamarin è un sistema completo com’è android e senza limitazioni (pure nel multitasking)?
inoltre per prestazioni in generale cosa si intende? più veloce a caricare i programmi, richiesta hardware minore, esecuzione più veloce?? è una cosa che si ripercuote più sul sistema o sui singoli programmi? perché ad esempio il browser di android dai vari bench nn ha nulla da invidiare a quelli della concorrenza!! il browser su xobotos riesce a fare ancora meglio?
La tesi del “è inefficiente così vendono l’hardware” non è sostenibile considerata la competizione del mercato.
Di fatto i Windows Phones (che vendono pochissimo) sono più reattivi dei prodotti Android con hw superiore.
Ma soprattutto, con l’iPhone in circolazione che continua a crescere non credo che Samsung (e cito perché è l’unica che con Android abbia fatto i soldi, tutti gli altri manufacturer non hanno bilanci così buoni) abbia voglia di dover vendere prodotti con hardware “sovradimensionato” per fare quello che fa già la concorrenza. Soprattutto in fascia alta (e l’ultimo keynote a Londra dimostra la volontà di volersi confrontare direttamente con il Melafonino). Il prezzo si scontra con le valutazioni del mercato, se devi spendere di più per dare la stessa esperienza d’uso non è un vantaggio, anzi.
@Dom: ti capisco, ormai si tende a non ottimizzare più di tanto. Ma almeno la virtual machine, che è l’elemento più importante di una piattaforma che ne fa uso, dovrebbe essere accuratamente ottimizzata.
Poi se i programmi che ci girano sopra non lo sono, amen. Rimane responsabilità dei singoli programmatori.
Ma se la VM non è ottimizzata, ne risentono TUTTE le applicazioni, e questo è un danno di gran lunga maggiore.
@zephyr83: A livello prestazionale sembra che XobotOS sia di gran lunga superiore a Dalvik.
Inoltre ne è un sostituito completo (infatti, come dicevo, il codice di Xobots è generato direttamente da quello Java di Dalvik, con qualche adattamento manuale).
Al momento non ci sono dati sul consumo delle risorse (memoria) né sui tempi di startup delle applicazioni, come dicevo nell’articolo.
zephyr credo che un applicativo importante come il browser sia sicuramente scritto in codice nativo per cui Dalvik o no non subirà differenze prestazionali.
E’ molto probabile. Concordo anche sull’altro commento che hai scritto.
@Davide io non stavo affermando che l’ottimizzazione è attivamente impedita dai produttori, così come i produttori non frammentano apposta l’ecosistema per vendere più terminali (dato che è evidente che a lungo termine questo danneggia la percezione di Android).
La mia era una semplice constatazione del fatto che in Android le scelte di standardizzazzione, ottimizzazione e coerenza sfortunatamente vengono dopo altre mille considerazioni di mercato, e che quindi è normale aspettarsi certi problemi.
Che poi appunto, vanno a mordere le stesse aziende che trascurano questi aspetti ragionando come manufacturers degli anni 2000 (puntando tutto sui volumi), concentrandosi sui terminali di fascia bassa pieni di crapware e subito abbandonati… poi certo, sono sicuro che dà fastidio anche a Samsung che per andare vagamente quanto l’iphone 4S, lo SIII debba essere 4 volte più potente.
in linea di massima sono daccordo con te, cioè “su un dispositivo mobile che centra su una macchina virtuale per far girare il 90% della robba, quest’ultima dovrebbe essere iper ottimizzata”
la cosa pero che mi convince poco sono i benchmark, partendo dal presupposto che sono nettamente di parte: oracle dimostra che oracle jvm è meglio di dalvik, e i tizi di mono dicono che mono è meglio.
partendo dal fatto che i test non sono oggettivi assumo che ogni dato non specificatamente detto va contro la tesi che vogliono raggiungere, quindi tempi di startup, memoria occupata e non che altro li condidero fondamentali per avere un giudizio
inoltre google ha mai dato una risposta a queste obiezioni?
PS scusa la pignoleria
Mi sembrano osservazioni legittime, non pignoleria. ;)
Su memoria e startup, come detto, non ho trovato nulla, e sono aspetti ugualmente interessanti da considerare (la memoria un po’ meno, per quel che ho scritto: nell’ultimo periodo abbonda).
Risposte di Google non ne ho lette. Se le avessi trovate, avrei scritto un articolo più completo, o comunque le avrei riportate.
Anzi, colgo l’invito a postare qualche link se qualcuno ne ha, perché, penso si sia capito, è un argomento che m’interessa particolarmente.
Una cosa: riguardo ai test di Oracle, è stato fatto uso di alcune suite di benchmark molto note e apprezzate.
Sono meno interessanti quelli di Xamarin, ma testano comunque campi noti e utilizzati in ambito informatico.
Android Browser è basato su Webkit che è scritto in C++, quindi va direttamente eseguito dalla CPU in linguaggio macchina.
E ne eredita pure i memory leak, allora. O:-)
se da una parte i dati che mancano mi fanno sospettare della conclusione a cui sono giunti…
dall’altro il totale silenzio da parte di google mi fa sospettare che forse non sanno cosa rispondere
PS in ogni caso continuo a considerare la piattaforma android la migliore tra le piattaforme mobile presenti oggi
PS2 la cosa che non mi è chiara è cosa sia esattamente “Java SE Embedded” cioè sarebbe il java mobile edition? cioè per capirsi il java presente nei dispositivi symbian?
No, la J2ME è un’altra cosa. Questa sembra essere una versione “ridotta” della normale JSE.
Per quanto riguarda i dati, beh, per lo meno sulle prestazioni non vedo cosa ci sarebbe da sospettare. In entrambi i casi sono state descritte le modalità di esecuzione dei test, e Xamarin mette a disposizione persino tutti i sorgenti su Git Hub, quindi chiunque può cercare di riprodurli e verificare come stiano le cose. Il silenzio di Google, a mio avviso, è eloquente.
P.S. Che Android sia la miglior piattaforma mobile è ampiamente opinabile, ma quest’articolo parla d’altro e non vorrei che, al solito, si deragliasse, quindi chiudiamo qui l’OT, cortesemente.
@Davide Costantini
Su windows phone hai ragione però è più limitato di android (soprattutto per quanto riguarda il multitasking), ha già l’accelerazione via hardware dell’interfaccia (con android arrivata scandalosamente solo con ICS….a dire il vero con honeycomb) e a quanto pare l’uso di memoria RAM sembra abbastanza abbondante (vedi problemi che ha il lumia 610 con diverse applicazioni).
sempre stato convinto che WP sia scritto meglio di android però difficile valutare quanto le prestazioni dipendano effettivamente da un VM più prestante (alla fine anche WP usa una VM) e quanto dalle “limitazioni” per questo sarebbe stato bello avere riscontri riguardo a xobotos, quanto è completo il sistema e come gestisce memoria e processi!
Il discorso è molto semplice… Java deve morire! Viva C#!
@zephyr83: se così fosse, tutti i terminali Windows Phone dovrebbero avere problemi, non credi?
Comunque stiamo nuovamente deragliando dal topic, che parla di tutt’altro…
Per tornare in tema, se i test effettuati con XobotOS dovessero essere confermati con altre tipologie di codice/applicazioni (perché su ciò che è stato fatto chiunque può verificare la bontà dei risultati ottenuti), il distacco da Dalvik sarebbe abissale, e Google dovrebbe seriamente pensare a rimetter mano alla sua virtual machine.
Stiamo parlando del cuore della piattaforma. Almeno questa dovrebbe essere ottimizzata il più possibile.
@Cesare Di Mauro
In che senso tutti i terminali WP dovrebbero avere problemi? che problemi? quelli di ram ce li ha solo il lumia 610 perché è l’unico con 256 MB! Se ti riferisci ai “problemi” di android bhe il discorso è diverso essendo differente il sistema operativo (multitasking limitato e compagnia bella).
Cmq è da tempo che si parla di Dalvik migliorate, già da prima di froyo eppure tutto tace ancora! O a quelli di google in fondo va bene così (mi sembra strano ma neanche più di tano), oppure prima di fare altri passi grossi nei confronti della VM stanno aspettando la fine delle diatribe con Oracle :D
In ogni caso concordo che su un sistema basato su virtual machine, quest’ultima deve esser la migliore possibile!
Il problema è: riuscirà Google a migliorare le prestazioni della VM senza perdere la compatibilità con tutte le applicazioni sviluppate finora?
Alla fine chi glielo fa fare a Google di rischiare, il trend dei “telefoninari” è di cambiare telefono ogni 18 mesi, l’hardware continua a migliorare le prestazioni ogni 6 mesi, per cui ci ritroviamo in una situazione simile a quella dei PC nella seconda metà degli anni 90: ottimizzazione software zero, tanto basta cambiare processore o aumentare la RAM..
Ho sentito molto parlare di questo famoso android on c#, però non mi è affatto chiaro cos’è che avrebbero fatto. Si parla di android in c# ma dai file che trovo su git mi pare che sia un porto di mono su android piuttosto.
Il kernel ovviamente non c’entra, e quindi che rimane? Le core libraries sono riscritte in c#? E le varie librerie webkit, opengl, sgl, media framework, ecc…?
Google ha alcuni reparti che fanno faville, e altri che invece produco codice a martellate.
Il reparto Android è uno di questi.
Per ottimizzare la Dalvik hanno assunto un tipo geniale, un tizio che si è costruito una CPU con componenti standard, poi si è messo a scrivere un compilatore e pure un OS per la sua CPU tutto fatto in casa. (Magic 1 Homebrew CPU).
Questo tizio ha scritto il JIT compiler di Dalvik, introdotto con Android 2.2.
Ora, non so cosa faccia sto tipo, se lavora ancora per Google oppure no, fatto sta che secondo i raffazzonati “standard di qualità” Google, la Dalvik è già allo stato dell’arte perchè sono anni che non la ottimizzano più.
A loro interessa monetizzare, tutto ciò che l’utente non vede non è essenziale, tutto ciò che gli inserzionisti non chiedono (ricordatevi che il grosso dei guadagni di google deriva da AdSense) non è necessario.
Beh, lo staff di Android l’ha acquisito. Forse è questo il motivo della disparità col resto… :P
@zephyr83: se il problema è la ram dimezzata, ti sei già risposto da solo. Non è certo un problema di Windows Phone. Comunque finiamola con questo OT che non c’entra nulla con l’articolo.
@Giacomo: ti assicuro che si può benissimo stravolgere la virtual machine senza compromettere la retrocompatibilità col codice già scritto (a meno che non dipenda da bug specifici della VM; ma questo esula dalla nozione di “contratto” che la VM offre alle applicazioni).
@alex: Mono per Android è già disponibile, e si chiama MonoDroid. XobotOS è completamente diverso.
Android è costituito da Linux, driver, librerie, ecc., a cui è stata aggiunta una virtual machine che macina un particolare bytecode che deriva dalla compilazione di sorgenti scritti in Java. La stessa VM mette a disposizione un framework, scritto per lo più in Java, che espone alle applicazioni affinché ne facciano uso.
Ecco, con XobotOS è stata convertita interamente in C# tutta la parte di Android scritta in Java. Si parla di circa 1 milione di codice. E ovviamente al posto di Dalvik il tutto gira sulla VM di Mono.
Spero sia chiaro adesso, ma se hai dubbi, chiedi pure.
Giusto per completare quanto detto da Cesare con qualche esempio:
Sono in Java (e quindi dipendono da Dalvik):
– Il 90% dell’interfaccia grafica
– Applicazioni di base come Launcher, Calendario, Email, Gestore pacchetti, Menu di sistema, Sistema di notifiche
– Sistema di comunicazione tra le applicazioni per mezzo degli Intent e Intent Filter (praticamente il cuore di Android)
mentre sono scritti in codice nativo:
– Webkit, di conseguenza il 90% del codice del browser (sono in Java solo le parti di contorno, come menu, preferiti e settaggi)
– Codec audio e video
– librerie di codifica / decodifica / compressione / decompressione
– Kernel e drivers
– strato a basso livello dell’interfaccia grafica (C / OpenGL)
E’ chiaro. In java sono scritte le core libraries e i componenti dell’application framework. Oltre ad alcune applicazioni, ma questo non è molto interessante ai fini del porting.
E ovviamente il tutto è compilato/jit tramite dalvik.
Dunque quelli di mono hanno sostituito tutti questi componenti e lasciato il resto inalterato.
Se è così non dovrebbero esserci problemi a far girare xobotos su x86.
Senza dubbio. Mono gira già su x86, e Android pure… ;)
Molto interessante la discussione.
Mi piacciono i tuoi contenuti Antonio Barba. Vorrei aggiungere che l’interesse di Google con Android è voler raggiungere la più elevata utenza possibile proprio per non perdere il mercato delle ricerche (26 miliardi di dollari sui 39 complessivi, tutti di AdWords… altri 11 sono di adsense o meglio AdWords su rete display).
Quindi Android per natura non può essere un OS che punta alla qualità assoluta. Ovvio che i ragazzi di Google cercano di fare il lavoro migliore possibile, ma ogni terminale in più per loro è un vantaggio e infatti ora si contano circa 3900 diversi device Android.
Per gli sviluppatori è un suicidio. Avrebbero dovuto vincolare ad alcuni set di risoluzioni standard, lavorare con i manufacturer per avere al day 0 i driver per tutte le piattaforme pronti, curare gli update. Ma niente di tutto ciò.
Non gli importa perché loro vendono pubblicità. E tra l’altro dal mobile si stima vengano solo fra gli 1.3 e gli 1.9 miliardi di fatturato (stime di Asymco), tutto pubblicitario.
L’unico che fa i soldi con Android è Samsung. Oltre a Apple e Samsung gli altri produttori di smartphone stanno tutti messi o così così o addirittura proprio male.
Per questo sono convinto che Samsung potrebbe entro 1 o 2 anni presentare il proprio fork. Il lancio del Galaxy S 3 super pompato dimostra che non vogliono fare i secondi ad Apple.
Scusate l’OT, ma il modello di business di Google si riflette sul modello di sviluppo di Android e le sue inefficienze.
Spiego meglio un punto: per Google non è importante la qualità assoluta ma la diffusione massiva. Per questo in alcuni aspetti Android non potrà mai essere all’altezza di iOS per i prodotti di fascia alta. Primo fra tutti il problema è negli aggiornamenti (ricordo che il vetusto 3GS viene ancora aggiornato dalla Apple).
Per questo Samsung potrebbe rompersi le scatole anche se loro hanno dimostrato di non comportarsi bene sul discorso aggiornamenti.
Chiuso OT.
La relativa inefficienza di Dalvik si nota anche dal fatto che ICS fatto girare su un Desire con processore a 1GHz e 512MB di RAM non è particolarmente più lento che sul Galaxy Nexus con il doppio di RAM e dual-core a 1.2GHz.
In realtà si notano molte differenze usando le stesse applicazioni sui due dispositivi, ma di certo le prestazioni non aumentano linearmente “con l’hardware”.
Dal mio punto di vista di sviluppatore amatoriale, credo che una nuova VM sia d’obbligo, anche se costringe ad avere due versioni delle app. Tanto l’esperienza di sviluppo è già così pietosa che non farebbe molta differenza :D
@Dario: una nuova VM potrebbe tranquillamente* continuare a lavorare con il bytecode attuale. Cambia l’implementazione ma non l’interfaccia, altrimenti che cosa ce l’hanno messa a fare una VM? Il vantaggio rispetto ad una CPU di silicio è proprio quello! :)
*: tranne nel caso in cui si ritenesse indispensabile la rottura della compatibilità per eliminare funzioni ridondanti e/o sostituire degli opcode con altri più efficienti.
Comunque, da sviluppatore Android professionista (se non si fosse ancora capito), mi interessa maggiormente una stabilità delle API e minore frammentazione. POI guardo le prestazioni del codice, anche perchè sviluppo una tipologia di apps in cui la velocità di calcolo non è rilevante ai fini dell’utilizzo, che poi rappresenta il 90% del mercato reale di apps per telefoni.
Non mi sorprenderebbe per niente se il team di XOBOTOS venga assunto in blocco da Google.
Loro hanno detto che il loro progetto era solo un’esercizio di stile, ma mi sa che si son fatti ben notare :)