Wir möchten Ihnen nun weitere Informationen zur Leistung geben.

Willkommen zum dritten Tag der Performance Spotlight Week. Heute möchten wir Ihnen weitere Details und Anleitungen zu wichtigen Bereichen der App-Leistung geben. Wir behandeln die profilgesteuerte Optimierung, Leistungsverbesserungen bei Jetpack Compose und Überlegungen zur Arbeit im Hintergrund. Kommen wir also gleich zur Sache.

Profilgesteuerte Optimierung

Baseline-Profile und Startprofile sind grundlegend, um die Start- und Laufzeitleistung einer Android-App zu verbessern. Sie sind Teil einer Gruppe von Leistungsoptimierungen, die als „profilgesteuerte Optimierung“ bezeichnet werden.

Wenn eine App verpackt wird, nimmt der d8-Dexer Klassen und Methoden und füllt die classes.dex-Dateien Ihrer App. Wenn ein Nutzer die App öffnet, werden diese DEX-Dateien nacheinander geladen, bis die App gestartet werden kann. Wenn Sie ein Startprofil bereitstellen, weiß d8, welche Klassen und Methoden in die ersten classes.dex Dateien gepackt werden sollen. Durch diese Struktur kann die App weniger Dateien laden, was die Startgeschwindigkeit verbessert.

Mit Baseline-Profilen werden die Just-in-time-Kompilierungsschritte (JIT) effektiv von Nutzergeräten auf Entwicklercomputer verlagert. Der generierte AOT-kompilierte (Ahead Of Time) Code hat sich als nützlich erwiesen, um sowohl die Startzeit als auch Rendering-Probleme zu reduzieren.

Trello und Baseline-Profile

Wir haben die Entwickler der Trello App gefragt, wie sich Baseline-Profile auf die Leistung ihrer App ausgewirkt haben. Nachdem Baseline-Profile auf den wichtigsten Nutzerpfad angewendet wurden, konnte Trello die App-Startzeit um 25 % reduzieren.

Trello konnte die Startzeit der App mithilfe von Baseline-Profilen um 25 % verbessern.

Baseline-Profile bei Meta

Außerdem haben Entwickler bei Meta vor Kurzem einen Artikel dazu veröffentlicht, wie sie ihre Android-Apps mit Baseline-Profilen beschleunigen.

In den Apps von Meta haben die Teams nach der Anwendung von Baseline-Profilen eine Verbesserung verschiedener wichtiger Messwerte um bis zu 40 % festgestellt.

Technische Verbesserungen wie diese können Ihnen helfen, die Nutzerzufriedenheit und den Geschäftserfolg zu steigern. Wenn Sie diese Informationen mit Ihren Produktverantwortlichen, CTOs und Entscheidungsträgern teilen, kann dies auch dazu beitragen, die Leistung Ihrer App zu verbessern.

Erste Schritte mit Baseline-Profilen

Um ein Baseline- oder Startup-Profil zu erstellen, schreiben Sie einen Makrobenchmark-Test, der die App ausführt. Während des Tests werden Profildaten erfasst, die bei der App-Kompilierung verwendet werden. Die Tests werden mit der neuen UiAutomator API geschrieben, die wir morgen vorstellen.

Das Schreiben eines solchen Benchmarks ist ganz einfach. Das vollständige Beispiel finden Sie auf GitHub.

  @Test

fun profileGenerator() {

    rule.collect(

        packageName = TARGET_PACKAGE,

        maxIterations = 15,

        stableIterations = 3,

        includeInStartupProfile = true

    ) {

        uiAutomator {

            startApp(TARGET_PACKAGE)

        }

    }


}

Wissenswertes

Schreiben Sie zuerst ein Baseline-Profil und ein Startup-Profil für den von Ihren Nutzern am häufigsten genutzten Pfad. Das bedeutet, dass der Haupteinstiegspunkt, den Ihre Nutzer in Ihre App nehmen, in der Regel nach der Anmeldung liegt. Schreiben Sie dann weitere Testläufe, um ein vollständigeres Bild zu erhalten. Das gilt nur für Baseline-Profile. Sie müssen nicht alles mit einem Baseline-Profil abdecken. Halten Sie sich an die am häufigsten verwendeten Routen und messen Sie die Leistung im Feld. Mehr dazu erfährst du im Beitrag von morgen.

