In che modo il compilatore Ark di Huawei può migliorare le prestazioni delle app Android

Gran parte della recente conversazione su Huawei ha ruotato attorno alla sfortunata situazione politica dell'azienda a causa di a Ordine esecutivo statunitense che vieta a molte aziende di condurre affari con Huawei. Le ripercussioni di una decisione così cruciale sono troppo enormi per non prestarvi attenzione. Ma in una realtà alternativa in cui questo ordine esecutivo non esistesse, Huawei sarebbe stata sotto i riflettori per questo ha recentemente rivelato Ark Compiler, l'ultima innovazione che pretende di colmare il divario prestazionale delle app tra Android e Android iOS.

Prima di approfondire cos'è Ark Compiler, dobbiamo fare un passo indietro e capire cos'è un compilatore e lo scopo che serve nel sistema Android.

Breve storia di compilatori e interpreti su Android

Un compilatore è un programma per computer che traduce il codice da una lingua a un'altra lingua, spesso essendo un linguaggio macchina nativo. Questo può poi essere eseguito direttamente dal computer oppure tramite un altro programma (interprete). Questa traduzione è necessaria perché scriviamo codice in linguaggi di programmazione leggibili dall'uomo (come Java e Kotlin), mentre il computer capisce solo il linguaggio macchina nativo (codice binario sotto forma di 1 e 0). Il compilatore funge quindi da ponte tra le istruzioni scritte da un essere umano e la capacità della macchina di comprendere e quindi eseguire tali istruzioni. La rapidità ed efficienza con cui avviene questa conversione e la successiva interpretazione definisce quindi l'efficienza del compilatore introducendo una correlazione diretta tra l'efficienza del compilatore e le prestazioni e l'efficienza del codice e, per estensione, app.

Dalvik VM

