Showing Revision 4 created 02/02/2016 by QA_SP_1_RU.

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

   04-04 Memory_Leaks

3. 280 0:00 - 0:04
   Одной из лучших черт языка Java в Android
   является то, что эта среда
4. 4310 0:04 - 0:08
   cама управляет памятью,
   и вам не нужно следить за тем,
5. 8470 0:08 - 0:11
   когда объекты создаются или уничтожаются.
6. 11060 0:11 - 0:14
   Однако, хотя это всё и хорошо,
7. 13620 0:14 - 0:17
   есть скрытые проблемы производительности,
   которые скрываются под поверхностью.
8. 17330 0:17 - 0:20
   Теперь запомните, динамическая память
   в среде выполнения Android
9. 20330 0:20 - 0:24
   разделена на пространства
   на основе типа выделения и того,
10. 23720 0:24 - 0:28
    как система сможет организовать выделения
    памяти для событий СМ наилучшим образом.
11. 27980 0:28 - 0:31
    Каждое такое пространство обладает
    своим зарезервированным объёмом памяти.
12. 30980 0:31 - 0:34
    Когда общий размер объекта в пространстве
    приближается к верхнему пределу,
13. 34140 0:34 - 0:38
    запускается событие сборки мусора,
    чтобы освободить пространство
14. 38050 0:38 - 0:40
    и удалить ненужные объекты.
15. 39612 0:40 - 0:44
    Такие события СМ обычно не влияют на
    производительность вашей системы.
16. 43935 0:44 - 0:46
    Однако, когда много таких событий
    запускается снова и снова,
17. 46369 0:46 - 0:49
    это может быстро снизить
    частоту смены кадров.
18. 48915 0:49 - 0:51
    Чем больше времени тратится на СМ,
19. 50725 0:51 - 0:54
    тем меньше его остаётся на другие задачи,
    вроде отрисовки или трансляции аудио.
20. 54492 0:54 - 0:58
    Одной из таких обычных ситуаций,
    с которой сталкиваются разработчики
21. 57632 0:58 - 1:01
    при инициации множества событий СМ,
    является утечка памяти.
22. 60792 1:01 - 1:04
    Утечки памяти — это объекты,
    которые приложение больше не использует,
23. 64272 1:04 - 1:07
    однако сборщик мусора не может распознать
    их как неиспользуемые.
24. 67402 1:07 - 1:10
    В результате
    они остаются в памяти постоянно,
25. 69502 1:10 - 1:13
    занимая ценное пространство, которое
    не освобождается для других объектов.
26. 73282 1:13 - 1:15
    По мере роста утечки памяти
27. 74542 1:15 - 1:18
    доступное пространство в поколениях памяти
    будет становиться всё меньше,
28. 77802 1:18 - 1:22
    что приведёт к тому,
    что события СМ будут запускаться всё чаще,
29. 82230 1:22 - 1:25
    пытаясь высвободить пространство для
    нормальной работы программы.
30. 85490 1:25 - 1:29
    Задача поиска и устранения утечек
    довольно не проста.
31. 88530 1:29 - 1:30
    Некоторые утечки очень легко создать,
32. 90040 1:30 - 1:34
    например, создавая циклические ссылки
    на неиспользуемые программой объекты.
33. 93790 1:34 - 1:35
    Другие утечки не так просты,
34. 95410 1:35 - 1:40
    вроде удержания дескрипторов на объектах
    загрузки классов в процессе их загрузки.
35. 99680 1:40 - 1:43
    В любом случае, стабильно работающее
    быстрое приложение должно следить
36. 103160 1:43 - 1:46
    и определять возможности возникновения
    утечек памяти.
37. 105640 1:46 - 1:48
    Я хочу сказать,
    что ваша программа будет работать
38. 107720 1:48 - 1:49
    на множестве разных устройств,
39. 109270 1:49 - 1:52
    и не все они будут иметь те же
    объёмы и параметры памяти.
40. 112150 1:52 - 1:55
    К счастью, в самом пакете Android SDK
    имеется простой инструмент,
41. 115420 1:55 - 1:58
    помогающий нам понять,
    где могут возникать утечки.
42. 117610 1:58 - 1:59
    Давайте рассмотрим его.