Wir sind das Android LLVM-Toolchain-Team. Eine unserer obersten Prioritäten ist die Verbesserung der Android-Leistung durch Optimierungstechniken im LLVM-Ökosystem. Wir suchen ständig nach Möglichkeiten, Android schneller, reibungsloser und effizienter zu machen. Obwohl ein Großteil unserer Optimierungsarbeit im Userspace stattfindet, bleibt der Kernel das Herz des Systems. Heute möchten wir Ihnen zeigen, wie wir die automatische Feedback-gesteuerte Optimierung (AutoFDO) in den Android-Kernel integrieren, um Nutzern erhebliche Leistungssteigerungen zu ermöglichen.

Was ist AutoFDO?

Bei einem Standard-Softwarebuild trifft der Compiler Tausende kleiner Entscheidungen, z. B. ob eine Funktion inline ausgeführt werden soll und welcher Zweig einer Bedingung wahrscheinlich verwendet wird. Diese Entscheidungen basieren auf statischen Code-Hinweisen. Diese Heuristiken sind zwar nützlich, aber sie sagen die Codeausführung bei der tatsächlichen Nutzung des Smartphones nicht immer genau voraus.

AutoFDO ändert dies, indem es reale Ausführungsmuster verwendet, um den Compiler zu steuern. Diese Muster stellen die häufigsten Ausführungspfade für Anweisungen dar, die der Code bei der tatsächlichen Nutzung durchläuft. Sie werden erfasst, indem der Verzweigungsverlauf der CPU aufgezeichnet wird. Diese Daten können zwar von Geräten in der Flotte erfasst werden, für den Kernel werden sie jedoch in einer Laborumgebung mit repräsentativen Arbeitslasten synthetisiert, z. B. durch Ausführen der 100 beliebtesten Apps. Wir verwenden einen Sampling-Profiler, um diese Daten zu erfassen und zu ermitteln, welche Teile des Codes „aktiv“ (häufig verwendet) und welche „inaktiv“ sind.Wenn wir den Kernel mit diesen Profilen neu erstellen, kann der Compiler viel intelligentere Optimierungsentscheidungen treffen, die auf die tatsächlichen Android-Arbeitslasten zugeschnitten sind.

Um die Auswirkungen dieser Optimierung zu verstehen, sollten Sie die folgenden wichtigen Fakten berücksichtigen:

• Unter Android entfallen etwa 40% der CPU-Zeit auf den Kernel.
• Wir verwenden AutoFDO bereits, um native ausführbare Dateien und Bibliotheken im Userspace zu optimieren. Dadurch wird der Start von inaktiven Apps um etwa 4% verbessert und die Startzeit um 1% verkürzt.

Leistungssteigerungen in der Praxis

Wir haben beeindruckende Verbesserungen bei wichtigen Android-Messwerten erzielt, indem wir Profile aus kontrollierten Laborumgebungen genutzt haben. Diese Profile wurden durch App-Crawling und -Starten erfasst und auf Pixel-Geräten mit den Kerneln 6.1, 6.6 und 6.12 gemessen.

Die bemerkenswertesten Verbesserungen sind unten aufgeführt. Details zu den AutoFDO-Profilen für diese Kernel-Versionen finden Sie in den entsprechenden Android-Kernel-Repositories für die Kernel android16-6.12 und android15-6.6.

Das sind nicht nur theoretische Zahlen. Sie führen zu einer schnelleren Benutzeroberfläche, schnelleren App-Wechseln, einer längeren Akkulaufzeit und einem insgesamt reaktionsschnelleren Gerät für den Endnutzer.

Funktionsweise: Die Pipeline

Unsere Bereitstellungsstrategie umfasst eine ausgefeilte Pipeline, um sicherzustellen, dass die Profile relevant bleiben und die Leistung stabil bleibt.

Schritt 1: Profilerfassung

Während wir unsere interne Testflotte verwenden, um Profile von Binärdateien im Userspace zu erstellen, sind wir für das Generic Kernel Image (GKI) zu einer kontrollierten Laborumgebung gewechselt. Durch die Entkopplung der Profilerstellung vom Geräte-Releasezyklus sind flexible, sofortige Updates unabhängig von den bereitgestellten Kernel-Versionen möglich. Tests bestätigen, dass diese laborgestützten Daten Leistungssteigerungen liefern, die mit denen von realen Flotten vergleichbar sind.

• Tools und Umgebung: Wir flashen Testgeräte mit dem neuesten Kernel-Image und verwenden simpleperf, um Ausführungsstreams für Anweisungen zu erfassen. Dieser Prozess basiert auf Hardwarefunktionen zum Aufzeichnen des Verzweigungsverlaufs, insbesondere auf der Verwendung von  ARM Embedded Trace Extension (ETE) und ARM Trace Buffer Extension (TRBE) auf Pixel-Geräten.
• Arbeitslasten:  Wir erstellen eine repräsentative Arbeitslast mit den 100 beliebtesten Apps aus der Android App Compatibility Test Suite (C-Suite). Um möglichst genaue Daten zu erfassen, konzentrieren wir uns auf Folgendes:
  • App-Start: Optimierung für die sichtbarsten Verzögerungen für Nutzer
  • **KI-gestütztes App-Crawling**: Simulation von zusammenhängenden, sich entwickelnden Nutzerinteraktionen
  • Systemweite Überwachung:Erfassung nicht nur von App-Aktivitäten im Vordergrund, sondern auch von kritischen Hintergrundarbeitslasten und Interprozesskommunikation
