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, den Build und die Laufzeitleistung einer App auswirken kann.

APK-Größe und Build-Zeiten

In diesem Abschnitt wird die Auswirkung auf die APK-Größe und die Build-Zeit anhand der Sunflower-Beispiel-App untersucht. Diese App demonstriert 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 die minimierte Release-APK jedes Projekts mit aktivierter Ressourcen- und Code-Verkleinerung im R8-Vollmodus. Die Messung erfolgte mit dem APK Analyzer.

Als Compose zum ersten Mal in Sunflower eingeführt wurde, stieg die APK-Größe von 2.252 KB auf 3.034 KB, also 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 zu einer reinen Compose-App migriert wurde, sank die APK-Größe von 3.034 KB auf 2.966 KB, also um 68 KB. Diese Verringerung ist auf das Entfernen nicht verwendeter Ansichtsabhängigkeiten wie AppCompat und ConstraintLayout zurückzuführen.

Build-Zeit

Durch das Hinzufügen von Compose verlängert sich die Build-Zeit 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, sodass eine durchschnittliche Build-Zeit für die Debug-Build-Dauer von Sunflower ermittelt werden kann:

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

Als Compose zum ersten Mal in Sunflower eingeführt wurde, stieg die durchschnittliche Build-Zeit von 299 ms auf 399 ms, 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.

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

Zusammenfassung

Durch die Verwendung von Compose wird die APK-Größe Ihrer App erhöht. Außerdem dauert das Erstellen der App länger, da der Compose-Code kompiliert werden muss. Diese Nachteile müssen jedoch gegen die Vorteile von Compose abgewogen werden, insbesondere die Steigerung der Entwicklerproduktivität bei der Einführung von Compose. Das Play Store-Team hat beispielsweise festgestellt, dass für das Schreiben von Benutzeroberflächen viel weniger Code erforderlich ist, manchmal bis zu 50%weniger. Dadurch werden die Produktivität und die Wartungsfreundlichkeit des Codes erhöht.

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

Laufzeitleistung

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

Intelligente Neukompositionen

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

Baseline-Profile

Baseline-Profile sind eine hervorragende Möglichkeit, häufige Nutzerabläufe zu beschleunigen. Wenn Sie ein Baseline-Profil in Ihre App einbinden, kann die Codeausführungsgeschwindigkeit beim ersten Start um etwa 30% verbessert werden, da Interpretations- und JIT-Kompilierungsschritte (Just-in-time) für enthaltene Codepfade vermieden werden.

Die Jetpack Compose-Bibliothek enthält ein eigenes Baseline Profile. Wenn Sie Compose in Ihrer App verwenden, erhalten Sie diese Optimierungen automatisch. Diese Optimierungen wirken sich jedoch nur auf Codepfade innerhalb der Compose-Bibliothek aus. Wir empfehlen Ihnen daher, Ihrer App ein Baseline Profile 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 erbt von View

Für jedes View, das auf dem Bildschirm gerendert wird, z. B. TextView, Button oder ImageView, sind Speicherzuweisungen, explizite Statusverfolgung und verschiedene Callbacks erforderlich, um alle Anwendungsfälle zu unterstützen. Außerdem muss der benutzerdefinierte View-Inhaber eine explizite Logik implementieren, um ein erneutes Zeichnen zu verhindern, wenn es nicht erforderlich ist, z. B. bei der wiederholten Datenverarbeitung.

Jetpack Compose bietet hierfür mehrere Lösungen. Compose hat keine expliziten aktualisierbaren Objekte für Zeichenansichten. UI-Elemente sind einfache zusammensetzbare Funktionen, deren Informationen auf wiederholbare Weise in die Komposition geschrieben werden. So werden explizite Statusverfolgung, Speicherzuweisungen und Rückrufe auf die Composables beschränkt, die diese Funktionen benötigen, anstatt sie für alle Erweiterungen eines bestimmten View-Typs zu erzwingen.

Außerdem bietet Compose smarte Neukompositionen, bei denen das zuvor gezeichnete Ergebnis wiedergegeben wird, wenn keine Änderungen erforderlich sind.

Mehrere Layoutdurchläufe

Herkömmliche ViewGroups haben viele Ausdrucksmöglichkeiten in ihren APIs für Messung und Layout, was zu mehreren Layoutdurchläufen führen kann. Diese mehreren Layoutdurchläufe können zu exponentieller Arbeit führen, wenn sie an bestimmten verschachtelten Stellen in der Ansichtshierarchie ausgeführt werden.

Jetpack Compose erzwingt über seinen API-Vertrag einen einzelnen Layoutdurchlauf für alle Layout-Composables. So kann Compose tiefe UI-Strukturen effizient verarbeiten. Wenn mehrere Messungen erforderlich sind, bietet Compose integrierte 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.

Compose-Benchmark

In Jetpack Compose 1.0 gibt es erhebliche Leistungsunterschiede zwischen einer App im debug- und im release-Modus. Für repräsentative Zeitangaben immer den release-Build anstelle von debug verwenden, 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 Regressionen zu erkennen. Sehen Sie sich beispielsweise den Benchmark für die Lazy Column und das zugehörige Dashboard an, um Regressionen zu verfolgen.

Profilinstallation mit Compose

Da Jetpack Compose eine nicht gebündelte Bibliothek ist, profitiert sie nicht von Zygote, die 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 Profilinstallationsprogrammen können Apps kritischen Code angeben, der bei der Installation AOT-kompiliert (Ahead-of-Time) werden soll. Compose enthält Profilinstallationsregeln, die die Startzeit und Ruckler in Compose-Apps reduzieren.