Wie der Ark Compiler von Huawei die Leistung von Android-Apps verbessern kann

Ein Großteil der jüngsten Gespräche rund um Huawei drehte sich um die unglückliche politische Situation des Unternehmens aufgrund von a Eine US-Erlassverordnung, die viele Unternehmen daran hinderte, Geschäfte mit Huawei zu tätigen. Die Auswirkungen einer solch entscheidenden Entscheidung sind viel zu enorm, um sie nicht zu beachten. Aber in einer alternativen Realität, in der es diese Durchführungsverordnung nicht gibt, wäre Huawei dafür im Rampenlicht gestanden hat kürzlich den Ark Compiler vorgestellt, die neueste Innovation, die angeblich die App-Leistungslücke zwischen Android und überbrückt iOS.

Bevor wir näher darauf eingehen, was Ark Compiler ist, 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 von einer Sprache in eine andere Sprache übersetzt, wobei es sich häufig um eine native Maschinensprache handelt. Dies kann dann entweder direkt vom Computer ausgeführt werden oder durch ein anderes Programm (Interpreter) ausgeführt werden. Diese Übersetzung ist notwendig, da wir Code in für Menschen lesbaren Programmiersprachen schreiben (wie Java und Kotlin), während der Computer nur die native Maschinensprache (Binärcode in Form von Einsen und) versteht 0er). 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 erfolgen, bestimmt somit die Effizienz des Compilers Einführung einer direkten Korrelation zwischen der Effizienz des Compilers und der Leistung und Effizienz des Codes und im weiteren Sinne: Apps.

Dalvik VM

In den frühen Tagen von Android nutzte das Betriebssystem die sogenannte Dalvik VM (den Interpreter) zusammen mit einem JIT-Compiler (Just-in-Time). Dieses ältere Video von XDA TVs Android Basics 101 Die Serie befasst sich mit der Dalvik-VM und dem JIT-Setup, die beide den Anforderungen früher Android-Systeme dienten, bei denen es häufig zu Speicherbeschränkungen kam. Die Dalvik-VM nahm Java-Bytecode und konvertierte ihn in Maschinencode, sobald der Code ausgeführt werden musste (daher Just-In-Time). Dies war notwendig, da der Speicherplatz in Telefonen damals eine echte Einschränkung darstellte, so dass Apps mit diesem Ansatz 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 Nutzung der App durch den Benutzer stattfand.

Dalvik hatte auch Einschränkungen hinsichtlich seines Garbage-Collection-Mechanismus. Dalvik verfolgte alle Speicherzuordnungen gemeinsam. Sobald Dalvik feststellt, dass ein Teil des Speichers nicht mehr vom Programm verwendet wird, gibt es diesen Speicher ohne Eingreifen des Programmierers wieder auf den Heap zurück. Dieser Prozess wird Garbage Collection (GC) genannt und zielt darauf ab, Speicherobjekte in einem Programm zu finden, auf die nicht mehr zugegriffen wird, und dann die von diesen Objekten verwendeten Ressourcen zurückzugewinnen, um Speicher freizugeben. Das System bestimmt auf kollektiver Basis, wann ein GC erforderlich ist, sodass App-Entwickler nicht auswählen können, wann GC-Ereignisse auftreten (selbst in ART). Wenn also während einer intensiven Verarbeitungsaktivität in der Vordergrund-App ein GC-Ereignis auftritt, wird das System angehalten die Ausführung des Prozesses und beginnen mit der GC, wodurch sich die Verarbeitungszeit erhöht und ein spürbarer „Ruck“ beim auftritt Benutzer.

Diese und andere Einschränkungen veranlassten Google, alternative Ansätze für eine schnellere Leistung zu erkunden.

Android-Runtime

