Android 4.4 KitKat nasconde ART e supporto Audio DSP

kit-kat-android

Durante la serata di ieri, poco dopo l’annuncio ufficiale da parte di Google di Android 4.4 KitKat e del Nexus 5, vi abbiamo proposto un articolo approfondito su tutte le novità introdotte con la nuova versione di Android. In particolare, abbiamo visto come siano state introdotte numerose novità sia per quanto riguarda il codice interno che per quanto riguarda l’interfaccia utente, ma vi sarebbero ancora altre novità molto interessanti che non aspettano altro che venire alla luce.

Una di queste è la presenza di un nuovo compilatore virtuale chiamato ART, che si occupa di far girare le applicazioni di Android. Come ben saprete, la macchina virtuale su cui attualmente girano le applicazioni Android è la Dalvik, le cui prestazioni restano discutibili. Dopo però l’acquisizione di FlexyCore da parte di Google, ricorderete, eventualmente a Mountain View stanno valutando di migliorare le prestazioni di tutte le applicazioni proprio implementando questo nuovo compilatore ART sviluppato appunto in collaborazione con FlexyCore.

Questo compilatore è capace di leggere file di tipo OAT, mentre la Dalvik è capace di leggere file di tipo ODEX. In Android 4.4 KitKat, inoltre, vi sarebbe anche una conversione dex2oat che permetterebbe di convertire i file ODEX in file OAT e quindi renderli compatibili con il compilatore ART.

dalvik-art

Si badi bene che questo strumento per adesso è previsto solo nella console degli sviluppatori, i quali potranno scegliere se far girare la propria applicazione via Dalvik o via ART. Molto probabilmente, quindi, Google starebbe orientandosi verso un graduale abbandono della Dalvik in favore del compilatore ART, che darebbe tanti benefici in termini di prestazioni. Le applicazioni, infatti, girerebbero molto più veloci di adesso. Ci si aspetta, quindi, che Android 4.4 KitKat riesca ad eseguire anche applicazioni realizzate per ART.

Oltre questa novità molto importante ve ne sarebbe un’altra legata all’audio. In particolare, vi è il supporto all’Audio Tunneling grazie al processore per segnali digitali DSP (Digital Signal Processor). In pratica cosa accade: quando ascoltiamo musica, di solito è la CPU che si occupa di elaborare i segnali audio digitali, e questo comporta un grosso consumo di energia. Con l’utilizzo di un processore DSP, come quello che si trova a bordo del Nexus 5, i segnali audio digitali non vengono elaborati più dalla CPU ma da tale co-processore che risulta molto più efficiente. Questo consente di diminuire drasticamente il consumo di batteria durante la riproduzione dell’audio e, per questo motivo, le ore di ascolto dell’audio sono passate da 30 a ben 60 nel Nexus 5.

Naturalmente non tutti i dispositivi hanno un processore DSP, per cui questa caratteristica per adesso rimarrà propria del Nexus 5. Google, comunque, è al lavoro con i suoi partner al fine di introdurre questa funzionalità anche nei prossimi dispositivi.

Via e Via

Commenti

