Russian subtitles

← 04-02 Memory,_GC,_and_Performance

04-02 Memory,_GC,_and_Performance

Get Embed Code
13 Languages

Showing Revision 3 created 01/24/2016 by sp16.

  1. Теперь, когда наш код
    работает быстро и просто замечательно,
  2. давайте поговорим о памяти и о том, как
    она влияет на производительность системы.
  3. В большинстве языков программирования
    более низкого уровня,
  4. или лучше сказать, более производительных,
    вроде C, C++
  5. и Fortran, обычно программистам
    приходится управлять памятью самим.
  6. Фактически,
    программисты отвечают
  7. за выделение блока памяти и
    за последующее его освобождение
  8. по завершении работы с этим блоком.
  9. Поскольку вы определяете момент и объём
    выделяемой памяти по вашему усмотрению,
  10. итоговое качество управления памятью будет
    зависеть от ваших навыков и эффективности.
  11. На вас ложится большая ответственность.
  12. И обычно программисты не всегда могут
    наилучшим образом следить
  13. за всеми теми битами и байтами памяти.
  14. Разработка продукта -
    это всегда тяжелый процесс,
  15. и память часто заканчивается
    будучи не освобождённой верным образом.
  16. Такие неосвобождённые блоки памяти зовутся
    утечками памяти, и они просто висят,
  17. занимая ресурсы, которые вы бы могли
    потратить с большей пользой где-либо ещё.
  18. Чтобы уменьшить этот беспорядок, стресс,
    а иногда и снизить затраты,
  19. вызванные утечками памяти, были
    разработаны языки с управлением памятью.
  20. Исполнительная среда в этих языках
    следит за выделением памяти и
  21. возвращает память системе,
    когда она уже более не используется
  22. самим приложением, всё это без какого-либо
    контроля со стороны программиста.
  23. Это искусство, или скорее наука,
    перераспределения памяти в среде
  24. с управлением памяти известно как
    сбор мусора. Эта концепция была создана
  25. Джоном МакКарти в 1959 году
    для решения проблем в языке LISP.
  26. Основные принципы процесса сборки мусора
    следующие: первое,
  27. найти объекты данных в программе,
    которые будут недоступны в дальнейшем,
  28. например, какой-либо участок памяти,
    на который код не ссылается.
  29. И второе, заново использовать ресурсы,
    используемые другими объектами.
  30. В теории концепция проста,
    но все становится очень сложным,
  31. когда у вас 2 миллиона строк кода и
    4 гигабайта памяти к распределению.
  32. Теперь подумайте, сборка мусора
    может быть действительно полезна,
  33. когда у вас имеется около 20 000 выделений
    памяти в программе.
  34. Какие из них уже не нужны?
  35. Или лучше спросить, когда следует
    запустить событие сборки мусора,
  36. чтобы освободить неиспользуемую память?
  37. Это сложные вопросы, на самом деле,
  38. но к счастью у нас было почти 50 лет
    на разработки, чтобы внести улучшения,
  39. и вот почему сборщик мусора
    в среде выполнения Android
  40. представляет собой намного более мощную
    систему, чем оригинальная идея МакКарти.
  41. Он создан, чтобы быть настолько быстрым и
    незаметным, насколько это возможно.
  42. По сути, участки памяти в среде выполнения
    Android разделены на пространства
  43. на основе типа выделения и того,
  44. как система сможет организовать выделения
    памяти для событий СМ наилучшим образом.
  45. Как только выделяется объект,
  46. данные характеристики учитываются при
    выборе наиболее подходящего пространства,
  47. в зависимости от того, какую версию
    среды выполнения Android вы используете.
  48. И вот здесь один очень важный момент.
  49. Пространства обладают заданным размером,
  50. и когда объекты выделяются,
    мы следим за общим размером,
  51. и по мере роста объема пространства
    системе необходимо вызвать событие
  52. сбора мусора в попытке высвободить память
    для будущих выделений.
  53. Здесь важно подчеркнуть, что события СМ
    будут вести себя по-разному,
  54. в зависимости от используемой
    версии среды выполнения Android.
  55. Например, в Dalvik многие события СМ
    останавливают основные события,
  56. то есть любой запущенный управляемый код
    будет остановлен до конца операции.
  57. Это может стать очень проблематичным,
    если такие события будут длиться дольше,
  58. либо их будет слишком много,
  59. поскольку это будет значительно снижать
    частоту смены кадров.
  60. >> И чтобы внести ясность,
  61. инженеры Android потратили много времени,
    пытаясь добиться того, чтобы эти события
  62. выполнялись как можно быстрее, чтобы
    снизить прерывания, которые, как сказано,
  63. могут вызвать снижение производительности
    вашего кода.
  64. Во-первых, поймите, что чем больше времени
    ваше приложение тратит на сбор мусора в
  65. данном цикле, тем меньше времени остается
    на остальные операции при необходимости
  66. поддержания времени в пределах
    16-мсек порога отрисовки.
  67. Поэтому, если у вас запускается множество
    событий СМ, либо очень долгие события идут
  68. одно за другим, это может привести к
    превышению 16-мсек порога отрисовки
  69. временем обработки кадра, что вызовет
    скачки или запаздывания у пользователей.
  70. Во-вторых, поймите, что, возможно,
    ваш код делает что-то такое, что
  71. заставляет запускать сбор мусора чаще,
    либо удлинняет этот процесс.
  72. Например, если вы выделяете множество
    объектов в самом внутреннем цикле,
  73. который работает очень долго,
    вы, таким образом, засоряете память
  74. множеством объектов, и вам придётся
    запускать множество событий сбора мусора
  75. очень быстро из-за такой
    дополнительной нехватки памяти.
  76. И несмотря на то, что
    мы работаем в среде управляемой памяти,
  77. утечки памяти всё-таки происходят.
  78. Хотя они появляются и не так просто,
    как в других языках.
  79. Такие утечки могут засорять память
    объектами, которые не будут удаляться
  80. во время событий сбора мусора,
    снижая размер используемого пространства
  81. и приводя в итоге к вызову ещё
    большего числа событий СМ лавинообразно.
  82. Поэтому здесь нужно выбирать:
  83. если вы хотите снизить количество событий
    СМ за текущий цикл обработки кадра,
  84. то вам придётся заняться оптимизацией
    использования памяти вашим приложением.
  85. С точки зрения кода, отследить то,
    откуда возникают подобные проблемы,
  86. может быть не просто,
  87. но, к счастью, Android SDK содержит в себе
    для этого мощные средства.
  88. Давайте рассмотрим их.