ART è pronto a sostituire Dalvik? Sì, secondo un commit nell’AOSP

1 febbraio 201460 commenti

Una delle novità presenti in Android 4.4 Kit Kat, seppur solo per gli sviluppatori, è il runtime compiler ART, che, secondo un recente commit nell'AOSP, questa è pronta a sostituire Dalvik.


Per chi non ha idea di cosa stiamo parlando, “runtime” significa:

il termine runtime o run-time (spesso reso in italiano come tempo di esecuzione) indica il momento in cui un programma per computer viene eseguito – fonte Wikipedia

Da KitKat, Google ha dato la possibilità agli sviluppatori di testare il nuovo runtime compiler ART, che andrebbe a sostituire quello di default, Dalvik. Perchè ART dovrebbe essere meglio di Dalvik? ART precompila (procedimento AOT, Ahead-Of-Time) in precedenza le applicazioni, portando, almeno in teoria, una serie di vantaggi, come una migliore durata della batteria e una maggiore velocità di tutto il sistema operativo. Per ulteriori informazioni su Dalvik e ART, leggete questo nostro precedente articolo.

Sebbene fossimo convinti che prima che Dalvik fosse sostituito sarebbe passato ancora molto tempo, un nuovo commit nell’Android Open Source Project (AOSP) sembra smentirci. Questo, infatti, sarebbe un forte indizio che ART potrebbe diventare il runtime di default della prossima versione di Android.

Il cambio nel codice è davvero semplice: viene impostato ART come default. Dalvik, ovviamente, non verrà abbandonato di punto in bianco, ma diciamo che potrebbe avere i giorni contati.

Ci teniamo ad avvisarvi, tuttavia, che sebbene ora questo cambio di configurazione faccia parte dell’AOSP, non significa che arriverà presto. Anzi, è anche possibile che questo verrà cambiato nuovamente in futuro.

Diciamo che, però, è un importante passo per ART, una prima pietra miliare.

