Messwerte für „Schreiben“ und „Aufrufen“ vergleichen

Jetpack Compose beschleunigt die UI-Entwicklung und verbessert die Android-Entwicklung. Beachten Sie jedoch, dass sich das Hinzufügen von Compose zu einer vorhandenen App auf Messwerte wie die APK-Größe, den Build und die Laufzeitleistung einer App auswirken kann.

APK-Größe und Build-Dauer

In diesem Abschnitt werden die Auswirkungen auf die APK-Größe und die Buildzeit anhand der Beispiel-App Sunflower untersucht. Diese App veranschaulicht Best Practices für die Migration einer View-basierten App zu Compose.

APK-Größe

Wenn Sie Ihrem Projekt Bibliotheken hinzufügen, erhöht sich die APK-Größe. Die folgenden Ergebnisse gelten für das reduzierte Release-APK jedes Projekts, bei dem die Ressourcen- und Codeschrumpfung aktiviert ist, unter Verwendung des R8-Modus "Voll" und mit APK Analyzer gemessen.

Als Compose zum ersten Mal zu Sunflower hinzugefügt wurde, stieg die APK-Größe von 2.252 KB auf 3.034 KB – eine Erhöhung um 782 KB. Das generierte APK bestand aus dem UI-Build mit einer Mischung aus „Views“ und „Compose“. Dieser Anstieg ist zu erwarten, da Sunflower zusätzliche Abhängigkeiten hinzugefügt wurden.

Im Umkehrschluss konnte die APK-Größe von Sunflower nach der Migration zu einer reinen Compose-App von 3.034 KB auf 2.966 KB reduziert werden – eine Reduzierung um 68 KB. Dieser Rückgang ist auf das Entfernen nicht verwendeter Ansichtsabhängigkeiten wie AppCompat und ConstraintLayout zurückzuführen.

Build-Zeit

Wenn Sie Compose hinzufügen, erhöht sich die Build-Zeit Ihrer Anwendung, da der Compose-Compiler zusammensetzbare Funktionen in Ihrer Anwendung verarbeitet. Die folgenden Ergebnisse wurden mit dem eigenständigen gradle-profiler-Tool abgerufen, das einen Build mehrmals ausführt, sodass die durchschnittliche Build-Zeit für die Debug-Build-Dauer von Sunflower ermittelt werden kann:

gradle-profiler --benchmark --project-dir . :app:assembleDebug

Beim ersten Hinzufügen von Compose in Sunflower wurde die durchschnittliche Build-Zeit von 299 ms auf 399 ms erhöht – also um 100 ms. Diese Dauer ist darauf zurückzuführen, dass der Compose-Compiler zusätzliche Aufgaben ausführt, um den im Projekt definierten Compose-Code zu transformieren.

Im Gegensatz dazu sank die durchschnittliche Buildzeit nach Abschluss der Migration von Sunflower zu Compose auf 342 ms, was einer Reduzierung um 57 ms entspricht. Diese Verringerung lässt sich auf mehrere Faktoren zurückführen, die die Buildzeit insgesamt reduzieren, z. B. das Entfernen der Datenbindung, die Migration von Abhängigkeiten, die kapt verwenden, zu KSP und die Aktualisierung mehrerer Abhängigkeiten auf die neuesten Versionen.

Zusammenfassung

Wenn Sie Compose verwenden, erhöht sich die APK-Größe Ihrer App und die Buildzeit Ihrer App wird aufgrund des Kompilierungsprozesses von Compose-Code ebenfalls erhöht. Diese Kompromisse müssen jedoch gegen die Vorteile von Compose abgewogen werden, insbesondere im Hinblick auf die Steigerung der Entwicklerproduktivität bei der Verwendung von Compose. Das Play Store-Team hat beispielsweise festgestellt, dass für die Erstellung der Benutzeroberfläche viel weniger Code erforderlich ist, manchmal bis zu 50%weniger, was die Produktivität und Wartbarkeit des Codes erhöht.

Weitere Fallstudien finden Sie unter Compose für Teams verwenden.

Laufzeitleistung

In diesem Abschnitt werden Themen zur Laufzeitleistung in Jetpack Compose behandelt, um zu verstehen, wie Jetpack Compose im Vergleich zur Leistung des View-Systems abschneidet und wie Sie sie messen können.

Intelligente Neuzusammensetzungen

Wenn Teile der UI ungültig sind, versucht Compose, nur die Teile neu zusammenzusetzen, die aktualisiert werden müssen. Weitere Informationen finden Sie in der Dokumentation zum Lebenszyklus von Compose-Elementen und zu den Phasen von Jetpack Compose.

Baseline-Profile

