French 字幕

← 04-06 Spotting_Leaks_In_Memory_Monitor

04-06 Spotting_Leaks_In_Memory_Monitor

埋め込みコードを取得する
13言語

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

  1. Très bien, parlons des fuites de mémoire.
  2. les fuites de mémoire sont sournoises.
  3. Elles peuvent être lentes et insidieuses,
    prenant parfois des jours ou
  4. des semaines avant même de
    réaliser que vous en avez un.
  5. Vous le réaliserez peut-être seulement
    quand vos utilisateurs commencent
  6. à se plaindre de ralentissements étranges
    après l'utilisation de votre application.
  7. Ne laissez pas cela vous arriver.
  8. Heureusement, avec un peu de patience,
    une bonne tête, et les bons outils,
  9. vous aurez la possibilité d'éliminer
    ces fuites de votre application.
  10. Nous utiliserons Memory Monitor pour voir
    le comportement d'une fuite en action, et
  11. et dans la vidéo suivante, nous utiliserons
    Heap Viewer pour la confirmation initiale.
  12. Maintenant, voyons un micro exemple pour
    voir à quoi ressemble une fuite,
  13. et voir comment les outils SDK peuvent
    nous aider à identifier une telle fuite.
  14. Dans cet exemple, nous allons tourner
    l'appareil pour
  15. quelques minutes et
    le profiler avec Memory Monitor.
  16. Ceci pour vous présenter une
    situation courante de fuite qui peut
  17. arriver durant la création et
    destruction d'une activité.
  18. Nous pouvons volontairement déclencher
    ce cycle en tournant l'appareil.
  19. Oui, je sais, ça peut semble
    totalement étrange.
  20. Mais nous allons le faire pour démontrer
    comment une fuite peut se produire
  21. pour montrer comment
    ça peut être lent et insidieux.
  22. Au premier passage, la fuite consomme
    lentement la mémoire disponible pour
  23. votre application, jusqu'à finalement
    provoquer un garbage collection
  24. Plus important encore, il faut noter
    que le garbage collector
  25. ne peut récupérer toute cette énergie
    en raison de la fuite dans l'app.
  26. Et puis, finalement,
  27. Un deuxième événement GC se produit
    très tôt, environ 30 secondes plus tard.
  28. Maintenant, remarquez que quand
    la fuite consomme toute la mémoire libre,
  29. Android ajuste et accorde à l'application
    un plus haut plafond de mémoire
  30. Bien que ce soit un bel ajustement
    du système, si la fuite est pas corrigée,
  31. elle consommera de la mémoire jusqu'à ce
    que le système ne puisse plus en allouer
  32. Cela va influencer les performances
    de l'appareil et
  33. éventuellement conduire au plantage
    de votre application.
  34. Vous pouvez attendre un peu plus longtemps,
    et le troisième GC se produira.
  35. Et puis un quatrième quelque peu
    similaire aux deux premiers.
  36. Maintenant, comme vous pouvez le voir,
    le modèle continue, et
  37. plus de mémoire est allouée par le système
  38. Vous pouvez également voir un comportement
    similaire en utilisant Heap Viewer.