Gérer la mémoire de votre application

Cette page explique comment réduire de manière proactive l'utilisation de la mémoire dans votre application. Pour savoir comment le système d'exploitation Android gère la mémoire, consultez la présentation de la gestion de mémoire.

La mémoire vive (RAM) est une ressource précieuse dans tout environnement de développement logiciel, et elle est encore plus utile sur un système d'exploitation mobile où la mémoire physique est souvent limitée. Bien qu'Android Runtime (ART) et la machine virtuelle Dalvik effectuent tous les deux une récupération de mémoire de routine, cela ne signifie pas que vous pouvez ignorer quand et où votre application alloue et libère de la mémoire. Vous devez toujours éviter les fuites de mémoire, généralement causées par la conservation de références d'objets dans des variables de membre statiques, et libérer des objets Reference au moment approprié, tels que définis par des rappels de cycle de vie.

Réduire l'empreinte de code et de ressources de votre application

Certaines ressources et bibliothèques de votre code peuvent utiliser de la mémoire à votre insu. La taille globale de votre application, y compris les bibliothèques tierces ou les ressources intégrées, peut affecter la quantité de mémoire utilisée par votre application. Vous pouvez améliorer l'utilisation de la mémoire de votre application en supprimant de votre code tous les composants, ressources et bibliothèques inutiles, redondants ou superflus.

Réduire la taille globale de l'application en activant R8

Le code d'application compilé fait partie intégrante de l'empreinte mémoire d'exécution. Chaque classe, méthode, dépendance de bibliothèque et constante de chaîne doivent être chargées dans la RAM lors de l'exécution. Plus votre codebase compilée est grande, plus votre application a besoin de RAM physique pour exister.

Vous pouvez utiliser R8 pour réduire l'espace mémoire utilisé par votre application. Bien que R8 soit traditionnellement connu pour réduire la taille des APK, il a un impact positif direct sur la mémoire d'exécution (RAM). R8 analyse le bytecode de votre application pour supprimer le code mort, fusionner les classes redondantes, insérer les méthodes et réduire les identifiants. En chargeant moins de bytecode compilé à partir de l'APK dans la RAM, il réduit l'empreinte mémoire de base globale de l'application. De plus, la minimisation des noms de classes, de méthodes et de champs en identifiants plus courts réduit directement la surcharge de RAM. Les optimisations telles que la fusion de classes et l'inlining de méthodes étendu remplacent également les modèles d'allocation et les recherches d'exécution coûteux, ce qui permet d'optimiser la mémoire du tas et de la pile.

Comprendre les règles de conservation

Les règles de conservation sont des instructions de configuration qui indiquent à R8 les parties de votre code à conserver pendant l'optimisation, ce qui l'empêche de supprimer ou de réduire le code sur lequel votre application s'appuie. Pour en savoir plus, consultez la Présentation des règles Keep.

Des règles de conservation mal rédigées empêchent R8 d'optimiser de grandes parties de votre codebase. Évitez les règles de conservation trop larges et suivez ces bonnes pratiques :

  • Règles globales à éviter :
    • -dontoptimize : désactive complètement l'optimisation pour l'ensemble de l'application, ce qui entraîne des exécutables plus volumineux et plus lents.
    • -dontshrink : empêche la suppression du code et des ressources inutilisés.
    • -dontobfuscate : empêche la minification des noms, ce qui vous prive d'économies de mémoire précieuses (en particulier dans les grandes applications).

  • Évitez les caractères génériques à l'échelle du package : les règles générales telles que -keep class com.example.package.** { *; } forcent R8 à conserver chaque classe, champ et méthode de ce package. Cela empêche complètement R8 de supprimer, d'optimiser ou de minifier le code de ce package.

  • Utilisez le fichier de configuration R8 par défaut : utilisez toujours proguard-android-optimize.txt.

Pour en savoir plus sur la création de règles de conservation, consultez la présentation des règles de conservation. Pour connaître les schémas spécifiques à utiliser et à éviter, consultez Bonnes pratiques concernant les règles Keep.

