Return to Video

04-02 Memory,_GC,_and_Performance

  • 0:00 - 0:03
    Теперь, когда наш код
    работает быстро и просто замечательно,
  • 0:03 - 0:08
    давайте поговорим о памяти и о том, как
    она влияет на производительность системы.
  • 0:08 - 0:12
    В большинстве языков программирования
    более низкого уровня,
  • 0:12 - 0:14
    или лучше сказать, более производительных,
    вроде C, C++
  • 0:14 - 0:18
    и Fortran, обычно программистам
    приходится управлять памятью самим.
  • 0:18 - 0:20
    Фактически,
    программисты отвечают
  • 0:20 - 0:25
    за выделение блока памяти и
    за последующее его освобождение
  • 0:25 - 0:26
    по завершении работы с этим блоком.
  • 0:26 - 0:31
    Поскольку вы определяете момент и объём
    выделяемой памяти по вашему усмотрению,
  • 0:31 - 0:35
    итоговое качество управления памятью будет
    зависеть от ваших навыков и эффективности.
  • 0:35 - 0:36
    На вас ложится большая ответственность.
  • 0:36 - 0:40
    И обычно программисты не всегда могут
    наилучшим образом следить
  • 0:40 - 0:42
    за всеми теми битами и байтами памяти.
  • 0:42 - 0:45
    Разработка продукта -
    это всегда тяжелый процесс,
  • 0:45 - 0:49
    и память часто заканчивается
    будучи не освобождённой верным образом.
  • 0:49 - 0:53
    Такие неосвобождённые блоки памяти зовутся
    утечками памяти, и они просто висят,
  • 0:53 - 0:58
    занимая ресурсы, которые вы бы могли
    потратить с большей пользой где-либо ещё.
  • 0:58 - 1:01
    Чтобы уменьшить этот беспорядок, стресс,
    а иногда и снизить затраты,
  • 1:01 - 1:05
    вызванные утечками памяти, были
    разработаны языки с управлением памятью.
  • 1:05 - 1:09
    Исполнительная среда в этих языках
    следит за выделением памяти и
  • 1:09 - 1:12
    возвращает память системе,
    когда она уже более не используется
  • 1:12 - 1:16
    самим приложением, всё это без какого-либо
    контроля со стороны программиста.
  • 1:16 - 1:20
    Это искусство, или скорее наука,
    перераспределения памяти в среде
  • 1:20 - 1:24
    с управлением памяти известно как
    сбор мусора. Эта концепция была создана
  • 1:24 - 1:30
    Джоном МакКарти в 1959 году
    для решения проблем в языке LISP.
  • 1:30 - 1:33
    Основные принципы процесса сборки мусора
    следующие: первое,
  • 1:33 - 1:37
    найти объекты данных в программе,
    которые будут недоступны в дальнейшем,
  • 1:37 - 1:40
    например, какой-либо участок памяти,
    на который код не ссылается.
  • 1:40 - 1:44
    И второе, заново использовать ресурсы,
    используемые другими объектами.
  • 1:44 - 1:47
    В теории концепция проста,
    но все становится очень сложным,
  • 1:47 - 1:51
    когда у вас 2 миллиона строк кода и
    4 гигабайта памяти к распределению.
  • 1:51 - 1:53
    Теперь подумайте, сборка мусора
    может быть действительно полезна,
  • 1:53 - 1:57
    когда у вас имеется около 20 000 выделений
    памяти в программе.
  • 1:57 - 1:58
    Какие из них уже не нужны?
  • 1:58 - 2:01
    Или лучше спросить, когда следует
    запустить событие сборки мусора,
  • 2:01 - 2:04
    чтобы освободить неиспользуемую память?
  • 2:04 - 2:06
    Это сложные вопросы, на самом деле,
  • 2:06 - 2:10
    но к счастью у нас было почти 50 лет
    на разработки, чтобы внести улучшения,
  • 2:10 - 2:12
    и вот почему сборщик мусора
    в среде выполнения Android
  • 2:12 - 2:15
    представляет собой намного более мощную
    систему, чем оригинальная идея МакКарти.
  • 2:15 - 2:19
    Он создан, чтобы быть настолько быстрым и
    незаметным, насколько это возможно.
  • 2:19 - 2:23
    По сути, участки памяти в среде выполнения
    Android разделены на пространства
  • 2:23 - 2:24
    на основе типа выделения и того,
  • 2:24 - 2:28
    как система сможет организовать выделения
    памяти для событий СМ наилучшим образом.
  • 2:28 - 2:30
    Как только выделяется объект,
  • 2:30 - 2:33
    данные характеристики учитываются при
    выборе наиболее подходящего пространства,
  • 2:33 - 2:37
    в зависимости от того, какую версию
    среды выполнения Android вы используете.
  • 2:37 - 2:39
    И вот здесь один очень важный момент.
  • 2:39 - 2:41
    Пространства обладают заданным размером,
  • 2:41 - 2:44
    и когда объекты выделяются,
    мы следим за общим размером,
  • 2:44 - 2:47
    и по мере роста объема пространства
    системе необходимо вызвать событие
  • 2:47 - 2:52
    сбора мусора в попытке высвободить память
    для будущих выделений.
  • 2:52 - 2:54
    Здесь важно подчеркнуть, что события СМ
    будут вести себя по-разному,
  • 2:54 - 2:57
    в зависимости от используемой
    версии среды выполнения Android.
  • 2:57 - 3:01
    Например, в Dalvik многие события СМ
    останавливают основные события,
  • 3:01 - 3:05
    то есть любой запущенный управляемый код
    будет остановлен до конца операции.
  • 3:05 - 3:09
    Это может стать очень проблематичным,
    если такие события будут длиться дольше,
  • 3:09 - 3:11
    либо их будет слишком много,
  • 3:11 - 3:14
    поскольку это будет значительно снижать
    частоту смены кадров.
  • 3:14 - 3:15
    >> И чтобы внести ясность,
  • 3:15 - 3:18
    инженеры Android потратили много времени,
    пытаясь добиться того, чтобы эти события
  • 3:18 - 3:21
    выполнялись как можно быстрее, чтобы
    снизить прерывания, которые, как сказано,
  • 3:21 - 3:25
    могут вызвать снижение производительности
    вашего кода.
  • 3:25 - 3:29
    Во-первых, поймите, что чем больше времени
    ваше приложение тратит на сбор мусора в
  • 3:29 - 3:33
    данном цикле, тем меньше времени остается
    на остальные операции при необходимости
  • 3:33 - 3:35
    поддержания времени в пределах
    16-мсек порога отрисовки.
  • 3:35 - 3:38
    Поэтому, если у вас запускается множество
    событий СМ, либо очень долгие события идут
  • 3:38 - 3:42
    одно за другим, это может привести к
    превышению 16-мсек порога отрисовки
  • 3:42 - 3:47
    временем обработки кадра, что вызовет
    скачки или запаздывания у пользователей.
  • 3:47 - 3:50
    Во-вторых, поймите, что, возможно,
    ваш код делает что-то такое, что
  • 3:50 - 3:55
    заставляет запускать сбор мусора чаще,
    либо удлинняет этот процесс.
  • 3:55 - 3:59
    Например, если вы выделяете множество
    объектов в самом внутреннем цикле,
  • 3:59 - 4:02
    который работает очень долго,
    вы, таким образом, засоряете память
  • 4:02 - 4:06
    множеством объектов, и вам придётся
    запускать множество событий сбора мусора
  • 4:06 - 4:09
    очень быстро из-за такой
    дополнительной нехватки памяти.
  • 4:09 - 4:12
    И несмотря на то, что
    мы работаем в среде управляемой памяти,
  • 4:12 - 4:14
    утечки памяти всё-таки происходят.
  • 4:14 - 4:17
    Хотя они появляются и не так просто,
    как в других языках.
  • 4:17 - 4:20
    Такие утечки могут засорять память
    объектами, которые не будут удаляться
  • 4:20 - 4:24
    во время событий сбора мусора,
    снижая размер используемого пространства
  • 4:24 - 4:27
    и приводя в итоге к вызову ещё
    большего числа событий СМ лавинообразно.
  • 4:27 - 4:29
    Поэтому здесь нужно выбирать:
  • 4:29 - 4:33
    если вы хотите снизить количество событий
    СМ за текущий цикл обработки кадра,
  • 4:33 - 4:36
    то вам придётся заняться оптимизацией
    использования памяти вашим приложением.
  • 4:36 - 4:39
    С точки зрения кода, отследить то,
    откуда возникают подобные проблемы,
  • 4:39 - 4:41
    может быть не просто,
  • 4:41 - 4:44
    но, к счастью, Android SDK содержит в себе
    для этого мощные средства.
  • 4:44 - 4:46
    Давайте рассмотрим их.
Title:
04-02 Memory,_GC,_and_Performance
Description:

04-02 Memory,_GC,_and_Performance

more » « less
Video Language:
English
Team:
Udacity
Project:
ud825 - Android Performance
Duration:
04:47

Russian subtitles

Revisions Compare revisions