French subtitles

← 04-02 Memory,_GC,_and_Performance

04-02 Memory,_GC,_and_Performance

Get Embed Code
13 Languages

Showing Revision 9 created 01/01/2016 by QA_SP_4_FR.

  1. Maintenant que tout notre code
    est optimisé et que tout marche bien
  2. parlons un peu de mémoire et de son effet
    sur les performances dans notre système.
  3. Les langages de programmation qui sont
    connus pour être proche du matériel,
  4. ou plutôt, de haute performance,
    comme C, C ++,
  5. et Fortran, exigent pour les programmeurs
    de gérer la mémoire eux-mêmes.
  6. Les programmeurs sont responsables
  7. de l'allocation d'un bloc de mémoire, puis
    ensuite de sa désallocation
  8. quand ils ont fini de l'utiliser.
  9. Comme vous définissez quand et combien
    de mémoire allouer,
  10. la qualité de la gestion de mémoire dépend
    de vos compétences et de votre efficacité
  11. Une grande responsabilité.
  12. En réalité, les programmeurs
    ne sont pas toujours les meilleurs
  13. pour garder la trace
    de ces fragments de mémoire.
  14. Pensez-y, le développement de produits
    est un processus laborieux et précis.
  15. Et la mémoire finit souvent
    par ne pas être libérée proprement.
  16. Ces blocs non libérés de mémoire, ce sont
    les fuites de mémoire et ils restent là
  17. monopolisant les ressources que
    vous pourriez utiliser mieux ou ailleurs.
  18. Pour réduire ce chaos, ce stress,
    voire de grosses pertes d'argent
  19. dûes aux fuites de mémoire, on a créé
    des langages avec gestion de mémoire.
  20. Ces langages permettent de
    suivre les allocations de mémoire
  21. et libèrent la mémoire pour le système
    quand elle n'est plus nécessaire
  22. pour l'application elle-même, le tout
    sans aucune intervention du programmeur.
  23. Cet art, voire science, de récupération
    de mémoire dans un environnement
  24. de gestion de mémoire est appelé :
    garbage collection, concept créé par
  25. John McCarthy en 1959 pour résoudre
    les problèmes dans le langage Lisp.
  26. Les grands principes du garbage collection
    sont les suivants : numéro un,
  27. retrouver les données d'objets qui
    ne seront plus accessibles à l'avenir
  28. par exemple, toute mémoire
    n'étant plus référencée par le code.
  29. Numéro deux, récupérer
    les ressources utilisées par ces objets.
  30. Concept simple en théorie qui devient
    assez complexe lorsque vous avez
  31. 2 millions de lignes de code et
    quatre gigas pour les allocations.
  32. Pensez-y, le garbage collection
    peut être assez tordu, ainsi,
  33. si vous avez quelque 20 000 allocations
    dans votre programme en ce moment,
  34. lesquelles sont inutiles ?
  35. Mieux : quand faut-il exécuter
    un événement de garbage collection
  36. pour libérer de la mémoire
    qui ne sert plus ?
  37. Ce sont des questions
    très difficiles en fait,
  38. heureusement nous avons eu environ 50 ans
    d'innovation pour les améliorer,
  39. c'est pourquoi le garbage collector
    dans Android,
  40. est un peu plus sophistiqué
    que la proposition originale de McCarthy.
  41. Il a été conçu pour être rapide
    et le moins intrusif possible.
  42. Sur android la mémoire s'empile, les temps
    d’exécution se partagent en espaces
  43. sur la base du type d'allocation
    et de la meilleure façon pour le système
  44. de gérer les allocations
    pour les futurs GC.
  45. Quand un nouvel objet est alloué,
  46. ces caractéristiques sont considérées
    pour sélectionner les meilleurs espaces
  47. selon la version d'Android runtime
    que vous utilisez.
  48. Et voici la partie importante.
  49. Chaque espace a une taille définie,
  50. À mesure que les objets sont alloués,
    nous suivons le total des tailles
  51. et quand un espace commencera à grandir,
    le système devra faire un événement
  52. de garbage collection pour libérer de la
    mémoire pour les prochaines allocations.
  53. Maintenant, il faut préciser
    que les événements GC diffèreront
  54. selon le runtime Android
    que vous utilisez.
  55. Par exemple, avec Dalvik les événements GC
    sont du type : « stop the world »,
  56. ainsi tout code géré qui s'exécute
    s'arrête jusqu'à la fin de l'opération.
  57. ce qui peut devenir problématique, lorsque
    ces GC durent plus longtemps
  58. ou quand il y en a un peu trop à la fois,
  59. car cela va considérablement
    influencer votre fréquence d'images
  60. - Et soyons clairs,
  61. Les ingénieurs Android ont beaucoup
    travaillé pour que ces événements
  62. soient aussi courts que possible pour
    réduire les interruptions, cela étant dit,
  63. ils peuvent encore causer des problèmes
    de performance d'appli dans votre code.
  64. Tout d'abord, comprenez que plus
    votre appli. prend du temps à faire du GC
  65. sur une frame donnée, moins elle en a pour
    le reste du circuit logique
  66. qu'il faut pour rester sous la barrière
    des 16 millisecondes de rendu.
  67. Donc si vous avez pleins ou de longs GC
    se produisant d'affilée,
  68. cela pourrait faire passer votre de temps
    de traitement de frame au-dessus de
  69. ces 16 millisecondes de rendu, causant
    des saccades pour vos utilisateurs.
  70. Deuxièmement, sachez que votre flux
    de code peut faire le genre de choses
  71. qui entraîne plus de GC, ou les faire
    durer plus longtemps que la durée normale.
  72. Par exemple, si vous allouez beaucoup
    d'objets dans la partie la plus interne
  73. d'une boucle qui dure longtemps,
    alors vous allez polluer
  74. votre tas de mémoire avec trop d'objets et
    vous allez avoir un grand nombre de GC
  75. rapidement, du fait de cette pression
    supplémentaire sur la mémoire
  76. Même dans un environnement
    de mémoire contrôlée,
  77. des fuites de mémoire
    peuvent se produire.
  78. Bien qu'elles ne soient pas aussi faciles
    à créer qu'avec les autres langages.
  79. Ces fuites peuvent polluer votre tas
    avec des objets qui ne seront pas libérés
  80. avec un événement de GC, réduisant
    la quantité d'espace utilisable
  81. et entraînant plusieurs événements de GC,
    de façon régulière par la suite.
  82. C'est donc ça le truc,
  83. Si vous voulez réduire la quantité de GC
    qui se produit dans une frame donnée,
  84. alors vous devez optimiser l'utilisation
    de la mémoire de vos applications.
  85. Sur le plan du code, traquer l'origine
    de ce genre de problèmes
  86. peut être compliqué.
  87. Heureusement, le SDK Android dispose d'un
    ensemble d'outils puissants pour vous.
  88. Jetons-y un coup d’œil.