onDestroy : qu'est-ce que c'est, fin du travail d'Activity dans Android

onDestroy : qu'est-ce que c'est dans Android ?

onDestroy — une méthode de callback qu'Android appelle avant de détruire complètement une Activity ou un Fragment. C'est la dernière opportunité pour le développeur de libérer des ressources, d'annuler des opérations d'arrière-plan et de finaliser le travail avec les données. Après l'exécution d'onDestroy, l'instance Activity/Fragment est marquée pour le ramasse-miettes (GC) et ne peut plus être utilisée.

Raisons d'appeler onDestroy :

• Appel explicite à finish() — l'utilisateur a appuyé sur « Retour » ou le développeur a appelé finishActivity().
• Rotation d'écran — l'Activity est détruite et recréée avec une nouvelle configuration.
• Changement de configuration — clavier, changement de langue, changement de taille d'écran (multi-fenêtre).
• Décision du système — Android tue l'Activity pour libérer des ressources (mais onDestroy peut ne pas être appelé).

Selon les statistiques Google Android Vitals (2025), environ 12 % de tous les cas de destruction d'Activity sont dus à la rotation d'écran, 65 % à finish() et 23 % aux changements de configuration. Le pourcentage de morts de processus avec onDestroy ignoré est d'environ 5 — 8 % selon les appareils avec peu de RAM (moins de 4 Go).

Quand onDestroy est appelé — et quand il ne l'est pas

onDestroy est appelé dans la plupart des scénarios standard, mais il existe des exceptions importantes que le développeur doit prendre en compte. Comprendre les garanties d'invocation d'onDestroy est critique pour l'architecture de l'application, en particulier pour sauvegarder des données et annuler des tâches WorkManager.

Quand onDestroy est appelé :

• L'utilisateur appuie sur le bouton « Retour » — Activity.finish() → onPause → onStop → onDestroy.
• Rotation d'écran — l'Activity est détruite (onPause → onStop → onDestroy), puis recréée.
• Changement de configuration — paramètre système nécessitant la recréation de l'Activity.
• Appel à finishAffinity() — termine toutes les Activities dans la pile.
• Suppression d'un Fragment du FragmentManager — le Fragment reçoit onPause → onStop → onDestroyView → onDestroy → onDetach.

Quand onDestroy N'EST PAS appelé :

• Mort du processus par le système — Android tue tout le processus de l'application quand la mémoire est insuffisante. L'Activity ne reçoit pas onDestroy car le processus se termine au niveau du noyau Linux.
• Terminaison anormale — une exception non capturée dans le thread principal tue l'application sans appeler onDestroy.
• Arrêt forcé — l'utilisateur arrête de force l'application dans les paramètres.

En raison de l'absence de garantie d'invocation d'onDestroy, Google recommande : ne comptez jamais sur onDestroy pour sauvegarder des données critiques. Utilisez onSaveInstanceState(), WorkManager ou Room avec sauvegarde automatique. onDestroy est pour libérer des ressources, pas pour la persistance.

onDestroy dans Activity et Fragment : points communs et différences

onDestroy existe à la fois pour Activity et Fragment, mais avec des contrats différents. Le cycle de vie du Fragment est plus détaillé : en plus d'onDestroy, il y a onDestroyView (destruction de la hiérarchie de View) et onDetach (détachement de l'Activity).

La différence clé : la View d'un Fragment est recréée plus souvent que le Fragment lui-même. Lors de la rotation d'écran, le Fragment passe par onDestroyView (destruction de la View), mais le Fragment lui-même et son ViewModel restent vivants. onDestroyView est l'endroit approprié pour nettoyer les références de View afin d'éviter les fuites mémoire. Le onDestroy de Fragment est analogue au onDestroy d'Activity, appelé lorsque le Fragment est complètement supprimé.

Les fragments enfants sont détruits avant le onDestroy du Fragment parent. Dans l'Activity, les fragments enfants reçoivent onDestroy lorsque le onDestroy de l'Activity parente est appelé. L'ordre est garanti : les fragments se terminent avant l'Activity qui les contient.

Que faire dans onDestroy : liste de vérification de nettoyage

onDestroy est destiné à libérer toutes les ressources qui ne doivent pas survivre à l'Activity ou au Fragment. Contrairement à onStop, qui libère les ressources jusqu'au retour, onDestroy effectue le nettoyage final.

Liste de vérification des actions obligatoires dans onDestroy :

• Annuler les coroutines et Flow — annulez les jobs qui ne sont pas liés à viewModelScope. viewModelScope est annulé automatiquement, mais lifecycleScope est lié au cycle de vie de l'Activity.
• Fermer les sockets et canaux — WebSocket (OkHttp), BluetoothSocket, ServerSocket. Les garder ouverts après la destruction est une fuite de ressources système.
• Fermer les fichiers et flux — FileInputStream, FileOutputStream, Cursor. Un Cursor peut provoquer ANR sur ContentProvider s'il n'est pas fermé.
• Se désabonner de ContentObserver — si l'Activity surveille les changements de contenu (contacts, bibliothèque multimédia).
• Désenregistrer BroadcastReceiver — les récepteurs enregistrés dynamiquement doivent être annulés.
• Fermer la base de données — Room ferme la connexion automatiquement lorsque l'Application est détruite, mais SQLiteDatabase direct nécessite close() manuel.

