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-Zeiten

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 beziehen sich auf das minimierte Release-APK jedes Projekts mit aktivierter Ressourcen- und Code-Komprimierung, mit dem Vollmodus von R8 und wurden mit dem 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 Ansichten 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 Buildzeit Ihrer App, da der Compose-Compiler Composables in Ihrer App verarbeitet. Die folgenden Ergebnisse wurden mit dem eigenständigen Tool gradle-profiler erzielt, das einen Build mehrmals ausführt, damit eine durchschnittliche Buildzeit für die Dauer des Debug-Builds von Sunflower ermittelt werden kann:

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

Als Compose zum ersten Mal zu Sunflower hinzugefügt wurde, erhöhte sich die durchschnittliche Buildzeit von 299 ms auf 399 ms – eine Erhöhung 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 Abwägungen müssen jedoch gegen die Vorteile von Compose abgewogen werden, insbesondere im Hinblick auf die Produktivitätssteigerung von Entwicklern bei der Einführung 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 for Teams einführen.

Laufzeitleistung

In diesem Abschnitt werden Themen zur Laufzeitleistung in Jetpack Compose behandelt. Sie erfahren, wie sich Jetpack Compose im Vergleich zur Leistung des View-Systems schlägt und wie Sie sie messen können.

Intelligente Neuzusammensetzungen

Wenn Teile der Benutzeroberfläche ungültig sind, versucht Compose, nur die Teile neu zu erstellen, 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

Referenzprofile sind eine hervorragende Möglichkeit, gängige Nutzerpfade zu beschleunigen. Wenn Sie ein Baseline-Profil in Ihre App einbinden, lässt sich die Codeausführungsgeschwindigkeit nach der ersten Ausführung um etwa 30% verbessern, da die Interpretation und die Just-in-Time-Kompilierung (JIT) 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. 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 der 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.

Außerdem 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 mehrmaligen Layoutdurchläufe können zu exponentiell mehr Arbeit führen, wenn sie an bestimmten verschachtelten Stellen in der Ansichtshierarchie ausgeführt werden.

Jetpack Compose erzwingt über seinen API-Vertrag einen einzelnen Layout-Pass für alle Layout-Kompositionen. 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. Verwenden Sie für repräsentative Zeitangaben immer den Build release anstelle von debug, wenn Sie Ihre App profilieren.

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 den Benchmark für die Lazy-Spalte und das zugehörige Dashboard an, um Regressionen zu verfolgen.

Profilinstallation erstellen

Da Jetpack Compose eine nicht gebundelte Bibliothek ist, kann es nicht von Zygote profitieren, das die UI Toolkit-Klassen und Drawables des View-Systems vorlädt. In Jetpack Compose 1.0 wird die Profilinstallation für Release-Builds verwendet. 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.