Erklärung zum Ark Compiler: Wie der App Compiler von Huawei die Leistung von Android-Apps verbessern kann

Ein Großteil der jüngsten Gespräche über Huawei drehte sich um die unglückliche politische Lage des Unternehmens, da viele Unternehmen aufgrund eines US-Erlasses keine Geschäfte mit Huawei tätigen konnten. Die Auswirkungen einer solchen Entscheidung sind viel zu groß, um sie nicht zu berücksichtigen. In einer alternativen Realität, in der es diese Executive Order nicht gibt, wäre Huawei im Rampenlicht des kürzlich veröffentlichten Ark Compiler, der neuesten Innovation, die behauptet, die Leistungslücke zwischen Android und iOS zu schließen.

Bevor wir uns mit Ark Compiler befassen, müssen wir einen Schritt zurücktreten und verstehen, was ein Compiler ist und welchen Zweck er im Android-System erfüllt.

Kurze Geschichte der Compiler und Interpreter auf Android

Ein Compiler ist ein Computerprogramm, das Code aus einer Sprache in eine andere Sprache übersetzt, wobei es sich häufig um eine Maschinensprache handelt. Dies kann dann entweder direkt vom Computer oder über ein anderes Programm (Interpreter) ausgeführt werden. Diese Übersetzung ist notwendig, weil wir Code in für Menschen lesbaren Programmiersprachen (wie Java und Kotlin) schreiben, während der Computer nur die Maschinensprache versteht (Binärcode in Form von Einsen und Nullen). Der Compiler dient somit als Brücke zwischen den Anweisungen, die ein Mensch schreibt, und der Fähigkeit der Maschine, diese Anweisungen zu verstehen und dann auszuführen. Wie schnell und effizient diese Konvertierung und anschließende Interpretation erfolgt, bestimmt die Effizienz des Compilers und führt somit zu einer direkten Korrelation zwischen der Effizienz des Compilers und der Leistung und Effizienz von Code und Apps.

Dalvik VM

In den Anfängen von Android verwendete das Betriebssystem den sogenannten Dalvik VM (den Interpreter) zusammen mit einem JIT-Compiler (Just-in-Time). Dieses ältere Video aus der TV-Serie Android Basics 101 behandelt die Dalvik-VM und das JIT-Setup, die beide die Anforderungen früherer Android-Systeme erfüllten, bei denen es zahlreiche Speicherbeschränkungen gab. Die Dalvik-VM nahm Java-Bytecode und wandelte ihn in Maschinencode um, wenn der Code ausgeführt werden musste (daher Just-In-Time). Dies war notwendig, da der Speicherplatz in Telefonen damals eine echte Einschränkung darstellte, sodass Apps mit kleineren Dateigrößen im System arbeiten konnten.

Das Kompilieren und Interpretieren von Apps zur Laufzeit hatte den Nachteil einer insgesamt langsameren App-Leistung, da die Kompilierung gleichzeitig mit der Verwendung der App durch den Benutzer erfolgen würde.

Dalvik hatte auch Einschränkungen mit seinem Garbage Collection-Mechanismus. Dalvik verfolgte gemeinsam jede Speicherzuweisung. Sobald Dalvik feststellt, dass ein Teil des Speichers nicht mehr vom Programm verwendet wird, gibt es diesen Speicher ohne Eingreifen des Programmierers auf den Heap zurück. Dieser Prozess wird als Garbage Collection (GC) bezeichnet. Ziel ist es, Speicherobjekte in einem Programm zu finden, auf die nicht mehr zugegriffen wird, und anschließend die von diesen Objekten verwendeten Ressourcen für die Speicherfreigabe zurückzugewinnen. Das System ermittelt kollektiv, wann ein GC erforderlich ist, sodass App-Entwickler nicht entscheiden können, wann GC-Ereignisse auftreten (auch nicht in ART). Wenn also ein GC-Ereignis in der Mitte einer intensiven Verarbeitungsaktivität in der Vordergrund-App auftritt, unterbricht das System die Ausführung des Prozesses und beginnt mit dem GC. Dadurch wird die Verarbeitungszeit verlängert und den Benutzern ein spürbarer „Ruck“ auferlegt.

Diese und andere Einschränkungen veranlassten Google, nach alternativen Ansätzen für eine schnellere Leistung zu suchen.

Android Runtime

