Нашли ошибку в тексте? Напишите нам.

Обзор управления памятью | Разработчики Android

Среда выполнения Android (ART) и виртуальная машина Dalvik используют пейджинг и отображение памяти (mmapping) для управления памятью. Это означает, что любая память приложения изменяет — будь то путем выделения новые объекты или соприкасающиеся с mmapped страницы — остается в ОЗУ и не может быть выгружен. Единственный способ освободить память из приложения — освободить ссылки на объекты, которые содержит приложение, делая память доступной для уборщик мусора. То есть за одним исключением: любые файлы mmapped без изменений, таких как код, могут быть выгружены из ОЗУ, если система хочет использовать эту память в другом месте.

На этой странице объясняется, как Android управляет процессами приложений и памятью. распределение. Для получения дополнительной информации о том, как более эффективно управлять памятью, см. в вашем приложении см. Управляйте памятью вашего приложения.

Вывоз мусора

Среда управляемой памяти, такая как виртуальная машина ART или Dalvik, отслеживает каждое выделение памяти. Как только он определит что часть памяти больше не используется программой, он освобождает его обратно в кучу без какого-либо вмешательства со стороны программиста. Механизм освобождения неиспользуемой памяти в среде управляемой памяти известен как сбор мусора . Сбор мусора преследует две цели: находить в программе объекты данных, к которым в будущем нельзя будет получить доступ; а также восстановить ресурсы, используемые этими объектами.

Куча памяти Android является памятью поколений, а это означает, что различные группы распределений, которые он отслеживает, на основе ожидаемого срока службы и размера выделяемого объекта. Например, недавно выделенные объекты относятся к молодому поколению . Когда объект остается активным достаточно долго, его можно продвигать к старшему поколению, за которым следует постоянное поколение.

Каждое поколение кучи имеет свой собственный выделенный верхний предел объема памяти, которую могут занимать объекты. Каждый раз, когда начинается поколение чтобы заполнить, система выполняет сборку мусора событие в попытке освободить память. Продолжительность сбора мусора зависит от того, какое поколение объектов он собирает и сколько активных объектов в каждом поколении.

Несмотря на то, что сборка мусора может быть довольно быстрой, она все же может влияют на производительность вашего приложения. Вы обычно не контролируете когда внутри вашего кода происходит событие сборки мусора. Система имеет текущий набор критериев для определения того, когда выполнять вывоз мусора. Когда критерии удовлетворены, система прекращает выполнение процесса и начинает сборку мусора. Если сборка мусора происходит в середине цикла интенсивной обработки как анимация или во время воспроизведения музыки, это может увеличить время обработки. Это увеличение потенциально может подтолкнуть выполнение кода в вашем приложении к рекомендуемый порог 16 мс для эффективного и плавного рендеринга кадров.

Кроме того, ваш поток кода может выполнять виды работы, которые принудительное выполнение событий сборки мусора чаще или заставить их длиться дольше, чем обычно. Например, если вы выделяете несколько объектов в самая внутренняя часть цикла for во время каждого кадра альфа-канала смешивая анимацию, вы можете загрязнить кучу памяти много объектов.

Дополнительные общие сведения о сборке мусора см. Вывоз мусора.

Общая память

Для того, чтобы уместить все необходимое в оперативной памяти, Android пытается разделить страницы оперативной памяти между процессами. Это можно сделать это следующими способами:

• Каждый процесс приложения разветвляется из существующего процесса под названием Zygote. Процесс Zygote запускается при загрузке системы и загружает общие код и ресурсы фреймворка (например, темы деятельности). Чтобы запустить новый процесс приложения, система разветвляет процесс Zygote, затем загружает и запускает код приложения в новом процессе. Такой подход позволяет использовать большую часть страниц ОЗУ, выделенных для код и ресурсы фреймворка, которые будут совместно использоваться всеми процессами приложения.
• Большинство статических данных mmapped в процесс. Этот метод позволяет обмениваться данными между процессами, а также позволяет его пейджинг выходит, когда это необходимо. Примеры статических данных включают: Код Dalvik (поместив его в предварительно связанный .odex файл для прямого mmapping), ресурсы приложения (путем разработки таблицы ресурсов как структуры который может быть mmapped и путем выравнивания почтового индекса записи APK) и традиционный проект такие элементы, как нативный код в .so
  файлов.
