Сборщик мусора в Android

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

Является ли хорошей практикой запрашивать сборщик мусора в Android перед выполнением операции, требующей большого количества памяти? Если нет, следует ли мне вызывать его только в случае OutOfMemoryошибки?

Есть ли другие вещи, которые мне следует использовать, прежде чем прибегать к сборщику мусора?

Для версий до 3.0 сота : Да, звоните System.gc() .

Я пытался создать растровые изображения, но всегда получал ошибку «ВМ из памяти». Но когда я позвонил в System.gc()первый раз, все было нормально.

При создании растровых изображений Android часто дает сбой из-за ошибок нехватки памяти и не пытается сначала выполнить сборку мусора . Следовательно, вызовите System.gc(), и у вас будет достаточно памяти для создания растровых изображений.

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

Поэтому я рекомендую вызывать вручную System.gc()перед созданием растровых изображений.

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

Иногда , в некоторых относительно редких ситуациях, можно обнаружить, что конкретный сборщик мусора ошибается, и ручной вызов сборщика мусора может улучшить ситуацию с точки зрения производительности. Это потому, что на самом деле невозможно реализовать «идеальный» сборщик мусора, который бы оптимально управлял памятью во всех случаях. Такие ситуации трудно предсказать и зависят от многих тонких деталей реализации. «Хорошая практика» - позволить сборщику мусора работать сам по себе; ручной вызов GC является исключением, которое следует предусмотреть только после того, как будет должным образом засвидетельствована реальная проблема производительности.

Недостаточно памяти в приложении Android очень часто, если мы не обрабатываем растровое изображение должным образом. Решением проблемы может быть

if(imageBitmap != null) {
    imageBitmap.recycle();
    imageBitmap = null;
}
System.gc();
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 3;
imageBitmap = BitmapFactory.decodeFile(URI, options);
Bitmap  scaledBitmap = Bitmap.createScaledBitmap(imageBitmap, 200, 200, true);
imageView.setImageBitmap(scaledBitmap);

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

Если проблема все еще возникает, вы также можете добавить эту строку

BitmapFactory.Options options = new BitmapFactory.Options();
options.inTempStorage = new byte[16*1024];
options.inPurgeable = true;

для получения дополнительной информации перейдите по этой ссылке

https://web.archive.org/web/20140514092802/http://voices.yahoo.com/android-virtual-machine-vm-out-memory-error-7342266.html?cat=59

ПРИМЕЧАНИЕ. Из-за кратковременной «паузы», вызванной выполнением gc, не рекомендуется делать это перед каждым выделением битовой карты.

Оптимальный дизайн - это:

1. Освободите все растровые изображения, которые больше не нужны , с помощью if / recycle / nullпоказанного кода. (Придумайте способ, который поможет с этим.)

2. System.gc();

3. Разместите новые растровые изображения.

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

Вот цитата разработчика Android:

В большинстве случаев сборка мусора происходит из-за множества небольших, недолговечных объектов, и некоторые сборщики мусора, например сборщики мусора поколения, могут оптимизировать сбор этих объектов, чтобы приложение не прерывалось слишком часто. К сожалению, сборщик мусора Android не может выполнять такую ​​оптимизацию, поэтому создание недолговечных объектов в критических для производительности путях кода очень дорого обходится вашему приложению.

Так что, насколько я понимаю, нет необходимости срочно звонить в gc. Лучше потратить больше усилий, чтобы избежать ненужного создания объектов (например, создания объектов внутри циклов)

Вроде System.gc()не работают на Art Android 6.0.1 Nexus 5x, поэтому пользуюсь Runtime.getRuntime().gc();взамен.

Мое приложение управляет множеством изображений, и оно умерло с ошибкой OutOfMemoryError. Это мне помогло. В Manifest.xml Добавить

<application
....
   android:largeHeap="true"> 

Вообще говоря, вы не должны явно вызывать GC с помощью System.gc (). Есть даже лекция по вводу-выводу ( http://www.youtube.com/watch?v=_CruQY55HOk ), где они объясняют, что означает журнал пауз сборщика мусора и в котором также говорится, что никогда не следует вызывать System.gc (), потому что Dalvik знает лучше чем вы, когда это сделать.

С другой стороны, как упоминалось в ответах выше, уже процесс GC в Android (как и все остальное) иногда бывает ошибочным. Это означает, что алгоритмы Dalvik GC не соответствуют JVM Hotspot или JRockit и в некоторых случаях могут работать неправильно. Один из таких случаев - при выделении растровых объектов. Это сложно, потому что он использует память кучи и не кучу, и потому что одного свободного экземпляра объекта растрового изображения на устройстве с ограничением памяти достаточно, чтобы вызвать исключение OutOfMemory. Поэтому вызов его после того, как вам больше не нужно это растровое изображение, обычно предлагают многие разработчики, а некоторые даже считают хорошей практикой.

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

Также одно очень важное замечание о System.gc (). Этот метод не является командой, на которую Dalvik (или JVM) обязан отвечать. Считайте, что это больше похоже на обращение к виртуальной машине: «Не могли бы вы сделать сборку мусора, если это не мешает».

Лучший способ избежать OOM во время создания Bitmap,

http://developer.android.com/training/displaying-bitmaps/index.html

Я бы сказал нет, потому что разработчик документирует состояние использования ОЗУ :

...
GC_EXPLICIT

Явный сборщик мусора, например, когда вы вызываете gc () (которого следует избегать вызова и вместо того, чтобы доверять GC для запуска при необходимости).

...

Я выделил соответствующую часть жирным шрифтом.

Взгляните на серию YouTube « Паттерны производительности Android» - в ней вы найдете советы по управлению использованием памяти вашим приложением (например, использование ArrayMaps и SparseArrays вместо HashMaps в Android ).

Краткое примечание для разработчиков Xamarin .

Если вы хотите позвонить System.gc()в приложения Xamarin.Android, вы должны позвонитьJava.Lang.JavaSystem.Gc()

Нет необходимости вызывать сборщик мусора после файла OutOfMemoryError.

В Javadoc четко сказано:

Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

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