现在的移动手机内存越来越大，但是我们在开发时任然需要对我们的应用的内存经行把控，对于内存中的图像，如果
占用的内存太大，不及时释放或者对图片经行压缩，仍然会出现OOM异常
对于图片的加载，显示，处理，现在有许多第三方的工具类，如比较有名的Xutils，或者开源的框架如Universial Image Loader等等，这里不一一例举。
我们先看下图像的相关东西
颜色模型
对于常见的颜色模型，也就RGB，CMYK，YUV，ARGB。大多数API都采用RGB模型，android的API一般采用RGB和ARGB。
对于颜色的编码，说白了就是一个像素所占内存的大小，有浮点数编码（0.5，0.3，0.6），在java中一个float占4
个字节，所以一个像素要占12个字节。24位的整数编码（255,255,255），这种方式每个颜色位占用1个字节，所以一
个像素需要3字节，在java中可以用int类型存储，这样多出来的高8位我们可以存储透明度，所以就有了ARGB编码。
我们可以在BitmapFactory中看到RGB888和ARGB8888的原因。还有16位整数编码(31，45，31)从左到右依次用5bit，
6bit，5bit，也就是RGB565，所以这种编码一般用short或者char存储就可以了，当然他也可以表示透明度，这时候需
要相应的调整，4bit的透明度，4bit的R，4bit的G，4bit的B，这就是ARGB4444。
打个比方如果用ARGB8888编码，放入一张400*400的图片，那么就需要400*400*4字节的空间了
我们可以看出使用合适的编码，可以为我们的内存减少不少的空间
对于OOM这种异常我们有如下几种方式去处理：
1 缓存图像到内存，采用软引用缓存到内存，而不是在每次使用的时候都从新加载到内存；
2 调整图像大小，手机屏幕尺寸有限，分配给图像的显示区域本身就更小，有时图像大小可以做适当调整；
3 采用低内存占用量的编码方式，比如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省内存；
4 及时回收图像，如果引用了大量Bitmap对象，而应用又不需要同时显示所有图片，可以将暂时用不到的Bitmap对象
及时回收掉；
5 自定义堆内存分配大小，优化Dalvik虚拟机的堆内存分配；