Traces de pile dans Compose

Jetpack Compose exécute votre code en plusieurs phases différentes, ce qui entraîne l'exécution de certaines parties de la fonction @Composable séparément les unes des autres. Les plantages survenant lors de ces phases peuvent entraîner des traces de pile difficiles à déchiffrer, ce qui rend difficile l'identification de la fonction ou de la ligne de code exactes à l'origine du plantage.

Ajouter des informations sur la source aux traces de pile

Pour améliorer la lisibilité des traces de pile, une API d'activation fournit des informations plus détaillées sur l'emplacement des plantages, y compris les noms et les emplacements composables. Vous pouvez ainsi :

• Identifier et résoudre efficacement les sources de plantages
• Isoler les plantages pour les échantillons reproductibles
• Examiner les plantages qui n'affichaient auparavant que des frames de pile internes

Le runtime Compose peut détecter l'emplacement du plantage dans la composition et reconstruire une trace de pile en fonction de votre hiérarchie @Composable. La trace de la pile est ajoutée pour les plantages dans :

• Composition
• DisposableEffect et LaunchedEffect (sauf onDispose ou annulation)
• Coroutines lancées dans rememberCoroutineScope
• Mesurer, mettre en page et dessiner des passes

Pour activer cette fonctionnalité, ajoutez les lignes suivantes au point d'entrée de l'application :

// Enable stack traces at application level: onCreate
class SampleStackTracesEnabledApp : Application() {

    override fun onCreate() {
        super.onCreate()
        // Enable Compose stack traces for minified builds only.
        Composer.setDiagnosticStackTraceMode(ComposeStackTraceMode.Auto)

        // Alternatively:
        // Enable verbose Compose stack traces for local debugging
        Composer.setDiagnosticStackTraceMode(ComposeStackTraceMode.SourceInformation)
    }
}
Stacktraces.kt

Idéalement, effectuez cette configuration avant de créer des compositions pour vérifier que les informations de la trace de pile sont collectées correctement.

Quatre options sont disponibles pour ComposeStackTraceMode :

• Auto : option recommandée, car elle utilise GroupKeys si l'application est minifiée et None dans le cas contraire.
• GroupKeys : les traces de pile sont créées pour les applications réduites. Les informations sur la clé de groupe sont conservées même après la minification. Elles sont utilisées avec le fichier de mappage ProGuard émis par le compilateur Compose et R8 pour reconstruire un emplacement approximatif des fonctions @Composable. Ces traces de pile sont moins précises et optimisées pour éviter d'effectuer des tâches supplémentaires au moment de l'exécution. Le compilateur Compose est compatible avec l'émission de mappages R8 supplémentaires à partir de Kotlin 2.3.0.
• SourceInformation : utile pour les builds non minimisés, collecte les informations sources et les ajoute à la trace de la pile. Les résultats sont plus précis, mais entraînent un coût de performances important, semblable à celui de l'association de l'inspecteur de mise en page. Elles sont créées pour être utilisées dans les versions de débogage des applications afin d'obtenir des informations précises sur un plantage qui nécessite plus d'informations sur son emplacement. Les informations sur la source sont supprimées des applications réduites pour optimiser la taille et les performances du binaire.
• None : aucun détail supplémentaire de trace de pile n'a été ajouté.

Lorsque vous utilisez l'option SourceInformation, la trace de pile apparaît sous la forme d'un DiagnosticComposeException dans la liste des exceptions supprimées :

java.lang.IllegalStateException: Test layout error
    at <original trace>
Suppressed: androidx.compose.runtime.DiagnosticComposeException:
Composition stack when thrown:
    at ReusableComposeNode(Composables.kt:<unknown line>)
    at Layout(Layout.kt:79)
    at <lambda>(TempErrorsTest.kt:164)
    at <lambda>(BoxWithConstraints.kt:66)
    at ReusableContentHost(Composables.kt:164)
    at <lambda>(SubcomposeLayout.kt:514)
    at SubcomposeLayout(SubcomposeLayout.kt:114)
    at SubcomposeLayout(SubcomposeLayout.kt:80)
    at BoxWithConstraints(BoxWithConstraints.kt:64)
    at SubcomposeLayoutErrorComposable(TempErrorsTest.kt:164)
    at <lambda>(TempErrorsTest.kt:86)
    at Content(ComposeView.android.kt:430)
    at <lambda>(ComposeView.android.kt:249)
    at CompositionLocalProvider(CompositionLocal.kt:364)
    at ProvideCommonCompositionLocals(CompositionLocals.kt:193)
    at <lambda>(AndroidCompositionLocals.android.kt:113)
    at CompositionLocalProvider(CompositionLocal.kt:364)
    at ProvideAndroidCompositionLocals(AndroidCompositionLocals.android.kt:102)
    at <lambda>(Wrapper.android.kt:141)
    at CompositionLocalProvider(CompositionLocal.kt:384)
    at <lambda>(Wrapper.android.kt:140)

Limites connues

Voici quelques problèmes connus concernant les frames de trace de pile :

Traces de pile des informations sur la source

Numéros de ligne manquants (<unknown line>) dans le premier frame de pile pour les plantages dans la composition. Étant donné que l'introspection des informations sur la source a lieu après un plantage, les données de la table d'emplacement peuvent être incomplètes et le numéro de ligne peut être supprimé. ReusableComposeNode et remember ne produisent pas d'informations sur la source. Vous verrez donc <unknown line> dans les frames de pile de ces fonctions.

Traces de pile des clés de groupe

Par conception, les traces de pile basées sur GroupKeys ne peuvent pointer que vers la première ligne de la fonction @Composable. Ils ne contiennent pas non plus de données pour les fonctions qui ne produisent pas de groupe (comme les fonctions en ligne ou celles qui ne renvoient pas d'unité).

Plantages de la collecte de traces de pile

Si la collecte de la trace de pile plante pour une raison quelconque, cette exception est ajoutée en tant qu'exception supprimée au lieu de DiagnosticComposeException.

Signalez tout plantage supprimé ou toute incohérence de trace de pile au composant Compose Runtime.