Android largeheap что это

Русские Блоги

Изучите android: largeHeap

В повседневной разработке Android мы, должно быть, сталкивались со сбоями, такими как OutOfMemoryError. Причины — не более, чем две причины. Первая — слишком малая и недостаточная память, а вторая — неправильный дизайн программы и невозможность освобождения памяти. Больше. При решении этой проблемы мы более-менее слышали android: largeHeap, но что это за концепция, как ее использовать и в чем проблемы? Эта статья даст вам всестороннее введение в largeHeap в Android, чтобы помочь вам понять эту концепцию всесторонне и всесторонне.

Заточите нож и рубите дрова

Чтобы облегчить понимание, сначала кратко представьте некоторые основные понятия, относящиеся к статье.

• Обычно программа Android запускает виртуальную машину Dalvik, когда она работает (не говоря уже о режиме ART).
• Память времени выполнения виртуальной машины обычно состоит из двух частей: кучи и стека.
• Стек — это область данных памяти, в которой хранятся вызовы методов.
• Память кучи занимает большую часть пространства памяти виртуальной машины, а объекты, созданные во время выполнения программы, размещаются в памяти кучи.
• Если в памяти кучи нет свободного места для хранения сгенерированного объекта, JVM выдаст ошибку java.lang.OutOfMemoryError.

Если вы хотите узнать больше о куче и стеке, обратитесь к статьеРазница между кучей и стеком в Javaс участиемОбласть данных при запущенной JVM

Введение в largeHeap

Если приложение использует largeHeap, оно запросит у системы выделение большего объема памяти для виртуальной машины Dalvik. Также очень удобно использовать, просто добавьте в узел приложения файла манифестаandroid:largeHeap=“true”Вот и все.

насколько большой большой

В Android есть два следующих метода, которые помогут нам просмотреть текущий размер памяти.

• ActivityManager.getMemoryClass () получает размер внутренней памяти при нормальных условиях
• ActivityManager.getLargeMemoryClass () может получить максимальный размер памяти при включении largeHeap

Но как определяется максимальное значение largeHeap? Чтобы понять эту проблему, нам нужно посмотреть файл в системе Android.

Путь к файлу /system/build.prop , Поскольку файл относительно большой, здесь мы перехватываем только информацию о конфигурации памяти dalvik, как показано ниже.

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

dalvik.vm.heapstartsize=8m

Эквивалентно конфигурации виртуальной машины -Xms, этот элемент используется для установки начального размера кучи.

dalvik.vm.heapgrowthlimit=192m

Эквивалентно -XX: HeapGrowthLimit конфигурации виртуальной машины, этот элемент используется для установки максимального размера кучи памяти стандартного приложения. Стандартное приложение — это приложение, которое не использует android: largeHeap.

dalvik.vm.heapsize=512m

Эквивалентно конфигурации виртуальной машины -Xmx, этот элемент устанавливает максимальный размер памяти кучи приложения с помощью android: largeHeap.

dalvik.vm.heaptargetutilization=0.75

Эквивалентно -XX: HeapTargetUtilization виртуальной машины, этот элемент используется для установки текущего идеального использования памяти кучи. Его значение находится в диапазоне от 0 до 1. После того, как сборщик мусора завершит сборку мусора, память кучи Dalvik будет соответствующим образом скорректирована. Обычно результатом является размер выжившего в данный момент объекта, деленный на размер памяти кучи, а полученное значение — это установка этой опции, которая здесь равна 0,75. Обратите внимание, что это всего лишь справочное значение,Виртуальная машина Dalvik также может игнорировать этот параметр。

dalvik.vm.heapminfree=2mпротивdalvik.vm.heapmaxfree=8m

dalvik.vm.heapminfree соответствует конфигурации -XX: HeapMinFree, которая используется для установки минимального значения настройки памяти одной кучи.dalvik.vm.heapmaxfreeСоответствующая конфигурация — -XX: HeapMaxFree, которая используется для установки максимального значения одной настройки памяти кучи. При нормальных обстоятельствах также необходимо объединить значение -XX: HeapTargetUtilization, указанное выше, чтобы определить размер, который необходимо изменить во время настройки памяти.

Требуется ли разрешение largeHeap?

