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

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

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

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

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

Я попытался создать Bitmaps, но всегда получал ошибку «VM out of memory». Но, когда я сначала вызвал System.gc() , все было в порядке.

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

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

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

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

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

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

 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); 

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

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

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

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

http://voices.yahoo.com/android-virtual-machine-vm-out-memory-error-7342266.html


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

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

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

  2. System.gc();

  3. Выделите новые растровые изображения.

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

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

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

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

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

  

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

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

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

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

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

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

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

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

Это Джавадок четко заявляет:

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.

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

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


GC_EXPLICIT

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

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

Взгляните на серию YouTube « Шаблоны производительности Android» – она ​​покажет вам советы по управлению использованием памяти вашего приложения (например, с использованием Android ArrayMap и SparseArray s вместо HashMap s).

Быстрая заметка для разработчиков Xamarin .

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

  • Скрытие строк в Obfuscated code
  • Как получить путь к запуску java-программы
  • Разделить значение int на отдельные цифры
  • Java - чтение файла и разбиение на несколько файлов
  • Как создать Android-hashи Facebook Facebook?
  • Android getIntent (). GetExtras () возвращает null
  • Android FragmentManager BackStackRecord.run бросает NullPointerException
  • Создание с помощью каталога Intellij 2017.2 / out дублирует файлы в каталоге / build
  • Добавление Admob в libgdx
  • Центральное сообщение в диалоговом окне андроида
  • Как вы реализуете FileObserver из службы Android
  • Давайте будем гением компьютера.