Android--Bitmap加载&ImageLoader

在Android的初级开发阶段，我们只关注如何实现我们的功能————不管黑猫白猫，抓到老鼠就是好猫。但在这个过程中我们很容易会忽略一些东西，如性能的损失、内存泄漏、代码耦合度高，逻辑混乱以及因此带来的代码混乱。

实际上上述问题我反而觉得最后一个是最严重的，垃圾代码多了，虽然能运行，但一旦某个环节发生问题就会牵一发动全身，甚至很可能整个项目都要重构。因而我们要学会解耦，其中最好的办法莫过于将每一个功能单独封装成一个模块，尽量少在别的模块里面调用别的模块。

虽然话是这么说，但是完全遵循上述还是很困难的，因为有些时候已经成了定性思维，稍不留神就又写了一遍垃圾代码。多读、多写、多看，将良好的编程习惯融入自己的风格里面，总能成长的。

Android优化是一个很大的话题，Android developer中也给出了许多开发者需要注意的地方,多学习一下开发者文档总是没有错的。

Part.1 Bitmap 加载

在Android开发中，我们经常用到的图像文件有两种，一种是Drawable，另一种就是Bitmap。
文档对Drawable的描述是“something that can be Drawn”，并且它本身是一个抽象类。而Bitmap本身可以从Drawable中加载出来，相比于Drawable，Bitmap会占用更大的内存，并且其加载速度也比Drawable要来的慢。但我们仍要使用它的原因是它比Drawable来说，进行图像的处理要更加方便。

在Android中有一大半的OOM的原因都是因为Bitmap的处理不当而造成的。一张色彩丰富分辨率极高的图片直接加载进APP中的时候会消耗巨额的内存，而一个APP一般而言只会被分配16M的内存可以使用。

综上所述，要处理好Bitmap的加载是十分必要的。

1.1.BitmapFactory.Options

我们加载一个Bitmap的时候大多数会选择使用BitmapFactory.decodeFile(),BitmapFactory.decodeResource()、BitmapFactory.Stream()、BitmapFactory.decodeByteArray()这四个方法来对文件、资源、输入流以及字节数组进行加载。

对于Bitmap的优化莫过于从大小上进行优化，由于移动设备的屏幕大小有限，我们能看到的只有imageView大小的图片，最多也不过是占据整个屏幕，因此我们何不对照片进行裁剪呢。

另外，不同格式的编码方式也对Bitmap的大小有影响，在Android中对一个Bitmap的色彩存储方案有4种，分别是ARGB_8888(默认)、ARGB_4444、ALPHA_8以及RGB_565，关于上述色彩方案的区别可以查看下方的引用：

Bitmap.Config ARGB_4444：每个像素占四位，即A=4，R=4，G=4，B=4，那么一个像素点占4+4+4+4=16位

Bitmap.Config ARGB_8888：每个像素占四位，即A=8，R=8，G=8，B=8，那么一个像素点占8+8+8+8=32位

Bitmap.Config RGB_565：每个像素占四位，即R=5，G=6，B=5，没有透明度，那么一个像素点占5+6+5=16位

Bitmap.Config ALPHA_8：每个像素占四位，只有透明度，没有颜色。

而默认Android的色彩方案采用的是ARGB_8888,每个像素点占据