Почему у вас возник этот вопрос? Причина вот в чем. Прежде всего, фиксируется память устройства.Когда мы используем largeHeap, мы можем увеличить память нашей программы, но эта часть увеличенной памяти может быть вызвана фоновой программой, убитой системой. Следовательно, теоретически возможно убить другие программы с помощью largeHeap.

Однако в результате никаких разрешений не требуется. Google работает так же в начале. Просто добавьте android: largeHeap = «true» в элемент Application, чтобы использовать его в обычном режиме.

Влияние largeHeap на сборщик мусора

Имея больше памяти, означает ли это тратить больше времени на просмотр объектов для сборки мусора? вообще-то нет.

Во-первых, largeHeap поддерживается начиная с Android 4.0, а метод параллельной сборки мусора был введен с Android 2.3.

До введения параллельной сборки мусора в системе был принят метод сборки Stop-the-World. Сборка мусора обычно занимает несколько сотен миллисекунд, что сильно влияет на взаимодействие и реакцию.

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

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

С осторожностью используйте largeHeap

При использовании largeHeap следует проявлять осторожность. LargeHeap можно использовать, но мы должны быть осторожны.

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

В дополнение к вышесказанному, если это только для решения проблемы OutOfMemoryError, не рекомендуется использовать largeHeap для выделения большего количества памяти, что является индикатором отсутствия лечения. Чтобы справиться с такими проблемами OOM, рекомендуется прочитать следующие статьи, чтобы понять утечки памяти и сборку мусора в Android, найти проблему из кода и решить ее фундаментально.

Ловушка

Независимо от того, включен ли largeHeap или нет, ActivityManager.getLargeMemoryClass () может распечатать размер largeHeap. Потому что он просто считывает значение файла конфигурации. То есть следующий код будет печатать один и тот же журнал независимо от того, включен largeHeap или нет.

Как проверить

Что касается проверки, установите здесь кнопку, чтобы каждый раз создавать объект памяти 100 МБ, и наблюдайте за реакцией до и после открытия largeHeap

• Возьмем для примера 192 МБ памяти, доступной при нормальных обстоятельствах, дважды нажмите кнопку, приложение выйдет из строя.
• Затем откройте largeHeap в манифесте, возьмите в качестве примера максимально доступную память 512 МБ, щелкните 6 раз, и приложение выйдет из строя

Чтобы проверить исходный код, вы можете посетить github для просмотраlargeHeapDemo

Источник

Русские Блоги

Android: объяснение атрибутов largeHeap

Внедрение largeHeap

Если приложение использует largeHeap, оно запросит систему выделить больше памяти для виртуальной машины Dalvik. Его также очень удобно использовать, просто добавьте его в узел приложения файла манифестаandroid:largeHeap=“true” Вот и все

Насколько велика?

В Android есть два следующих метода, которые помогут нам увидеть текущий объем памяти.

• ActivityManager.getMemoryClass () получает размер внутренней памяти при нормальных обстоятельствах
• ActivityManager.getLargeMemoryClass () может получить максимальный объем памяти для включения largeHeap

Но как определяется максимальное значение largeHeap? Чтобы понять эту проблему, нам нужно взглянуть на файл в системе Android.

Этот путь к файлу /system/build.prop Поскольку файл относительно большой, здесь мы только перехватываем информацию о конфигурации памяти dalvik следующим образом.

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

dalvik.vm.heapstartsize=8m

Эквивалент конфигурации -Xms виртуальной машины, этот элемент используется для установки начального размера памяти кучи.

dalvik.vm.heapgrowthlimit=192m

Эквивалент конфигурации виртуальной машины -XX: HeapGrowthLimit, этот элемент используется для установки максимального размера памяти кучи для стандартного приложения. Стандартное приложение, которое не использует Android: LargeHeap.

dalvik.vm.heapsize=512m

Эквивалентно конфигурации -Xmx виртуальной машины, этот элемент устанавливает максимальный размер кучи памяти для приложений, использующих android: largeHeap.

dalvik.vm.heaptargetutilization=0.75

