Je trouve ces codes peut cas fuite de mémoire sur Android 2,1android.media.SoundPool cause-t-il une fuite de mémoire?
SoundPool soundPool = new SoundPool(10, 7, 0);
...
...
soundPool = null;
chaque fois après l'exécution, le pluging MAT dit que deux objets String de « android: unnamed_thread » sont ajoutés au tas du processus. Est-ce un problème?
Je vois deux possibilités (il peut bien être plus). Le premier (le plus probable) est vrai pour tous les objets Java: le fait que vous définissiez la référence sur null ne signifie pas automatiquement que l'objet qui le sous-tend sera récupéré. Si un objet SoundPool contient lui-même une référence aux deux objets threads, aucun des trois ne sera nécessairement GC'ed tant que l'espace n'est pas nécessaire (bien que cela dépende, bien sûr, de l'agressivité de votre collecteur). La seconde (moins probable) est qu'Android peut être suffisamment intelligent pour mettre en cache des objets thread (ou même SoundPool) au cas où ils devraient être réutilisés. Ils peuvent avoir fait cela comme une optimisation des performances si la création d'objets est plus coûteuse que le recyclage d'objets.
Dans ce cas, ils auraient toujours une référence aux objets quelque part dans un cache et ils ne seraient pas considérés comme éligibles pour la récupération de place.
avez-vous essayé d'exécuter soundPool.release() au lieu de soundPool = null?
Merci beaucoup. Et j'ai appelé System.gc() dans mon code, mais cela n'a pas aidé à nettoyer ces objets. Cela signifie-t-il que la première possibilité n'est pas possible? – user421301
Je suis à peu près certain que 'System.gc()' est un _suggestion_ à faire de garbage collection: "Appeler cette méthode suggère que la machine virtuelle Java déploie des efforts pour recycler les objets inutilisés ...". Donc, je ne l'exclurais pas comme une possibilité. – paxdiablo