Android: как работает функция Bitmap recycle ()?

Допустим, я загрузил изображение в объект растрового изображения, например

Bitmap myBitmap = BitmapFactory.decodeFile(myFile);

Теперь, что произойдет, если я загружу другое растровое изображение, например

myBitmap = BitmapFactory.decodeFile(myFile2);

Что происходит с первым myBitmap? Собирается ли мусор, или мне нужно вручную собирать мусор перед загрузкой другого растрового изображения, например. myBitmap.recycle()?

Кроме того, есть ли лучший способ загружать большие изображения и отображать их одно за другим, перерабатывая в пути?

Первое растровое изображение не собирается сборщиком мусора при декодировании второго. Сборщик мусора сделает это позже, когда решит. Если вы хотите освободить память как можно скорее, вы должны позвонить recycle()непосредственно перед декодированием второго растрового изображения.

Если вы хотите загрузить действительно большое изображение, вам следует передискретизировать его. Вот пример: странная проблема нехватки памяти при загрузке изображения в объект Bitmap .

Я думаю, проблема в следующем: в версиях Android до Honeycomb фактические необработанные данные растрового изображения хранятся не в памяти виртуальной машины, а в собственной памяти. Это родная память будет освобождена , когда соответствующий JavaBitmap объект GC'd.

Однако , когда у вас заканчивается собственная память, dalvik GC не запускается, поэтому возможно, что ваше приложение использует очень мало java-памяти, поэтому dalvik GC никогда не вызывается, но использует тонны собственной памяти для растровых изображений. что в конечном итоге вызывает ошибку OOM.

По крайней мере, это мое предположение. К счастью, в Honeycomb и более поздних версиях все растровые данные хранятся в виртуальной машине, поэтому вам вообще не нужно их использовать recycle(). Но для миллионов пользователей 2.3 (фрагментация потрясает кулаком ) вы должны использовать recycle()везде, где это возможно (огромные хлопоты). Или, в качестве альтернативы, вы можете вместо этого вызвать GC.

Вам нужно будет вызвать myBitmap.recycle () перед загрузкой следующего изображения.

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

if (myBitmap != null) {
    myBitmap.recycle();
    myBitmap = null;
}
Bitmap original = BitmapFactory.decodeFile(myFile);
myBitmap = Bitmap.createScaledBitmap(original, displayWidth, displayHeight, true);
if (original != myBitmap)
    original.recycle();
original = null;

Я кэширую displayWidth и displayHeight в статике, которую я инициализировал в начале своей Activity.

Display display = getWindowManager().getDefaultDisplay();
displayWidth = display.getWidth();
displayHeight = display.getHeight();

После того как растровое изображение было загружено в память, фактически оно состояло из двух частей. Первая часть включает некоторую информацию о растровом изображении, другая часть включает информацию о пикселях растрового изображения (она состоит из байтового массива). Первая часть существует в используемой памяти Java, вторая часть существует в используемой памяти C ++. Они могут напрямую использовать память друг друга. Bitmap.recycle () используется для освобождения памяти C ++. Если вы сделаете только это, GC будет собирать часть java, и всегда будет использоваться память C.

Тимммм был прав.

согласно: http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

Кроме того, до Android 3.0 (уровень API 11) резервные данные растрового изображения хранились в собственной памяти, которая не высвобождалась предсказуемым образом, что могло привести к кратковременному превышению приложением пределов памяти и сбою.