L'analyseur de configuration R8 fournit des informations sur votre configuration R8 et sur l'impact de chaque règle de conservation sur votre application. Pour savoir comment identifier les règles qui bloquent l'optimisation, consultez Analyseur de configuration R8.

Attention aux bibliothèques externes

Souvent, le code de bibliothèque externe n'est pas écrit pour les environnements mobiles et il peut être inefficace lorsqu'il est utilisé sur un client mobile. Lorsque vous utilisez une bibliothèque externe, vous devrez peut-être l'optimiser pour les appareils mobiles. Planifiez ce travail à l'avance et analysez la bibliothèque en termes de taille de code et d'empreinte RAM avant de l'utiliser.

Même certaines bibliothèques optimisées pour les mobiles peuvent poser problème en raison de leurs différentes implémentations. Par exemple, une bibliothèque peut utiliser des tampons de mémoire allégés rapides, tandis qu'une autre utilise des tampons de mémoire micro, ce qui entraîne deux intégrations de tampons différentes dans votre application. Cela peut se produire avec différentes intégrations de journalisation, d'analyse, de frameworks de chargement d'images, de mise en cache, et de bien d'autres éléments inattendus.

Bien que l'optimisation de votre application à l'aide de R8 puisse supprimer le code inutilisé des dépendances, son efficacité est souvent limitée par la configuration interne de la bibliothèque. Par exemple, des règles de conservation générales ou l'utilisation de la réflexion dans une bibliothèque peuvent empêcher R8 de réduire son code, ce qui entraîne une empreinte mémoire plus importante. Pour obtenir des stratégies sur la sélection de bibliothèques efficaces, consultez Choisir judicieusement les bibliothèques.

Évitez d'utiliser une bibliothèque partagée pour seulement une ou deux fonctionnalités sur des dizaines. N'importez pas une quantité importante de code et de frais généraux que vous n'utilisez pas. Lorsque vous envisagez d'utiliser une bibliothèque, recherchez l'implémentation qui correspond le mieux à vos besoins. Sinon, créez votre propre intégration.

Injection de dépendances avec Hilt ou Dagger 2

Les frameworks d'injection de dépendances peuvent simplifier le code que vous écrivez et fournir un environnement adaptatif utile pour tester et modifier la configuration.

Si vous avez l'intention d'utiliser un framework d'injection de dépendances dans votre application, envisagez d'utiliser Hilt ou Dagger. Hilt est une bibliothèque d'injection de dépendances pour Android qui s'exécute sur Dagger. Dagger n'utilise pas la réflexion pour scanner le code de votre application. Vous pouvez utiliser l'implémentation statique du temps de compilation de Dagger dans des applications Android sans coûts d'exécution ni utilisation de mémoire inutiles.

D'autres frameworks d'injection de dépendances qui utilisent la réflexion initialisent des processus en scannant votre code à la recherche d'annotations. Ce processus peut nécessiter beaucoup plus de cycles de processeur et de mémoire RAM, et entraîner un retard notable au lancement de l'application.

Lorsque vous utilisez l'injection de dépendances, veillez à éviter les fuites de mémoire en vous assurant que les objets sont correctement délimités. Conserver des objets plus longtemps que nécessaire en les associant au mauvais cycle de vie peut entraîner des fuites de mémoire. Pour en savoir plus, consultez les conseils sur l'évitement des fuites de mémoire avec des objets à portée limitée.

Charger les images de manière intentionnelle

Les bitmaps graphiques sont généralement les objets communs les plus volumineux résidant dans la mémoire de votre application. Même si vous travaillez avec des fichiers compressés tels que des fichiers JPEG, le fichier doit être décompressé en bitmap non compressé pour être affiché à l'écran. Un petit fichier image compressé peut se développer en un bitmap très volumineux.

