Confrontare le metriche di Scrivi e Visualizza

Jetpack Compose accelera lo sviluppo dell'UI e migliora lo sviluppo di Android. Tuttavia, tieni presente che l'aggiunta di Compose a un'app esistente può influire su metriche come le dimensioni dell'APK, la build e il rendimento di runtime di un'app.

Dimensioni dell'APK e tempi di build

Questa sezione esamina l'impatto sulle dimensioni dell'APK e sul tempo di compilazione esaminando l' app di esempio Sunflower, un'app che dimostra le best practice per la migrazione di un'app basata su View a Compose.

Dimensioni dell'APK

L'aggiunta di librerie al progetto ne aumenta le dimensioni dell'APK. I seguenti risultati si riferiscono all'APK di release ridotto di ogni progetto con la riduzione di risorse e codice abilitata, utilizzando la modalità completa R8 e misurata con Strumento di analisi APK.

Quando è stato aggiunto Compose a Sunflower per la prima volta, le dimensioni dell'APK sono aumentate da 2252 kB a 3034 kB, con un aumento di 782 kB. L'APK generato consisteva nella build dell'UI con un mix di visualizzazioni e Compose. Questo aumento è prevedibile in quanto sono state aggiunte dipendenze aggiuntive a Sunflower.

Al contrario, quando Sunflower è stata migrata a un'app solo Compose, le dimensioni dell'APK sono diminuite da 3034 kB a 2966 kB, con una diminuzione di 68 kB. Questa diminuzione è dovuta alla rimozione delle dipendenze di visualizzazione inutilizzate, come AppCompat e ConstraintLayout.

Tempo di compilazione

L'aggiunta di Compose aumenta il tempo di compilazione dell'app, poiché il compilatore Compose elabora i componibili nell'app. I seguenti risultati sono stati ottenuti utilizzando lo strumento autonomo gradle-profiler, che esegue una build più volte in modo da poter ottenere un tempo di compilazione medio per la durata della build di debug di Sunflower:

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

Quando è stato aggiunto Compose a Sunflower per la prima volta, il tempo di compilazione medio è aumentato da 299 ms a 399 ms, con un aumento di 100 ms. Questa durata è dovuta al fatto che il compilatore Compose esegue attività aggiuntive per trasformare il codice Compose definito nel progetto.

Al contrario, il tempo di compilazione medio è sceso a 342 ms, con una diminuzione di 57 ms, al termine della migrazione di Sunflower a Compose. Questa riduzione può essere attribuita a diversi fattori che riducono collettivamente il tempo di compilazione, come la rimozione del data binding, la migrazione delle dipendenze che utilizzano kapt a KSP e l'aggiornamento di diverse dipendenze alle versioni più recenti.

Riepilogo

L'adozione di Compose aumenterà effettivamente le dimensioni dell'APK dell'app e anche il rendimento del tempo di build dell'app a causa del processo di compilazione del codice Compose. Tuttavia, questi compromessi devono essere valutati rispetto ai vantaggi di Compose, in particolare per quanto riguarda l'aumento della produttività degli sviluppatori quando si adotta Compose. Ad esempio, il team del Play Store ha scoperto che la scrittura dell'UI richiede molto meno codice, a volte fino al 50%, aumentando così la produttività e la manutenibilità del codice.

Puoi leggere altri case study in Adotta Compose per i team.

Rendimento di runtime

Questa sezione tratta argomenti relativi al rendimento del tempo di esecuzione in Jetpack Compose per aiutarti a capire come si confronta Jetpack Compose con il rendimento del sistema View e come puoi misurarlo.

Ricompilazioni intelligenti

Quando le parti dell'UI non sono valide, Compose tenta di ricompilare solo le parti che devono essere aggiornate. Scopri di più nella documentazione relativa al ciclo di vita dei componibili e alle fasi di Jetpack Compose.

Profili di baseline