Эквивалентно -XX: HeapTargetUtilization виртуальной машины, этот элемент используется для установки текущего идеального использования памяти кучи. Его значение лежит между 0 и 1. После того, как GC выполнит сборку мусора, память кучи Dalvik будет соответствующим образом скорректирована. В результате обычно размер текущего живого объекта и памяти кучи разделяется. Полученное значение является настройкой этой опции, которая здесь равна 0,75. Обратите внимание, что это просто справочное значение, Виртуальная машина Dalvik также может игнорировать этот параметр。

dalvik.vm.heapminfree=2m иdalvik.vm.heapmaxfree=8m

dalvik.vm.heapminfree соответствует конфигурации -XX: HeapMinFree, которая используется для установки минимального значения для настройки памяти одной кучи.dalvik.vm.heapmaxfree Соответствующая конфигурация -XX: HeapMaxFree используется для установки максимального значения настройки памяти одной кучи. Обычно значение -XX: HeapTargetUtilization выше необходимо объединить, чтобы определить размер настройки памяти.

Нужно ли разрешение LargeHeap?

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

Однако в результате этого разрешение не требуется. Это имеет место в начале Google. Просто добавьте android: largeHeap = «true» к элементу Application, чтобы использовать его как обычно.

Эффект largeHeap на GC

Имеет ли больше памяти, означает ли это, что для сбора мусора объектов требуется больше времени? На самом деле нет.

Во-первых, largeHeap поддерживается с Android 4.0, а параллельная сборка мусора — с Android 2.3.

До введения параллельной сборки мусора в системе применялся метод сбора Stop-the-World, сборщик мусора обычно занимает сотни миллисекунд, что влияет на взаимодействие и реакцию.

После введения параллельной сборки мусора в начале и конце GC будет короткое время паузы, обычно в течение 10 миллисекунд.

Поэтому параллельная сборка мусора используется в системах, поддерживающих largeHeap. Время паузы GC не будет очень продолжительным и мало влияет на интерактивный ответ.

Используйте LargeHeap с осторожностью

Для использования largeHeap мы должны придерживаться осторожного подхода, можно использовать largeHeap, но будьте осторожны.

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

В дополнение к описанной выше ситуации, если это просто для решения проблемы OutOfMemoryError, и попытаться использовать largeHeap для выделения большего объема памяти, этот индикатор не является лекарством. Чтобы справиться с такими проблемами OOM, рекомендуется прочитать следующие статьи, чтобы понять утечки памяти и сборку мусора в Android, найти проблему из кода и фундаментально решить проблему. ——————— Эта статья взята из блога yaoandliang_Android в CSDN. Для получения полного текстового адреса, пожалуйста, нажмите: https://blog.csdn.net/qq_33544860/article/details/53187742 ? utm_source = copy60/article/details/53187742

Интеллектуальная рекомендация

Многослойная презентацияViewController Jap

. Недавно, проект использует многоэтажные прыжки [A presentViewController: B animated: YES] [B presentViewController: C animated: YES] . Проблема в том, где: как это идет прямо к? Я не нашел ме.

Распечатать список с конца до головы

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

Типы данных и переменные

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

Python Daily Practice (4) -идиомы заполняют музыку

оглавление 1. Одно место 2. Случайное расположение 3. Добавьте баллы для оценки 4. Получение файла 5. Установите уровень сложности. 6. Срок завершения 7. Выберите заполнение пропусков. 1. Одно место Н.

Источник

Большие требования к памяти в Android – что делать?

Здравствуйте, уважаемые читатели.

Сегодня предлагаем вашему вниманию небольшой материал о грамотном использовании памяти в Android.

Приятного чтения!

Эта статья посвящена базовым приемам управления использованием памяти в приложениях – например, в браузерах, фоторедакторах и программах для просмотра PDF – в которых предъявляются большие запросы к памяти.

Для начала немного теории

Большинство приложений для Android работают поверх среды исполнения (ART), заменившей ныне устаревающую виртуальную машину Dalvik. ART и Dalvik похожи на виртуальную машину Java (JVM), с которой их роднят схожие принципы проектирования. Они используют для хранения данных приложений два отдельных пространства: стек и кучу.

Стек-память в Java используется для хранения локальных переменных (примитивных типов и ссылок на объекты). Каждый поток Java имеет собственный отдельный стек. Стек-память относительно невелика по сравнению с памятью кучи. Размер стека Java в Dalvik обычно составляет 32 KB для кода Java и 1 MB для нативного кода (C++/JNI). В ART появился унифицированный стек для Java и C++, размер которого составляет около 1 MB.

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

