Fuite de mémoire : ce que c'est, scénarios typiques et diagnostic

Qu'est-ce qu'une fuite de mémoire dans les applications mobiles ?

Fuite de mémoire — situation dans laquelle la mémoire allouée n'est pas restituée au système après que l'objet n'est plus nécessaire au programme. Le ramasse-miettes considère cet objet comme vivant car une chaîne de références active depuis une GC Root pointe vers lui.

En Java/Kotlin, le ramasse-miettes fonctionne automatiquement, mais il ne peut pas déterminer qu'un objet est logiquement inutile s'il existe une référence technique vers lui. Le développeur doit rompre explicitement les connexions inutiles. En Swift/Objective-C, ARC compte automatiquement les références, mais les cycles de rétention bloquent la diminution du compteur.

Le principal danger des fuites est l'effet cumulatif. Chaque fuite consomme une petite quantité de mémoire, mais avec des transitions répétées entre écrans (rotations d'écran, ouverture/fermeture d'Activities), les fuites s'accumulent jusqu'à épuiser la limite du heap.

En quoi une fuite diffère-t-elle du gonflement ?

Fuite — l'objet est inaccessible au code mais n'est pas supprimé par le GC. Gonflement — l'objet est logiquement nécessaire mais stocké en quantité excessive. Exemple de gonflement : un cache d'images de 100 Mo avec un ensemble de travail de 30 Mo. Les deux problèmes mènent à OOM, mais les causes et les méthodes de traitement diffèrent.

Comment fonctionne le ramasse-miettes et pourquoi les fuites se produisent-elles ?

ART (Android Runtime) utilise le ramasse-miettes générationnel avec compactage concurrent. La mémoire est divisée en génération jeune (Young), génération âgée (Old) et objets volumineux (Large). Les objets qui survivent à plusieurs cycles GC sont déplacés vers la génération Old, où la collecte a lieu moins fréquemment — cela accélère les cycles normaux.

Le GC démarre lorsque le heap atteint un certain seuil d'occupation (généralement 75-85%). Pendant le GC, tous les threads de l'application sont suspendus (STW — Stop The World). Plus il y a d'objets vivants, plus la pause est longue. Les fuites augmentent le nombre d'objets vivants, allongeant les pauses du GC.

Le collecteur détermine les objets vivants en parcourant le graphe à partir des GC Roots : champs statiques, variables de pile des threads actifs, références JNI. Tout objet atteignable via des références depuis ces racines est considéré comme vivant — même si le développeur sait qu'il n'est plus nécessaire.

// Exemple : collection statique comme GC Root — fuite permanente
object GlobalHolder {
    val listeners = mutableListOf<WeakReference<Any>>()
}

class LeakingFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        GlobalHolder.listeners.add(WeakReference(this))
        // WeakReference n'empêche pas le GC — comportement correct
    }
}

WeakReference résout le problème : le GC ignore les références faibles lors de la détermination des objets vivants. S'il ne reste que des références faibles vers un objet, il sera collecté lors du cycle GC le plus proche.

Scénarios typiques de fuites dans Android et iOS

Activity Context — le scénario de fuite le plus massif dans Android. Si un singleton, un champ statique ou un service de longue durée stocke une référence à un Activity Context, toute l'Activity avec toutes ses vues ne peut pas être collectée par le GC. Solution : utilisez Application Context pour les objets de longue durée.

Handler et messages envoyés — Handler.postDelayed(runnable, delay) place un message dans la file d'attente du Main Looper. Si l'Activity est détruite avant l'expiration du délai, le message est toujours dans la file et maintient une référence via Runnable → classe anonyme → classe externe (Activity).

class SafeActivity : AppCompatActivity() {
    private val mainHandler = Handler(Looper.getMainLooper())
    private val callback = Runnable { /* update UI */ }

    override fun onResume() {
        super.onResume()
        mainHandler.postDelayed(callback, 5000)
    }

    override fun onPause() {
        mainHandler.removeCallbacks(callback) // obligatoire : vider la file d'attente
        super.onPause()
    }
}

Classes internes — une classe interne non statique a une référence implicite à l'instance de la classe externe. Si la classe externe est une Activity et que la classe interne est passée à l'extérieur (par exemple, à RecyclerView.Adapter), l'Activity ne peut pas être collectée.

• TimerTask et ScheduledExecutorService — tâches planifiées avant la destruction de l'Activity
• BroadcastReceiver — non désenregistré dans onPause/onDestroy continue de maintenir le Context
• ViewModel avec référence à View — ViewModel survit à l'Activity, la référence à la View entraîne une fuite
• Retrofit Call — si Call n'est pas annulé, la réponse arrive à un Fragment détruit

Outils de diagnostic des fuites de mémoire

Android Studio Memory Profiler — outil intégré de surveillance du heap en temps réel. Affiche un graphique de la mémoire utilisée, le nombre d'allocations et d'objets par type. Permet d'enregistrer un heap dump et de l'exporter au format HPROF pour analyse dans MAT.

Eclipse MAT (Memory Analyzer Tool) — analyseur de bureau de heap dump. Construit automatiquement des rapports Leak Suspects, mettant en évidence les objets avec le plus grand retained size et suggérant la chaîne GC Root suspectée pour chaque objet suspect.

Xcode Memory Graph Debugger — pour iOS. Suspend l'application et visualise le graphe d'objets. Les cycles de rétention sont surlignés en rouge ; vous pouvez cliquer sur n'importe quel objet pour voir son retain count et ses références.

Selon le Uber Engineering Blog, l'intégration du profilage automatique de la mémoire (LeakCanary + analyse de heap dump) dans le pipeline CI/CD réduit les incidents liés à la mémoire en production de 60% en 3 mois.

Méthodes pour éliminer les fuites

Remplacer Context — si un objet survit à l'Activity, utilisez applicationContext. Tous les objets de longue durée (singletons, repositories, helpers de base de données) doivent recevoir Application Context, pas Activity Context. Exception : les composants d'interface utilisateur qui ont besoin d'accéder au thème ou aux ressources spécifiques à l'Activity.

Composants sensibles au cycle de vie — l'utilisation de LifecycleObserver, DefaultLifecycleObserver ou d'extensions réactives annule automatiquement les abonnements à onDestroy. Android Jetpack fournit lifecycleScope et viewModelScope, qui sont nettoyés par l'événement de cycle de vie correspondant.

Classe interne statique — si la classe interne n'a pas besoin d'accéder aux champs de la classe externe, rendez-la static. Une classe interne statique n'a pas de référence implicite à la classe externe. Si l'accès est nécessaire, utilisez WeakReference pour la référence explicite.

class MyActivity : AppCompatActivity() {

    // ❌ Classe interne non statique — référence implicite à MyActivity
    inner class BadListener : SomeListener {
        override fun onEvent() { /*...*/ }
    }

    // ✅ Classe interne statique — pas de référence implicite
    class GoodListener(private val activityRef: WeakReference<MyActivity>) : SomeListener {
        override fun onEvent() { /*...*/ }
    }
}

Sous iOS, utilisez des listes de capture : [weak self] dans les fermetures qui peuvent survivre à leur créateur. Pour les délégués, utilisez des références faibles (weak var delegate). Pour les fermetures dont l'appel est garanti uniquement pendant la durée de vie de self, [unowned self] peut être utilisé, mais avec prudence — l'accès à un objet désalloué provoquera un plantage.