• Во многих местах Android имеет одинаковую динамику. Оперативная память между процессами с использованием явно выделенного общие области памяти (либо с ashmem, либо с gralloc). Например, оконные поверхности используют общие память между приложением и компоновщиком экрана, и буферы курсора используют общую память между контент-провайдер и клиент.

Из-за широкого использования разделяемой памяти определение сколько памяти использует ваше приложение забота. Методы правильного определения вашего приложения использование памяти обсуждается в Исследование использования вашей оперативной памяти.

Выделение и освобождение памяти приложения

Куча Dalvik ограничена единый диапазон виртуальной памяти для каждого процесса приложения. Это определяет логический размер кучи, который может увеличиваться по мере необходимости но только до предела, который определяет система для каждого приложения.

Логический размер кучи отличается от объем физической памяти, используемой кучей. При проверке кучи вашего приложения Android вычисляет значение, называемое пропорциональным размером набора (PSS), который учитывает как грязные, так и чистые страницы которые используются совместно с другими процессами, но только в сумма, которая пропорциональна количеству общих приложений что ОЗУ. Это (PSS) общее количество, которое система считается вашим объемом физической памяти. Дополнительные сведения о PSS см. Исследование использования вашей оперативной памяти руководство.

Куча Dalvik не уплотняет логическую размер кучи, что означает, что Android не дефрагментировать кучу, чтобы закрыть пространство. Андроид может уменьшить размер логической кучи только тогда, когда неиспользуемое пространство в конце кучи. Однако, система по-прежнему может уменьшить физическую память, используемую кучей. После сборки мусора Dalvik просматривает кучу и находит неиспользуемые страницы, затем возвращается эти страницы в ядро ​​с помощью madvise. Итак, в паре выделение и освобождение крупных куски должны привести к восстановлению всех (или почти всех) используемая физическая память. Однако, восстановление памяти из небольших выделений может быть намного менее эффективен, потому что страница использовала для небольшого выделения все еще может использоваться совместно с что-то еще, что еще не было освобождено.

Ограничить память приложения

Чтобы поддерживать функциональную многозадачную среду, Android устанавливает жесткое ограничение на размер кучи для каждого приложения. Точный предел размера кучи варьируется между устройствами в зависимости от объема оперативной памяти устройства есть в наличии в целом. Если ваше приложение достигло кучи и пытается выделить больше память, он может получить OutOfMemoryError .

В некоторых случаях может потребоваться запросить систему, чтобы точно определить, сколько места в куче вы доступны на текущем устройстве, например, чтобы определить, сколько данных безопасно хранить в кеш. Вы можете запросить у системы этот рисунок, позвонив getMemoryClass() . Этот метод возвращает целое число, указывающее количество мегабайты, доступные для кучи вашего приложения.

Переключение приложений

Когда пользователи переключаются между приложениями, Android хранит приложения, которые не находятся на переднем плане, то есть не видны пользователю или запущенному службы переднего плана, такие как воспроизведение музыки — в кэше. Например, когда пользователь впервые запускает приложение, для него создается процесс; но когда пользователь покидает приложение, этот процесс делает , а не выйти. Система хранит процесс в кэше. Если пользователь позже возвращается в приложение, система повторно использует процесс, тем самым ускоряет переключение приложений.

Если ваше приложение имеет кешированный процесс и сохраняет ресурсы что в данный момент не нужно, то ваше приложение — даже когда пользователь его не использует — влияет на систему Общая производительность. Поскольку системе не хватает ресурсов, таких как память, он убивает процессы в кеше. Система также учитывает процессы, которые занимают больше всего памяти и может завершить их, чтобы освободить оперативную память.

Примечание: Чем меньше памяти потребляет ваше приложение в кэше, тем выше его шансы не быть убитым и иметь возможность быстро возобновиться. Однако, в зависимости от мгновенных системных требований, возможно кэширование процессы, которые могут быть остановлены в любое время независимо от использования их ресурсов.

Для получения дополнительной информации о кэшировании процессов во время не работает на переднем плане и как Android решает, какие можно убить, см. Процессы и потоки руководство.

