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

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

APK-Größe und Build-Zeiten

In diesem Abschnitt werden die Auswirkungen auf die APK-Größe und die Build-Zeit anhand der Beispiel-App Sunflower erläutert. Diese App zeigt Best Practices für die Migration einer ansichtsbasierten App zu Compose.

APK-Größe

Wenn Sie Ihrem Projekt Bibliotheken hinzufügen, erhöht sich die APK-Größe. Die folgenden Ergebnisse beziehen sich auf das minimierte Release-APK der einzelnen Projekte mit aktivierter Ressourcen- und Codekomprimierung im vollständigen R8-Modus, gemessen mit dem APK Analyzer.

Nur Aufrufe Gemischte Ansichten und Compose Nur verfassen
Downloadgröße 2.252 KB 3.034 KB 2.966 KB

Als Compose zum ersten Mal zu Sunflower hinzugefügt wurde, stieg die APK-Größe von 2.252 KB auf 3.034 KB – ein Anstieg 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.

Als Sunflower dagegen zu einer reinen Compose-App migriert wurde, verringerte sich die APK-Größe von 3.034 KB auf 2.966 KB, also um 68 KB. Diese Verringerung war auf das Entfernen nicht verwendeter Ansichtsabhängigkeiten wie AppCompat und ConstraintLayout zurückzuführen.

Build-Dauer

Wenn Sie Compose hinzufügen, erhöht sich die Build-Zeit Ihrer App, da der Compose-Compiler die zusammensetzbaren Funktionen in Ihrer App verarbeitet. Die folgenden Ergebnisse wurden mit dem eigenständigen Tool gradle-profiler erzielt, das einen Build mehrmals ausführt, um eine durchschnittliche Build-Zeit für die Debug-Build-Dauer von Sunflower zu erhalten:

gradle-profiler --benchmark --project-dir . :app:assembleDebug
Nur Aufrufe Gemischte Ansichten und Compose Nur verfassen
Durchschnittliche Build-Dauer 299,47 ms 399,09 ms 342,16 ms

Als Compose zum ersten Mal zu Sunflower hinzugefügt wurde, stieg die durchschnittliche Build-Zeit von 299 ms auf 399 ms – ein Anstieg 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.

Umgekehrt sank die durchschnittliche Build-Zeit auf 342 ms, was einer Verringerung um 57 ms entspricht, als die Migration von Sunflower zu Compose abgeschlossen war. Diese Reduzierung ist auf mehrere Faktoren zurückzuführen, die zusammen die Build-Zeit verkürzen, z. B. das Entfernen der Datenbindung, die Migration von Abhängigkeiten, die kapt zu KSP verwenden, und die Aktualisierung mehrerer Abhängigkeiten auf die neuesten Versionen.

Zusammenfassung

Die Verwendung von Compose erhöht die APK-Größe Ihrer App und aufgrund des Kompilierungsprozesses von Compose-Code auch die Build-Zeit Ihrer App. Diese Nachteile müssen jedoch gegen die Vorteile von Compose abgewogen werden, insbesondere im Hinblick auf die Steigerung der Entwicklerproduktivität bei der Einführung von Compose. Das Google Play Store-Team hat beispielsweise festgestellt, dass beim Schreiben von Benutzeroberflächen viel weniger Code erforderlich ist, manchmal bis zu 50%. Dadurch werden die Produktivität und die Wartbarkeit des Codes erhöht.

Weitere Fallstudien finden Sie unter Compose für Teams einführen.

Laufzeitleistung

In diesem Abschnitt werden Themen im Zusammenhang mit der Laufzeitleistung in Jetpack Compose behandelt. So können Sie die Leistung von Jetpack Compose mit der des View-Systems vergleichen und messen.

Intelligente Neuzusammenstellungen

Wenn Teile der Benutzeroberfläche ungültig sind, versucht Compose, nur die Teile neu zu erstellen, die aktualisiert werden müssen. Weitere Informationen dazu finden Sie in der Dokumentation zum Lebenszyklus von Composables und zu den Jetpack Compose-Phasen.

Baseline-Profile

Baseline-Profile sind eine hervorragende Möglichkeit, gängige User Journeys zu beschleunigen. Wenn Sie ein Baseline-Profil in Ihre App einbinden, kann sich die Ausführungsgeschwindigkeit von Code ab dem ersten Start um etwa 30% verbessern, da die Schritte zur Interpretation und Just-in-time (JIT)-Kompilierung für die enthaltenen Codepfade vermieden werden.

Die Jetpack Compose-Bibliothek enthält ein eigenes Baseline-Profil. Wenn Sie Compose in Ihrer App verwenden, werden diese Optimierungen automatisch angewendet. Sie wirken sich jedoch nur auf Codepfade innerhalb der Compose-Bibliothek aus. Daher empfehlen wir, 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 View

Jedes View, das auf dem Bildschirm gezeichnet wird, z. B. TextView, Button oder ImageView, erfordert Arbeitsspeicherzuweisungen, explizites Status-Tracking und verschiedene Callbacks, um alle Anwendungsfälle zu unterstützen. Außerdem muss der Inhaber des benutzerdefinierten View eine explizite Logik implementieren, um ein erneutes Zeichnen zu verhindern, wenn es nicht erforderlich ist, z. B. bei wiederholter Datenverarbeitung.

Jetpack Compose bietet hierfür verschiedene Lösungen. Compose hat keine expliziten aktualisierbaren Objekte zum Zeichnen von Ansichten. UI-Elemente sind einfache zusammensetzbare Funktionen, deren Informationen auf wiederholbare Weise in die Komposition geschrieben werden. So werden explizites Statustracking, Arbeitsspeicherzuweisungen und Callbacks auf die Composables beschränkt, die diese Funktionen benötigen, anstatt sie für alle Erweiterungen eines bestimmten View-Typs zu verlangen.

Außerdem bietet Compose intelligente Neuzusammensetzungen, bei denen das zuvor gezeichnete Ergebnis wiedergegeben wird, wenn Sie keine Änderungen vornehmen müssen.

Mehrere Layoutdurchläufe

Herkömmliche ViewGroups bieten in ihren Mess- und Layout-APIs viele Ausdrucksmöglichkeiten, was sie anfällig für mehrere Layoutdurchgänge macht. Diese mehrfachen Layoutdurchläufe können zu exponentieller Arbeit führen, wenn sie an bestimmten verschachtelten Punkten in der Ansichtshierarchie durchgeführt werden.

Jetpack Compose erzwingt über seinen API-Vertrag einen einzelnen Layoutdurchlauf für alle Layout-Kompositionen. So kann Compose tiefe UI-Bäume effizient verarbeiten. Wenn mehrere Messungen erforderlich sind, bietet Compose intrinsische 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 eingespart, da Layouts in Kotlin geschrieben und wie der Rest Ihrer App kompiliert werden.

Benchmark Compose

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

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 Regressionen zu erkennen. Sehen Sie sich beispielsweise den Benchmark für LazyColumn und das zugehörige Dashboard an, um Regressionen zu verfolgen.

Compose-Profilinstallation

Da Jetpack Compose eine ungebündelte Bibliothek ist, profitiert sie nicht von Zygote, das die UI-Toolkit-Klassen und Drawables des View-Systems vorab lädt. Jetpack Compose 1.0 verwendet die Profilinstallation für Release-Builds. Mit Profilinstallationsprogrammen können Apps kritischen Code angeben, der bei der Installation Ahead-of-Time (AOT) kompiliert werden soll. Compose enthält Regeln für die Profilinstallation, die die Startzeit und das Ruckeln in Compose-Apps reduzieren.