Каковы преимущества установки для 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>

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

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

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

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

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

ОБНОВИТЬ

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

ОБНОВЛЕНИЕ 2

Вот несколько советов, с которыми можно справитьсяout of memory errors

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

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

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

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

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

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

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

Вывод :

По возможности избегайте использования largeHeapoption. Это может стоить вам незаметного падения производительности и плохого взаимодействия с пользователем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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