Каковы преимущества установки значения LargeHeap в true?

У меня есть приложение с почти 50 классов, которые я устанавливаю android:largeHeap="true", как можно увидеть ниже. Это хорошая практика?

<application
        android:name=".MyApplication"
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="Mall"
        android:largeHeap="true"
        android:logo="@drawable/logo_for_up"
        android:screenOrientation="portrait"
        android:theme="@style/AppTheme" >
</application>

Просьба предложить преимущества и недостатки его использования.

У меня проблемы с памятью, поэтому я задаю этот вопрос.

7 ответов

Слишком поздно для вечеринки здесь, но я все равно предложу свои 0,02$.
Это не очень хорошая идея, чтобы использовать android:largeHeap="true" Вот выдержка из Google, которая объясняет это,

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

вот полная ссылка на документацию https://developer.android.com/training/articles/memory.html

ОБНОВИТЬ

После работы мучительно с out of memory errors я бы сказал, что добавление этого в манифест, чтобы избежать проблемы, не является грехом, также как @Milad указывает на то, что это не влияет на нормальную работу приложения

ОБНОВЛЕНИЕ 2

Вот несколько советов, чтобы иметь дело с out of memory errors

1) Используйте эти обратные вызовы, которые дает Android onLowMemory, onTrimMemory(int) и очистить кэш изображений, таких как (Пикассо, скользить, фреска....), вы можете прочитать больше о них здесь и здесь
2) сжать ваши файлы (изображения, pdf)
3) читайте о том, как более эффективно обрабатывать растровые изображения здесь
4) Регулярно используйте пух перед выпуском продукции, чтобы код был гладким и не громоздким

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

Что вы получаете:

  • Очевидно, вы получите большую кучу, что означает снижение риска OutOfMemoryError,

Что вы теряете:

  • Вы можете потерять некоторые кадры, которые могут вызвать видимое сцепление. Большая куча заставляет сборку мусора занимать больше времени. Потому что сборщик мусора в основном должен пройти весь ваш живой набор объектов. Обычно время паузы при сборке мусора составляет около 5 мс, и вы можете подумать, что несколько миллисекунд не имеют большого значения. Но каждая миллисекунда считается. Android-устройство должно обновлять свой экран каждые 16 мс, и более длительное время GC может увеличить время обработки вашего кадра до 16-миллисекундного барьера, что может вызвать видимое зацепление.

  • Также переключение приложений станет медленнее. Система Android может уничтожать процессы в кеше LRU, начиная с процесса, который использовался не так давно, но также уделять внимание тому, какие процессы наиболее интенсивно используют память. Поэтому, если вы используете большую кучу, ваш процесс с большей вероятностью будет убит, когда он будет фоновым, что означает, что может потребоваться больше времени, когда пользователи захотят переключиться с других приложений на ваши. Также другие фоновые процессы с большей вероятностью будут выброшены, когда ваш процесс находится на переднем плане, потому что вашему приложению требуется больше памяти. Это означает, что переключение с вашего приложения на другое также занимает больше времени.

Заключение:

Избегать использования largeHeap вариант как можно больше. Это может стоить вам заметного падения производительности и плохого пользовательского опыта.

Если вы должны использовать (и сохранить) большой объем памяти, тогда да, вы можете и должны использовать android:largeHeap="true". Но если вы используете его, вы должны быть готовы к тому, что ваше приложение будет выгружено из памяти всякий раз, когда другие приложения находятся на переднем плане.

Под "быть готовым" я подразумеваю, что вы должны спроектировать для этой вероятности, чтобы ваши методы onStop() и onResume() были написаны настолько эффективно, насколько это возможно, при этом гарантируя, что все соответствующие состояния сохраняются и восстанавливаются таким образом, чтобы безупречный внешний вид для пользователя.

Есть три метода, которые относятся к этому параметру: maxMemory(), getMemoryClass() и getLargeMemoryClass().

Для большинства устройств maxMemory () будет представлять значение, аналогичное getMemoryClass () по умолчанию, хотя последнее выражается в мегабайтах, а первое выражается в байтах.

Когда вы используете параметр largeHeap, maxMemory() будет увеличен до более высокого уровня для конкретного устройства, тогда как getMemoryClass () останется прежним.

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

Функция maxMemory (), напротив, ограничивает размер кучи, поэтому вы получаете доступ к дополнительной куче за счет увеличения ее значения, а largeHeap увеличивает это значение. Однако увеличенный объем кучи по-прежнему ограничен, и этот предел будет зависеть от устройства, что означает, что объем кучи, доступный для вашего приложения, будет варьироваться в зависимости от ресурсов устройства, на котором работает ваше приложение. Таким образом, использование largeHeap - это не приглашение для вашего приложения отказаться от всякой осторожности и пройти через шведский стол "все, что вы можете съесть".

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

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

Определить размер кучи приложения в Android

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

У меня есть приложение с почти 50 классов

Я не думаю, что это создает много проблем. Причиной возникновения ошибки outOfMemory обычно является загрузка большого количества изображений в приложении или что-то в этом роде. Если вы недовольны использованием большой кучи, вы должны найти способ оптимизировать использование памяти.

Вы также можете использовать библиотеки загрузки изображений, такие как Picasso, UIL или Glide. Все они имеют функцию кэширования изображений в памяти и / или на диске.

На самом деле Android: LargeHeap является инструментом для увеличения выделенной памяти для приложения.

Нет четкого определения необходимости использования этого флага. Если вам нужно больше памяти - Android предоставляет вам инструмент для ее увеличения. Но необходимость использования вы сами определяете.

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

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

Да, это хорошая практика, чтобы положить android:largeHeap="true" потому что Android дает вам инструмент для увеличения выделенной памяти при необходимости.

Вы можете получить больше идей по этой ссылке: https://developer.android.com/topic/performance/memory

Другие вопросы по тегам