如何加载大图片及bitmap相关处理

前言

我们要说点什么：

1.我们应该怎么加载一个大图片，从而避免OOM（我喜欢stackoverflow.com的名字）

2.我们是否应该鄙视：setbackgroundresource等直接通过一个id构建bitmap/drawable的方法

3.一些参考资料

转自 http://blog.csdn.net/qlsusu/article/details/8137889

正文

加载那个大图片

你的图片有多大，在我看来，一张40K+的图片，已经被称为大图片了

当你的程序，通过view.setbackgroundxxx来频繁的（100ms一张图片，或者，更短的ms）更换图片时（或者，你采用surfaceview的style），上述的40K+已经非常的大了

你应该选择什么API来显示你的图片：

bitmapdrawable，而不是setbackgroundresource(int id)

为什么：通过一个id来获取一个bitmap/drawable时，android系统会对该资源进行缓存，从而下次访问迅速响应，但是，它只缓存，不释放，再多的memory也不够用，进而OOM

bitmapdrawable的创建过程很节省时间吗？：

我曾经做过一个实验，在无bitmapfactory.options的时候，反复的加载一个40K+的图片1000次，算的其平均加载一张图片的时间为：68ms

options.inSampleSize

针对于上面的例子，当你选择设置了options.inSampleSize = 2时（width和height均为原来的1/2），你会得到平均30ms左右的加载时间

但是，inSampleSize会使得图片的尺寸缩小（如果view.lp.width/height为wrap_content），会使得图片变得模糊（如果view.lp.width/height被限定成xxdp，这也包含了match_parent）

但是，它是有用的：

一个场景：你已经算的，你的view只有50px*50px的大小，而对应的image的分辨率却是720px*1280px

那么，你应该确定options.inSampleSize，来减少加载时间，甚至避免oom

下面，给出一个最佳实践：

[java]  view plain copy

1. public static final BitmapFactory.Options getBitmapOptions(  
2.         BitmapFactory.Options... option) {  
3.     BitmapFactory.Options options = null;  
4.     if (option == null || option.length == 0) {  
5.         options = new BitmapFactory.Options();  
6.     } else {  
7.         options = option[0];  
8.     }  
9.     options.inPurgeable = true;  
10.     options.inInputShareable = true;  
11.     // options.inDither = true;  
12.     // options.inScaled = false;  
13.     options.inPreferredConfig = Bitmap.Config.RGB_565;  
14.     return options;  
15. }  
16.   
17. /** 
18.  * 在加载asset图片时，考虑opt.inSampleSize：比较 img.width/height 和 width/height 
19.  *  
20.  * @param path 
21.  * @param am 
22.  * @param width 
23.  *            要求的width 
24.  * @param height 
25.  *            要求的height 
26.  * @return 
27.  */  
28. public static final Bitmap getBitmapConsideringSize(String path,  
29.         AssetManager am, int width, int height) {  
30.     InputStream is = null;  
31.     Bitmap bitmap = null;  
32.     try {  
33.         is = am.open(path);  
34.         BitmapFactory.Options opt = new Options();  
35.         opt.inJustDecodeBounds = true;  
36.         BitmapFactory.decodeStream(is, null, opt);  
37.         int widthRatio = (int) Math.ceil(opt.outWidth / (float) width);  
38.         int heightRatio = (int) Math.ceil(opt.outHeight / (float) height);  
39.   
40.         opt = getBitmapOptions();  
41.         if (widthRatio > 1 && heightRatio > 1) {  
42.             opt.inSampleSize = widthRatio > heightRatio ? widthRatio  
43.                     : heightRatio;  
44.         }  
45.         bitmap = BitmapFactory.decodeStream(is, null, opt);  
46.     } catch (Exception e) {  
47.         e.printStackTrace();  
48.     } finally {  
49.         closeStream(is);  
50.     }  
51.     return bitmap;  
52. }  

通过上述方法，每次加载40K+的图片，平均只需要26ms，且没有改变图像的尺寸（别被骗了，你的图片规格有可能降低了：RGB_565，但是，还好）

看看decodestream

转：