Erste Schritte mit der profilgesteuerten Optimierung

In diesem Video vom Android Developers Summit erfahren Sie, wie Baseline-Profile funktionieren:

In der Android Build Time-Folge zur profilgesteuerten Optimierung finden Sie weitere Informationen: 

Außerdem haben wir ausführliche Informationen zu Baseline-Profilen und Startprofilen.

Leistungsverbesserungen in Jetpack Compose

Das UI-Framework für Android hat sich durch die Leistungsverbesserungen des Entwicklerteams deutlich verbessert. Seit Version 1.9 von Jetpack Compose ist die Anzahl der Ruckler beim Scrollen in einem internen Benchmark-Test mit langem Scrollen auf 0, 2 % gesunken. 

Diese Verbesserungen wurden durch mehrere Funktionen in den neuesten Releases ermöglicht.

Anpassbares Cache-Zeitfenster

Standardmäßig werden bei Lazy Layouts nur Elemente in Scrollrichtung vorab zusammengestellt. Wenn etwas aus dem Bildschirm gescrollt wird, wird es verworfen. Sie können jetzt die Anzahl der beizubehaltenden Elemente über einen Bruchteil des Darstellungsbereichs oder eine dp-Größe anpassen. So kann Ihre App mehr Arbeit im Voraus erledigen und die verfügbare Zeit effizienter nutzen, nachdem die pausierbare Komposition zwischen Frames aktiviert wurde.

Wenn Sie anpassbare Cache-Zeiträume verwenden möchten, instanziieren Sie ein LazyLayoutCacheWindow und übergeben Sie es an Ihre Lazy List oder Ihr Lazy Grid. Messen Sie die Leistung Ihrer App mit verschiedenen Cache-Fenstergrößen, z. B. 50% des Darstellungsbereichs. Der optimale Wert hängt von der Struktur Ihrer Inhalte und der Größe der Elemente ab.

  val dpCacheWindow = LazyLayoutCacheWindow(ahead = 150.dp, behind = 100.dp)

val state = rememberLazyListState(cacheWindow = dpCacheWindow)

LazyColumn(state = state) {

    // column contents

}

Pausierbare Zusammensetzung

Mit dieser Funktion können Kompositionen pausiert und ihre Arbeit auf mehrere Frames aufgeteilt werden. Die APIs wurden in Version 1.9 eingeführt und werden jetzt in Version 1.10 standardmäßig für das Lazy Layout-Prefetching verwendet. Die Vorteile sind am größten bei komplexen Elementen mit längeren Kompositionszeiten. 

Weitere Leistungsoptimierungen für Compose

In den Versionen 1.9 und 1.10 von Compose hat das Team auch einige weniger offensichtliche Optimierungen vorgenommen.

Mehrere APIs, die im Hintergrund Coroutinen verwenden, wurden verbessert. Wenn Entwickler beispielsweise Draggable und Clickable verwenden, sollten sie schnellere Reaktionszeiten und eine höhere Anzahl von Zuweisungen feststellen.

Durch Optimierungen beim Tracking von Layoutrechtecken wurde die Leistung von Modifizierern wie onVisibilityChanged() und onLayoutRectChanged() verbessert. Dadurch wird die Layoutphase beschleunigt, auch wenn diese APIs nicht explizit verwendet werden.

Eine weitere Leistungsverbesserung ist die Verwendung von im Cache gespeicherten Werten beim Beobachten von Positionen über onPlaced().

Text im Hintergrund vorab abrufen

