Fuite mémoire et gonflement « ce que c'est, causes et comment éviter

Qu'est-ce qu'une fuite mémoire et le gonflement d'application ?

Fuite mémoire — une situation où un objet qui n'est plus nécessaire à l'application continue d'être conservé dans le tas parce qu'une référence active depuis l'ensemble racine (GC Root) pointe encore vers lui. Le ramasse-miettes considère cet objet comme vivant et ne le supprime pas.

Gonflement mémoire — un problème plus large où l'application consomme plus de mémoire que nécessaire pour effectuer ses tâches courantes. Causes : mise en cache excessive, duplication d'objets, structures de données sous-optimales et fragmentation du tas.

Sous Android, chaque application dispose d'un tas limité (généralement 64–512 Mo selon l'appareil et la version de l'OS). Sous iOS, la limite est moins stricte, mais le système envoie un avertissement mémoire à l'approche de la limite.

Selon le Facebook Engineering Blog, les fuites mémoire causent ~15% des rapports de crash dans les applications mobiles. Sous Android, s'ajoutent les ANR dus aux pauses fréquentes du GC en cas de mémoire insuffisante.

Motifs courants de fuites mémoire sous Android et iOS

Référence statique à Activity — une fuite classique sous Android. Si un champ statique ou un singleton conserve une référence à une Activity, elle ne sera pas collectée par le GC même après finish() tant que le singleton est vivant. Une Activity est un objet lourd contenant une hiérarchie de vues, des ressources et un Context.

object LeakHolder {
    var activityRef: Activity ?= null // leak: static reference to Activity
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        LeakHolder.activityRef = this // ❌ MainActivity will never be GC'd
    }
}

Classes anonymes et lambdas — retiennent implicitement une référence à la classe externe. Si un Runnable ou Callback est passé à un service externe et que l'Activity est détruite, l'objet de la classe anonyme reste dans la file et empêche l'Activity d'être collectée.

• Handler avec délai — si l'Activity est détruite mais que Handler.postDelayed n'a pas encore été exécuté, l'Activity fuit
• Thread et AsyncTask — lors de la rotation de l'écran, l'Activity est recréée tandis que l'ancien Thread continue de conserver une référence à l'ancienne Activity
• Retrofit/Callback — un Callback anonyme conserve une référence au presenter ou au fragment
• Observateurs — abonnements LiveData ou RxJava sans désabonnement à onDestroy

Sous iOS, le problème principal est les cycles de rétention : deux objets maintiennent des références fortes l'un vers l'autre, et l'ARC ne peut mettre à zéro le compteur de références d'aucun des deux. Un cas typique : une closure qui capture self fortement, et self qui conserve une référence à la closure.

Comment détecter les fuites mémoire ?

LeakCanary — une bibliothèque de Square pour la détection automatique des fuites sous Android. Après la destruction d'une Activity ou d'un Fragment, elle vérifie si l'objet a été collecté par le GC. Sinon, elle fait un heap dump et affiche la trace de la fuite.

// LeakCanary 2.x — auto-integration via Application
class ExampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // LeakCanary auto-installs in debug build
        // via ContentProvider — zero code setup
    }
}

// Force check invocation
AppWatcher.objectWatcher.watch(watchedObject, "leak description")

Android Studio Profiler — un outil intégré de surveillance mémoire en temps réel. Il permet d'enregistrer un heap dump, de trouver des objets suspects (Retained Size > 1 Mo) et de tracer le chemin racine GC jusqu'à chaque objet.

Pour iOS, utilisez le Xcode Memory Graph Debugger. Il visualise le graphe d'objets en mémoire, montre les cycles de rétention et permet de détecter instantanément les références circulaires. Instruments > Allocations est également disponible pour la surveillance à long terme.

Stratégies de prévention

WeakReference — un mécanisme de base pour les références qui ne doivent pas interférer avec le ramasse-miettes. Si le GC décide de collecter un objet, WeakReference retourne null. Il est utilisé pour les callbacks, les écouteurs et les références aux composants d'interface depuis des threads d'arrière-plan.

Composants Lifecycle-aware — une approche architecturale implémentée dans Android Jetpack (Lifecycle, LiveData, Flow, coroutines). Les abonnements sont automatiquement annulés à onDestroy, éliminant la principale classe de fuites.

class MyViewModel : ViewModel() {
    private val _data = MutableLiveData<List<User>>()
    val data: LiveData<List<User>> get() = _data

    fun loadData() {
        viewModelScope.launch {
            val result = repository.fetchData()
            _data.postValue(result)
            // coroutine auto-cancels on onCleared()
        }
    }
}

viewModelScope et lifecycleScope — des CoroutineScope intégrés dans Android qui sont annulés à l'événement de cycle de vie correspondant. Cela élimine les fuites via les coroutines — le scénario le plus courant dans le développement Android moderne.

• N'utilisez pas de références statiques à Context, Activity, View ou Fragment
• Annulez tous les abonnements RxJava dans disposeBag / CompositeDisposable à onDestroy
• Utilisez [weak self] / [unowned self] dans les closures iOS pour prévenir les cycles de rétention
• Vérifiez Bitmap et les objets volumineux — ils doivent être recyclés ou nullifiés

Outils de profilage mémoire

Memory Profiler dans Android Studio — l'outil principal de surveillance du tas. Il montre les allocations en direct, les instantanés du tas et les comptes d'objets par type. Il permet d'enregistrer un dump et de l'analyser dans MAT (Memory Analyzer Tool) pour trouver des objets suspects.

Eclipse MAT — un analyseur de heap dump de bureau. Après avoir chargé un fichier HPROF depuis Android Studio, MAT construit un arbre dominant, montre la taille de rétention de chaque objet et propose une analyse automatique des fuites suspectes via le Leak Suspects Report.

Xcode Memory Graph — un débogueur visuel de cycles de rétention. En cliquant sur le bouton Memory Graph Debugger, Xcode arrête l'application, construit un graphe complet d'objets en mémoire et surligne les cycles de rétention en rouge.

Selon Google I/O 2023, les applications utilisant LeakCanary dans les builds de débogage réduisent les crashes liés à la mémoire de 30–50% dans les 2 premiers mois suivant l'adoption. Il est recommandé d'ajouter LeakCanary dès la phase d'intégration du projet.