Управление памятью в Android. Управление памятью Android | by Niharika Arora

Android использует подкачку и mmap вместо предоставления пространства подкачки, что означает, что любая память, к которой прикасается ваше приложение, не может быть выгружена, пока вы не освободите все ссылки.

Размер кучи виртуальной машины Dalvik* для процессов приложений ограничен. Приложения запускаются с 2 МБ, а максимальное выделение, помеченное как «largeHeap», ограничено 36 МБ (в зависимости от конкретной конфигурации устройства). Примерами приложений с большой кучей являются Photo/Video Editor, Camera, Gallery и Home Screen.

Android хранит фоновые процессы приложений в кэше LRU. Когда системе не хватает памяти, она убивает процессы в соответствии со стратегией LRU, но также учитывает, какое приложение потребляет больше всего памяти. В настоящее время максимальное количество фоновых процессов равно 20 (в зависимости от конкретной конфигурации устройства). Если вам нужно, чтобы ваше приложение дольше работало в фоновом режиме, освободите ненужную память перед переходом в фоновый режим, и система Android с меньшей вероятностью выдаст сообщение об ошибке или даже завершит работу приложения.

Среда управляемой памяти, такая как виртуальная машина ART или Dalvik, отслеживает каждое выделение памяти. Как только он определяет, что часть памяти больше не используется программой, он освобождает ее обратно в кучу без какого-либо вмешательства со стороны программиста. Механизм освобождения неиспользуемой памяти в среде управляемой памяти известен как сборка мусора . Сборка мусора преследует две цели: найти объекты данных в программе, к которым нельзя будет получить доступ в будущем; и восстановить ресурсы, используемые этими объектами.

Куча памяти Android относится к поколениям, а это означает, что существуют разные группы выделений памяти, которые она отслеживает в зависимости от ожидаемого срока службы и размера выделяемого объекта. Например, недавно выделенные объекты относятся к молодому поколению . Когда объект остается активным достаточно долго, его можно повысить до более старого поколения, за которым следует постоянное поколение.

Каждое поколение кучи имеет свой собственный выделенный верхний предел объема памяти, который могут занимать объекты. Каждый раз, когда поколение начинает заполняться, система выполняет событие сборки мусора, пытаясь освободить память. Продолжительность сборки мусора зависит от того, какое поколение объектов оно собирает и сколько активных объектов находится в каждом поколении.

Несмотря на то, что сборка мусора может быть довольно быстрой, она все же может повлиять на производительность вашего приложения. Обычно вы не контролируете, когда происходит событие сборки мусора из вашего кода. В системе есть работающий набор критериев для определения того, когда выполнять сборку мусора. Когда критерии удовлетворяются, система прекращает выполнение процесса и начинает сборку мусора. Если сборка мусора происходит в середине цикла интенсивной обработки, такой как анимация или воспроизведение музыки, это может увеличить время обработки. Это увеличение потенциально может привести к тому, что выполнение кода в вашем приложении превысит рекомендуемый порог в 16 мс для эффективного и плавного рендеринга кадров.

Кроме того, ваш поток кода может выполнять виды работы, которые заставляют события сборки мусора происходить чаще или заставляют их длиться дольше, чем обычно. Например, если вы выделяете несколько объектов в самой внутренней части цикла for во время каждого кадра анимации альфа-смешивания, вы можете засорить кучу памяти большим количеством объектов. В этом случае сборщик мусора выполняет несколько событий сборки мусора и может снизить производительность вашего приложения.

Студия Android включает инструмент отладки под названием Dalvik Debug Monitor Service (DDMS). DDMS предоставляет такие услуги, как захват экрана на устройстве, многопоточность, информация о куче на устройстве, logcat, процессы, входящие вызовы, проверка SMS, местоположение, спуфинг данных и многое другое, связанное с тестированием вашего приложения для Android.

DDMS подключает IDE к приложениям, работающим на устройстве. В Android каждое приложение работает в своем собственном процессе, в каждом из которых размещается собственная виртуальная машина (ВМ). И каждый процесс прослушивает отладчик на другом порту.