Mit Android 4.4 KitKat führte Google ART (Android Runtime) in Vorschauform mit einem AOT-Compiler (Ahead-Of-Time) ein, und mit Android 5.0 Lollipop ließ Google Dalvik zugunsten von ART als einzigem verfügbaren Interpreter fallen. ART with AOT hat den Code zum Zeitpunkt der Installation der App in die Maschinensprache konvertiert, anstatt auf eine solche Konvertierung zu warten, wenn die App verwendet wird. Dieser Ansatz beschleunigte somit die Startzeiten von Apps, führte jedoch auch zu Nachteilen in Form von langsameren Installationszeiten und einer erhöhten Nutzung des Festplattenspeichers. Um dies auszugleichen, hat Google eine Kombination aus AOT, JIT und profilgesteuerter Kompilierung mit ART unter Android 7.0 Nougat eingeführt, um sicherzustellen, dass kein einzelner Faktor drastisch beeinflusst wird.

Android ART-Implementierung

ART hat auch daran gearbeitet, die Garbage Collection weniger aufdringlich zu machen. Der GC-Prozess wurde dahingehend optimiert, dass insgesamt weniger Pausen (einzelne kurze Pause im Vergleich zu zwei Pausen bei Dalvik), weniger Fragmentierung und weniger Speicherbedarf erforderlich sind. Googles Präsentation auf der Google I / O 2014 geht detaillierter auf die Einschränkungen von Dalviks GC und die Verbesserungen von ART in diesem Bereich ein.

Selbst bei diesen Änderungen im Laufe der Jahre bestand die Grundvoraussetzung des Google-Ansatzes darin, Code während der Ausführung zu interpretieren und gleichzeitig den Zeitpunkt des Kompilierens (der Übersetzung) zu variieren. Die Garbage Collection ist auch für App-Entwickler aufgrund ihrer inhärenten Unterbrechung und Kollektivität nach wie vor ein Problem. Wahrscheinlich leidet die Leistung der Android-Apps darunter, dass weiterhin Gemeinkosten anfallen.

Ark Compiler von Huawei

Huawei hat an einer effizienteren Lösung gearbeitet und infolgedessen Hunderte von Fachleuten eingestellt. Das Ergebnis dieser Bemühungen ist der Ark Compiler, von dem Huawei behauptet, er sei der erste statische Compiler, der eine direkte Übersetzung in Maschinensprache ermöglicht, ohne dass ein Dolmetscher erforderlich ist. Ark Compiler wurde auch mit dem Ziel entwickelt, die Effizienz der Ausführung für Java und C zu maximieren. Aus diesem Grund sollte man theoretisch die besten Ergebnisse mit diesen Sprachen erzielen.

Grafik von Huawei. Vom Benutzer übersetzter Text MyKeyVans.

Huawei präsentiert einige wichtige Funktionen des Ark Compilers:

  • Kompilierungstechniken wie AOT und JIT können einige Programme in Maschinencode konvertieren und direkt auf der CPU ausführen. Diese Techniken können sich jedoch nicht vollständig vom Interpreter und den damit verbundenen Einschränkungen lösen. Der Ark Compiler verwendet eine statische Kompilierung, die es ihm ermöglicht, sich vom dynamischen Interpreter zu lösen und die Leistung der App um ein Vielfaches zu steigern .
  • Die statische Kompilierung hat möglicherweise den Nachteil, dass sie zu starr ist und keine Anpassungen vornehmen kann, die ein dynamischer Compiler während der Ausführung vornehmen kann. Huawei behauptet, dass die statische Kompilierung des Ark Compilers dies behebt, “ indem die dynamischen Funktionen in der Programmiersprache nahtlos in Maschinencode übersetzt werden.
  • Bestehende Kompilierungsvorgänge finden während oder nach der Installation des App-Pakets auf dem Mobilgerät statt. Der Ark Compiler wurde für die Bereitstellung während der Softwareentwicklung entwickelt. Wir gehen davon aus, dass er dabei hilft, Zeitaufwand während der Installation und Ausführung zu vermeiden. Wir gehen davon aus, dass App-Entwickler in der Lage sind, während des App-Entwicklungsprozesses verschiedene Sprachen direkt in nativen Maschinencode zu kompilieren. Das resultierende APK benötigt daher möglicherweise keine Interaktion mit einem Interpreter oder einer virtuellen Maschine, um zu funktionieren. Dies würde beispielsweise theoretisch die mit JNI verbundenen Gemeinkosten reduzieren.
  • Ark Compiler ändert auch den kollektiven Charakter der Garbage Collection. Dadurch können GC-Ereignisse für verschiedene Java-Threads separat auftreten. Dieser aufgeteilte Ansatz behauptet, dass Vordergrund-Apps weniger Spaß machen.