Память кучи в Java используется виртуальной машиной для выделения объектов. Когда бы ни создавался объект, это происходит в куче. Виртуальные машины, например, JVM или ART, выполняют регулярную сборку мусора, убирают все объекты, на которые больше не осталось ссылок, и таким образом высвобождают память для выделения новых объектов.
Для обеспечения удобства использования Android жестко ограничивает размеры кучи для каждого работающего приложения. Предельный размер кучи варьируется от устройства к устройству и зависит от того, сколько RAM на этом устройстве. Если ваше приложение достигает предельного размера кучи и пытается выделить еще памяти, то выдается ошибка OutOfMemoryError , и приложение завершается. Давайте рассмотрим некоторые примеры, помогающие избежать такой ситуации.

Анализ памяти кучи

Самый важный инструмент, позволяющий разобраться с проблемами памяти в ваших приложениях и понять, как используется память – это профилировщик памяти, доступный в Android Studio.

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

Типичный сеанс работы с профилировщиком памяти должен выглядеть так:

• Отсматриваем наиболее частые выделения памяти и проходы сборщика мусора для выявления возможных проблем с производительностью.
• Отсматриваем, как использовалась память с течением времени, в особенности такие операции, на которые, как известно, требуется выделять много памяти. Убедитесь, что после завершения этих операций использование памяти снижается. Например, ниже показано, как воздействует на память активность PdfActivity из PSPDFKit после загрузки документа.
• Делаем дамп кучи в разные моменты времени исполнения вашего приложения и проверяем, как используется память. Ищем большие объекты, которые хранятся в памяти и не подпадают под сборку мусора. Дампы кучи также помогают выявить утечки памяти – например, можно поискать в дампе кучи ваши активности и посмотреть, были ли собраны их старые экземпляры.

Утечки памяти

Современные сборщики мусора – это сложные произведения технологического искусства, результат многолетних исследований и разработок, в которых участвовали сотни людей, от академиков до разработчиков-профессионалов. Однако до сих пор приходится быть начеку, чтобы не допускать утечек в памяти.

Образцовое решение для выявления утечек в памяти – библиотека LeakCanary. Она автоматически выдает уведомления, когда в вашей тестовой сборке (development build), выдавая вам стектрейс утечки в UI этой программы. Можно (и следует) интегрировать ее уже сегодня, тем более, что это не сложно!

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

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

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

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

Большая куча

Одно из лобовых решений, позволяющих справиться с высокими требованиями к памяти – запросить большую кучу Dalvik для вашего приложения. Для этого можно добавить android:largeHeap=»true» к тегу в файле AndroidManifest.xml .

Если для свойства largeHeap задано значение true , Android будет создавать все процессы для вашего приложения с большой кучей. Эта настройка предназначена только для тех приложений, которые по природе своей без нее работать не смогут, то есть, они используют объемные ресурсы, которые должны одновременно умещаться в памяти.

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

Проверка, сколько памяти сможет использовать ваше приложение

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

Android поддерживает даже такие устройства, на которых всего 512 MB RAM. Убедитесь, что не обошли вниманием и низкотехнологичные устройства! При помощи метода isLowRamDevice() можно проверить, не запущено ли ваше приложение на таком устройстве, где мало доступной памяти. Точное поведение этого метода зависит от устройства, но обычно он возвращает true на тех устройствах, где меньше 1 GB RAM. Нужно убедиться, что ваше приложение корректно работает и на этих устройствах, и на них отключать все возможности, использующие большой объем памяти.

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

Используйте оптимизированные структуры данных

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

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

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

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

Предотвращайте перемешивание памяти

Виртуальные машины Java/Android выделяют объекты очень быстро. Сборка мусора также идет весьма быстро. Однако при выделении большого количества объектов за короткий промежуток времени можно столкнуться с проблемой под названием «перемешивание памяти» (memory churn). В таком случае виртуальная машина не будет успевать выделять объекты в таком темпе, а сборщик мусора – их утилизировать, и приложение начнет притормаживать, а в экстремальных случаях даже израсходует всю память.

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

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

Источник