I profili di baseline sono un modo eccellente per velocizzare i percorsi utente comuni. L'inclusione di un profilo di baseline nell'app può migliorare la velocità di esecuzione del codice di circa il 30% dal primo avvio, evitando i passaggi di interpretazione e compilazione just-in-time (JIT) per i percorsi di codice inclusi.

La libreria Jetpack Compose include il proprio profilo di baseline e ottieni automaticamente queste ottimizzazioni quando utilizzi Compose nella tua app. Tuttavia, queste ottimizzazioni interessano solo i percorsi di codice all'interno della libreria Compose, pertanto ti consigliamo di aggiungere un profilo di baseline alla tua app per coprire i percorsi di codice al di fuori di Compose.

Confronto con il sistema View

Jetpack Compose offre molti miglioramenti rispetto al sistema View. Questi miglioramenti sono descritti nelle sezioni seguenti.

Tutto estende View

Ogni View che viene disegnata sullo schermo, come TextView, Button o ImageView, richiede allocazioni di memoria, monitoraggio esplicito dello stato e vari callback per supportare tutti i casi d'uso. Inoltre, il proprietario di View personalizzato deve implementare una logica esplicita per impedire il ridisegno quando non è necessario, ad esempio per l'elaborazione ripetitiva dei dati.

Jetpack Compose risolve questo problema in diversi modi. Compose non ha oggetti aggiornabili espliciti per il disegno delle visualizzazioni. Gli elementi dell'UI sono semplici funzioni componibili le cui informazioni vengono scritte nella composizione in modo riproducibile. In questo modo è possibile ridurre il monitoraggio esplicito dello stato, le allocazioni di memoria e i callback solo ai componibili che richiedono queste funzionalità, anziché richiederle a tutte le estensioni di un determinato tipo di View.

Inoltre, Compose fornisce ricompilazioni intelligenti, riproducendo il risultato disegnato in precedenza se non devi apportare modifiche.

Più passaggi di layout

I ViewGroup tradizionali hanno molta espressività nelle API di misurazione e layout che li rendono soggetti a più passaggi di layout. Questi passaggi di layout multipli possono causare un lavoro esponenziale se eseguiti in punti nidificati specifici nella gerarchia delle visualizzazioni.

Jetpack Compose applica un singolo passaggio di layout per tutti i componibili di layout tramite il contratto API. In questo modo, Compose può gestire in modo efficiente alberi dell'UI profondi. Se sono necessarie più misurazioni, Compose dispone di misurazioni intrinseche.

Rendimento di avvio della visualizzazione

Il sistema View deve espandere i layout XML quando mostra un determinato layout per la prima volta. Questo costo viene salvato in Jetpack Compose, poiché i layout sono scritti in Kotlin e compilati come il resto dell'app.

Benchmark di Compose

In Jetpack Compose 1.0, esistono differenze notevoli tra il rendimento di un'app in modalità debug e release. Per i tempi rappresentativi, utilizza sempre la build release anziché debug durante la profilazione dell'app.

Per verificare il rendimento del codice Jetpack Compose, puoi utilizzare la libreria Jetpack Macrobenchmark. Per scoprire come utilizzarla con Jetpack Compose, consulta il progetto MacrobenchmarkSample.

Il team di Jetpack Compose utilizza anche Macrobenchmark per rilevare eventuali regressioni. Ad esempio, consulta il benchmark per la colonna lazy e la relativa dashboard per monitorare le regressioni.

Installazione del profilo Compose

Poiché Jetpack Compose è una libreria non in bundle, non beneficia di Zygote che precarica le classi e i disegnabili del toolkit dell'UI del sistema View. Jetpack Compose 1.0 utilizza l'installazione del profilo per le build di release. I programmi di installazione del profilo consentono alle app di specificare il codice critico da compilare AOT (Ahead-Of-Time) al momento dell'installazione. Compose include regole di installazione del profilo che riducono il tempo di avvio e il jank nelle app Compose.