Ab Version 1.9 bietet Compose die Möglichkeit, Text in einem Hintergrundthread vorab abzurufen. So können Sie Caches vorab aufwärmen, um ein schnelleres Textlayout zu ermöglichen. Das ist für die Rendering-Leistung von Apps relevant. Während des Layouts muss Text an das Android-Framework übergeben werden, in dem ein Wort-Cache gefüllt wird. Standardmäßig wird dies im UI-Thread ausgeführt. Wenn Sie das Prefetching und das Füllen des Wort-Cache auf einen Hintergrundthread auslagern, kann das Layout beschleunigt werden, insbesondere bei längeren Texten. Wenn Sie das Prefetching in einem Hintergrundthread ausführen möchten, können Sie einen benutzerdefinierten Executor an eine beliebige Komponente übergeben, die intern BasicText verwendet. Dazu übergeben Sie ein LocalBackgroundTextMeasurementExecutor an ein CompositionLocalProvider.

  val defaultTextMeasurementExecutor = Executors.newSingleThreadExecutor()

CompositionLocalProvider(

    LocalBackgroundTextMeasurementExecutor provides DefaultTextMeasurementExecutor

) {

    BasicText("Some text that should be measured on a background thread!")


}

Je nach Text kann dies die Leistung beim Rendern von Text verbessern. Um sicherzugehen, dass sich die Rendering-Leistung Ihrer App verbessert, sollten Sie Benchmarks durchführen und die Ergebnisse vergleichen.

Überlegungen zur Leistung bei Hintergrundaufgaben

Hintergrundaktivitäten sind ein wichtiger Bestandteil vieler Apps. Möglicherweise verwenden Sie Bibliotheken wie WorkManager oder JobScheduler, um Aufgaben wie die folgenden auszuführen:

• Analyseereignisse regelmäßig hochladen
• Daten zwischen einem Backend-Dienst und einer Datenbank synchronisieren
• Verarbeitung von Medien (z.B. Größenanpassung oder Komprimierung von Bildern)

Eine wichtige Herausforderung bei der Ausführung dieser Aufgaben besteht darin, Leistung und Energieeffizienz in Einklang zu bringen. Mit WorkManager können Sie dieses Gleichgewicht erreichen. Es ist auf Energieeffizienz ausgelegt und ermöglicht es, Aufgaben auf ein optimales Ausführungsfenster zu verschieben, das von einer Reihe von Faktoren beeinflusst wird, darunter von Ihnen angegebene oder vom System auferlegte Einschränkungen. 

WorkManager ist jedoch keine Einheitslösung. Android bietet auch eine Reihe von energieoptimierten APIs, die speziell für bestimmte gängige Core User Journeys (CUJs) entwickelt wurden.  

Auf der Landingpage für Hintergrundarbeiten finden Sie eine Liste mit einigen dieser Aufgaben,  z. B. das Aktualisieren eines Widgets und das Abrufen des Standorts im Hintergrund.

Lokale Debugging-Tools für Hintergrundaufgaben: Häufige Szenarien

Um Hintergrundarbeiten zu debuggen und zu verstehen, warum eine Aufgabe verzögert wurde oder fehlgeschlagen ist, müssen Sie sehen können, wie das System Ihre Aufgaben geplant hat. 

WorkManager bietet dazu mehrere zugehörige Tools, mit denen Sie lokal debuggen und die Leistung optimieren können. Einige davon funktionieren auch für JobScheduler. Hier sind einige häufige Szenarien, die bei der Verwendung von WorkManager auftreten können, sowie eine Erklärung der Tools, mit denen Sie sie debuggen können.

Fehlerbehebung bei der Ausführung geplanter Aufgaben

Die Verzögerung oder Nichtausführung geplanter Aufgaben kann verschiedene Ursachen haben, z. B. nicht erfüllte oder vom System auferlegte Einschränkungen. 

Der erste Schritt bei der Untersuchung, warum geplante Aufgaben nicht ausgeführt werden, besteht darin, zu prüfen, ob die Aufgabe erfolgreich geplant wurde. Prüfen Sie nach der Bestätigung des Planungsstatus, ob es nicht erfüllte Einschränkungen oder Vorbedingungen gibt, die die Ausführung der Aufgabe verhindern.

