-
Title:
04-04 Memory_Leaks
-
Description:
-
Une des meilleures choses le langage
Java Android, c'est un environnement
-
de mémoire gérée, en d'autre termes,
vous n'avez pas à trop vous préoccupez
-
de la création et destruction des objets
-
Bien que ce soit le plus souvent génial
-
Il y a quelques problèmes
de performance cachés ici.
-
Rappelez-vous, les tas de mémoire
dans les runtimes Android
-
sont segmentés en espace,
en fonction du type d'allocation et
-
la meilleure façon pour le système de gérer
les allocations des futurs événements GC.
-
Et chaque espace a sa propre
taille de mémoire réservée.
-
Lorsque la taille combinée d'un objet dans
un espace approche sa limite supérieure
-
un événement garbage collection est
déclenché pour libérer de l'espace et
-
supprimer les objets inutiles.
-
ces GC ne sont habituellement pas
un problème pour votre performance.
-
Cependant, s'il sont récurrents
de plus en plus et encore plus
-
peut rapidement influencer
votre temps de frame
-
Plus vous passer de temps à faire du GC,
-
moins vous en avez pour autres choses
comme le rendu ou le streaming audio.
-
Choses courantes pour les développeurs
et qui entraîne beaucoup de
-
ces évènements de GC
sont les fuites de mémoire.
-
Les fuites de mémoire sont des objets
que l'application n'utilise plus,
-
mais le garbage collector ne les
reconnaît pas comme inutile
-
Le résultat est qu'ils
restent dans votre tas,
-
occupant un espace précieux
jamais libéré pour d'autres objets.
-
Si vous continuez à avoir
des fuites de mémoire
-
l'espace disponible dans la génération de
de votre tas continue à devenir
-
de plus en plus petit, ce qui signifie
que plus de GC viendront plus souvent
-
Pour essayer de libérer de l'espace pour
l'exécution normale du programme.
-
La recherche et la correction
des fuites de mémoire est assez complexe.
-
Certaines fuites de mémoire peuvent
survenir très facilement,
-
par exemple des références circulaires
aux objets que le programme n'utilise pas
-
d'autres ne sont pas aussi simples,
-
comme tenir aux objets class loader
quand ils sont chargés.
-
Dans les deux cas, une bonne application,
bien rapide, doit être consciente et
-
réceptive aux fuites de mémoire
qui peuvent exister.
-
Votre code va être exécuté
sur plein de périphériques,
-
de différents types, et
-
ils n'auront pas tous la même
taille et empreinte de mémoire
-
Heureusement, il y a un outil simple
qui vous permet de voir là
-
où ces fuites pourraient se produire
à l'intérieur du SDK Android.
-
Allons voir ça!