Bitmap的加载和Cache

由于Bitmap的特殊性以及Android对单个应用所施加的内存限制，比如16M，这导致加载Bitmap的时候很容易出现内存溢出。比如以下场景：

Android中常用的缓存策略也是很有意思，缓存策略一个通用的思想，可以用到很多场景中，比如在实际开发中经常需要用到Bitmap做缓存。通过缓存策略，我们不需要每次都从网络上请求图片或者从存储设备中加载图片，这样就极大地提高了图片的加载效率以及产品的用户体验。目前比较常用的缓存策略是LruCache和DiskLruCache，其中LruCache常被用做内存缓存，而DiskLruCache用做存储缓存。Lru是Least Recently Used的缩写，即最近最少使用算法，这种算法的核心思想：当缓存快满时，会淘汰近期最少使用的缓存目标，很显然Lru算法的思想是很容易被接受的。

Bitmap在Android中指的是一张图片，可以是png格式也可以是jpg等其他常见的图片格式。BitmapFactory类提供了四类方法：decodeFile、decodeResource、decodeStream和decodeByteArray，分别用于支持从文件系统、资源、输入流以及字节数组中加载出一个Bitmap对象，其中decodeFile和decodeResource又间接调用了decodeStream方法，这四类方法最终是在Android的底层实现的，对应着BitmapFactory类的几个native方法。

如何高效地加载Bitmap呢，其实核心思想也简单，那就是采用BitmapFactory.Options来加载所需尺寸的图片。主要是用到它的inSampleSize参数，即采样率。当inSampleSize为1时，采样后的图片大小为图片的原始大小，当inSampleSize大于1时，比如为2，那么采样后的图片其宽/宽均为原图大小的1/2，而像素数为原图的1/4，其占有的内存大小也为原图的1/4。从最新官方文档中指出，inSampleSize的取值应该是2的指数，比如1、2、4、8、16等等。

通过采样率即可有效地加载图片，那么到底如何获取采样率呢，获取采样率也很简单，循序如下流程：

将BitmapFactory.Options的inJustDecodeBounds参数设为True并加载图片

从BitmapFactory.Options中取出图片的原始宽高信息，他们对应于outWidth和outHeight参数

根据采样率的规则并结合目标View的所需大小计算出采样率inSampleSize

将BitmapFactory.Options的inJustDecodeBounds参数设为False，然后重新加载图片。

经过上面4个步骤，加载出的图片就是最终缩放后的图片，当然也有可能不需要缩放。代码如下：

缓存策略在Android中有着广泛的使用场景，尤其在图片加载这个场景下，缓存策略变得更为重要。有一个场景就是批量下载网络图片，在PC上是可以把所有的图片下载到本地再显示即可，但是放到移动设备上就不一样了。不管是Android还是IOS设备，流量对于用户来说都是一种宝贵的资源。

如何避免过多的流量消耗呢，那就是缓存。当程序第一次从网络加载图片后，就将其缓存到存储设备上，这样下次使用这张图片就不用从网络上获取了，这样就为用户节省了流量。很多时候为了提高用户的用户体验，往往还会把图片在内存中再缓存一份，这样当应用打算从网络上请求一张图片时，程序首先从内存中去获取，如果内存中没有那就从存储设备中去获取，如果存储设备中也没有，那就从网络上下载这张图片。因为从内存中加载图片比从存储设备中加载图片要快，所以这样既提高了程序的效率又为用户节约了不必要的流量开销。

目前常用的一种缓存算法是LRU（Least Recently Used）,LRU是近期最少使用算法，它的核心思想是当缓存满时，会优先淘汰那些近期最少使用的缓存对象。采用LRU算法的缓存有两种：LruCache和DiskLruCache，LruCache用于实现内存缓存，而DiskLruCache则充当了存储设备缓存，通过这二者的完美结合，就可以很方便地实现一个具有很高实用价值的ImageLoader。

LruCache

