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

Lesemodus Mischansichten und „Schreiben“ Nur schreiben
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 – 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
Nur Aufrufe Mischansichten und „Schreiben“ Schreibgeschützt
Durchschnittliche Build-Zeit 299,47 ms 399,09 ms 342,16 ms

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. Dies 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 for Teams einführen.

Laufzeitleistung

In diesem Abschnitt werden Themen zur Laufzeitleistung in Jetpack Compose behandelt. So können Sie besser nachvollziehen, wie sich Jetpack Compose im Vergleich zur Leistung des View-Systems schlägt und wie Sie diese 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 zusammensetzbaren Funktionen und zu den Phasen der Jetpack Compose-Phase.

Referenzprofile

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 hat im Vergleich zum Ansichtssystem viele Verbesserungen. 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. Darüber hinaus muss der benutzerdefinierte View-Inhaber eine explizite Logik implementieren, um zu verhindern, dass Daten entnommen werden, wenn dies nicht erforderlich ist, 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-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 außerdem MacroBenchmark, um mögliche Regressionen 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, 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, die die Startzeit und Verzögerungen in Compose-Anwendungen reduzieren.