Mit Android 4.4 KitKat stellte Google vor ART (Android-Runtime) in Vorschauform mit einem AOT-Compiler (Ahead-Of-Time) und mit Android 5.0 Lollipop ließ Google Dalvik zugunsten von ART als einzigem verfügbaren Interpreter fallen. ART mit AOT konvertierte Code zum Zeitpunkt der Installation der App in Maschinensprache, anstatt auf die Konvertierung zu warten, während die App verwendet wird. Dieser Ansatz beschleunigte somit die Startzeiten von Apps, brachte aber auch Nachteile in Form langsamerer Installationszeiten und einer erhöhten Speicherplatznutzung mit sich. Zum Ausgleich: Google angenommen eine Kombination aus AOT, JIT und profilgesteuerter Kompilierung mit ART auf Android 7.0 Nougat, um sicherzustellen, dass kein einzelner Faktor drastisch beeinflusst wird.

ART hat auch daran gearbeitet, die Garbage Collection weniger aufdringlich zu gestalten. Der GC-Prozess wurde optimiert, um insgesamt schneller zu sein, mit weniger Pausen (einzelne kurze Pause im Vergleich zu Dalviks zwei Pausen), weniger Fragmentierung und weniger Speicherverbrauch. Die Präsentation von Google auf der Google I/O 2014 geht detaillierter auf die Einschränkungen von Dalviks GC und die diesbezüglichen Verbesserungen von ART ein.

Trotz dieser Ä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 Kompilierungs- (Übersetzungs-) Elements zu variieren. Auch für App-Entwickler stellt die Garbage Collection aufgrund ihrer inhärenten unterbrechenden und kollektiven Natur weiterhin ein Problem dar. Darunter leidet wohl die Leistung der Android-App, da weiterhin Gemeinkosten anfallen.

Ark Compiler von Huawei

Huawei hat an der Entwicklung einer effizienteren Lösung gearbeitet und daher Hunderte von Experten auf diesem Gebiet eingestellt. Das Ergebnis dieser Bemühungen ist der Ark Compiler, der laut Huawei der erste statische Compiler überhaupt ist Dies ermöglicht eine direkte Übersetzung in Maschinensprache, wodurch die Notwendigkeit einer solchen vollständig entfällt Dolmetscher. Ark Compiler wurde auch mit dem Ziel entwickelt, die Laufeffizienz für Java und C zu maximieren, sodass man theoretisch mit diesen Sprachen die besten Ergebnisse erzielen sollte.

Nachfolgend stellt Huawei einige wichtige Funktionen des Ark Compilers vor:

• Kompilierungstechniken wie AOT und JIT können einige Programme in Maschinencode umwandeln und direkt auf der CPU ausführen. Diese Techniken sind jedoch nicht in der Lage, sich vollständig vom Interpreter und den damit verbundenen Einschränkungen zu lösen. Der Ark-Compiler nutzt die statische Kompilierung, die es ihm ermöglicht, sich vom dynamischen Interpreter zu lösen, was die Möglichkeit eröffnet, die App-Leistung zu steigern, indem er „Sprünge und Grenzen."
• 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 dieses Problem löst.durch die nahtlose Übersetzung der dynamischen Funktionen der Programmiersprache in Maschinencode."
• Bestehende Kompilierungsprozesse finden während oder nach der Installation des App-Pakets auf dem mobilen Gerät statt. Ark Compiler ist für den Einsatz während der Softwareentwicklung konzipiert, was unserer Meinung nach dazu beiträgt, den Zeitaufwand bei der Installation und Ausführung zu verringern. Wir gehen davon aus, dass App-Entwickler während der App-Entwicklung verschiedene Sprachen direkt in nativen Maschinencode kompilieren können Entwicklungsprozess, und das resultierende APK benötigt daher möglicherweise keine Interaktion mit einem Interpreter oder einer virtuellen Maschine Funktion. Dies würde beispielsweise theoretisch die mit JNI verbundenen Gemeinkosten reduzieren.
• Ark Compiler verändert auch den kollektiven Charakter der Garbage Collection. Dadurch können GC-Ereignisse für verschiedene Java-Threads separat auftreten. Dieser unterteilte Ansatz soll weniger störende Auswirkungen auf Vordergrund-Apps haben.