使用view.setBackgroundResource,imageview.setImageResource,bitmapFactory.decodeResource这样的方法来设置一张大图片的时候，
这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。
decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。
如果在读取时加上图片的Config参数，可以跟有效减少加载的内存，从而跟有效阻止抛out of Memory异常
注意：decodeStream直接拿的图片来读取字节码了，不会根据机器的各种分辨率来自动适应

使用缓存LruCache

为什么用：使用缓存，可以让我们下次访问一个元素 的消耗时间 变短

lru: Least Recently Used

cache: 缓存

如何访问：我们放入item<key,value>到这个cache中，我们根据key来去取value（注意：value有可能为null，下面说，为什么）

有什么用：

我们在源源不断的往cache里面放入item（而item本身可能是耗内存的，比如<String, Bitmap>），

我们不在意：是否因为生成了足够多的item，而占据了大量的内存，从而导致oom，

为什么：cache在帮我们维护内存，它知道：在我们即将放入一个item时，有可能会导致oom，则，它释放掉lru item(s)

注意什么：当我们根据key来获取value时，value有可能为null，那么，需要自行构建value，（并建议：将<key,value>放入到cache中）

参考：

https://developer.android.com/reference/android/util/LruCache.html

https://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

http://stackoverflow.com/questions/12716574/bitmap-recycle-with-largeheap-enabled

别让你的程序卡掉，或者，抛出异常

作为一个单独的小结，我理解，上述问题是多么的重要，以及，令人抓狂

你可以试试每隔60ms来播放1万张40K+图片，并且按照上述方法来进行展示

但是，依然，程序能挂掉，或者，屏幕已经全黑了（你会很确定，你的程序没有死掉，但是，你看到的一切全黑了）

你查看logcat，你会发现：imageref_ashmem create failed <(null)>

可以google，或者stackoverflow，它会告诉你，你需要释放bitmap

你可能会反问，都不会再OOM了，为什么还要释放bitmap，答案，很简单，因为黑屏，因为异常（开玩笑的，如果你知道更确认的原因，请告诉我，请尽量使用通俗易懂的语言，3x）

如何释放一个bitmap：bitmap.recycle()

bitmap会立刻释放吗：不会，但是会在某个时刻被释放

它会立刻引发GC吗：不会（说到这里，如果在你的程序里，频繁的调用gc，或者被动的被调用gc（如：频繁的调用setbackgroundresource，且每次都是个大图片），那么你将有幸看到你的程序离迟钝只有一步之遥了，所以，请不要这样做，因为，它只会让性能更差，你可以实验一下）

它会引发什么样的问题：你可能有机会看到这样一个异常：{你引用了一个已经被recycled的bitmap，然后程序就这样挂了}，所以，请你考虑应该进行释放操作的时机，给一个参考：你在显示当前图片的时候，也许，你愿意将之前的图片给释放掉

我们该鄙视诸如setbackgroundresource此类吗

的确，setbackgroundresource让人抓狂：它缓存了太多东西，导致OOM

但是，它的存在是为了它的另外一面：当下次访问该图片的时候，能快速响应

接下来的一个问题，下次访问是在什么时候，停100ms再访问这个图片算很长吗？

不幸的是，是的，100ms再访问，会显的很长

当你在编写一个撞球的游戏，每100ms刷新一次屏幕，是那么的漫长，这时，你巴不得刚设置完view的img后，就立刻开始下一次view的img设置（因为android的刷新是有时间的，所以，这样做，是有意义的）（啊，这个球很快，这一秒还在这，下一秒已经在那了，太快了，瞬间转移，也许，你也认为100ms一帧是漫长的）

从bitmapdrawable中实验来看，图片加载的时间为20ms，那么，这个时间很快吗？有直接从缓存里面取来的快吗？

所以，我们不应该鄙视

一些参考资料

google上有很多的处理OOM的资料，在此，我贴出一些：

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

http://blog.sina.com.cn/s/blog_5de73d0b010117ix.html

http://www.cnblogs.com/siyiganshou/

http://blog.csdn.net/imyfriend/article/details/8039767