Für die Fehlersuche in diesem Szenario stehen mehrere Tools zur Verfügung.

Background Task Inspector

Der Background Task Inspector ist ein leistungsstarkes Tool, das direkt in Android Studio integriert ist. Sie bietet eine visuelle Darstellung aller WorkManager-Aufgaben und der zugehörigen Status („Wird ausgeführt“, „In die Warteschlange eingereiht“, „Fehlgeschlagen“, „Erfolgreich“). 

Wenn Sie herausfinden möchten, warum geplante Aufgaben nicht mit dem Background Task Inspector ausgeführt werden, sehen Sie sich die aufgeführten Arbeitsstatus an. Der Status „In die Warteschlange eingereiht“ bedeutet, dass Ihr Job geplant wurde, aber noch auf die Ausführung wartet.

Vorteile:Mit diesem Tool können Sie nicht nur alle Aufgaben ganz einfach aufrufen, sondern es ist auch besonders nützlich, wenn Sie verkettete Aufgaben haben. Der Background Task Inspector bietet eine grafische Ansicht, mit der Sie sehen können, ob ein Fehler bei einer vorherigen Aufgabe die Ausführung der folgenden Aufgabe beeinträchtigt hat.

Listenansicht des Background Task Inspector

Grafikansicht im Background Task Inspector

adb shell dumpsys jobscheduler

Dieser Befehl gibt eine Liste aller aktiven JobScheduler-Jobs (einschließlich WorkManager-Workern) zusammen mit den angegebenen Einschränkungen und den vom System auferlegten Einschränkungen zurück. Außerdem wird der Jobverlauf zurückgegeben. 

Verwenden Sie diese Option, wenn Sie Ihre geplanten Aufgaben und die zugehörigen Einschränkungen auf andere Weise ansehen möchten. Bei WorkManager-Versionen vor WorkManager 2.10.0 gibt adb shell dumpsys jobscheduler eine Liste von Workern mit diesem Namen zurück:

  [package name]/androidx.work.impl.background.systemjob.SystemJobService

Wenn Ihre App mehrere Worker hat, können Sie nach dem Aktualisieren auf WorkManager 2.10.0 die Namen der Worker sehen und sie so leichter unterscheiden:

  #WorkerName#@[package name]/androidx.work.impl.background.systemjob.SystemJobService

Vorteile : Mit diesem Befehl können Sie herausfinden, ob es systembedingte Einschränkungen  gab, die Sie mit dem Background Task Inspector nicht ermitteln können. So wird beispielsweise der Standby-Bucket Ihrer App zurückgegeben, der sich auf das Zeitfenster auswirken kann, in dem geplante Aufgaben abgeschlossen werden.

Debug-Logging aktivieren

Sie können benutzerdefiniertes Logging aktivieren, um ausführliche WorkManager-Logs mit dem Tag WM— zu sehen. 

Vorteile:Sie können sehen, wann Arbeit geplant ist, wann Einschränkungen erfüllt sind und wann Lebenszyklusereignisse eintreten. Diese Logs können Sie bei der Entwicklung Ihrer App einsehen.

WorkInfo.StopReason

Wenn Sie bei einem bestimmten Worker eine unvorhersehbare Leistung feststellen, können Sie programmatisch den Grund dafür ermitteln, warum der Worker beim vorherigen Ausführungsversuch mit WorkInfo.getStopReason beendet wurde. 

Es empfiehlt sich, Ihre App so zu konfigurieren, dass sie WorkInfo mit getWorkInfoByIdFlow beobachtet, um festzustellen, ob Ihre Arbeit durch Hintergrundbeschränkungen, Einschränkungen, häufige Zeitüberschreitungen oder sogar durch den Nutzer beendet wird.

Vorteile:Mit WorkInfo.StopReason können Sie Felddaten zur Leistung Ihrer Mitarbeiter erfassen.

Hohe Wakelock-Dauer beheben, die von Android Vitals für WorkManager gemeldet wurde

