Localisation et résolution de la cause de la grande taille du tas

Question

J'essaie de savoir pourquoi mon application utilise une grande quantité de mémoire. Je vois souvent à l'aide entre 15 et 18MO, ce qui est considérablement plus élevé que je ne le pensez. J'ai pris un coup d'oeil à la taille de segment de mémoire via DDMS et vu ceci:

Qui avait l'air un peu suspectes, parce que mon application ne permet pas de traiter avec de grandes images. En fait, la somme totale de l'un drawable dans mon application est d'environ 250KB. J'ai donc créé un tas de vidage et utilisé TAPIS de localiser l'endroit où tout cela de mémoire. byte[] tableaux ont été de loin le plus grand consommateur, de sorte que j'ai foré vers le bas et de remarquer ce qui suit:

Je n'ai absolument aucune idée de pourquoi sPreloadedDrawables est responsable d'une forte retenu la taille du segment. Je n'ai aucune idée de comment faire pour identifier la cause du problème, ou comment "réparer".

Où dois-je aller d'ici? Mon application fonctionne la plupart du temps dans l'arrière-plan par l'intermédiaire des services qui ne traitent pas les données d'image du tout. J'ai les Activités que l'utilisateur peut choisir d'utiliser, mais encore une fois, ils utilisent de petits un drawable qui n'explique pas une telle grande taille de segment de mémoire. J'ai aussi vérifié pour les méchants occurances de l'Activité de fuites etc, mais je n'ai pas de localiser tout.

Des idées?

EDIT: j'ai remarqué que la taille de segment de mémoire est sensiblement plus bas lorsque vous exécutez dans l'émulateur. C'est assez déroutant. :/

Answer 1

Le système de précontrainte le défaut de ressources système, cela est indépendant de vos ressources de l'application, des choses comme standard un drawable pour les cases à cocher et des boutons radio. 10.5 MO ne semble pas grande mais il y a beaucoup de défaut de ressources système, et les Images sont plus grandes, une fois stockées dans la mémoire. Le préchargement n'est pas nouveau, mais la taille de la précharge peut être plus grand dans SA. Affichage de la densité joue probablement un rôle dans ce long avec simplement l'ajout de plus d'un drawable système préchargé dans ICS.

Il n'existe actuellement aucun moyen de réduire la mémoire occupée par l' sPreloadedDrawables

Il est regrettable qu'il n'y a pas un moyen de l'effacer après l'application du processus est généré pour les applications (surtout des jeux) qui n'utilisent pas la plupart du système un drawable. Dans ce cas, même si la grande taille de la précharge des ressources semble avoir été un bug avec une version spécifique (ou de la télécommande de port) de l'ICS. Sinon, il est habituellement une petite quantité de mémoire, donc je doute qu'il soit jamais nécessaire de disposer d'un tel mécanisme pour réduire la précontrainte de l'utilisation de la mémoire.

Si vous êtes à court de mémoire comme un résultat de ce cache alors je serais probablement remplir un rapport de bogue à Google.

Vous pouvez suivre, par l'intermédiaire du processus de préchargement ici si vous êtes intéressé par plus de détails internes. ZygoteInit.preloadResources

Answer 2

http://www.google.com/events/io/2011/sessions/memory-management-for-android-apps.html