• Validierung:Diese synthetische Arbeitslast weist eine Ähnlichkeit von 85% mit Ausführungsmustern auf, die von unserer internen Flotte erfasst wurden.
• Zielgerichtete Daten:Durch ausreichend häufige Wiederholung dieser Tests erfassen wir hochgenaue Ausführungsmuster, die die reale Nutzerinteraktion mit den beliebtesten Anwendungen genau darstellen. Darüber hinaus können wir mit diesem erweiterbaren Framework nahtlos zusätzliche Arbeitslasten und Benchmarks integrieren, um unsere Abdeckung zu erweitern.

Schritt 2: Profilverarbeitung

Wir verarbeiten die Rohdaten der Trace-Erfassung nach, um sicherzustellen, dass sie sauber und effektiv sind und für den Compiler bereit sind.

• Aggregation:Wir konsolidieren Daten aus mehreren Testläufen und Geräten in einer einzigen Systemansicht.
• Konvertierung: Wir konvertieren Rohdaten in das AutoFDO-Profilformat und filtern bei Bedarf unerwünschte Symbole heraus.
• Profilkürzung:Wir kürzen Profile, um Daten für „inaktive“ Funktionen zu entfernen, damit sie mit der Standardoptimierung verwendet werden können. Dadurch werden Regressionen in selten verwendetem Code verhindert und unnötige Erhöhungen der Binärgröße vermieden.

Schritt 3: Profiltests

Vor der Bereitstellung werden Profile streng überprüft, um sicherzustellen, dass sie konsistente Leistungssteigerungen ohne Stabilitätsrisiken liefern.

• Profil- und Binäranalyse:Wir vergleichen den Inhalt des neuen Profils (einschließlich aktiver Funktionen, Stichprobenanzahl und Profilgröße) genau mit früheren Versionen. Wir verwenden das Profil auch, um ein neues Kernel-Image zu erstellen und Binärdateien zu analysieren, um sicherzustellen, dass die Änderungen am Textabschnitt den Erwartungen entsprechen.
• Leistungsüberprüfung:Wir führen gezielte Benchmarks für das neue Kernel-Image aus. Dadurch wird bestätigt, dass die Leistungssteigerungen beibehalten werden, die durch frühere Baselines erzielt wurden.

Kontinuierliche Updates

Code „driftet“ im Laufe der Zeit natürlich, sodass ein statisches Profil irgendwann seine Wirksamkeit verliert. Um eine optimale Leistung aufrechtzuerhalten, führen wir die Pipeline kontinuierlich aus, um regelmäßige Updates zu ermöglichen:

• Regelmäßige Aktualisierung: Wir aktualisieren Profile in den LTS-Zweigen des Android-Kernels vor jedem GKI-Release, um sicherzustellen, dass jeder Build die neuesten Profildaten enthält.
• Zukünftige Erweiterung:Wir stellen diese Updates derzeit für die Zweige android16-6.12 und android15-6.6 bereit und werden die Unterstützung auf neuere GKI-Versionen wie die kommende Version android17-6.18 ausweiten.

Stabilität gewährleisten

Eine häufige Frage bei der profilgesteuerten Optimierung ist, ob sie Stabilitätsrisiken birgt. Da AutoFDO hauptsächlich die Heuristiken des Compilers beeinflusst, z. B. die Inline-Ausführung von Funktionen und das Code-Layout, anstatt die Logik des Quellcodes zu ändern, bleibt die funktionale Integrität des Kernels erhalten. Diese Technologie hat sich bereits in großem Maßstab bewährt und dient seit Jahren als Standardoptimierung für Android-Plattformbibliotheken, ChromeOS und die eigene Serverinfrastruktur von Google.

Um ein konsistentes Verhalten zu gewährleisten, wenden wir standardmäßig eine konservative Strategie an. Funktionen, die nicht in unseren hochgenauen Profilen erfasst werden, werden mit Standardmethoden des Compilers optimiert. Dadurch verhalten sich die „inaktiven“ oder selten ausgeführten Teile des Kernels genau wie in einem Standardbuild, wodurch Leistungsregressionen oder unerwartetes Verhalten in Grenzfällen verhindert werden.

Unsere Zukunftspläne

Wir stellen AutoFDO derzeit für die Zweige android16-6.12 und android15-6.6 bereit. Über diese erste Einführung hinaus sehen wir mehrere vielversprechende Möglichkeiten, die Technologie weiter zu verbessern:

• Erweiterte Reichweite:Wir freuen uns darauf, AutoFDO-Profile für neuere GKI-Kernel-Versionen und zusätzliche Build-Ziele über die aktuelle aarch64-Unterstützung hinaus bereitzustellen.
• Optimierung von GKI-Modulen:Derzeit konzentriert sich unsere Optimierung auf die Hauptbinärdatei des Kernels (vmlinux). Wenn AutoFDO auf GKI-Module ausgeweitet wird, könnte dies zu Leistungssteigerungen für einen größeren Teil des Kernel-Subsystems führen.
• Unterstützung von Anbietermodulen:Wir möchten AutoFDO auch für Anbietermodule unterstützen, die mit dem Driver Development Kit (DDK) erstellt wurden. Da die Unterstützung bereits in unserem Build-System (Kleaf) und den Profilerstellungstools (simpleperf) verfügbar ist, können Anbieter diese Optimierungstechniken auf ihre spezifischen Hardwaretreiber anwenden.
• Breitere Profilabdeckung:Es besteht die Möglichkeit, Profile aus einer größeren Anzahl von wichtigen Nutzerverhalten (Critical User Journeys, CUJs) zu erfassen, um sie zu optimieren.

Durch die Einführung von AutoFDO im Android-Kernel sorgen wir dafür, dass die Grundlage des Betriebssystems für die Art und Weise optimiert ist, wie Sie Ihr Gerät jeden Tag verwenden.