Showing Revision 1 created 12/26/2015 by sp16.

1. Title:
   04-04 Memory_Leaks
2. Description:

   04-04 Memory_Leaks

3. 280 0:00 - 0:04
   Une des meilleures choses le langage
   Java Android, c'est un environnement
4. 4310 0:04 - 0:08
   de mémoire gérée, en d'autre termes,
   vous n'avez pas à trop vous préoccupez
5. 8470 0:08 - 0:11
   de la création et destruction des objets
6. 11060 0:11 - 0:13
   Bien que ce soit le plus souvent génial
7. 12620 0:13 - 0:17
   Il y a quelques problèmes
   de performance cachés ici.
8. 17330 0:17 - 0:20
   Rappelez-vous, les tas de mémoire
   dans les runtimes Android
9. 20330 0:20 - 0:24
   sont segmentés en espace,
   en fonction du type d'allocation et
10. 23720 0:24 - 0:28
    la meilleure façon pour le système de gérer
    les allocations des futurs événements GC.
11. 27980 0:28 - 0:31
    Et chaque espace a sa propre
    taille de mémoire réservée.
12. 30580 0:31 - 0:34
    Lorsque la taille combinée d'un objet dans
    un espace approche sa limite supérieure
13. 34140 0:34 - 0:38
    un événement garbage collection est
    déclenché pour libérer de l'espace et
14. 38050 0:38 - 0:40
    supprimer les objets inutiles.
15. 39612 0:40 - 0:44
    ces GC ne sont habituellement pas
    un problème pour votre performance.
16. 43935 0:44 - 0:46
    Cependant, s'il sont récurrents
    de plus en plus et encore plus
17. 46369 0:46 - 0:49
    peut rapidement influencer
    votre temps de frame
18. 48915 0:49 - 0:51
    Plus vous passer de temps à faire du GC,
19. 50725 0:51 - 0:54
    moins vous en avez pour autres choses
    comme le rendu ou le streaming audio.
20. 54492 0:54 - 0:58
    Choses courantes pour les développeurs
    et qui entraîne beaucoup de
21. 57632 0:58 - 1:01
    ces évènements de GC
    sont les fuites de mémoire.
22. 60792 1:01 - 1:04
    Les fuites de mémoire sont des objets
    que l'application n'utilise plus,
23. 64272 1:04 - 1:07
    mais le garbage collector ne les
    reconnaît pas comme inutile
24. 67402 1:07 - 1:10
    Le résultat est qu'ils
    restent dans votre tas,
25. 69502 1:10 - 1:13
    occupant un espace précieux
    jamais libéré pour d'autres objets.
26. 73282 1:13 - 1:15
    Si vous continuez à avoir
    des fuites de mémoire
27. 74542 1:15 - 1:18
    l'espace disponible dans la génération de
    de votre tas continue à devenir
28. 77802 1:18 - 1:22
    de plus en plus petit, ce qui signifie
    que plus de GC viendront plus souvent
29. 82230 1:22 - 1:25
    Pour essayer de libérer de l'espace pour
    l'exécution normale du programme.
30. 85490 1:25 - 1:29
    La recherche et la correction
    des fuites de mémoire est assez complexe.
31. 88530 1:29 - 1:30
    Certaines fuites de mémoire peuvent
    survenir très facilement,
32. 90040 1:30 - 1:34
    par exemple des références circulaires
    aux objets que le programme n'utilise pas
33. 93790 1:34 - 1:35
    d'autres ne sont pas aussi simples,
34. 95410 1:35 - 1:40
    comme tenir aux objets class loader
    quand ils sont chargés.
35. 99680 1:40 - 1:43
    Dans les deux cas, une bonne application,
    bien rapide, doit être consciente et
36. 103160 1:43 - 1:46
    réceptive aux fuites de mémoire
    qui peuvent exister.
37. 105640 1:46 - 1:48
    Votre code va être exécuté
    sur plein de périphériques,
38. 108160 1:48 - 1:49
    de différents types, et
39. 109270 1:49 - 1:52
    ils n'auront pas tous la même
    taille et empreinte de mémoire
40. 112150 1:52 - 1:55
    Heureusement, il y a un outil simple
    qui vous permet de voir là
41. 115420 1:55 - 1:58
    où ces fuites pourraient se produire
    à l'intérieur du SDK Android.
42. 117610 1:58 - 1:59
    Allons voir ça!