Les classes internes sont-elles intrinsèquement dangereuses pour les fuites de mémoire dans le développement Android ?

Êtes-vous en sécurité lorsque vous utilisez des classes internes ?

Lorsque vous travaillez sur des applications Android, des problèmes liés aux fuites de mémoire surviennent souvent. Les classes internes, lorsqu’elles sont utilisées dans le cadre d’une activité, peuvent présenter des risques potentiels. Mais quand exactement ces fuites peuvent-elles se produire ?

Classes internes et fuites de mémoire

Une fuite de mémoire se produit lorsqu'une classe interne survit plus longtemps que sa classe externe (c'est-à-dire une activité ). Cette situation peut survenir lorsqu'un objet en dehors de la classe conteneur conserve une référence à l'objet interne, le gardant vivant même après la disparition de la classe parent.

Exemple 1 : aucun risque de fuite

final Dialog dialog = new Dialog(this);
dialog.setContentView(R.layout.dialog_generic);
Button okButton = (Button) dialog.findViewById(R.id.dialog_button_ok);
TextView titleTv = (TextView) dialog.findViewById(R.id.dialog_generic_title);

okButton.setOnClickListener(new OnClickListener() {
    public void onClick(View v) {
        dialog.dismiss();
    }
});

titleTv.setText("dialog title");
dialog.show();

Dans cet exemple, la classe anonyme étendant OnClickListener ne survivra pas à l'activité, éliminant ainsi le risque de fuite.

Exemple 2 : Potentiel de danger

_handlerToDelayDroidMove = new Handler();
_handlerToDelayDroidMove.postDelayed(_droidPlayRunnable, 10000);

private Runnable _droidPlayRunnable = new Runnable() { 
    public void run() {
        _someFieldOfTheActivity.performLongCalculation();
    }
};

Cet exemple implique un Runnable anonyme, qui est un type de classe interne. Étant donné que le Runnable contient une référence implicite à l’activité englobante, il peut rester actif même après la destruction de l’activité. De ce fait, ce code est considéré comme dangereux et pourrait entraîner une fuite de mémoire.

Se protéger contre les fuites avec les classes internes

Pour éviter les fuites impliquant les classes internes :

• Utilisez des classes internes statiques lorsque cela est possible.
• Si vous utilisez des classes internes non statiques, assurez-vous que leur durée de vie est plus courte que celle de la classe externe.
• Envisagez d'utiliser des modèles de conception comme le Factory pour éviter les références directes.

Activités et vues

Les activités conservent des références à leurs hiérarchies de vues, ce qui fait des fuites de mémoire un problème important. Tout objet faisant référence à une activité ou à une vue peut les maintenir en vie, ce qui entraîne des fuites.

Prévenir les fuites dans les activités et les vues

• Évitez de conserver des références à des activités ou des contextes pendant des périodes prolongées.
• Si un contexte de longue durée est nécessaire, utilisez getApplicationContext().
• Envisagez de remplacer les modifications de configuration pour minimiser le risque de fuites lors des changements d'orientation.

Runnables

Les Runnables sont une autre source potentielle de fuites de mémoire, en particulier lorsqu'ils sont utilisés comme classes internes anonymes.

Prévenir les fuites avec les Runnables

• Utilisez des exécutables étendus au lieu d'exécutables anonymes.
• Rendre les exécutables étendus statiques si possible.
• Évitez d'utiliser des exécutables anonymes dans des objets qui ont une longue durée de vie références à des activités ou des vues.
• Envisagez plutôt d'utiliser AsyncTask, car il est géré par VM par défaut.

Quand les classes internes survivent aux classes externes

Cela peut se produire lorsqu'une classe externe crée une classe interne et que la classe interne stocke une référence à la classe externe, la gardant ainsi en vie. Même après la destruction de la classe externe, la classe interne reste accessible via la référence.

Conclusion

L'utilisation de classes internes au sein d'une activité nécessite une réflexion approfondie pour éviter les fuites de mémoire. En adhérant aux bonnes pratiques décrites ci-dessus, les développeurs peuvent minimiser ces risques et assurer le bon fonctionnement de leurs applications Android.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!