LruCache是Android 3.1提供的一个缓存类，通过support-v4兼容包可以兼容到早期的Android版本。它是一个泛型类，它内部采用一个LinkedHashMap，当强引用的方式存储外界的缓存对象，其提供了get和put方法来完成缓存的获取和添加操作，当缓存满时，LruCache会移除较早使用的缓存对象，然后再添加新的缓存对象。

强引用：直接的对象引用

软引用：当一个对象只有软引用存在时，系统内存不足时此对象会被gc回收。

弱引用：当一个对象只有弱引用存在时，此对象会随时被gc回收。

LruCache是线程安全的，因为用到了LinkedHashMap。从Android 3.1开始，LruCache就已经是Android源码的一部分。

DiskLruCache

DiskLruCache用于实现存储设备缓存，即磁盘存储，它通过将缓存对象写入文件系统从而实现缓存的效果。DiskLruCache得到了Android官方文档的推荐，但它不属于Android SDK的一部分。

ImageLoader的实现

一般来说，一个优秀的ImageLoader应该具备如下功能：

图片的同步加载

图片的异步加载

图片压缩

内存缓存

磁盘缓存

网络拉取

图片的同步加载是指能够以同步的方式向调用者提供所加载的图片，这个图片可能是从内存缓存读取的，也可能是从磁盘缓存中读取的，还可能是从网络拉取的。

图片的异步加载是一个很有用的功能，很多时候调用者不想再单独的线程中以同步的方式来获取图片，这个时候ImageLoader内部需要自己在线程中加载图片并将图片设置所需的ImageView。图片压缩的作用更需要了，这是降低OOM概率的有效手段，ImageLoader必须合适地处理图片的压缩问题。

内存缓存和磁盘缓存是ImageLoader的核心，也是ImageLoader的意义所在，通过这两级缓存极大地提高了程序的效率并且有效地降低了对用户所造成的流量消耗，只有当这两级缓存都不可用时才需要从网络中拉取图片。

一个实现ImageLoader的例子：

在一般ListView或者GridView中，使用照片墙的时候，容易出现滑动卡顿，如何优化呢，有三点建议：

不要在getView中执行耗时操作。比如加载图片，肯定会导致卡顿，因为加载图片是一个耗时的操作，这种操作必须通过异步的方式来处理。

控制异步任务的执行频率。比如在异步加载图片时，用户刻意地频繁上下滑动，这就会在一瞬间产生上百个异步任务，这些异步任务会造成线程池的拥堵并随即带来大量的UI更新操作，这是没有意义的。那该如何解决呢，可以考虑在列表滑动的时候，停止加载图片，尽管这个过程是异步的，等列表停下来以后在加载图片仍然可以获得良好的用户体验。

开启硬件加速可以解决莫名的卡顿问题，通过设置android:hardwareAccelerated = "true"即可为Activity开启硬件加速。

源于对掌握的Android开发基础点进行整理，罗列下已经总结的文章，从中可以看到技术积累的过程。

1，Android系统简介

2，ProGuard代码混淆

3，讲讲Handler+Looper+MessageQueue关系

4，Android图片加载库理解

5，谈谈Android运行时权限理解

6，EventBus初理解

7，Android 常见工具类

8，对于Fragment的一些理解

9，Android 四大组件之 " Activity "

10，Android 四大组件之" Service "

11，Android 四大组件之“ BroadcastReceiver "

12，Android 四大组件之" ContentProvider "

13，讲讲 Android 事件拦截机制

14，Android 动画的理解

15，Android 生命周期和启动模式

16，Android IPC 机制

17，View 的事件体系

18，View 的工作原理

19，理解 Window 和 WindowManager

20，Activity 启动过程分析

21，Service 启动过程分析

22，Android 性能优化

23，Android 消息机制

24，Android Bitmap相关

25，Android 线程和线程池

26，Android 中的 Drawable 和动画

27，RecylerView 中的装饰者模式

28，Android 触摸事件机制

29，Android 事件机制应用

30，Cordova 框架的一些理解

31，有关 Android 插件化思考

32，开发人员必备技能——单元测试