При запуске DDMS подключается к ADB ( Android Debug Bridge , утилита командной строки, входящая в состав Google Android SDK). Отладчик Android используется для отладки приложения Android и запускает службу мониторинга устройств между ними. Это уведомит DDMS о подключении или отключении устройства. Когда устройство подключено, между ADB и DDMS создается служба мониторинга ВМ, которая уведомляет DDMS о запуске или завершении работы ВМ на устройстве.

Android — это всемирная мобильная платформа, и миллионы разработчиков Android занимаются созданием стабильных и масштабируемых приложений. Вот список советов и рекомендаций по улучшению использования памяти в приложениях Android:

1. Будьте осторожны при использовании шаблона проектирования с «абстракцией». Хотя с точки зрения шаблона проектирования абстракция может помочь построить более гибкого архитектора программного обеспечения. В мобильном мире абстракция может включать в себя побочный эффект для выполнения своего дополнительного кода, что потребует больше времени и памяти. Если абстракция не может обеспечить вашему приложению значительную пользу, вам лучше не использовать ее.
2. Избегайте использования «enum». Перечисление удваивает выделение памяти, чем обычная статическая константа, поэтому не используйте его.
3. Попробуйте использовать оптимизированные контейнеры SparseArray, SparseBooleanArray и LongSparseArray вместо HashMap. HashMap выделяет объект записи во время каждого сопоставления, что является неэффективным действием памяти, а также поведение с низкой производительностью — «автоупаковка/распаковка» распространяется на все использование. Вместо этого контейнеры, подобные SparseArray, сопоставляют ключи с простым массивом. Но помните, что эти оптимизированные контейнеры не подходят для большого количества элементов, при выполнении действий добавления/удаления/поиска они медленнее, чем Hashmap, если ваш набор данных превышает тысячи записей.
4. Избегайте создания ненужных объектов. Не выделяйте память специально для краткосрочных временных объектов, если этого можно избежать, и сборка мусора будет происходить реже, когда создается меньше объектов.
5. Проверьте доступную кучу вашего приложения. Вызовите ActivityManager::getMemoryClass(), чтобы узнать, сколько кучи (МБ) доступно для вашего приложения. Исключение OutofMemory возникнет, если вы попытаетесь выделить больше памяти, чем доступно. Если ваше приложение объявляет «большую кучу» в AndroidManifest.xml, вы можете вызвать ActivityManager::getLargeMemoryClass() для запроса предполагаемого большого размера кучи.
6. Координация с системой путем реализации обратного вызова onTrimMemory(). Внедрите ComponentCallbacks2::onTrimMemory(int) в Activity/Service/ContentProvider, чтобы постепенно освобождать память в соответствии с последними системными ограничениями. onTrimMemory(int) повышает общую скорость отклика системы, а также дольше поддерживает ваш процесс в системе.
7. Когда возникает TRIM_MEMORY_UI_HIDDEN, это означает, что весь пользовательский интерфейс в вашем приложении был скрыт, и вам необходимо освободить ресурсы пользовательского интерфейса. Когда ваше приложение находится в активном режиме, вы можете получить TRIM_MEMORY_RUNNING[MODERATE/LOW/CRITICAL] или в фоновом режиме вы можете получить TRIM_MEMORY_[BACKGROUND/MODERATE/COMPLETE]. Вы можете освободить некритические ресурсы на основе стратегии освобождения памяти при нехватке системной памяти.
8. Внешние библиотеки следует использовать с осторожностью. Внешние библиотеки часто пишутся для немобильных устройств и могут быть неэффективны в Android. Вы должны принять во внимание усилия по переносу и оптимизации библиотеки для мобильных устройств, прежде чем решите ее использовать. Если вы используете библиотеку только для одной или двух функций из тысяч других применений, может быть лучше реализовать ее самостоятельно.
9. Службы следует использовать с осторожностью. Если вам нужна служба для запуска задания в фоновом режиме, избегайте ее работы, если она не активно выполняет задачу. Попробуйте сократить срок его службы, используя IntentService, который завершит свою работу, когда завершит обработку намерения. Службы следует использовать с осторожностью, чтобы никогда не оставлять одну из них работающей, когда она не нужна. В худшем случае общая производительность системы будет низкой, и пользователи найдут ваше приложение и удалят его (если это возможно).
10. Но если вы создаете приложение, которое должно работать в течение длительного периода времени, например, службу музыкального проигрывателя, вы должны разделить его на два процесса: один для пользовательского интерфейса, а другой для фоновой службы, установив свойство «android:process» для вашей службы в AndroidManifest.xml. Ресурсы в процессе пользовательского интерфейса могут быть освобождены после скрытия, в то время как служба фонового воспроизведения все еще работает. Имейте в виду, что процесс фоновой службы НЕ ДОЛЖЕН касаться какого-либо пользовательского интерфейса; в противном случае выделение памяти будет удвоено или утроено!

