Каковы преимущества установки largeHeap в true?

Ответ 1

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

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

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

ОБНОВЛЕНИЕ

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

ОБНОВЛЕНИЕ 2

Вот несколько советов для: out of memory errors

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

Ответ 2

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

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

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

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

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

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

Вывод:

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

Ответ 3

Фактически android: largeHeap - инструмент для увеличения выделенной памяти для приложения.

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

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

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

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

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

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

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