Infolge dieser Änderungen kann Ark Compiler anscheinend die Bedienbarkeit von Android-Systemen um bis zu 24%, die Reaktionsgeschwindigkeit um bis zu 44% und die Benutzerfreundlichkeit von Anwendungen von Drittanbietern um bis zu 60% verbessern Leistung auf dem Niveau von iOS.

Der Ark Compiler wird derzeit für die ARM-Chip-Architektur kompiliert und optimiert. Huawei hofft, dass kollaboratives Hardware- und Software-Design in Zukunft dazu beitragen wird, die Fähigkeiten der Kirin-Chips zu maximieren.

Der Ark Compiler unterstützt die standardmäßige Verwendung von Java und ermöglicht die direkte Kompilierung von Apps von Drittanbietern, ohne dass der App-Entwickler Codeänderungen vornehmen muss. Ark Compiler ermöglicht auch "Anpassungen der Codestruktur" zur weiteren Verbesserung der Leistung und des Speichers. Huawei hat Ark Compiler zu einem Open-Source-System gemacht, mit dem Entwickler von Drittanbietern die Technologie übernehmen und an ihre Bedürfnisse anpassen können, was die Akzeptanz bei App-Entwicklern und Herstellern von Mobiltelefonen fördert.

Huawei erwähnt zwar keine Nachteile für den Ark Compiler, aber man kann zumindest mit großen App-Größen rechnen, aber dies sollte bei Geräten der aktuellen Generation, die über ausreichend Speicherplatz verfügen, keine Probleme bereiten. Wir gehen auch davon aus, dass Ark Compiler nicht für alle CPU-Architekturen verfügbar sein wird, da die Kompatibilitätsprobleme von Google nicht das Problem von Huawei sind. Der Ark Compiler wurde entwickelt, um während der Entwicklung und nicht während der Installation verwendet zu werden. Dies ist ein Hinweis darauf, dass Huawei möglicherweise Änderungen an der Bereitstellung und Installation von Apps auf Android-Geräten vorgenommen hat und möglicherweise auch an ihrem eigenen APK-Design gearbeitet hat. Wenn dies zutrifft, könnte dies ein großes Kompatibilitätsproblem im Ökosystem darstellen, und es würde eine Weile dauern, bis dies zu einer Standard-Android-Funktion wird, wenn überhaupt.

Das Nichtkompilieren auf dem Gerät eines Benutzers wirft auch eine große Frage zur Optimierung auf. ART optimiert derzeit auf der Basis einer Mikroarchitektur, was bedeutet, dass die resultierende Binärdatei für ein Snapdragon-Gerät im Vergleich zu einem Exynos-Gerät oder sogar für ein Snapdragon 845 im Vergleich zu einem Snapdragon 625 unterschiedlich ist. Dieser Ansatz ist für Hersteller mit vollständiger Kontrolle sinnvoll des SoC, wie Apple und Huawei. Angesichts der Tatsache, dass der Rest der Android-Welt viele verschiedene SoCs verwendet, wird die Erzwingung einer generischen Optimierung für alle Geräte erneut ein Hindernis für die Standardisierung des Ark-Compilers sein. Erwarten Sie daher nicht, dass Ark Compiler bald auf Ihrem bevorzugten benutzerdefinierten ROM eintreffen wird.

Zur Verdeutlichung wurde der Ark-Compiler für Android entwickelt, und Huawei hat nichts in Bezug auf das angebliche Homebrew-Betriebssystem und die Kompatibilität mit dem Ark-Compiler erwähnt, sodass wir diesbezüglich keine Vermutungen anstellen.

Huawei plant zwei große Konferenzen, die Entwicklern und dem größeren Ökosystem gewidmet sind. Dies sind die Huawei Device China Developers Conference und die Green Alliance China Developers Conference. Beide Veranstaltungen befassen sich mit spezifischen Open-Source-Problemen im Zusammenhang mit dem Huawei Ark Compiler, um die Vorteile dieser Technologie so weit wie möglich zugänglich zu machen.


Besonderer Dank geht an Senior Recognized Contributor Dees_Troy und Recognized Developer arter97 für ihre Unterstützung und Beiträge.

Hinweis: Huawei / Honor hat die Bereitstellung offizieller Bootloader-Freischaltcodes für seine Geräte eingestellt. Daher können die Bootloader ihrer Geräte nicht entsperrt werden, was bedeutet, dass Benutzer keine benutzerdefinierten ROMs rooten oder installieren können.