Аккуратно используйте память. Приведенные выше советы могут постепенно принести пользу вашему приложению и продлить его работу в системе. Но все преимущества будут потеряны, если произойдет утечка памяти. Вот некоторые знакомые потенциальные утечки, которые разработчик должен иметь в виду.

1. Не забудьте закрыть курсор после запроса базы данных. Если вы хотите держать курсор открытым в течение длительного времени, вы должны использовать его осторожно и закрыть его, как только задача базы данных завершится.
2. Не забудьте вызвать unregisterReceiver() после вызова registerReceiver().
3. Избегайте утечки контекста. Если вы объявите статическую переменную-член «Drawable» в своей Activity, а затем вызовете view.setBackground(drawable) в onCreate(), после поворота экрана будет создан новый экземпляр Activity, а старый экземпляр Activity никогда не сможет быть освобожден. потому что drawable установил представление как обратный вызов, а представление имеет ссылку на действие (контекст). Утечка экземпляра Activity означает значительный объем памяти, что легко приведет к OOM.
4. Есть два способа избежать такой утечки:

• Не хранить долгоживущие ссылки на контекстную активность. Ссылка на действие должна иметь тот же жизненный цикл, что и само действие.
• Попробуйте использовать контекстное приложение вместо контекстной активности.

5. Будьте осторожны при использовании потоков. Потоки в Java — это корни сборки мусора; то есть виртуальная машина Dalvik (DVM) хранит жесткие ссылки на все активные потоки в системе выполнения, и в результате потоки, оставшиеся работающими, никогда не будут допущены к сборке мусора. Потоки Java будут сохраняться до тех пор, пока они не будут явно закрыты или весь процесс не будет уничтожен системой Android. Вместо этого платформа приложений Android предоставляет множество классов, предназначенных для облегчения фоновой работы разработчиков:

• Используйте загрузчик вместо потока для выполнения кратковременных асинхронных фоновых запросов в сочетании с жизненным циклом Activity.
• Используйте службу и сообщите о результатах в действие с помощью BroadcastReceiver.
• Используйте AsyncTask для кратковременных операций.

Средство профилирования Android поможет вам управлять памятью на устройстве Android. Android SDK предоставляет два способа профилирования памяти приложений:

1. Использование Allocation Tracker
2. Использование дампа кучи

Allocation Tracker записывает каждое выделение памяти, которое приложение выполняет во время цикла профилирования. Средство отслеживания распределения полезно, когда вы хотите узнать, какой тип распределения памяти имеет место. Но это не дает вам никакой информации о куче приложения, которая представляет собой память , отведенную для динамического распределения памяти.

Средство отслеживания распределения отображает выделение памяти для выбранного процесса. Он показывает конкретные выделяемые объекты вместе с потоком, методом и строковым кодом, который их выделил.

DDMS предоставляет возможность отслеживать объекты, выделяемые в память, и видеть, какие классы и потоки выделяют эти объекты. Это позволяет вам отслеживать, где размещаются объекты в режиме реального времени, когда вы выполняете определенные действия в своем приложении. Эти данные полезны для измерения использования памяти, которое в противном случае может повлиять на производительность приложения.

• Установите приложение в эмулятор Android или на устройство. Нажмите кнопку Android в нижней части Android Studio.
• Начать отслеживание распределения.
• Поэкспериментируйте с приложением некоторое время.
• Остановить отслеживание распределения.

См. рисунок ниже:

• Через несколько секунд откроется панель с вашими записанными данными.

Дамп кучи — это моментальный снимок кучи приложения, который хранится в двоичном формате HPROF. Виртуальная машина Dalvik может создавать полный дамп содержимого виртуальной кучи.