Loading...
  • Walter

    Comunque, ho iniziato ad usare ART da poco, e devo dire che un discreto giovamento nelle performance e nella durata della batteria l’ho notato. Niente di trascendentale, non pensate che si raddoppi la durata o si dimezzi il tempo d’apertura delle app.

    Quanto alla compatibilità, non uso tantissime app 3rd party, quindi per ora non ho constatato svantaggi.

    • In teoria la dalvik ha passato vari processi di ottimizzazione notevoli. Inizialmente interpretava il codice. Da Android 2.2 è stato inserito un compilatore JIT che consente di avere un codice compilato in fase di esecuzione, quindi perdita di tempo in esecuzione per compilare il codice (o il codice dei metodi a seconda del sistema adoperato) ma comunque giovamento nell’esecuzione una volta avviata ed eseguita l’app. Diversamente con ART la compilazione avviene in fase di installazione. Se ottimizzeranno il compilatore ci saranno notevoli benefici.

  • goldenboy

    finché non diventa compatibile il framework xposed, art resta lì a fare la muffa!

    • Enrico Cid

      Se art verrà adottato di default in futuro lo switch per selezionare runtime sarà rimosso…
      Quindi il dev dell xposed se deve sbriga a capire come riscrivere le classi :)

  • mah

    sinceramente non ho trovato grandi cambiamenti con art al momento. di sicuro verrà migliorato nelle prossime versioni e saranno molto evidenti i vantaggi, ma ora come ora non capisco perché tutti si ostinino a dire che art è enormemente meglio di dalvik in termini di velocità del sistema…

    • Nicholas

      Chi lo dice sta mentendo. Cioè, mi spiego meglio: in teoria ART *sarà* superiore a Dalvik per reattività e miglioramento di batteria, ma *in futuro*.
      Per ora è solamente una funzione sperimentale, nulla di più. Anzi, i vantaggi sono praticamente nulli.

      • Lorenzo Giorgi

        A essere sinceri i miglioramenti ci sono… Dura un po’ di più la batteria e il dispositivo è un po’ più reattivo. Niente di Sconvolgente ma i miglioramenti ci sono già. Questa è ovviamente una mia opinione personale.

        • Nicholas

          Sì, hai ragione, mi sono espresso male io. Volevo dire che i miglioramenti non sono così “miracolosi” come si potrebbe pensare. :)

          • giacomofurlan

            Invece sul mio Nexus 4 per alcune applicazioni ho trovato la differenza Dalvik / ART sconvolgente… anche solo per i tempi di latenza. Sarà che non mi accontento facilmente e noto anche le cose più piccole :)

      • vortex67

        Concordo,ART per ora è solo tanto fumo.

    • Se riuscissero ad effettuare una conversione completa a un reale runtime environment invece che usare una VMachine forse si vedrebbero sostanziali miglioramenti e si potrebbe sfruttare pienamente il kernel linux di android, molto superiore a quello dei vari iOS e Windows Phone. Ma finché continueremo a “virtualizzare” ( si fa per dire ) il tutto…

      • giacomofurlan

        iOS usa sempre un derivato FreeBSD… che vai dicendo?

        In ogni caso la VM costringe le applicazioni ad un ambiente chiuso, il modo più semplice per effettuare il sandboxing e quindi rafforzare la sicurezza.

        • Buona parte di iOs é stata riprogettata ad hoc per i device portable. Quel poco che é rimasto non puó essere nemmeno paragonato a un sistema BSD vero e proprio. Oltretutto la parte BSD é quella relativa alle reti. Il resto é l’ottimo Mach (XNU). Niente da ridire ma attualmente Linux sta facendo passi da gigante tanto da essere favorito anche in ambiti di sicurezza server. Per non parlare del maggiore supporto a molte piattaforme. La Vmachine é un buon modo per effettuare il sandboxing ma non unico anche se semplice. In informatica si applicaspesso il concetto di non obsolescenza, pertanto se sui desktop si trovano anche altre soluzioni probabilmente queste si potranno anche riadattare. ART in ogni caso prevede la compilazione in fase di installazione proprio per ovviare il passaggio per il compilatore JIT che causa una diminuizione delle prestazioni rispetto a un sistema con app compilate. Non mi sembra dunque di aver detto troppe boiate. Non vedo cosa ci sia anche di sbagliato nel dire che iOs e wPhone rimarrebbero dietro…

          • giacomofurlan

            Per mantenere il sandboxing dovresti avviare comunque una virtualizzazione per ogni gruppo di processi… su un dispositivo mobile è impensabile ad oggi… quale priorità daresti alla CPU? E quanta RAM ad ogni virtualizzazione? Amplificheremmo allora ai problemi di paging della RAM. Con una sola VM invece puoi amministrare tutte le applicazioni, rendendo la soluzione l’unica ad oggi possibile su hardware limitato.

            Comunque sì, iOS si basa su un ibrido XNU/FreeBSD. Se non erro su iOS i programmi viaggiano compilati (velocità d’esecuzione), però così facendo la Apple si prende a carico di controllarle una ad una, cosa che per gli sviluppatori Google vorrebbe dire pagare un “bollo” annuale, cosa che la Google ha sempre voluto evitare.

            ART attualmente non compila tutto il codice, ma solo quelle parti che possono essere eseguite a prescindere da particolari restrizioni (le quali vengono ancora girate tramite la VM).

          • Praticamente ti sei risposto da solo :)….. Il problema è la base ma l’hardware sta crescendo. Il fatto che ART faccia questo ora non vuol dire che lo farà anche nelle prossime release.
            Il fatto che il codice debba essere controllato non ho ben capito a cosa tu ti riferisca. Quale pericolo dovrebbe esserci. La protezione delle aree di memoria la prevede il sistema operativo, il sandboxing lo deve attuare sempre lui. Il problema dovrebbe essere il trap delle eccezioni? Attualmente se non sbaglio non lo supporta nativamente neanche Dalvik ma viene probabilmente previsto un codice di gestione da parte dell’OS.

          • giacomofurlan

            Se non erro tutte le chiamate “sandboxate” vengono passate tramite la VM, mentre le altre vengono dirette direttamente al processore… in questo modo si ha un passaggio in meno e quindi maggiore velocità d’esecuzione.

            In ogni caso dubito che avremo mai tanta RAM per poter virtualizzare N sistemi per N applicazioni… possiamo creare algoritmi di previsione d’utilizzo della RAM, ma se sfori? Non puoi riallocare dinamicamente la memoria centrale. Ed il micro-kernel da avviare? Possiamo sempre utilizzare la memoria condivisa, ma comunque è un overhead del processore.

            Per il codice controllato… ti riferisci alla Apple? No, non controllano il codice, ma prendono in esame ogni applicazione che intendi immettere nell’AppStore, non c’è un controllo automatico, la analizzano e vedono se è potenzialmente dannosa. Se anche è fuori di una virgola dalle loro policy non te la pubblicano.

          • Continuo a non capire dove sia il problema. Un sistema attuale top gamma ha 2 giga di ram almeno se non 3GB. Molto più di alcuni pc di circa 6 o 7 anni fa. Hai la tua memoria al boot dedicata al kernel. La restante memoria può essere suddivisa fra sistema e applicazioni. Così come sui desktop si riesce a gestire il tutto con quantitativi anche più esigui di ram lo si potrà fare con accortezza anche sui device portable fra qualche anno. I problemi di ri-allocazione, gli algoritmi di previsione sono problemi contro il quale si scontra in ogni caso la VMachine ora. Cosa cambia? Il dover progettare la gestione sul sistema? Un po’ di lavoro che hanno già fatto altri in passato, non vedo cosa vi sia di così difficile. Un tempo forse i sistemi handheld erano più complessi da gestire ma ora almeno per quanto concerne i quantitativi di memoria ram e le prestazioni non c’è molto di che lamentarsi. Non fraintendermi non intendo che i sistemi siano paragonabili a quelli attuali ma sicuramente offrono più memoria di sistemi del passato e offrono quasi altrettanta potenza.
            Relativamente al codice controllato non vedo dove sia il problema. E’ l’os che deve prevedere la sicurezza e la gestione corretta delle risorse e non un’azienda in fase di compilazione o post-compilazione in questo caso. Pertanto il tutto è da prevedere sul sistema, sul runtime environment e sull’SDK. Cosa faranno gli sviluppatori è altro conto.

          • giacomofurlan

            Essendo una, ora la VM si prende una fetta grande di RAM e non glie ne importa nulla, perché può dare dinamicamente tutto o nulla alle applicazioni, le quali agiscono nel sotto-paging della VM in modo dinamico. La VM non ha mai la necessità di riallocare la RAM, perché se la ciuccia praticamente tutta. Se invece spezzetti la RAM in tante VM, vai a sprecare un grosso quantitativo di memoria, il che non è bene neanche su un server di produzione e, in definitiva, (1) ti permette di aprire meno applicazioni per volta e (2) puoi avere seri problemi di OOME.

            Per quanto riguarda il codice compilato o meno, a differenza di iOS, è che la Apple ti fa compilare tutto il codice perché c’è un controllo umano di ciò che fa e ciò che non fa. Nel momento in cui compili funzioni di monitoring del traffico (ne dico una), né il kernel né la VM possono bloccarti. Semplice no? Quindi o vieni controllato, oppure non ti daranno mai il permesso di compilare anche quelle parti (rallentando così l’esecuzione).

          • Ok, forse ho capito il perché non riusciamo a capirci. Provo a spiegarti il mio punto di vista. A me non interessa assolutamente quali siano gli attuali problemi, quale soluzione viene attuata ora, quale potrebbe essere attuata sulla base di ciò che abbiamo ora e quale è stata usata in altri ambiti. Io vedo soltanto i lati negativi del continuare a usare un sistema basato su una Virtual Machine. Castra un sistema con potenzialità molto maggiori.
            Per quanto concerne le problematiche che hai evidenziato. Non vedo perché usare tante VMachine. E perché se compilo funzioni di monitoring dovrei avere problemi. Perché attualmente si ragiona in modo diametralmente opposto alla teoria dei Sistemi Operativi. Un OS deve prevedere tecniche di protezione dell’hardware, della memoria e accessi all’hardware soltanto tramite system call con conseguente passaggio da user mode a kernel mode soltanto al kernel. Come venga implementato è altro conto. Su altri sistemi non basati sulle Vmachine è stato fatto. Hai contestato la mancanza di memoria e io ti sto dicendo che attualmente abbiamo 3GB di ram e che probabilmente per quando ART sarà davvero rilasciato avremo device dai 2 ai 4GB di ram. Pertanto, giacché dovrebbe essere una conversione che avverrà nel lungo periodo c’è tutto il tempo e tutte le risorse per farlo. Abbiamo inoltre un esempio lampante di device con poca ram eppure esecuzione del codice compilato (iOS 1GB di ram). Per quanto riguarda il numero di app contemporanee non credo che su un tablet o smartphone si useranno mai tante applicazioni quanto se ne usano su un sistema desktop. Si deve lavorare! E’ stato fatto da altri e lo si può fare, anche su Android. Attualmente considerato il funzionamento attuato hanno fatto un ottimo lavoro, che riesce bene o male a mantenersi alla pari della concorrenza. Immagina tu se provvedessero a farlo lavorare in modo analogo. C’è un’ottima base, sfruttata ancora non al 100%.

          • danitkd93

            Questa è una delle poche politiche Google che non condivido. Non è sbagliato far pagare una quota annuale alle app. Se queste in un anno hanno riscosso un minimo di successo con il ricavato non gli penserebbe nulla pagare una piccola somma, se invece nel giro di un anno non hanno riscosso un minimo di interesse è giusto che vengano eliminate dagli sviluppatori dal play Store. Salirebbe il livello di ogni app nel play Store e si farebbe pulizia di tutte quelle app spazzatura che non vengono più aggiornate e che nessuno istalla.
            In più se ciò permetterà di avere una maggiore ottimizzazione del sistema android gli sviluppatori avranno anche meno lavoro da fare per ottimizzare le loro app per far si che girino decentemente!

          • Alessandro Carlo Paolucci

            però basare la permanenza di un’app sullo store sulla sua popolarità non è necessariamente corretta, di base ognuno sviluppa la sua app e la pubblica e già ora il mercato la punisce se nessuno la installa scendendo di rank nelle ricerche. sul fatto di far pagare le app di successo ci si può anche stare, ma come fissare la soglia? poi parliamo solo di app a pagamento? e il costo dovrebbe variare in base al successo? bho…ha senso?
            si può ripulire il market anche senza metterlo a pagamento insomma…

    • Emanu_lele

      Scusa mah che telefono hai? Io ho un GNex e con ART il telefono sembra un altro. Anche l’autonomia è aumentata e con il governator impostato su perfomance ci ho fatto 16 ore di fila di cui 6 di schermo acceso. Ora è tutto velocissimo non solo nella Home e nel Drower ma anche nell’apertura della app è diventato una scheggia. ART è proprio un altra storia soprattutto per l’hardware datato.

  • Pingback: ART è pronto a sostituire Dalvik? Sì, secondo un commit nell’AOSP | News Novità Notizie Trita Web()

  • Pingback: ART è pronto a sostituire Dalvik? Sì, secondo un commit nell’AOSP - WikiFeed()

  • Chi dice che non ci sono molte differenze fra art e dalvik:
    Per ora sono disponibili solo su dispositivi più o meno top di gamma, ma vedrete che fra un annetto, quando il nostro nexus non sarà più un top, allora ci si accorgerà delle differenze.

    PS ART è ancora all’inizio, serve un po di sviluppo, ma lo renderanno veramente migliore a mio (e a loro) parere

  • Francesco

    La differenza tra ART e Dalvik c’è, soprattutto nel multitasking, che è più veloce e nella fluidità generale del sistema, niente di “rivoluzionario”, ma se si può avere il meglio, perché restare indietro? C’è qualche problema con alcune applicazioni, ma sono molto poche e sicuramente tutto verrà reso compatibile al 100%.

    • SuperAnty97

      Xposed installer non compatibile… Per me è l’applicazione più importante che ho…

      • Emanu_lele

        Io ho un G Nexus, uso ART è il telefono sembra un altro terminale, la durata della batteria è aumentata di molto (16 ore di fila di cui 6 di schermo acceso) La fluidità è paragonabile a quella di un Nexus 4, le app si aprono immediatamente senza nessuna latenza. I programmatori di Xposed si devono dare una mossa perché di certo non si torna indietro.

        • SuperAnty97

          ho provato ART mettendo la cataclysm sul nexus 4 (perché volevo una rom stock ma con qualche mod come gravitybox) e sono estremamente soddisfatto, è fluidissimo, peccato però che alcune app non sono ancora compatibili (drastic non mi funziona), hai ragione una volta provata non voglio più tornare a Dalvik! :)

  • Alessandro Marcheselli

    Qualche buon’anima che traduca le scritte in modo che possa capirle anche io? Non sono mai stato molto bravo nel modding, ma mi piacerebbe esserlo :D

    • Sorrata

      1. Non c’è molto da tradurre in quanto si tratta di directory di Android, protocolli e cose varie
      2. Per “moddare” ti servirà imparare l’ inglese, MOLTO inglese
      3. Queste sono operazioni che avvengono a bassissimo livello (kernel e runtime)
      4. In pratica il documento dice che è stato levata la runtime dalvik come predefinita (scritte in rosso) ed è stata impostata art come principale (scritte verdi).

      Spero di averti aiutato :D

      • Alessandro Marcheselli

        Quindi vorrebbe dire che io da Android kitkat avrò questo ART che ottimizzerá tutto il sistema?

    • Nicholas

      Per quanto riguarda “runtime” c’è il link a Wikipedia nella definizione. Se ci sono altre domande, chiedi pure che proveremo a risponderti :)

      • Alessandro Marcheselli

        Grazie, avrei una domanda che non c’entra molto con questo discorso: se io installo la custom ROM di Android 4.4, ottengo anche le applicazioni di Android 4.4? Voglio dire: per esempio io ho uno smartphone con Gingerbread ed installo la ROM di Android 4.4: posso scaricare tutte le applicazioni che con Gingerbread non avrei avuto?

        • altervox

          Si.

        • Nicholas

          Assolutamente sì :) questo è anche il bello di Android, no?

          • Alessandro Marcheselli

            Grazie mille per la disponibilità nel rispondermi sempre :D

        • giacomofurlan

          Nonostante la 4.4 sia “leggera” non aspettarti miracoli in ogni caso – e se per applicazioni intendi giochi… beh, un dispositivo bloccato alla 2.3 non avrà una GPU in grado di farli andare decentemente…

          • Alessandro Marcheselli

            Sì ok, non è il mio caso (per fortuna): ti scrivo da HTC One ed era solo una curiosità :D grazie mille!

      • cionci

        Il link è po’ fuorviante e non spiega cosa sia ART. Il link giusto sarebbe l’equivalente in italiano di questo: http://en.m.wikipedia.org/wiki/Runtime_library

        • Nicholas

          Il link di Wikipedia spiega solamente cos’è un runtime compiler. Per maggiori informazioni, nell’articolo c’è un link (che porta ad un nostro precedente articolo) che spiega nel dettaglio le differenze tra Dalvik e ART :)

          • cionci

            Oddio, il link spiega cos’è il tempo di esecuzione, che è ben diverso da runtime compiler. Senza considerare che l’unico runtime compiler è dalvik, mentre Art è un ahead-of-time compiler ;-)
            Entrambi sono però runtime library!

  • Pingback: ART è pronto a sostituire Dalvik? Sì, secondo un commit nell’AOSP | Crazyworlds()

  • Pingback: ART è pronto a sostituire Dalvik? Sì, secondo un commit nell’AOSP()

  • Busta Gunz

    Come farò ora a cancellare le Dalvik Cache? :(

    • Porco boia cane cattivone

      È vero non serve a un cazzo ma ci fa sentire fighi :-[

      • Busta Gunz

        Si difatti sono anni che sto sul panorama modding Android e in ogni guida c’è scritto di cancellare le dalvik cache, ma alla fine non fa assolutamente nulla lol

        • Porco boia cane cattivone

          Hahhahha. Quello che ci ha messo il meno deve essere Cristopher Davik in persona (molto offeso dalle nostre eresie)

        • Kaiserxol

          Se non fai il wipe della Dalvik al riavvio, con la nuova rom, non viene ricreato l’index delle app poichè la cache è già popolata. Per questo si fa il wipe. Se non lo fai potresti anche non avere problemi, soprattutto su update della stessa rom (quando si usano le nightly), ma dire che non serve a niente mi sembra parecchio un’eresia :-D
          Prova a scrivere questa cosa su XDA e vediamo se le reazioni sono le stesse di questo blog ;-)

      • Simmmmmm

        Dopo “ciao Darwin” Adesso in TV vedremo “Ciao Dalvik”! Ehuehue

    • Albe

      Nelle future recovery metteranno “Wipe Art Cache”…ormai Dalvik cache era troppo mainstream :D

  • Enrico Cid

    C’è più di un commit… Infatti stavo per segnalarlo…ma non pensavo fosse cosi importante, dato che mi sembra scontato questo passaggio.. quindi non ho aperto i commit dove c’è scritto “64”… XD

  • Pingback: ART è pronto a sostituire Dalvik? Sì, secondo un commit nell’AOSP - HostingPost.itHostingPost.it()

  • Pingback: ART è pronto a sostituire Dalvik? Sì, secondo un commit nell’AOSP | Notizie, guide e news quotidiane!()

  • SuperAnty97

    Io non riesco ad abbandonare dalvik finché non fanno gravity box anche per Art

  • Nicola Craperi

    ART migliora:
    -fluidità del sistema(soprattutto nel multitasking)
    -durata batteria(leggermente)
    Chiunque abbia la possibilità di cambiare la Run time io consiglio di settare ART anche se non porta differenze marcatissime rispetto a davlik. Tuttavia anche queste piccole differenze sfruttano al meglio il proprio device. Quindi se si ha la possibilità di apportare migliorie (anche piccole) perché non farlo ? POSSESORE DI UN NEXUS 5

  • Pingback: ART è pronto a sostituire Dalvik? Sì, secondo un commit nell'AOSP | WP7 Developer()

  • Francesco Mangano

    Buongiorno.. La differenza tra le due runtime la noterete quando da art tornerete a dalvik. Io personalmente con art ho notato i seguenti pro: durata sensibilmente migliore della batteria, avvio e spegnimento più rapidi,maggiore fluidità del sistema e microlag (se mai ce ne fossero sul nexus 5) completamente azzerati,maggiore quantità libera di ram. Invece i contro sono: crash anomali delle app anche di sistema quali chrome o YouTube, impossibilità di installare determinate app (anche se la maggior parte funzionano) , in ogni caso si ha una minore affidabilità del sistema. Ovviamente questo potrebbe essere dovuto dall’impossibilità di effettuare uno swipe della cash dal sistema recovery . quindi se volete farlo vi toccherà fare un hard reset con conseguente ritorno in automatico a dalvik. Il mio consiglio è quello di aspettare ulteriori migliorie della runtime art io che addirittura finalmente venga implementata in un eventuale prossimo aggiornamento di KitKat (molto improbabile). A mio giudizio come inizio non c’è male, le differenze si notano specialmente se siete utenti molto esigenti sulle prestazioni e durata della batteria, ma il gioco non vale la candela attualmente. Un saluto!! Nexu 5