文章探讨了Android系统中图片内存管理的问题，特别是Bitmap对象引起的内存溢出(OutOfMemory)问题。通过深入研究BitmapFactory.options.inPurgeable参数，提供了一种有效避免内存溢出的方法。
小太上一篇关于图像技术的文章《为什么Android的图片质量会比iPhone的差？》（http://blog.sina.com.cn/s/blog_12ce70a430102v1p3.html），引起了不少讨论。其实，谷歌在图像技术方面没搞明白的，可不仅仅只是libjpeg的optimize_mode参数那么简单。
跟安卓系统在图像内存管理方面的“糊涂”比起来，图片品质还真算不上个事，质量差点大家还能忍，内存管理不当则会导致应用的崩溃（OOM : Out of Memory）可就真没人能忍了。
Bitmap很占内存，那到底会占多少内存呢？计算起来很简单，如果你需要显示一个长宽均为612个像素的正方形图片，对应的Bitmap对象需要612*612*4=1498176个字节的内存，即大约不到1.5MB的内存。这种级别的内存消耗，在开发桌面应用时，问题不大，反正这么多年了，大家已经习惯了不管三七二十一，所有的内存都归我用。到了移动互联网时代，那可就不行了，智能手机操作系统（如iOS和Android）严格限制了每个应用能够使用的内存空间，超了您就崩溃出去吧，千万别影响到其它应用的正常运行。
关于图像内存管理中的OOM问题，基本上每位安卓开发者都遇到过，网上搜一下，能找到各种“神奇”的解决方案，比如说：
1、减小图片的显示尺寸，不使用ARGB_8888（32位），而是选择使用ARGB_4444（16位）甚至是RGB_565（8位）。嗯，遇到问题不是想着怎么解决，而是选择用更小、更差的显示品质来代替，这思路，赞！按这种逻辑，无图应用最省内存，大家都去开发无图应用好了。
2、显式的回收图片内存，也就是手工的recycle一个Bitmap对象。听起来这还真像是正道，需要内存的时候分配，不需要的时候回收，这总该没问题了吧？其实这种解决方案假定的是安卓系统的垃圾回收效率低甚至有可能不可靠，这种写法嘛，遇到ListView里不断滚屏显示图片的需求（这也算得上是很基本的需求了吧？），总会遇到这样那样的古怪问题，不是“out of memory”，就是“trying to use a recycled bitmap”，反正就一个字“崩”！
3、设置Bitmap对象为软引用（Soft Reference），频繁的手动调用垃圾回收（Garbage Collection）。需要请求大一点的内存空间之前，先gc一下，释放点儿内存，让崩溃的概率低一些。这的确算的上个招数，但也仅仅是治标不治本，让崩溃的概率稍微低上那么一点点。
作为一个在图片方面进行过很多努力的团队，上述的“解决方案”我们都尝试过、纠结过，可就是无法彻底解决问题，OOM那可真算得上是我们在安卓开发上所遇到过的最大的“拦路虎”了。
我们不仅使用DDMS来监控内存的情况，还用到了MAT（Memory Analyzer Tool）来分析可能导致内存问题的原因。在分析过程中，我们甚至找到过MIUI历史版本中的一些内存泄露问题，可还是无法彻底解决OOM。
为了尽可能避免代码逻辑所导致的影响，我们跑了一个干干净净的谷歌用来培训开发者的项目BitmapFun，可还是没用，ListView滚动滚动，内存就激增，滚快一点儿，应用就崩。
记得当时我们几个还曾内部交流过，谷歌自己难道就不知道BitmapFun会OOM吗？
最终，彻底解决问题、彻底搞清楚安卓系统在图片方面的内存管理机制、彻底弄明白垃圾回收和内存泄露的原理，靠的还是一个小小的选项：inPurgeable（以及与其相关的inInputShareable选项）。
关于BitmapFactory.options.inPurgeable选项的详细描述，可参阅谷歌官方文档（http://developer.android.com/reference/android/graphics/BitmapFactory.Options.html#inPurgeable）。
如果设置inPurgeable选项为true，当系统需要回收内存时，会清理Bitmap对象所占据的内存。这样，如果需要再次访问Bitmap对象，则需要re-decode。因为re-decode需要保持对源（InputStream或ByteArray）的引用，所以，inPurgeable不能用于decodeResource和decodeFile。
这其实才是OOM的终极解决之道，因为应用中所需显示的图片通常来源于jpg或png的文件，相比起Bitmap对象所需的内存（比如1.5MB），jpg或png则要小得多（比如50KB）。保留对于Bitmap源的引用（InputStream或ByteArray），所需要的内存可能仅仅是几十分之一，而在需要再次显示Bitmap对象时，re-decode所需要耗费的系统性能对于现如今的硬件计算能力来说微乎其微。需要re-decode，却再无OOM的困扰了，这是何等重要的参数啊！
好了，现在在你的应用中放心大胆的设置inPurgeable为true吧，然后再设置对应的InputShareable为true，用DDMS监控一下内存使用情况。有没有发现，无论是快速滚动ListView，还是不断点击查看大图，内存占用都很低而且非常稳定？再也不用担心因Bitmap导致的OOM了吧？
这么重要的选项，谷歌给出的建议竟然是“不建议使用”，对此，小太只能说一句“呵呵”了。（有本事让你家的BitmapFun别OOM啊！）
关于Bitmap对象的内存使用，暂且说到这儿。小太再说说安卓开发中解决内存问题的一般性原则：
1、OOM是最讨厌的一种崩溃，通常不会崩在有问题的、内存泄露的代码上，这只能靠仔细分析内存泄露来解决。
2、安卓的垃圾回收机制是可以信赖的，不需要手工recycle，不需要频繁调用gc（Bitmap的OOM是因为需要的内存太多，并不一定是内存泄露）。对象用完了之后，去掉引用就足够了。
3、永远只用ARGB_8888，早期的安卓甚至曾建议开发者用RGB_565，那是谷歌自己没想明白。
4、内存泄露的问题一定是引用没释放，大部分问题并不需要MAT这类的高级工具来进行深度跟踪，通常DDMS+Review代码就足够了。
5、近一年安卓平台上应用的OOM问题没那么明显，有两方面的原因，第一是安卓开发者水平的普遍提高、代码越写越好、内存泄露越来越少，第二则是智能手机硬件的不断发展（旗舰机都3GB内存了吧？），还真不是因为谷歌搞明白了。
最后再补充一句，无论是optimize_code，还是inPurgeable，苹果都是真懂，从一开始就懂，iOS开发者真幸福！
我们团队开源了之前基于BitmapFun改写的Sample（包括：LRUCache缓存、图片下载、ListView......），欢迎试用并多提宝贵意见，开源项目地址：
https://github.com/bither/bither-bitmap-sample
跟安卓系统在图像内存管理方面的“糊涂”比起来，图片品质还真算不上个事，质量差点大家还能忍，内存管理不当则会导致应用的崩溃（OOM : Out of Memory）可就真没人能忍了。
Bitmap很占内存，那到底会占多少内存呢？计算起来很简单，如果你需要显示一个长宽均为612个像素的正方形图片，对应的Bitmap对象需要612*612*4=1498176个字节的内存，即大约不到1.5MB的内存。这种级别的内存消耗，在开发桌面应用时，问题不大，反正这么多年了，大家已经习惯了不管三七二十一，所有的内存都归我用。到了移动互联网时代，那可就不行了，智能手机操作系统（如iOS和Android）严格限制了每个应用能够使用的内存空间，超了您就崩溃出去吧，千万别影响到其它应用的正常运行。
关于图像内存管理中的OOM问题，基本上每位安卓开发者都遇到过，网上搜一下，能找到各种“神奇”的解决方案，比如说：
1、减小图片的显示尺寸，不使用ARGB_8888（32位），而是选择使用ARGB_4444（16位）甚至是RGB_565（8位）。嗯，遇到问题不是想着怎么解决，而是选择用更小、更差的显示品质来代替，这思路，赞！按这种逻辑，无图应用最省内存，大家都去开发无图应用好了。
2、显式的回收图片内存，也就是手工的recycle一个Bitmap对象。听起来这还真像是正道，需要内存的时候分配，不需要的时候回收，这总该没问题了吧？其实这种解决方案假定的是安卓系统的垃圾回收效率低甚至有可能不可靠，这种写法嘛，遇到ListView里不断滚屏显示图片的需求（这也算得上是很基本的需求了吧？），总会遇到这样那样的古怪问题，不是“out of memory”，就是“trying to use a recycled bitmap”，反正就一个字“崩”！
3、设置Bitmap对象为软引用（Soft Reference），频繁的手动调用垃圾回收（Garbage Collection）。需要请求大一点的内存空间之前，先gc一下，释放点儿内存，让崩溃的概率低一些。这的确算的上个招数，但也仅仅是治标不治本，让崩溃的概率稍微低上那么一点点。
作为一个在图片方面进行过很多努力的团队，上述的“解决方案”我们都尝试过、纠结过，可就是无法彻底解决问题，OOM那可真算得上是我们在安卓开发上所遇到过的最大的“拦路虎”了。
我们不仅使用DDMS来监控内存的情况，还用到了MAT（Memory Analyzer Tool）来分析可能导致内存问题的原因。在分析过程中，我们甚至找到过MIUI历史版本中的一些内存泄露问题，可还是无法彻底解决OOM。
为了尽可能避免代码逻辑所导致的影响，我们跑了一个干干净净的谷歌用来培训开发者的项目BitmapFun，可还是没用，ListView滚动滚动，内存就激增，滚快一点儿，应用就崩。
记得当时我们几个还曾内部交流过，谷歌自己难道就不知道BitmapFun会OOM吗？
最终，彻底解决问题、彻底搞清楚安卓系统在图片方面的内存管理机制、彻底弄明白垃圾回收和内存泄露的原理，靠的还是一个小小的选项：inPurgeable（以及与其相关的inInputShareable选项）。
关于BitmapFactory.options.inPurgeable选项的详细描述，可参阅谷歌官方文档（http://developer.android.com/reference/android/graphics/BitmapFactory.Options.html#inPurgeable）。
如果设置inPurgeable选项为true，当系统需要回收内存时，会清理Bitmap对象所占据的内存。这样，如果需要再次访问Bitmap对象，则需要re-decode。因为re-decode需要保持对源（InputStream或ByteArray）的引用，所以，inPurgeable不能用于decodeResource和decodeFile。
这其实才是OOM的终极解决之道，因为应用中所需显示的图片通常来源于jpg或png的文件，相比起Bitmap对象所需的内存（比如1.5MB），jpg或png则要小得多（比如50KB）。保留对于Bitmap源的引用（InputStream或ByteArray），所需要的内存可能仅仅是几十分之一，而在需要再次显示Bitmap对象时，re-decode所需要耗费的系统性能对于现如今的硬件计算能力来说微乎其微。需要re-decode，却再无OOM的困扰了，这是何等重要的参数啊！
好了，现在在你的应用中放心大胆的设置inPurgeable为true吧，然后再设置对应的InputShareable为true，用DDMS监控一下内存使用情况。有没有发现，无论是快速滚动ListView，还是不断点击查看大图，内存占用都很低而且非常稳定？再也不用担心因Bitmap导致的OOM了吧？
这么重要的选项，谷歌给出的建议竟然是“不建议使用”，对此，小太只能说一句“呵呵”了。（有本事让你家的BitmapFun别OOM啊！）
关于Bitmap对象的内存使用，暂且说到这儿。小太再说说安卓开发中解决内存问题的一般性原则：
1、OOM是最讨厌的一种崩溃，通常不会崩在有问题的、内存泄露的代码上，这只能靠仔细分析内存泄露来解决。
2、安卓的垃圾回收机制是可以信赖的，不需要手工recycle，不需要频繁调用gc（Bitmap的OOM是因为需要的内存太多，并不一定是内存泄露）。对象用完了之后，去掉引用就足够了。
3、永远只用ARGB_8888，早期的安卓甚至曾建议开发者用RGB_565，那是谷歌自己没想明白。
4、内存泄露的问题一定是引用没释放，大部分问题并不需要MAT这类的高级工具来进行深度跟踪，通常DDMS+Review代码就足够了。
5、近一年安卓平台上应用的OOM问题没那么明显，有两方面的原因，第一是安卓开发者水平的普遍提高、代码越写越好、内存泄露越来越少，第二则是智能手机硬件的不断发展（旗舰机都3GB内存了吧？），还真不是因为谷歌搞明白了。
最后再补充一句，无论是optimize_code，还是inPurgeable，苹果都是真懂，从一开始就懂，iOS开发者真幸福！
我们团队开源了之前基于BitmapFun改写的Sample（包括：LRUCache缓存、图片下载、ListView......），欢迎试用并多提宝贵意见，开源项目地址：
https://github.com/bither/bither-bitmap-sample
扫一扫
1411
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