Par exemple, la plupart des bitmaps utilisent la configuration ARGB_8888, ce qui signifie que chaque pixel nécessite 4 octets de mémoire (un octet chacun pour le rouge, le vert, le bleu et l'alpha (transparence)). Si vous avez un JPEG de 100 Ko et que vous l'affichez dans une vue de 1 000 x 1 000 pixels, le bitmap nécessitera 4 octets pour chacun de ces 1 000 000 pixels, ce qui représente jusqu'à 4 Mo de mémoire.

Vous pouvez optimiser votre utilisation des images de plusieurs façons. Par exemple, l'utilisation de bibliothèques de chargement d'images peut vous aider à libérer de la mémoire lorsque vous n'en avez pas besoin. Pour savoir comment gérer efficacement les images, consultez Optimiser les images bitmap.

Surveiller la mémoire disponible et l'utilisation de la mémoire

Vous devez identifier les problèmes d'utilisation de mémoire de votre application avant de pouvoir les résoudre. Le profileur de mémoire d'Android Studio vous aide à identifier et à diagnostiquer les problèmes de mémoire de différentes manières :

Le Profileur de mémoire s'intègre également à la bibliothèque de détection des fuites LeakCanary. En utilisant LeakCanary, vous pouvez transférer l'analyse des fuites de mémoire de l'appareil de test vers votre ordinateur de développement, ce qui peut accélérer considérablement votre workflow. Pour en savoir plus, consultez les notes de version d'Android Studio.

Il existe d'autres outils que vous pouvez utiliser pour diagnostiquer les problèmes de mémoire en fonction des données des utilisateurs qui exécutent votre application de production :

Libérer la mémoire en fonction d'événements

Android peut récupérer la mémoire de votre application ou l'arrêter complètement si nécessaire afin de libérer de la mémoire pour les tâches critiques, comme expliqué dans la présentation de la gestion de mémoire. Pour équilibrer davantage la mémoire système et éviter d'arrêter le processus de votre application comme le requiert le système, vous pouvez implémenter l'interface ComponentCallbacks2 dans vos classes Activity. La méthode de rappel onTrimMemory() fournie avertit votre application des événements liés au cycle de vie ou à la mémoire qui lui offrent une bonne occasion de réduire volontairement son utilisation de la mémoire. Libérer de la mémoire peut réduire la fréquence à laquelle votre application est arrêtée par le tueur de mémoire faible.

Votre implémentation de onTrimMemory() doit se concentrer exclusivement sur les événements TRIM_MEMORY_UI_HIDDEN et TRIM_MEMORY_BACKGROUND. (À partir d'Android 14, le système ne fournit plus de notifications pour les autres constantes héritées. Ces constantes sont officiellement obsolètes dans Android 15.)

  • TRIM_MEMORY_UI_HIDDEN : ce signal indique que l'UI de votre application n'est plus visible par l'utilisateur. Cette transition permet de libérer des allocations de mémoire importantes liées strictement à l'UI, telles que les bitmaps, les tampons de lecture vidéo ou les ressources d'animation complexes.

  • TRIM_MEMORY_BACKGROUND : ce signal indique que votre processus réside en arrière-plan et qu'il peut désormais être arrêté pour répondre aux besoins de mémoire globaux du système. Pour prolonger la durée pendant laquelle votre processus reste dans l'état mis en cache et réduire le nombre de démarrages à froid de l'application, vous devez libérer de manière agressive toutes les ressources qui peuvent être facilement reconstruites une fois que l'utilisateur reprend sa session.

Cet exemple de code montre comment implémenter le rappel onTrimMemory() pour répondre à différents événements liés à la mémoire :

Kotlin

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    // Other activity code.

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Java

import android.content.ComponentCallbacks2;
// Other import statements.

public class MainActivity extends AppCompatActivity
    implements ComponentCallbacks2 {

    // Other activity code.

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    public void onTrimMemory(int level) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Vérifier la quantité de mémoire dont vous avez besoin

Pour autoriser plusieurs processus en cours d'exécution, Android définit une limite stricte sur la taille du tas de mémoire alloué à chaque application. La limite exacte de cette taille varie selon les appareils, en fonction de la quantité de RAM dont ils disposent. Si votre application atteint la capacité du tas de mémoire et tente d'allouer plus de mémoire, le système génère une erreur OutOfMemoryError.

Pour éviter de manquer de mémoire, vous pouvez interroger le système afin de déterminer l'espace disponible sur l'appareil actuel pour le tas de mémoire. Dans ce cas, vous pouvez interroger le système en appelant getMemoryInfo(). Renvoie un objet ActivityManager.MemoryInfo qui fournit des informations sur l'état de la mémoire actuelle de l'appareil, y compris la mémoire disponible, la mémoire totale et le seuil de mémoire (niveau de mémoire à partir duquel le système se met à arrêter les processus). L'objet ActivityManager.MemoryInfo expose également lowMemory, qui est une valeur booléenne simple qui vous indique si l'appareil manque de mémoire.

L'exemple d'extrait de code suivant montre comment utiliser la méthode getMemoryInfo() dans votre application.

Kotlin

fun doSomethingMemoryIntensive() {

    // Before doing something that requires a lot of memory,
    // check whether the device is in a low memory state.
    if (!getAvailableMemory().lowMemory) {
        // Do memory intensive work.
    }
}

// Get a MemoryInfo object for the device's current memory status.
private fun getAvailableMemory(): ActivityManager.MemoryInfo {
    val activityManager = getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
    return ActivityManager.MemoryInfo().also { memoryInfo ->
        activityManager.getMemoryInfo(memoryInfo)
    }
}

Java

public void doSomethingMemoryIntensive() {

    // Before doing something that requires a lot of memory,
    // check whether the device is in a low memory state.
    ActivityManager.MemoryInfo memoryInfo = getAvailableMemory();

    if (!memoryInfo.lowMemory) {
        // Do memory intensive work.
    }
}

// Get a MemoryInfo object for the device's current memory status.
private ActivityManager.MemoryInfo getAvailableMemory() {
    ActivityManager activityManager = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
    ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
    activityManager.getMemoryInfo(memoryInfo);
    return memoryInfo;
}

Surveiller les processus supprimés en raison d'une mémoire insuffisante

Les fermetures dues à un manque de mémoire (LMK) visibles par l'utilisateur se produisent lorsque la mémoire système est extrêmement faible. Lorsque la mémoire est faible, le lmkd (démon tueur de mémoire faible) met fin aux processus en fonction de leur oom_adj_score. Les applications mises en cache ou exécutant un service sans UI associée (comme un job) obtiennent les scores les plus élevés et sont arrêtées en premier. Si la mémoire reste très faible, le démon est obligé de récupérer de la mémoire auprès des processus dont la valeur oom_adj_score est définie sur 0. Étant donné que ce score est réservé aux applications visibles, leur arrêt entraîne une sortie de processus immédiate et non progressive. Pour l'utilisateur final, l'application semble avoir planté, en contournant souvent les mécanismes standards de sauvegarde de l'état du cycle de vie et en entraînant une perte de la progression de l'utilisateur.

Les arrêts de processus de premier plan sont un axe majeur d'Android Vitals, car ils constituent un proxy haute fidélité pour la mauvaise gestion de la mémoire. Bien qu'un taux de LMK supérieur à 1% indique qu'une action immédiate est nécessaire, un taux faible n'est pas nécessairement un indicateur de bonne santé. Un faible taux de LMK perçus par l'utilisateur peut signifier que le démon LMK arrête fréquemment des processus en arrière-plan, ce qui dégrade les performances de démarrage tiède et la fluidité du multitâche. Par conséquent, nous vous recommandons de respecter les bonnes pratiques en matière de mémoire, quel que soit votre score LMK actuel, afin d'assurer la stabilité et l'état de l'appareil à long terme.

Utiliser ProfilingManager pour suivre les problèmes de mémoire

La plate-forme Android fournit ProfilingManager, une API d'observabilité avancée qui vous permet de capturer des données utilisateur en production en fonction des déclencheurs que vous définissez. Cela peut vous aider à identifier les problèmes de mémoire difficiles à reproduire.

Deux nouveaux déclencheurs introduits avec Android 17 sont particulièrement utiles pour détecter les problèmes de mémoire :

  • TRIGGER_TYPE_OOM indique que l'application a généré une OutOfMemoryError. Il se déclenche la prochaine fois que l'application démarre après le plantage, lorsque l'application s'enregistre pour les déclencheurs de profilage.
  • TRIGGER_TYPE_ANOMALY se déclenche lorsque le système détecte un comportement anormal de l'application. Cela peut, entre autres, être déclenché par une utilisation excessive de la mémoire. Il se déclenche après que l'application a fait preuve d'une utilisation excessive de la mémoire, et avant que le système ne prenne des mesures pour arrêter le processus incriminé. Par exemple, si l'application dépasse les limites de mémoire introduites dans Android 17, TRIGGER_TYPE_ANOMALY se déclenche avant que le système ne ferme l'application.

Pour en savoir plus sur l'utilisation de ProfilingManager pour enregistrer et récupérer des déclencheurs par programmation, consultez la documentation sur le profilage basé sur les déclencheurs.

Vous pouvez également utiliser le profilage piloté par l'application pour définir manuellement les points de début et de fin de la trace. Nous vous recommandons de le faire pour capturer manuellement des vidages ou des profils de tas dans les zones où vous pensez qu'il peut y avoir des fuites de mémoire ou une utilisation excessive de la mémoire.

Utiliser des constructions de code plus efficaces pour la mémoire

Certaines fonctionnalités Android, classes Java et constructions de code peuvent utiliser plus de mémoire que d'autres. Vous pouvez réduire la quantité de mémoire utilisée par votre application en choisissant des alternatives plus efficaces dans votre code.

Utiliser les services avec parcimonie

Nous vous recommandons vivement de ne pas laisser les services s'exécuter lorsque ce n'est pas nécessaire. Laisser les services s'exécuter inutilement est l'une des pires erreurs de gestion de la mémoire qu'une application Android puisse commettre. Si votre application a besoin d'un service pour fonctionner en arrière-plan, ne le laissez s'exécuter que s'il doit exécuter une tâche. Arrêtez le service lorsqu'il a terminé sa tâche. Sinon, vous risquez de provoquer une fuite de mémoire.

Lorsque vous démarrez un service, le système préfère continuer à exécuter le processus correspondant. Ce comportement rend les processus des services très gourmands, car la RAM utilisée par un service reste indisponible pour les autres processus. Cela réduit le nombre de processus mis en cache que le système peut conserver dans le cache LRU, ce qui rend le changement d'application moins efficace. Cela peut même entraîner un thrashing dans le système lorsque la mémoire est insuffisante et que le système ne peut gérer suffisamment de processus pour héberger tous les services en cours d'exécution.

En règle générale, évitez d'utiliser des services persistants, car ils demandent en permanence de la mémoire disponible. Nous vous recommandons plutôt d'utiliser une autre implémentation, telle que WorkManager. Pour savoir comment planifier des processus en arrière-plan à l'aide de WorkManager, consultez Tâches persistantes.

Utiliser des conteneurs de données optimisés

Certaines classes fournies par le langage de programmation ne sont pas optimisées pour les appareils mobiles. Par exemple, l'implémentation HashMap générique peut se révéler inefficace en mémoire, car elle a besoin d'un objet d'entrée distinct pour chaque mise en correspondance.

Le framework Android inclut plusieurs conteneurs de données optimisés, y compris SparseArray, SparseBooleanArray et LongSparseArray. Par exemple, les classes SparseArray sont plus efficaces, car elles évitent au système de compléter automatiquement la clé et parfois une valeur (ce qui crée un ou deux objet(s) de plus par entrée).

Si nécessaire, vous pouvez toujours basculer vers des tableaux bruts pour bénéficier d'une structure de données synthétique.

Attention aux abstractions de code

Les développeurs utilisent souvent les abstractions en tant que bonne pratique de programmation, car elles leur permettent d'améliorer la flexibilité et la maintenance du code. Cependant, les abstractions nécessitent généralement plus de code à exécuter. Comme indiqué dans Réduire l'empreinte de code et de ressources de votre application, un codebase compilé plus volumineux augmente directement la RAM physique requise par votre application. Si vos abstractions ne sont pas vraiment bénéfiques, évitez-les.

Utiliser des tampons de protocole allégés pour les données sérialisées

Les tampons de protocole sont un mécanisme extensible indépendant du langage et de la plate-forme, conçu par Google pour sérialiser des données structurées. Semblables au format XML, ils sont plus légers, plus simples et plus rapides. Si vous utilisez des tampons de protocole pour vos données, utilisez toujours des versions allégées dans votre code côté client. Les tampons de protocole classiques génèrent un code extrêmement détaillé, ce qui augmente l'empreinte du code de votre application dans la RAM (voir Gérer et optimiser l'empreinte du code de votre application) et contribue à l'augmentation de la taille de l'APK.

Pour en savoir plus, consultez le fichier README.

Faites attention aux fuites de mémoire

Une gestion incorrecte des références peut entraîner des fuites de mémoire, où les objets survivent à leur durée de vie utile, empêchant le récupérateur de mémoire de récupérer la mémoire de l'objet ayant fui. Pour éviter les fuites de mémoire, implémentez une conception sensible au cycle de vie.

Pour en savoir plus, consultez Fuites de mémoire.

Éviter la saturation de la mémoire

Les événements de récupération de mémoire n'affectent pas les performances de votre application. Cependant, une accumulation d'événements de récupération de mémoire en peu de temps peut rapidement décharger la batterie et augmenter légèrement le temps de configuration des frames en raison des interactions nécessaires entre le récupérateur de mémoire et les threads d'application. Plus le système se consacre à la récupération de mémoire, plus la batterie se décharge vite.

Souvent, les saturations de la mémoire peuvent entraîner une multiplication d'événements de récupération de mémoire. En pratique, une saturation de la mémoire décrit le nombre d'objets temporaires alloués dans un certain laps de temps.

Par exemple, vous pouvez allouer plusieurs objets temporaires dans une boucle for. Vous pouvez également créer de nouveaux objets Paint ou Bitmap dans la fonction onDraw() d'une vue. Dans les deux cas, l'application crée beaucoup d'objets rapidement et à grande échelle. Celles-ci peuvent rapidement utiliser toute la mémoire disponible des appareils de dernière génération, ce qui provoque un événement de récupération de mémoire.

Utilisez le Profileur de mémoire pour identifier les endroits de votre code où la saturation de la mémoire est élevée avant de pouvoir les corriger.

Une fois que vous avez localisé les zones problématiques dans votre code, essayez d'y réduire le nombre d'allocations. Envisagez de déplacer les éléments depuis des boucles internes ou éventuellement de les déplacer vers une structure d'allocation basée sur une fabrique.

Vous pouvez également déterminer si les pools d'objets profitent de ce cas d'utilisation. Avec un pool d'objets, au lieu de laisser tomber une instance d'objet, vous la libérez dans un pool lorsqu'elle n'est plus nécessaire. La prochaine fois qu'une instance d'objet de ce type sera nécessaire, vous pourrez l'acquérir à partir du pool plutôt que de l'allouer.

Évaluez méticuleusement les performances pour déterminer si un pool d'objets convient à une situation donnée. Dans certains cas, les pools d'objets peuvent nuire aux performances. Même si les pools évitent les allocations, ils entraînent d'autres frais généraux. Par exemple, la maintenance du pool implique généralement une synchronisation qui a des coûts non négligeables. De plus, la suppression de l'instance d'objet mis en pool pour éviter les fuites de mémoire pendant la sortie, puis son initialisation lors de l'acquisition peuvent entraîner des frais généraux.

Le fait de bloquer plus d'instances d'objets que nécessaire dans le pool alourdit la charge de récupération de mémoire. Bien que les pools d'objets réduisent le nombre d'appels de récupération de mémoire, ils augmentent la quantité de travail nécessaire pour chaque appel, car elle est proportionnelle au nombre d'octets actifs (accessibles).