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

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

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

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

98 голосов | спросил hpique 25 J0000006Europe/Moscow 2010, 14:57:57

9 ответов


0

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

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

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

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

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

ответил steve 11 SatEurope/Moscow2010-12-11T07:44:04+03:00Europe/Moscow12bEurope/MoscowSat, 11 Dec 2010 07:44:04 +0300 2010, 07:44:04
0

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

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

ответил Thomas Pornin 25 J0000006Europe/Moscow 2010, 18:47:05
0

Недостаточно памяти в приложениях для 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;

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

http://voices.yahoo. ком /Android-виртуальная машина VM-из-памяти ошибок 7342266.html


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

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

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

  2. System.gc();
  3. Выделите новые растровые изображения.

ответил yogesh 21 J0000006Europe/Moscow 2012, 09:03:55
0

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

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

  

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

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

ответил Andreas_D 25 J0000006Europe/Moscow 2010, 15:14:55
0

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

<application
....
   android:largeHeap="true"> 
ответил Klykoo 27 J000000Sunday14 2014, 14:26:15
0

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

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

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

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

ответил PSIXO 18 J000000Friday14 2014, 16:06:01
0

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

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

ответил prabhu 19 FebruaryEurope/MoscowbTue, 19 Feb 2013 11:27:56 +0400000000amTue, 19 Feb 2013 11:27:56 +040013 2013, 11:27:56
0

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

  

...
GC_EXPLICIT

     

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

     

...

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

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

ответил Farbod Salamat-Zadeh 8 MarpmTue, 08 Mar 2016 22:06:38 +03002016-03-08T22:06:38+03:0010 2016, 22:06:38
0

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

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

ответил Denis Gordin 12 +03002017-10-12T18:21:05+03:00312017bEurope/MoscowThu, 12 Oct 2017 18:21:05 +0300 2017, 18:21:05

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132