Comme le dit le titre. Lorsque vous utilisez la console d'AndroidStudio sur mon application, cela indique:
W / Système: une ressource n'a pas pu appeler la libération.
Parfois, il est répété plusieurs fois. Je sais ce que cela signifie mais j'ai vérifié plusieurs fois près de 2 000 lignes de codes, mais je n'ai aucune idée de ce qu'il me manque pour fermer / libérer.
Existe-t-il un moyen de développer ces informations à partir de la console? ou comment feriez-vous pour cibler ce qu'est la ressource ou quand elle ne se ferme pas? Toutes les idées sont les bienvenues. Merci.
3 Réponses :
Je ne pense pas que vous puissiez obtenir plus d'informations sur Logcat.
La vue mémoire d' Android Profiler est probablement un bon point de départ. L'examiner lors de l'utilisation de votre application devrait vous donner une idée des actions qui provoquent l'allocation et la non-libération de la mémoire. Vous pouvez également sélectionner des sections dans la chronologie et explorer des allocations spécifiques par classe.
Alternativement, LeakCanary est une excellente bibliothèque pour détecter les fuites de mémoire.
Merci. En fait, j'ai découvert l'outil Profiler il y a quelque temps mais c'est agréable de voir que je suis sur la bonne voie. Je ne peux pas vous voter parce que je suis nouveau :(
Ce message provient de dalvik.system.CloseGuard . Lors du débogage, vous pouvez le configurer pour créer des traces de pile au fur et à mesure que vous créez des ressources, afin de pouvoir localiser les objets qui ne sont pas fermés.
Cela ne fait pas partie de l'API du framework, j'utilise donc la réflexion pour l'activer:
try {
Class.forName("dalvik.system.CloseGuard")
.getMethod("setEnabled", boolean.class)
.invoke(null, true);
} catch (ReflectiveOperationException e) {
throw new RuntimeException(e);
}
plus d'infos: https://wh0.github.io/2020/08/12/closeguard.html
C'est la vraie réponse car elle vous permet de trouver ce qui cause directement le message. LeakCanary est un excellent outil, mais n'aide pas à résoudre ce type de message car l'objet à problème n'est généralement pas l'un des types de surveillance automatique (par exemple, activité, fragment, etc.)
La réponse de @guest fonctionne, mais vous pouvez obtenir exactement la même chose sans recourir à la réflexion en utilisant le mode strict . Plus précisément, quelque chose comme:
StrictMode.enableDefaults(); # <-- This includes warning on leaked closeables
En général, le mode strict peut faire beaucoup plus pour vous (voir le lien ci-dessus vers doc), et tout ce que vous avez à faire pour une configuration par défaut est:
StrictMode.setVmPolicy(new VmPolicy.Builder()
.detectLeakedClosableObjects()
.penaltyLog()
.build());