Aufgrund dieser Änderungen kann Ark Compiler Verbessert scheinbar die flüssige Bedienung des Android-Systems um bis zu 24 %, die Reaktionsgeschwindigkeit um bis zu 44 % und die Laufruhe der Anwendungen von Drittanbietern um bis zu 60 %.und behauptet, die Leistung von Android-Apps auf das gleiche Niveau wie auf iOS zu bringen.

Der Ark Compiler ist derzeit für die ARM-Chip-Architektur kompiliert und optimiert. Huawei hofft, dass in Zukunft durch kollaboratives Hardware- und Softwaredesign die Leistungsfähigkeit des Kirin-Chips maximiert wird.

Der Ark Compiler unterstützt die Standard-Java-Nutzung 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“ für weitere Verbesserungen der Leistung und des Speichers. Huawei hat sich dafür entschieden, Ark Compiler zu einem Open-Source-System zu machen, das es Drittentwicklern ermöglichen würde, es zu übernehmen und passen die Technologie an ihre Bedürfnisse an, um ihre Akzeptanz bei App-Entwicklern und Mobiltelefonen zu fördern Hersteller.

Während Huawei keine Nachteile des Ark Compilers nennt, kann man durchaus mit großen App-Größen rechnen Zumindest sollte dies jedoch bei Geräten der aktuellen Generation, die mit ausreichend ausgestattet sind, keine Probleme darstellen Lagerung. 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. Ark Compiler ist für die Verwendung während der Entwicklung und nicht während der Installation konzipiert; Dies ist ein Hinweis darauf, dass Huawei möglicherweise die Art und Weise, wie Apps auf Android-Geräten bereitgestellt und installiert werden, geändert und möglicherweise auch an seinem eigenen APK-Design gearbeitet hat. Wenn dies zutrifft, könnte dies ein großes Kompatibilitätsproblem im Ökosystem darstellen, und es würde, wenn überhaupt, noch lange dauern, bis dies zu einer Standard-Android-Funktion wird.

Das Nichtkompilieren auf dem Gerät eines Benutzers wirft ebenfalls eine große Frage zur Optimierung auf. ART optimiert derzeit pro Mikroarchitektur, was bedeutet, dass die resultierende Binärdatei wie folgt wäre unterschiedlich für ein Snapdragon-Gerät im Vergleich zu einem Exynos-Gerät oder sogar für einen Snapdragon 845 im Vergleich zu einem Snapdragon 625. Dieser Ansatz ist für Hersteller sinnvoll, die die volle Kontrolle über den SoC haben, wie Apple und Huawei. Da der Rest der Android-Welt jedoch viele verschiedene SoCs verwendet, wird die Erzwingung einer generischen Optimierung zur Verwendung auf allen Geräten erneut ein Hindernis für die Standardisierung des Ark Compilers darstellen. Erwarten Sie daher nicht, dass Ark Compiler bald auf Ihrem bevorzugten benutzerdefinierten ROM verfügbar sein wird.

Zur Klarstellung: Der Ark Compiler wurde für die Verwendung mit Android entwickelt und Huawei hat diesbezüglich nichts erwähnt angebliches Homebrew-Betriebssystem und seine Kompatibilität mit Ark Compiler, daher machen wir diesbezüglich keine Vermutungen.

Huawei plant, zwei große Konferenzen abzuhalten, die den Entwicklern und dem größeren Ökosystem gewidmet sind. Dabei handelt es sich um die Huawei Device China Developers Conference und die Green Alliance China Developers Conference. Bei beiden Veranstaltungen werden spezifische Open-Source-Probleme im Zusammenhang mit dem Ark Compiler von Huawei behandelt, um die Vorteile dieser Technologie so weit wie möglich zugänglich zu machen.

---

Besonderer Dank geht an XDA Senior Recognised Contributor Dees_Troy und anerkannter Entwickler arter97 für ihre Unterstützung und Beiträge.

Hinweis: Huawei/Honor stellt für seine Geräte keine offiziellen Bootloader-Freischaltcodes mehr bereit. Daher können die Bootloader ihrer Geräte nicht entsperrt werden, was bedeutet, dass Benutzer weder rooten noch benutzerdefinierte ROMs installieren können.