Что на самом деле делает Bitmap # recycle () в Android Honeycomb?

Я пишу приложение с очень интенсивным использованием памяти для Android Honeycomb, и я очень внимательно следил за тем, чтобы recycle () unused Bitmap везде, где это возможно; действительно, это необходимо для того, чтобы приложение вообще работало, так как Bitmap постоянно циклически загружаются и выгружаются из памяти. Однако я только что реализовал onConfigurationChanged () в Activity , и поэтому (по ряду причин) я пытаюсь поместить процедуры освобождения памяти в onStop () .

В настоящее время мой метод onStop () :

• устанавливает некоторые View для отображения по умолчанию Drawable ;
• вызывает recycle ( ) в Bitmap s, ранее использовавшихся этими View s;
• обнуляет ссылки на Bitmap s.

К сожалению, использование профилировщика памяти Eclipse, похоже, не оказывает никакого влияния на использование памяти .

Как вы понимаете, приложив столько усилий для освобождения ресурсов на языке с номинальной сборкой мусора, я надеялся на немного больший эффект. Итак, мой вопрос: что делает recycle () ? Действительно ли он запускает сборку мусора, или система будет удерживать память, даже если вы вызываете System.gc () - пока он не почувствует необходимость от чего-то избавиться?

NB Я знаю Bitmap s на самом деле не хранятся в обычной куче, но я подумал, что вызов recycle ( ) было достаточно, чтобы гарантировать, что они были исключены из собственной кучи.

ЧАСТЬ ОТВЕТА

Я обнаружил, что если ImageView содержит Bitmap , который был переработан, данные Bitmap все еще сохраняются в память до тех пор, пока setImageBitmap (null) не будет вызван в ImageView . Это может быть даже в том случае, если вызываются setImageResource (...) или setImageDrawable (...) (они загружались в относительно небольшом файле с девятью патчами, однако MAT Анализ показывает, что это не привело к удалению большого Bitmap , которое содержалось в закрытых элементах ImageView ). При простом вызове этой функции по адресу onStop () из кучи нашего приложения было забрано около 10 МБ. По-видимому, это может быть не так для сборок Android, предшествующих Honeycomb.