Ce qu'il NE FAUT PAS faire dans onDestroy : Ne sauvegardez pas de données dans onDestroy — utilisez onPause ou onSaveInstanceState. Ne démarrez pas de nouveau Service ou de tâches WorkManager — l'Activity sera détruite et vous ne pourrez pas suivre le résultat. N'essayez pas de mettre à jour l'interface utilisateur — la hiérarchie de View est déjà détruite ou en cours de destruction ; appeler findViewById() retournera null.

onDestroy et ViewModel : travail conjoint

ViewModel est conçu pour survivre à onDestroy d'Activity lors de la rotation d'écran, mais être détruit avec l'Activity lors de finish(). Ce comportement asymétrique est la principale cause de confusion chez les développeurs.

Lors de la rotation d'écran :

• Activity : onPause → onStop → onDestroy (Activity détruite).
• ViewModel : NON détruit — le ViewModelStore est sauvegardé et transmis à la nouvelle Activity.
• Nouvelle Activity : onCreate → onStart → onResume, reçoit le même ViewModel.

Lors de finish() (l'utilisateur a appuyé sur « Retour ») :

• Activity : onPause → onStop → onDestroy.
• ViewModel : onCleared() — appelé après onDestroy de l'Activity.
• Toutes les coroutines de viewModelScope sont annulées automatiquement.

Par conséquent, annuler viewModelScope dans onDestroy n'est pas nécessaire — ViewModel le fera lui-même. Si vous utilisez lifecycleScope (lié à l'Activity, pas à ViewModel), annulez-le dans onDestroy via lifecycleScope.cancel() ou gérez le Job manuellement.

Exemples de code avec onDestroy en Kotlin

Exemple 1 : onDestroy Activity avec annulation de coroutine lifecycleScope

Montre la gestion correcte de lifecycleScope dans une Activity : une coroutine est lancée pour surveiller l'état du réseau et annulée dans onDestroy.

class NetworkMonitorActivity : AppCompatActivity() {
    private val networkCallback = object : ConnectivityManager.NetworkCallback() {
        override fun onAvailable(network: Network) {
            Log.d("NetworkMonitor", "Réseau disponible")
        }
        override fun onLost(network: Network) {
            Log.d("NetworkMonitor", "Réseau perdu")
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_network)
        val connectivityManager = getSystemService(ConnectivityManager::class.java)
        connectivityManager.registerDefaultNetworkCallback(networkCallback)
        lifecycleScope.launch {
            Log.d("NetworkMonitor", "Surveillance réseau démarrée")
        }
    }

    override fun onDestroy() {
        super.onDestroy()
        val connectivityManager = getSystemService(ConnectivityManager::class.java)
        connectivityManager.unregisterNetworkCallback(networkCallback)
        Log.d("NetworkMonitor", "onDestroy : callback annulé")
    }
}

Dans onDestroy, l'enregistrement du callback réseau est annulé. lifecycleScope est annulé automatiquement lorsque le cycle de vie est détruit — une annulation séparée de la coroutine n'est pas requise. Le callback réseau doit être désenregistré, sinon il restera dans le système même après la destruction de l'Activity.

Exemple 2 : onDestroy Fragment avec nettoyage des références de View

Un Fragment nettoie correctement les références de View dans onDestroyView, empêchant les fuites mémoire dues aux fermetures.

class ProfileFragment : Fragment() {
    private var avatarView: ImageView? = null
    private var progressBar: ProgressBar? = null
    private val imageLoader = ImageLoader()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        avatarView = view.findViewById(R.id.avatar)
        progressBar = view.findViewById(R.id.progress)
        loadProfile()
    }

    private fun loadProfile() {
        viewLifecycleOwner.lifecycleScope.launch {
            try {
                progressBar?.visibility = View.VISIBLE
                val bitmap = imageLoader.load("https://example.com/avatar.png")
                avatarView?.setImageBitmap(bitmap)
            } finally {
                progressBar?.visibility = View.GONE
            }
        }
    }

    override fun onDestroyView() {
        super.onDestroyView()
        avatarView = null
        progressBar = null
        imageLoader.cancel()
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.d("ProfileFragment", "onDestroy : Fragment complètement détruit")
    }
}

Dans onDestroyView, les références de View sont mises à null — cela empêche les fuites mémoire si une fermeture dans imageLoader contient une référence à avatarView. Le Fragment lui-même et son ViewModel restent vivants jusqu'à onDestroy. imageLoader.cancel() annule le chargement si le Fragment quitte l'écran.

Exemple 3 : Vérification de isFinishing dans onDestroy

Utiliser isFinishing() permet de distinguer si l'Activity se termine par commande utilisateur ou pour recréation.

class AnalyticsActivity : AppCompatActivity() {
    private val analytics = Analytics()

    override fun onDestroy() {
        if (isFinishing) {
            Log.d("AnalyticsActivity", "Activity se termine avec finish() — envoi d'analyses")
            analytics.sendSessionEnd()
        } else {
            Log.d("AnalyticsActivity", "Activity recréée (rotation/configuration) — pas d'envoi d'analyses")
        }
        super.onDestroy()
    }
}

Vérifier isFinishing() est un modèle important pour les analyses, la journalisation et le nettoyage des données de session. Lors de la rotation, les événements de fin de session ne doivent pas être envoyés — l'utilisateur travaille toujours avec l'application. Selon Google Analytics, la vérification incorrecte de isFinishing() est la cause de 40 % des faux événements de session.