Intereting Posts
Как изменить выравнивание детальных представлений панели инструментов Когда вызывается getItem FragmentPagerAdapter? Отправка SMS программно без открытия сообщения PopupWindow $ BadTokenException: Невозможно добавить окно – токен null недействителен Android: я не могу удалить высоту / тень на моей панели инструментов React Native Android отпадает при попытке отладки в Chrome Проблемы с буферизацией с помощью android.media.MediaPlayer Я не могу прочитать AttributeSet из моих XML-ресурсов ArrayList indexOf () возвращает неверный индекс? Как добавить элементы подменю в NavigationView программно вместо меню xml Отображать направление места со стрелкой в ​​Android ListView Как сохранить размер фонового изображения при показе программной клавиатуры View on press onpress: изменить цвет фона при нажатии? Как показать, что нажата кнопка View? View.OnClickListener, метод или класс? Android – Grow Heap (Frag Case) – Байт-распределение. Не загружайте растровые изображения

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

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

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

Solutions Collecting From Web of "Каковы преимущества установки largeHeap в true?"

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

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

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

ОБНОВИТЬ

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

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

То, что вы получаете :

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

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

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

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

Вывод :

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

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

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

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

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

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

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

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