In Android Vitals gibt es den Messwert „Übermäßige Teil-Wakelocks“, der Wakelocks hervorhebt, die zur Akkuentladung beitragen. WorkManager ruft Wake Locks ab, um Aufgaben auszuführen. Wenn die Wake Locks den von Google Play festgelegten Grenzwert überschreiten, kann sich das auf die Sichtbarkeit Ihrer App auswirken. Wie können Sie herausfinden, warum Ihrer Arbeit so viel Wake Lock-Dauer zugewiesen wird? Sie können die folgenden Tools verwenden.

Dashboard von Android Vitals

Prüfen Sie zuerst im Dashboard für übermäßige Wake Locks bei Android Vitals, ob die lange Wake Lock-Dauer auf WorkManager zurückzuführen ist und nicht auf einen Alarm oder einen anderen Wake Lock. In der Dokumentation Von anderen APIs erstellte Wake Locks identifizieren erfahren Sie, welche Wake Locks aufgrund von WorkManager gehalten werden. 

Perfetto

Perfetto ist ein Tool zum Analysieren von System-Traces. Wenn Sie das Tool speziell zur Fehlerbehebung bei WorkManager verwenden, können Sie im Bereich „Gerätestatus“ sehen, wann Ihr Work gestartet wurde, wie lange er ausgeführt wurde und wie er zum Stromverbrauch beiträgt. 

Im Track „Gerätestatus: Jobs“ sehen Sie alle ausgeführten Worker und die zugehörigen Wake Locks.

Abschnitt „Gerätestatus“ in Perfetto mit der Ausführung von „CleanupWorker“ und „BlurWorker“

Ressourcen

Auf der Seite WorkManager debuggen finden Sie eine Übersicht der verfügbaren Debugging-Methoden für andere Szenarien, die auftreten können.

Wenn Sie einige dieser Methoden selbst ausprobieren und mehr über das Debuggen von WorkManager erfahren möchten, sehen Sie sich das Codelab Erweiterte Funktionen in WorkManager und Tests an.

Nächste Schritte

Heute haben wir uns nicht nur mit dem Verkleinern von Code beschäftigt, sondern auch angesehen, wie die Android-Laufzeit und Jetpack Compose Ihre App rendern. Ob es darum geht, kritische Pfade mit Baseline-Profilen vorzukompilieren oder Scrollstatus mit den neuen Funktionen von Compose 1.9 und 1.10 zu optimieren – bei diesen Tools geht es um die Wirkung Ihrer App. Außerdem haben wir uns ausführlich mit Best Practices für das Debuggen von Hintergrundaufgaben beschäftigt.

Android fragen

Am Freitag veranstalten wir eine Live-Frage-und-Antwort-Runde zum Thema Leistung. Stelle jetzt deine Fragen unter dem Hashtag #AskAndroid und lass sie von den Experten beantworten.

Die Herausforderung

Wir haben Sie am Montag aufgefordert, R8 zu aktivieren. Heute bitten wir Sie, ein Baseline-Profil für Ihre App zu erstellen.

Mit Android Studio Otter ist das dank des Assistenten für das Modul „Baseline Profile Generator“ einfacher denn je. Wählen Sie den wichtigsten Nutzerablauf aus, auch wenn es nur der App-Start und die Anmeldung ist, und erstellen Sie ein Profil.

Führen Sie dann einen Macrobenchmark aus, um CompilationMode.None mit CompilationMode.Partial zu vergleichen.

Teile deine Verbesserungen bei der Startzeit in den sozialen Medien mit #optimizationEnabled.

Morgen einschalten

Sie haben Ihre App mit R8 verkleinert und die Laufzeit mit Profile Guided Optimization optimiert. Aber wie können Sie diese Vorteile Ihren Stakeholdern nachweisen? Und wie können Sie Regressionen erkennen, bevor sie in die Produktion gelangen?

Morgen geht es weiter mit Tag 4: Leitfaden zur Leistungsoptimierung. Wir zeigen Ihnen, wie Sie Ihren Erfolg messen können – von Felddaten in Play Vitals bis hin zu detaillierten lokalen Analysen mit Perfetto.