Baseline-Profile sind eine hervorragende Möglichkeit, gängige Nutzerpfade zu beschleunigen. Wenn Sie Ihrer Anwendung ein Baseline-Profil hinzufügen, können Sie die Geschwindigkeit der Codeausführung ab dem ersten Start um etwa 30% verbessern, da keine Interpretation und JIT-Kompilierungsschritte für enthaltene Codepfade ausgeführt werden müssen.

Die Jetpack Compose-Bibliothek enthält ein eigenes Baseline-Profil. Wenn Sie Compose in Ihrer App verwenden, werden diese Optimierungen automatisch angewendet. Diese Optimierungen wirken sich jedoch nur auf Codepfade innerhalb der Compose-Bibliothek aus. Wir empfehlen Ihnen daher, Ihrer App ein Baseline-Profil hinzuzufügen, um Codepfade außerhalb von Compose abzudecken.

Vergleich mit dem View-System

Jetpack Compose bietet viele Verbesserungen gegenüber dem View-System. Diese Verbesserungen werden in den folgenden Abschnitten beschrieben.

Alles erweitert die Ansicht

Für jede View, die auf dem Bildschirm gezeichnet wird, z. B. TextView, Button oder ImageView, sind Speicherzuweisungen, explizite Statusverfolgung und verschiedene Rückrufe erforderlich, um alle Anwendungsfälle zu unterstützen. Außerdem muss der Inhaber des benutzerdefinierten View eine explizite Logik implementieren, um ein unnötiges Neuzeichnen zu verhindern, z. B. bei wiederholter Datenverarbeitung.

Jetpack Compose bietet dafür mehrere Möglichkeiten. In Compose gibt es keine expliziten aktualisierbaren Objekte für Zeichnungsansichten. UI-Elemente sind einfache kombinierbare Funktionen, deren Informationen auf speicherbare Weise in die Komposition geschrieben werden. So können explizites Status-Tracking, Speicherzuweisungen und Rückrufe auf die Composables beschränkt werden, für die diese Funktionen erforderlich sind, anstatt sie für alle Erweiterungen eines bestimmten View-Typs zu benötigen.

Darüber hinaus bietet „Compose“ intelligente Neuzusammensetzungen, bei denen das zuvor gezeichnete Ergebnis wiedergegeben wird, wenn keine Änderungen erforderlich sind.

Karten/Tickets mit mehreren Layouts

Traditionelle ViewGroups haben sehr ausdrucksstarke Mess- und Layout-APIs, die sie anfällig für mehrere Layoutdurchläufe machen. Diese mehrfachen Layoutübergänge können zu exponentiellen Arbeitsschritten führen, wenn sie an bestimmten verschachtelten Punkten in der Ansichtshierarchie ausgeführt werden.

Jetpack Compose erzwingt über seinen API-Vertrag einen einzelnen Layout-Pass für alle Layout-Composeables. So kann Compose tiefe UI-Bäume effizient verarbeiten. Wenn mehrere Messungen erforderlich sind, bietet Compose eigene Messungen.

Startleistung ansehen

Das View-System muss XML-Layouts aufblähen, wenn ein bestimmtes Layout zum ersten Mal angezeigt wird. Diese Kosten werden in Jetpack Compose gespart, da Layouts in Kotlin geschrieben und wie der Rest Ihrer App kompiliert werden.

Compose benchmarken

In Jetpack Compose 1.0 gibt es erhebliche Unterschiede zwischen der Leistung einer App im debug- und release-Modus. Für repräsentative Zeitangaben sollten Sie beim Profiling Ihrer App immer den Build release anstelle von debug verwenden.

Mit der Jetpack Macrobenchmark-Bibliothek können Sie die Leistung Ihres Jetpack Compose-Codes prüfen. Informationen zur Verwendung mit Jetpack Compose finden Sie im MacrobenchmarkSample-Projekt.

Das Jetpack Compose-Team verwendet Macrobenchmark auch, um mögliche Rückschritte zu erkennen. Sehen Sie sich beispielsweise die Benchmark für verzögerte Spalten und das Dashboard an, um Regressionen zu verfolgen.

Installation des Profils erstellen

Da Jetpack Compose eine nicht gebundelte Bibliothek ist, profitiert sie nicht von Zygote, das die UI Toolkit-Klassen und Drawables des View-Systems vorlädt. Jetpack Compose 1.0 verwendet die Profilinstallation für Release-Builds. Mit Profil-Installationsprogrammen können Apps kritischen Code angeben, der bei der Installation vorab (AOT) kompiliert werden soll. Compose liefert Installationsregeln für Profile aus, die die Startzeit und Ruckler in Compose-Apps reduzieren.