Android Honeycomb 中的 Bitmap#recycle() 实际上是做什么的? [英] What does Bitmap#recycle() in Android Honeycomb actually DO?

问题描述

我正在为 Android Honeycomb 编写一个非常占用内存的应用程序，并且我一直非常小心地recycle() 未使用的 Bitmap 尽可能；事实上，这对于应用程序的工作来说是必要的，因为 Bitmap 会不断地循环进出内存.但是，我刚刚在 Activity 中实现了 onConfigurationChanged()，因此(出于多种原因)我试图将内存释放例程放在 onStop().

I am writing a very memory intensive application for Android Honeycomb, and I've been very careful to recycle() unused Bitmaps wherever possible; indeed, this is necessary for the application to work at all, as Bitmaps are constantly being cycled in and out of memory. However, I have just implemented onConfigurationChanged() in the Activity, and so (for a number of reasons) I am trying to put memory freeing routines in onStop().

目前我的 onStop() 方法:

• 设置一些 View 以显示默认的 Drawable;
• 在这些View之前使用的Bitmap上调用recycle()；
• 对 Bitmap 的引用为空.

• sets some Views to display a default Drawable;
• calls recycle() on the Bitmaps previously used by these Views;
• nulls references to the Bitmaps.

不幸的是，使用 Eclipse 内存分析器，这似乎对内存使用完全没有影响.

Unfortunately, using the Eclipse memory profiler, it seems this is having no effect on the memory usage at all.

正如您所想象的那样，我付出了很多努力以名义上的垃圾收集语言来释放资源，我本来希望能有更多的效果.所以我的问题是:recycle() 有什么作用?它真的会触发垃圾收集，还是系统会保留内存——即使你调用了System.gc()——直到它觉得需要摆脱某些东西?

As you can imagine, having made so much effort to free resources in a nominally garbage-collected language, I would have hoped for a little more effect. So my question is: what does recycle() do? Does it actually trigger garbage collection, or will the system hold on to the memory—even if you call System.gc()—until it feels the need to get rid of something?

注意，我知道 Bitmap 实际上并不保存在常规堆中，但我认为调用 recycle() 足以确保它们从本机堆中删除.

NB I know Bitmaps aren't actually held in the regular heap but I thought calling recycle() was enough to ensure they were dropped out of the native heap.

部分答案

我发现如果 ImageView 包含一个被回收的 Bitmap，Bitmap 数据仍然保留在内存中，直到 setImageBitmap(null) 在 ImageView 上被调用.如果 setImageResource(...) 或 setImageDrawable(...) 被调用，甚至可能是这种情况(它们是，加载在一个相对较小的九个补丁中——然而，MAT 分析表明这并没有删除大 Bitmap，它包含在 ImageView 的私有成员中).简单地在 onStop() 调用这个函数已经从我们的应用程序堆中剔除了大约 10MB.显然，对于 Android 的蜂窝前版本，情况可能并非如此.

I have discovered that if an ImageView contains a Bitmap that has been recycled, the Bitmap data is still retained in memory until setImageBitmap(null) is called on the ImageView. This may even be the case if setImageResource(...) or setImageDrawable(...) are called (they were, loading in a relatively small nine-patch—however, MAT analysis shows this did not remove the large Bitmap, which was contained in the private members of the ImageView). Simply calling this function at onStop() has culled about 10MB from the heap of our application. Apparently this may not be the case for pre-Honeycomb builds of Android, though.

推荐答案

我发现，在 Honeycomb 中，如果 ImageView 包含一个被回收的 Bitmap，Bitmap 数据仍保留在内存中，直到在 ImageView 上调用 setImageBitmap(null).如果调用 setImageResource(...) 或 setImageDrawable(...) 甚至可能是这种情况(在这种情况下，一个非常大的位图被一个相当小九补丁，但只有在加载九补丁之前调用setImageBitmap(null)时，内存才真正被释放).

I have discovered that, in Honeycomb onwards, if an ImageView contains a Bitmap that has been recycled, the Bitmap data is still retained in memory until setImageBitmap(null) is called on the ImageView. This may even be the case if setImageResource(...) or setImageDrawable(...) are called (in this case, a very large bitmap was replaced with a fairly small nine-patch, but only when setImageBitmap(null) was called before loading the nine-patch was the memory actually disposed).

这篇关于Android Honeycomb 中的 Bitmap#recycle() 实际上是做什么的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！