Ti invitiamo ad usare toni consoni e di rimanere in tema all'argomento trattato, in caso contrario, il sistema automatico potrebbe oscurare il tuo messaggio e potrebbero trascorrere fino a 48h per la verifica ed un'eventuale autorizzazione.
TuttoAndroid si riserva comunque il diritto di allontanare le persone non adatte a tenere un comportamento corretto e rispettoso verso gli altri.

  • Tesky99

    Sapete se il Nexus 5 supporta la riproduzione audio a 24 bit/192 kHz cosa che è possibile su LG G2?

  • Pingback: Punto della situazione - Pagina 5 - Forum Android Italiano()

  • Pingback: ART: la nuova macchina virtuale che sostiurà Dalvik ?()

  • cionci

    Mi hanno bloccato il commento in moderazione…

    Ho avuto modo di analizzare 10 minuti il sorgente di Art (disponibile su Googlesource). Sinceramente mi sembra qualcosa di abbastanza brutale.

    In pratica ci sono quattro componenti:

    – un porting in JNI (librerie in linguaggio nativo richiamabili da Java) delle API di Java (non c’è traccia delle api di Android)
    – un disassembler di byte code Java che produce in output un sorgente in linguaggio assembly del file Java
    – un mockup della VM dalvik che altro non fa che verificare la presenza del file oat corrispondente nella cache e se non c’è chiama dex2oat
    – dex2oat che disassembla i file in byte code Java e li riassembla in file con interfaccia JNI in modo che le strutture pubbliche siano raggiungibili dagli altri file odex o oat

    Probabilmente anche le API Android vengono tradotte in oat al volo.
    Le uniche architetture supportate sono x86, mips e arm, tutte a 32 bit.

    Mi sembra una soluzione alquanto poco avanzata, sicuramente sarebbero possibili soluzioni più JIT. In pratica hanno buttato nel cestino Java :-

  • cionci

    Mi hanno bloccato il commento in moderazione…

    Ho avuto modo di analizzare 10 minuti il sorgente di Art (disponibile su Googlesource). Sinceramente mi sembra qualcosa di abbastanza brutale.

    In pratica ci sono quattro componenti:

    – un porting in JNI (librerie in linguaggio nativo richiamabili da Java) delle API di Java (non c’è traccia delle api di Android)
    – un disassembler di byte code Java che produce in output un sorgente in linguaggio assembly del file Java
    – un mockup della VM dalvik che altro non fa che verificare la presenza del file oat corrispondente nella cache e se non c’è chiama dex2oat
    – dex2oat che disassembla i file in byte code Java e li riassembla in file con interfaccia JNI in modo che le strutture pubbliche siano raggiungibili dagli altri file odex o oat

    Probabilmente anche le API Android vengono tradotte in oat al volo.
    Le uniche architetture supportate sono x86, mips e arm, tutte a 32 bit.

    Mi sembra una soluzione alquanto poco avanzata, sicuramente sarebbero possibili soluzioni più JIT. In pratica hanno buttato nel cestino Java :-

    • Andrea Campanella

      Buttare nel cestino java e’ la cosa piu’ intelligente da fare, java e’ semplice (che poi anche li…) da imparare e da usare, ma di sicuro non e’ efficente, anche con le istruzioni in hardware, sara’ ma a me un bel compilato c/c++ alla ios mi piace di piu’.

      poi boh, magari sono “vecchia scuola” io…

      • cionci

        Sicuramente, anche io sono della vecchia scuola, ma mi sembra un controsenso rispetto alle scelte prese fino ad ora.
        Se invece avessero integrato tutto nel compilatore JIT allora mi sarebbe piaciuto di più

        • Andrea Campanella

          java e’ rimasto per motivi storici, si era scelto tra ram vs cpu, e ha vinto la ram (basta considerare che le app salvano ancora le immagini in ram come bitmap -_-“) ma e’ palese che ora abbimo processori molto veloci ma la ram inizia a scarseggiare (2gb su uno smartphone, davvero?!?) si aggiunge anche il fatto che google punta sugli smarwatch e i g.glass, c’e’ meno spazio, e se puoi giocare con i processori, non puoi fare la stessa cosa con la ram, spazio piccolo= meno ram, quindi un cambio di direzione e’ imho l’unica possibilita’….

          • cionci

            Alla fine però non cambia molto nella gestione della ram con Art. Riferimenti e garbage collect dovranno usarli lo stesso perché sono insiti nel trattamento delle risorse delle API.
            Il vantaggio più grande è proprio nella velocità di esecuzione. Anzi, non mi meraviglierei se occupasse addirittura più Ram.

          • Andrea Campanella

            Non ho ancora guardato,mi fido di quello che mi dici, ma potrebbe essere solo un primo passo…

    • Andrea Campanella

      Buttare nel cestino java e’ la cosa piu’ intelligente da fare, java e’ semplice (che poi anche li…) da imparare e da usare, ma di sicuro non e’ efficente, anche con le istruzioni in hardware, sara’ ma a me un bel compilato c/c++ alla ios mi piace di piu’.

      poi boh, magari sono “vecchia scuola” io…

    • giacomofurlan

      Beh da quanto ne so iOS esegue dei binari già compilati, a differenza di Android che esegue i file su virtual machine. Il maggior pregio di ciò è che la VM gestisce l’accesso alle varie risorse (il sandbox), la cosa negativa è che rallenta tutto (anche se abbiamo visto che Windows 8 è riuscito a snellire molto tutta la struttura, pur basandosi sulla VM di .net). Già solo convertire i byte code Java in codice assembly risulta in un boost prestazionale non indifferente, snellendo il lavoro che la VM deve fare.

      Anche se brutale, questo ha dei pregi non indifferenti: gli sviluppatori continueranno a scrivere il codice come hanno sempre fatto, quindi nessun corso di aggiornamento etc ed allo stesso tempo permetterà ad applicazioni più pesanti di essere eseguite senza problemi su dispositivi con risorse più limitate.

  • Bob

    Chissà se questo varrà anche usando un DAC via usb-otg?

  • Marco

    Oooh finalmente ci decidiamo a risolvere i problemi alla radice!

  • cionci

    Doppio…

Top