Agli albori di Android, il sistema operativo utilizzava quella che veniva chiamata Dalvik VM (l'interprete) insieme a un compilatore JIT (just-in-time). Questo vecchio video di Android Basics 101 di XDA TV La serie tocca la Dalvik VM e la configurazione JIT, che soddisfacevano entrambe le esigenze dei primi sistemi Android in cui i vincoli di memoria erano abbondanti. La VM Dalvik ha preso il bytecode Java e lo ha convertito in codice macchina come e quando il codice doveva essere eseguito (quindi Just-In-Time). Ciò era necessario poiché lo spazio di archiviazione nei telefoni era un vero limite all'epoca, quindi questo approccio consentiva alle app di funzionare con file di dimensioni più piccole nel sistema.

La compilazione e l'interpretazione delle app in fase di esecuzione presentavano lo svantaggio di prestazioni complessivamente più lente dell'app poiché la compilazione veniva eseguita parallelamente al momento in cui l'utente utilizza l'app.

Dalvik aveva anche delle limitazioni con il suo meccanismo di Garbage Collection. Dalvik ha tenuto traccia collettivamente di ciascuna allocazione di memoria. Una volta che Dalvik determina che un pezzo di memoria non è più utilizzato dal programma, libera questa memoria nuovamente nell'heap senza alcun intervento da parte del programmatore. Questo processo è chiamato Garbage Collection (GC) e mira a trovare oggetti di memoria in un programma a cui non si accede più e quindi a recuperare le risorse utilizzate da tali oggetti per liberare memoria. Il sistema determina quando è necessario un GC su base collettiva, quindi gli sviluppatori di app non possono scegliere quando si verificano gli eventi GC [anche in ART]. Pertanto, se si verificasse un evento GC nel mezzo di un'attività di elaborazione intensiva sull'app in primo piano, il sistema verrebbe messo in pausa l'esecuzione del processo e iniziare GC, aumentando così il tempo di elaborazione e introducendo un notevole "strappo" nel file utenti.

Questi e altri vincoli hanno spinto Google a esplorare approcci alternativi per prestazioni più veloci.

Tempo di esecuzione Android

Con Android 4.4 KitKat, Google ha introdotto ARTE (Runtime Android) in forma di anteprima con un compilatore AOT (Ahead-Of-Time) e con Android 5.0 Lollipop, Google ha abbandonato Dalvik a favore di ART come unico interprete disponibile. ART con AOT ha convertito il codice in linguaggio macchina al momento dell'installazione dell'app, anziché attendere di eseguire tale conversione quando l'app è in uso. Questo approccio ha quindi accelerato i tempi di avvio delle app ma ha anche introdotto degli svantaggi sotto forma di tempi di installazione più lenti e un maggiore utilizzo dello spazio su disco. Per bilanciare il tutto, Google adottato una combinazione di AOT, JIT e compilazione guidata dal profilo con ART su Android 7.0 Nougat, per garantire che nessun singolo fattore venga influenzato drasticamente.

ART ha anche lavorato per rendere la Garbage Collection meno invadente. Il processo GC è stato ottimizzato per essere complessivamente più rapido con meno pause (una breve pausa rispetto alle due pause di Dalvik), meno frammentazione e meno utilizzo della memoria. La presentazione di Google al Google I/O 2014 entra più nel dettaglio spiegando i limiti del GC di Dalvik e i miglioramenti di ART a tal fine.

Nonostante questi cambiamenti nel corso degli anni, la premessa di base dell'approccio di Google prevedeva l'interpretazione del codice durante l'esecuzione variando al contempo i tempi dell'elemento di compilazione (traduzione). Garbage Collection continua inoltre a rappresentare un punto dolente per gli sviluppatori di app a causa della sua intrinseca natura collettiva e interruttiva. Probabilmente, le prestazioni delle app Android ne risentono poiché continuano a esserci costi generali coinvolti.

Compilatore Ark di Huawei

Huawei ha lavorato per sviluppare una soluzione più efficiente e di conseguenza ha assunto centinaia di esperti nel settore. Il risultato di questo sforzo è Ark Compiler, che secondo Huawei è il primo compilatore statico in assoluto che consente la traduzione diretta in linguaggio macchina, eliminando completamente la necessità di un file interprete. Ark Compiler è stato sviluppato anche con l'obiettivo di massimizzare l'efficienza di esecuzione per Java e C, quindi teoricamente si dovrebbero vedere i migliori risultati con questi linguaggi.

Huawei presenta alcune caratteristiche chiave del compilatore Ark come di seguito:

• Tecniche di compilazione come AOT e JIT possono convertire alcuni programmi in codice macchina ed eseguirli direttamente sulla CPU, ma queste tecniche non sono in grado di slegarsi completamente dall'interprete e dalle limitazioni ad esse connesse. Il compilatore Ark utilizza la compilazione statica, che gli consente di slegarsi dall'interprete dinamico, aprendo la possibilità di aumentare le prestazioni dell'app "passi da gigante."
• La compilazione statica ha il potenziale svantaggio di essere troppo rigida e di non essere in grado di apportare le modifiche che un compilatore dinamico può apportare durante l'esecuzione. Huawei afferma che la compilazione statica di Ark Compiler risolve questo problema "traducendo perfettamente le caratteristiche dinamiche del linguaggio di programmazione in codice macchina."
• I processi di compilazione esistenti hanno luogo durante o dopo l'installazione del pacchetto app sul dispositivo mobile. Ark Compiler è progettato per l'implementazione durante lo sviluppo del software, il che presumiamo aiuti a rimuovere le spese generali durante l'installazione e l'esecuzione. Presumiamo che gli sviluppatori di app siano in grado di compilare direttamente linguaggi diversi nel codice macchina nativo durante l'app processo di sviluppo, e l'APK risultante potrebbe quindi non aver bisogno dell'interazione con un interprete o una macchina virtuale funzione. Ciò ridurrebbe teoricamente le spese generali relative a JNI, ad esempio.
• Ark Compiler cambia anche la natura collettiva di Garbage Collection. Consente agli eventi GC di verificarsi separatamente per diversi thread Java. Questo approccio compartimentato afferma di offrire meno stravaganze sulle app in primo piano.

Come risultato di questi cambiamenti, Ark Compiler può apparentemente migliora la fluidità operativa del sistema Android fino al 24%, la velocità di risposta fino al 44% e la fluidità delle applicazioni di terze parti fino al 60%, sostenendo di portare le prestazioni delle app Android allo stesso livello di quelle di iOS.

Il compilatore Ark è attualmente compilato e ottimizzato per l'architettura dei chip ARM. Huawei spera che in futuro la progettazione collaborativa di hardware e software contribuirà a massimizzare le capacità del chip Kirin.

Il compilatore Ark supporta l'utilizzo standard di Java, consentendo la compilazione diretta di app di terze parti senza che lo sviluppatore dell'app apporti alcuna modifica al codice. Ark Compiler consente anche "aggiustamenti alla struttura del codice" per ulteriori miglioramenti alle prestazioni e alla memoria. Huawei ha scelto di rendere Ark Compiler un sistema open source, che consentirebbe l'adozione da parte di sviluppatori di terze parti e adattare la tecnologia alle loro esigenze, promuovendone l'adozione tra gli sviluppatori di app e i telefoni cellulari produttori.

Anche se Huawei non menziona alcun svantaggio dell'Ark Compiler, ci si possono aspettare app di grandi dimensioni almeno, ma questo non dovrebbe porre alcun problema sui dispositivi della generazione attuale che ne sono dotati in abbondanza magazzinaggio. Ci aspettiamo inoltre che Ark Compiler non sarà disponibile per tutte le architetture CPU, poiché i problemi di compatibilità di Google non sono il grattacapo di Huawei. Ark Compiler è progettato per essere utilizzato durante lo sviluppo e non durante l'installazione; ciò indica che Huawei potrebbe aver modificato il modo in cui le app vengono distribuite e installate sui dispositivi Android e potrebbe anche aver lavorato sul proprio design APK. Se corretto, ciò potrebbe rappresentare un grave problema di compatibilità nell'ecosistema e passerebbe molto tempo prima che diventi una funzionalità Android standard, se non mai.

Anche la mancata compilazione sul dispositivo dell'utente solleva una grande questione sull'ottimizzazione. ART attualmente ottimizza in base alla microarchitettura, il che significa che il binario risultante lo sarebbe diverso per un dispositivo Snapdragon rispetto a un dispositivo Exynos, o anche per uno Snapdragon 845 rispetto a uno Snapdragon 625. Questo approccio ha senso per i produttori che hanno il pieno controllo del SoC, come Apple e Huawei. Tuttavia, con il resto del mondo Android che utilizza molti SoC diversi, forzare un'ottimizzazione generica da utilizzare su tutti i dispositivi sarà ancora una volta un ostacolo per la standardizzazione del compilatore Ark. Di conseguenza, non aspettarti che Ark Compiler arrivi presto sulla tua ROM personalizzata preferita.

Per chiarezza, Ark Compiler è sviluppato per funzionare con Android e Huawei non ha menzionato nulla in relazione ad esso presunto sistema operativo homebrew e la sua compatibilità con Ark Compiler, quindi non facciamo presunzioni a riguardo.

Huawei prevede di tenere due importanti conferenze dedicate agli sviluppatori e all'ecosistema più ampio. Si tratta della Huawei Device China Developers Conference e della Green Alliance China Developers Conference. Entrambi gli eventi affronteranno specifiche questioni open source relative al compilatore Ark di Huawei, nel tentativo di rendere i vantaggi di questa tecnologia il più ampiamente accessibili possibile.

---

Un ringraziamento speciale al collaboratore riconosciuto senior di XDA Dees_Troy e sviluppatore riconosciuto arter97 per la loro assistenza e input.

Nota: Huawei/Honor hanno smesso di fornire i codici di sblocco ufficiali del bootloader per i suoi dispositivi. Pertanto, i bootloader dei loro dispositivi non possono essere sbloccati, il che significa che gli utenti non possono eseguire il root o installare ROM personalizzate.