一、前言
图片加载的轮子有很多了，Universal-Image-Loader, Picasso, Glide, Fresco等。
网上各种分析和对比文章很多，我们这里就不多作介绍了。
古人云：“纸上得来终觉浅，绝知此事要躬行”。
只看分析，不动手实践，终究印象不深。
用当下流行的“神经网络”来说，就是要通过“输出”，形成“反馈”，才能更有效地“训练”。
当然，大千世界，包罗万象，我们不可能任何事情都去经历。
能挑自己感兴趣的方面探究一番，已经幸事。
图片加载是笔者比较感兴趣的，其中有不少知识和技巧值得研究探讨。
话不多说，先来两张图暖一下气氛：
暖场结束，我们开始吧：
二、 框架命名
命名是比较令人头疼的一件事。
在反复翻了单词表之后，决定用Doodle作为框架的名称。
Picasso是画家毕加索的名字，Fresco翻译过来是“壁画”，比ImageLoader之类的要更有格调;
本来想起Van、Vince之类的，但想想还是不要冒犯这些巨擘了。
Doodle为涂鸦之意，除了单词本身内涵之外，外在也很有趣，很像一个单词：Google。
这样的兼具有趣灵魂和好看皮囊的词，真的不多了。
三、流程&架构
3.1 加载流程
概括来说，图片加载包含封装，解析，下载，解码，变换，缓存，显示等操作。
流程图如下：
- 封装参数：从指定来源，到输出结果，中间可能经历很多流程，所以第一件事就是封装参数，这些参数会贯穿整个过程；
- 解析路径：图片的来源有多种，格式也不尽相同，需要规范化；
- 读取缓存：为了减少计算，通常都会做缓存；同样的请求，从缓存中取图片（Bitmap）即可；
- 查找文件/下载文件：如果是本地的文件，直接解码即可；如果是网络图片，需要先下载；
- 解码：这一步是整个过程中最复杂的步骤之一，有不少细节；
- 变换：解码出Bitmap之后，可能还需要做一些变换处理（圆角，滤镜等）；
- 缓存：得到最终bitmap之后，可以缓存起来，一遍下次请求时直接取结果；
- 显示：显示结果，可能需要做些动画（淡入动画，crossFade等）。
以上简化版的流程（只是众多路径中的一个分支），后面我们将会看到，完善各种细节之后，会比这复杂很多。
但万事皆由简入繁，先简单梳理，后续再慢慢填充，犹如绘画，先绘轮廓，再描细节。
3.2 基本架构
解决复杂问题，思路都是相似的：分而治之。
参考MVC的思路，我们将框架划分三层：
- Interface: 框架入口和外部接口
- Processor: 逻辑处理层
- Storage：存储层，负责各种缓存。
具体划分如下：
- 外部接口
Doodle: 提供全局参数配置，图片加载入口，以及内存缓存接口。
Config: 全局参数配置。包括缓存路径，缓存大小，图片编码等参数。
Request: 封装请求参数。包括数据源，解码参数，行为参数，以及目标。
- 执行单元
Dispatcher : 负责请求调度, 以及结果显示。
Worker: 工作线程，异步执行加载，解码，变换，存储等。
Downloader: 负责文件下载。
Source: 解析数据源，提供统一的解码接口。
Decoder: 负责具体的解码工作。
- 存储组件
MemoryCache: 管理Bitmap缓存。
DiskCache: 图片“结果”的磁盘缓存（原图由OkHttp缓存）。
四、功能实现
上一节分析了流程和架构，接下来就是在理解流程，了解架构的前提下，
先分别实现关键功能，然后串联起来，之后就是不断地添加功能和完善细节。
简而言之，就是自顶向下分解，自底向上填充。
4.1 API设计
众多图片加载框架中，Picasso和Glide的API是比较友好的。
Picasso.with(context)
.load(url)
.placeholder(R.drawable.loading)
.into(imageView);Glide的API和Picasso类似。
当参数较多时，构造者模式就可以搬上用场了，其链式API能使参数指定更加清晰，而且更加灵活（随意组合参数）。
Doodle也用类似的API，而且为了方便理解，有些方法命名也参照Picasso和 Glide。
4.1.1 全局参数
- Config
object Config {
internal var userAgent: String = ""
internal var diskCachePath: String = ""
internal var diskCacheCapacity: Long = 128L shl 20
internal var diskCacheMaxAge: Long = 30 * 24 * 3600 * 1000L
internal var bitmapConfig: Bitmap.Config = Bitmap.Config.ARGB_8888
// ...
fun setUserAgent(userAgent: String): Config {
this.userAgent = userAgent
return this
}
fun setDiskCachePath(path: String): Config {
this.diskCachePath = path
return this
}
// ....
}- Doodle
object Doodle {
internal lateinit var appContext: Context
fun init(context: Context) : Config {
appContext = context as? Application ?: context.applicationContext
registerActivityLifeCycle(appContext)
return Config
}
}- 框架初始化
Doodle.init(context)
.setDiskCacheCapacity(256L shl 20)
.setMemoryCacheCapacity(128L shl 20)
.setDefaultBitmapConfig(Bitmap.Config.ARGB_8888)虽然也是链式API，但是没有参照Picasso那样的构造者模式的用法（读写分离），因为那种写法有点麻烦，而且不直观。
Doodle在初始化的时候传入context（最好传入Application）, 这样后面请求单个图片时，就不用像Picasso和Glide那样用with传context了。
4.1.2 图片请求
加载图片：
Doodle.load(url)
.placeholder(R.drawable.loading)
.into(topIv)实现方式和Config是类似的：
object Doodle {
// ....
fun load(path: String): Request {
return Request(path)
}
fun load(resID: Int): Request {
return Request(resID)
}
fun load(uri: Uri): Request {
return Request(uri)
}
}- Request
class Request {
internal val key: Long by lazy { MHash.hash64(toString()) }
// 图片源
internal var uri: Uri? = null
internal var path: String
private var sourceKey: String? = null
// 图片参数
internal var viewWidth: Int = 0
internal var viewHeight: Int = 0
// ....
// 加载行为
internal var priority = Priority.NORMAL
internal var memoryCacheStrategy= MemoryCacheStrategy.LRU
internal var diskCacheStrategy = DiskCacheStrategy.ALL
// ....
// target
internal var simpleTarget: SimpleTarget? = null
internal var targetReference: WeakReference<ImageView>? = null
internal constructor(path: String) {
if (TextUtils.isEmpty(path)) {
this.path = ""
} else {
this.path = if (path.startsWith("http") || path.contains("://")) path else "file://$path"
}
}
fun sourceKey(sourceKey: String): Request {
this.sourceKey = sourceKey
return this
}
fun into(target: ImageView?) {
if (target == null) {
return
}
targetReference = WeakReference(target)
if (noClip) {
fillSizeAndLoad(0, 0)
} else if (viewWidth > 0 && viewHeight > 0) {
fillSizeAndLoad(viewWidth, viewHeight)
}
// ...
}
private fun fillSizeAndLoad(targetWidth: Int, targetHeight: Int) {
viewWidth = targetWidth
viewHeight = targetHeight
// ...
Dispatcher.start(this)
}
override fun toString(): String {
val builder = StringBuilder()
if (!TextUtils.isEmpty(sourceKey)) {
builder.append("source:").append(sourceKey)
} else {
builder.append("path:").append(path)
}
// ....
return builder.toString()
}
}Request主要职能是封装请求参数，参数可以大约划分为4类：
- 1、图片源；
- 2、解码参数：宽高，scaleType，图片配置（ARGB_8888, RGB_565）等；
- 3、加载行为：加载优先级，缓存策略，占位图，动画等；
- 4、目标，ImageView或者回调等。
其中，图片源和解码参数决定了最终的bitmap, 所以，我们拼接这些参数作为请求的key，这个key会用于缓存的索引和任务的去重。
拼接参数后字符串很长，所以需要压缩成摘要，由于终端上的图片数量不会太多，64bit的摘要即可（原理参考《漫谈散列函数》）。
图片文件的来源，通常有网络图片，drawable/raw资源， assets文件，本地文件等。
当然，严格来说，除了网络图片之外，其他都是本地文件，只是有各种形式而已。
Doodle支持三种参数， id(Int), path(String), 和Uri（常见于调用相机或者相册时）。
对于有的图片源，路径可能会变化，比如url, 里面可能有一些动态的参数：
val url = "http://www.xxx.com/a.jpg?t=1521551707"请求服务端的时候，其实返回的是同一张图片。
但是如果用整个url作为请求的key的一部分，因为动态参数的原因，每次请求key都不一样，会导致缓存失效。
为此，可以将url不变的部分作为制定为图片源的key:
val url = "http://www.xxx.com/a.jpg"
Skate.load(url + "?t=" + System.currentTimeMillis())
.sourceKey(url)
.into(testIv);有点类似Glide的StringSignature。
请求的target最常见的应该是ImageView,
此外，有时候需要单纯获取Bitmap,
或者同时获取Bitmap和ImageView,
抑或是在当前线程获取Bitmap ……
总之，有各种获取结果的需求，这些都是设计API时需要考虑的。
4.2 缓存设计
几大图片加载框架都实现了缓存，各种文章中，有说二级缓存，有说三级缓存。
其实从存储来说，可简单地分为内存缓存和磁盘缓存；
只是同样是内存/磁盘缓存，也有多种形式，例如Glide的“磁盘缓存”就分为“原图缓存”和“结果缓存”。
4.2.1 内存缓存
为了复用计算结果，提高用户体验，通常会做bitmap的缓存；
而由于要限制缓存的大小，需要淘汰机制（通常是LRU策略）。
Android SDK提供了LruCache类，查看源码，其核心是LinkedHashMap。
为了更好地定制，这里我们不用SDK提供的LruCache，直接用LinkedHashMap，封装自己的LruCache。
internal class BitmapWrapper(var bitmap: Bitmap) {
var bytesCount: Int = 0
init {
this.bytesCount = Utils.getBytesCount(bitmap)
}
}internal object LruCache {
private val cache = LinkedHashMap<Long, BitmapWrapper>(16, 0.75f, true)
private var sum: Long = 0
private val minSize: Long = Runtime.getRuntime().maxMemory() / 32
@Synchronized
operator fun get(key: Long?): Bitmap? {
val wrapper = cache[key]
return wrapper?.bitmap
}
@Synchronized
fun put(key: Long, bitmap: Bitmap?) {
val capacity = Config.memoryCacheCapacity
if (bitmap == null || capacity <= 0) {
return
}
var wrapper: BitmapWrapper? = cache[key]
if (wrapper == null) {
wrapper = BitmapWrapper(bitmap)
cache[key] = wrapper
sum += wrapper.bytesCount.toLong()
if (sum > capacity) {
trimToSize(capacity * 9 / 10)
}
}
}
private fun trimToSize(size: Long) {
val iterator = cache.entries.iterator()
while (iterator.hasNext() && sum > size) {
val entry = iterator.next()
val wrapper = entry.value
WeakCache.put(entry.key, wrapper.bitmap)
iterator.remove()
sum -= wrapper.bytesCount.toLong()
}
}
}LinkedHashMap 构造函数的第三个参数：accessOrder，传入true时， 元素会按访问顺序排列，最后访问的在遍历器最后端。
进行淘汰时，移除遍历器前端的元素，直至缓存总大小降低到指定大小以下。
有时候需要加载比较大的图片，占用内存较高，放到LruCache可能会“挤掉”其他一些bitmap;
或者有时候滑动列表生成大量的图片，也有可能会“挤掉”一些bitmap。
这些被挤出LruCache的bitmap有可能很快又会被用上，但在LruCache中已经索引不到了，如果要用，需重新解码。
值得指出的是，被挤出LruCache的bitmap，在GC时并不一定会被回收，如果bitmap还被引用，则不会被回收；
但是不管是否被回收，在LruCache中都索引不到了。
我们可以将一些可能短暂使用的大图片，以及这些被挤出LruCache的图片，放到弱引用的容器中。
在被回收之前，还是可以根据key去索引到bitmap。
internal object WeakCache {
private val cache = HashMap<Long, BitmapWeakReference>()
private val queue = ReferenceQueue<Bitmap>()
private class BitmapWeakReference internal constructor(
internal val key: Long,
bitmap: Bitmap,
q: ReferenceQueue<Bitmap>) : WeakReference<Bitmap>(bitmap, q)
private fun cleanQueue() {
var ref: BitmapWeakReference? = queue.poll() as BitmapWeakReference?
while (ref != null) {
cache.remove(ref.key)
ref = queue.poll() as BitmapWeakReference?
}
}
@Synchronized
operator fun get(key: Long?): Bitmap? {
cleanQueue()
val reference = cache[key]
return reference?.get()
}
@Synchronized
fun put(key: Long, bitmap: Bitmap?) {
if (bitmap != null) {
cleanQueue()
val reference = cache[key]
if (reference == null) {
cache[key] = BitmapWeakReference(key, bitmap, queue)
}
}
}
}以上实现中，BitmapWeakReference是WeakReference的子类，除了引用Bitmap的功能之外，还记录着key, 以及关联了ReferenceQueue;
当Bitmap被回收时，BitmapWeakReference会被放入ReferenceQueue，
我们可以遍历ReferenceQueue，移除ReferenceQueue的同时，取出其中记录的key, 到cache中移除对应的记录。
利用WeakReference和ReferenceQueue的机制，索引对象的同时又不至于内存泄漏，类似用法在WeakHashMap和Glide源码中都出现过。
最后，综合LruCache和WeakCache，统一索引：
internal object MemoryCache {
fun getBitmap(key: Long): Bitmap? {
var bitmap = LruCache[key]
if (bitmap == null) {
bitmap = WeakCache[key]
}
return bitmap
}
fun putBitmap(key: Long, bitmap: Bitmap, toWeakCache: Boolean) {
if (toWeakCache) {
WeakCache.put(key, bitmap)
} else {
LruCache.put(key, bitmap)
}
}
// ......
}声明内存缓存策略：
object MemoryCacheStrategy{
const val NONE = 0
const val WEAK = 1
const val LRU = 2
}NONE: 不缓存到内存
WEAK： 缓存到WeakCache
LRU：缓存到LRUCache
4.2.2 磁盘缓存
曲面提到，Glide有两种磁盘缓存：“原图缓存”和“结果缓存”，
Doodle也仿照类似的策略，可以选择缓存原图和结果。
原图缓存指的是Http请求下来的未经解码的文件；
结果缓存指经过解码，剪裁，变换等，变成最终的bitmap之后，通过bitmap.compress()压缩保存。
其中，后者通常比前者更小，而且解码时不需要再次剪裁和变换等，所以从结果缓存获取bitmap通常要比从原图获取快得多。
为了尽量使得api相似，Doodle设置直接用Glide v3的缓存策略定义(Glide v4有一些变化）。
object DiskCacheStrategy {
const val NONE = 0
const val SOURCE = 1
const val RESULT = 2
const val ALL = 3
}NONE: 不缓存到磁盘
SOURCE: 只缓存原图
RESULT: 只缓存结果
ALL: 既缓存原图，也缓存结果。
Doodle的HttpClient是用的OkHttp, 所以网络缓存，包括原图的缓存就交给OkHttp了，
至于本地的图片源，本就在SD卡，只是各种形式而已，也就无所谓缓存了。
结果缓存，Doodle没有用DiskLruCache, 而是自己实现了磁盘缓存。
DiskLruCache是比较通用的磁盘缓存解决方案，笔者觉得对于简单地存个图片文件可以更精简一些，所以自己设计了一个更专用的方案。
其实磁盘缓存的管理最主要是设计记录日志，方案要点如下：
1、一条记录存储key(long)和最近访问时间(long)，一条记录16字节；
2、每条记录依次排列，由于比较规整，可以根据偏移量随机读写；
3、用mmap方式映射日志文件，以4K为单位映射。
文件记录之外，内存中还需要一个HashMap记录key到"文件记录"的映射, 其中，文件记录对象如下：
private class JournalValue internal constructor(
internal var key: Long,
internal var accessTime: Long,
internal var fileLen: Long,
internal var offset: Int) : Comparable<JournalValue> {
// ...
}只需记录key, 访问时间，文件大小，以及记录在日志文件中的位置即可。
那文件名呢？文件命名为key的十六进制，所以可以根据key运算出文件名。
运作机制：
访问DiskCache时，先读取日志文件，填充HashMap;
后面的访问中，只需读取HashMap就可以知道有没有对应的磁盘缓存；
存入一个“结果文件”则往HashMap存入记录，同时更新日志文件。
这种机制其实有点像SharePreferences, 二级存储，文件读一次之后接下来都是写入。
该方案的优点为：
1、节省空间，一页（4K）能记录256个文件；
2、格式规整，解析快；
3、mmap映射，可批量记录，自动定时写入磁盘，降低磁盘IO消耗；
4、二级存储，访问速度快。
当容量超出限制需要淘汰时，根据访问时间，先删除最久没被访问的文件；
除了实现LRU淘汰规则外，还可实现最大保留时间，删除一些太久没用到的图片文件。
虽然名为磁盘缓存，其实不仅仅缓存文件，“文件记录”也很关键，二者关系犹如文件内容和文件的元数据, 相辅相成。
4.3 解码
SDK提供了BitmapFactory，提供各种API，从图片源解码成bitmap，但这仅是图片解码的最基础的工作；
图片解码，前前后后要准备各种材料，留心各种细节，是图片加载过程中最繁琐的步骤之一。
4.3.1 解析数据源
前面提到，图片的来源有多种，我们需要识别图片来源，
然后根据各自的特点提供统一的处理方法，为后续的具体解码工作提供方便。
internal abstract class Source : Closeable {
// 魔数，提供文件格式的信息
internal abstract val magic: Int
// 旋转方向，EXIF专属信息
internal abstract val orientation: Int
internal abstract fun decode(options: BitmapFactory.Options): Bitmap?
internal abstract fun decodeRegion(rect: Rect, options: BitmapFactory.Options): Bitmap?
internal class FileSource constructor(private val file: File) : Source() {
//...
}
internal class AssetSource(private val assetStream: AssetManager.AssetInputStream) : Source() {
//...
}
internal class StreamSource constructor(inputStream: InputStream) : Source() {
//...
}
companion object {
private const val ASSET_PREFIX = "file:///android_asset/"
private const val FILE_PREFIX = "file://"
fun valueOf(src: Any?): Source {
if (src == null) {
throw IllegalArgumentException("source is null")
}
return when (src) {
is File -> FileSource(src)
is AssetManager.AssetInputStream -> AssetSource(src)
is InputStream -> StreamSource(src)
else -> throw IllegalArgumentException("unsupported source " + src.javaClass.simpleName)
}
}
fun parse(request: Request): Source {
val path = request.path
return when {
path.startsWith("http") -> {
val builder = okhttp3.Request.Builder().url(path)
if (request.diskCacheStrategy and DiskCacheStrategy.SOURCE == 0) {
builder.cacheControl(CacheControl.Builder().noCache().noStore().build())
} else if (request.onlyIfCached) {
builder.cacheControl(CacheControl.FORCE_CACHE)
}
valueOf(Downloader.getSource(builder.build()))
}
path.startsWith(ASSET_PREFIX) -> valueOf(Doodle.appContext.assets.open(path.substring(ASSET_PREFIX.length)))
path.startsWith(FILE_PREFIX) -> valueOf(File(path.substring(FILE_PREFIX.length)))
else -> valueOf(Doodle.appContext.contentResolver.openInputStream((request.uri ?: Uri.parse(path))))
}
}
}
}以上代码，从资源id, path, 和Uri等形式，最终转换成FileSource, AssetSource, StreamSource等。
- FileSource: 本地文件
- AssetSource：asset文件，drawable/raw资源文件
- StreamSource：网络文件，ContentProvider提供的图片文件，如相机，相册等。
其中，网络文件从OkHttp的网络请求获得，如果缓存了原图, 则会获得FileSource。
其实各种图片源最终都可以转化为InputStream，例如AssetInputStream其实就是InputStream的一种, 文件也可以转化为FileInputStream。
那为什么区分开来呢？ 这一切都要从读取图片头信息开始讲。
4.3.2 预读头信息
解码过程中通常需要预读一些头信息，如文件格式，图片分辨率等，作为接下来解码策略的参数，例如用图片分辨率来计算压缩比例。
当inJustDecodeBounds设置为true时， BitmapFactory不会返回bitmap, 而是仅仅读取文件头信息，其中最重要的是图片分辨率。
val options = BitmapFactory.Options()
options.inJustDecodeBounds = true
BitmapFactory.decodeStream(inputStream, null, options)读取了头信息，计算解码参数之后，将inJustDecodeBounds设置为false，
再次调用BitmapFactory.decodeStream即可获取所需bitmap。
可是，有的InputStream不可重置读取位置，同时BitmapFactory.decodeStream方法要求从头开始读取。
那先关闭流，然后再次打开不可以吗？ 可以，不过效率极低，尤其是网络资源时，不敢想象……
有的InputStream实现了mark(int)和reset()方法，就可以通过标记和重置支持重新读取。
这一类InputStream会重载markSupported()方法，并返回true, 我们可以据此判断InputStream是否支持重读。
幸运的是AssetInputStream就支持重读；
不幸的是FileInputStream居然不支持，OkHttp的byteStream()返回InputStream也不支持。
对于文件，我们通过搭配RandomAccessFile和FileDescriptor来重新重读；
而对于其他的InputStream，只能曲折一点，通过缓存已读字节来支持重新读取。
SDK提供的BufferedInputStream就是这样一种思路， 通过设置一定大小的缓冲区，以滑动窗口的形式提供缓冲区内重新读取。
遗憾的是，BufferedInputStream的mark函数需指定readlimit，缓冲区会随着需要预读的长度增加而扩容，但是不能超过readlimit；
若超过readlimit，则读取失败，从而解码失败。
/**
* @param readlimit the maximum limit of bytes that can be read before
* the mark position becomes invalid.
*/
public void mark(int readlimit) {
marklimit = readlimit;
markpos = pos;
}于是readlimit设置多少就成了考量的因素了。
Picasso早期版本设置64K, 结果遭到大量的反馈说解码失败，因为有的图片需要预读的长度不止64K。
从Issue的回复看，Picasso的作者也很无奈，最终妥协地将readlimit设为MAX_INTEGER。
但即便如此，后面还是有反馈有的图片无法预读到图片的大小。
笔者很幸运地遇到了这种情况，经调试代码，最终发现Android 6.0的BufferedInputStream，
其skip函数的实现有问题，每次skip都会扩容，即使skip后的位置还在缓冲区内。
造成的问题是有的图片预读时需多次调用skip函数，然后缓冲区就一直double直至抛出OutOfMemoryError……
不过Picasso最终还是把图片加载出来了，因为其catch了Throwable, 然后重新直接解码（不预读大小）；
虽然加载出来了，但是代价不小：只能全尺寸加载，以及前面预读时申请的大量内存（虽然最终会被GC），所造成的内存抖动。
Glide没有这个问题，因为Glide自己实现了类似BufferedInputStream功能的InputStream，完美地绕过了这个坑；
Doodle则是copy了Android 8.0的SDK的BufferedInputStream， 精简代码，加入一些缓冲区复用的代码等，可以说是改装版BufferedInputStream。
回头看前面一节的问题，为什么不统一用“改装版BufferedInputStream”来解码？
因为有的图片预读的长度很长，需要开辟较大的缓冲区，从这个角度看，FileSource和AssetSource更节约内存。
4.3.3 图片压缩
有时候需要显示的bitmap比原图的分辨率小。
比方说原图是 4096 * 4096, 如果按照ARGB_8888的配置全尺寸解码出来，需要占用64M的内存！
不过app中所需得bitmap通常会小很多， 这时就要压缩了。
比方说需要300 * 300的bitmap, 该怎么做呢？
网上通常的说法是设置 options.inSampleSize 来降采样。
阅读SDK文档，inSampleSize 需是整数，而且是2的倍数，
不是2的倍数时，会被 “be rounded down to the nearest power of 2”。
比方说前面的 4096 * 4096 的原图，
当inSampleSize = 16时，解码出256 * 256 的bitmap；
当inSampleSize = 8时，解码出512 * 512 的bitmap。
即使是inSampleSize = 8，所需内存也只有原来的1/64(1M），效果还是很明显的。
Picasso和Glide v3就是这么降采样的。
如果你发现解码出来的图片是300 * 300 （比如使用Picasso时调用了fit()函数），应该是有后续的处理（通过Matrix 和 Bitmap.createBitmap 继续缩放）。
那能否直接解码出300 * 300的图片呢？ 可以的。
查看 BitmapFactory.cpp 的源码，其中有一段：
const int density = env->GetIntField(options, gOptions_densityFieldID);
const int targetDensity = env->GetIntField(options, gOptions_targetDensityFieldID);
const int screenDensity = env->GetIntField(options, gOptions_screenDensityFieldID);
if (density != 0 && targetDensity != 0 && density != screenDensity) {
scale = (float) targetDensity / density;
}对应BitmapFactory.Options的两个关键参数：inDensity 和 inTargetDensity。
上面的例子，设置inTargetDensity=300， inDensity=4096(还要设置inScale=true), 则可解码出300 * 300的bitmap。
额外提一下，Glide v4也换成这种压缩策略了。
平时设计给切图，要放对文件夹，也是这个道理。
比如设计给了144 * 144（xxhdpi） 的icon, 如果不小心放到hdpi的资源目录下；
假如机器的dpi在320dpi ~ 480dpi之间（xxhdpi），则解码出来的bitmap是288 * 288的分辨率，；
如果刚好ImageView又是wrap_content设置的宽高，视觉上会比预期的翻了一番-_-。
言归正传，解码的过程为，通过获取图片的原始分辨率，结合Request的width和height, 以及ScaleType,
计算出最终要解码的宽高， 设置inDensity和inTargetDensity然后decode。
当然，有时候decode出来之后还要做一些加工，比方说ScaleType为CENTER_CROP而图片宽高又不相等，
则需要在decode之后进行裁剪，取出中间部分的像素。
关于ScaleType，Doodle是直接获取ImageView的ScaleType, 所以无需再特别调用函数指定；
当然也提供了指定ScaleType的API, 对于target不是ImageView时或许会用到。
fun scaleType(scaleType: ImageView.ScaleType)还有就是，解码阶段的压缩是向下采样的。
比如，如果原图只有100 100, 但是ImageView是200 200，最终也是解码出100 * 100的bitmap。
不过ImageView假如是CENTER_CROP或者FIX_XY等ScaleType，显示时通常会在渲染阶段自行缩放的。
如果确实就是需要200 * 200的分辨率，可以在解码后的变换（Transformation）阶段处理。
4.3.4 图片旋转
相信不少开发都遇到拍照后图片旋转的问题(尤其是三星的手机）。
网上有不少关于此问题的解析，这是其中一篇：关于图片EXIF信息中旋转参数Orientation的理解
Android SDK提供了ExifInterface 来获取Exif信息，Picasso正是用此API获取旋转参数的。
很可惜ExifInterface要到 API level 24 才支持通过InputStream构造对象，低于此版本，仅支持通过文件路径构造对象。
故此，Picasso当前版本仅在传入参数是文件路径（或者文件的Uri）时可处理旋转问题。
Glide自己实现了头部解析，主要是获取文件类型和exif旋转信息。
Doodle抽取了Glide的HeaderParse，并结合工程做了一些精简和代码优化, 嗯， 又一个“改装版”。
decode出bitmap之后，根据获取的旋转信息，调用setRotate和postScale进行对应的旋转和翻转，即可还原正确的显示。
4.3.5 变换
解码出bitmap之后，有时候还需要做一些处理，如圆形剪裁，圆角，滤镜等。
Picasso和Glide都提供了类似的API：Transformation
interface Transformation {
fun transform(source: Bitmap): Bitmap?
fun key(): String
}实现变换比较简单，实现Transformation接口，处理source，返回处理后的bitmap即可；
当然，还要在key()返回变换的标识，通常写变换的名称就好，如果有参数, 需拼接上参数。
Transformation也是决定bitmap长什么样的因素之一，所以需要重载key(), 作为Request的key的一部分。
Transformation可以设置多个，处理顺序会按照设置的先后顺序执行。
Doodle预置了三个常用的Transformation。
CircleTransformation：圆形剪裁，如果宽高不相等，会先取中间部分(类似CENTER_CROP)；
RoundedTransformation：圆角剪裁，可指定半径；
ResizeTransformation：大小调整，宽高缩放到指定大小。
需要指出的一点是, Request中指定大小之后并不总是能够解码出指定大小的bitmap,
如果原图分辨率小于指定大小，基于向下采样的策略，并不会主动缩放到指定的大小（前面有提到）。
若需要确定大小的bitmap, 可应用ResizeTransformation。
更多的变换，可以到glide-transformations寻找，
虽然不能直接导入引用， 但是处理方法是类似的，改造一下就可使用-_-
4.3.6 GIF图
GIF有静态的，也有动态的。
BitmapFactory支持解码GIF图片的第一帧，所以各个图片框架都支持GIF缩率图。
至于GIF动图，Picasso当前是不支持的，Glide支持，但据反馈有些GIF动图Glide显示不是很流畅。
Doodle本身也没有实现GIF动图的解码，但是留了拓展接口，结合第三方GIF解码库， 可实现GIF动图的加载和显示。
GIF解码库，推荐 android-gif-drawable。
具体用法：
在App启动时， 注入GIF解码的实现类（实现GifDecoder 接口）：
fun initApplication(context: Application) {
Doodle.init(context)
// ... 其他配置
.setGifDecoder(gifDecoder)
}
private val gifDecoder = object : GifDecoder {
override fun decode(bytes: ByteArray): Drawable {
return GifDrawable(bytes)
}
}使用时和加载到普通的ImageView没区别，如果图片源是GIF图片，会自动调用gifDecoder进行解码。
Doodle.load(url).into(gifImageView)当然也可以指定不需要显示动图， 调用asBitmap()方法即可。
4.3.7 图片复用
很多文章讲图片优化时都会提到两个点，压缩和图片复用。
Doodle在设计阶段也考虑了图片复用，并且也实现了，但实现后一直纠结其收益和成本-_-
- 1、正在使用的图片不能被复用，所以要添加引用计数策略，附加代码很多；
- 2、即使图片没有被引用，根据局部性原理，该图片可能稍后有可能被访问，所以也不应该马上被复用；
- 3、大多数情况下，符合复用条件(不用一段时间，尺寸符合要求）的并不多；
- 4、占用一些额外的计算资源。
最终，在看了帖子 picasso_vs_glide 之后，下决心移除了图片复用的代码。
以下该帖子中，Picasso的作者JakeWharton 的原话：
Slight correction here: "Glide reuses bitmaps period". Picasso does not at all. Nor do we have plans to. This is actually a performance optimization in some cases as we can retained cached images longer. It'd be nice to support both modes with programmer hints, but since ImageDecoder doesn't even support re-use I see no point to adding it.
Doodle定位是小而美的轻量级图片框架，过程中移除了不少价值不高的功能和复杂的实现。
有舍必有得，编程与生活，莫不如此。
4.4 线程调度
图片获取和解码都是耗时的操作，需放在异步执行；
而通常需要同时请求多张图片，故此，线程调度不可或缺。
Doodle的线程调度依赖于笔者的另一个项目Task, 具体内容详见：《如何实现一个线程调度框架》（又发了一波广告？-_-）。
简单的说，主要用到了Task的几个特性：
- 1、支持优先级;
- 2、支持生命周期（在Activity/Fragment销毁时取消任务）;
- 3、支持根据 Activity/Fragment 的显示/隐藏动态调整优先级;
- 4、支持任务去重。
关于任务去重，主要是以Request的key作为任务的tag, 相同tag的任务串行执行，
如此，当第一个任务完成，后面的任务读缓存即可，避免了重复计算。
对于网络图片源的任务，则以URL作为tag, 以免重复下载。
此外，线程池，在UI线程回调结果，在当前线程获取结果等操作，都能基于Task简单地实现。
4.5 Dispatcher
从Request，到开始解码，从解码完成，到显示图片， 之间不少零碎的处理。
把这些处理都放到一个类中，却不知道怎么命名了，且命名为Dispatcher吧。
都有哪些处理呢？
1、检查ImageView有没有绑定任务（启动任务后会将Request放入ImageView的tag中），
如果有，判断是否相同（根据请求的key）, 相同且前面的任务在执行，则取消之；2、启动任务前显示占位图（如果设置了的话）；
3、任务结束，如果任务失败，显示错误图片；
4、如果加载成功且设置了过渡动画，执行动画；
5、各种target的回调；
6、任务的暂停和开始。
其中，最后一点，在显示有大量数据源的RecycleView或者ListView时，
执行快速滑动时最好能暂停任务，停下来才恢复加载，这样能节省很多不必要的请求。
简而言之，Dispatcher有两个职责：
1、桥接的作用，连接外部于内部组件（有点像主板）；
2、处理结果的反馈（如图片的显示）。
五、回顾
第三章梳理了流程和架构；
第四章分解了各部分功能实现；
这一章我们做一下回顾和梳理。
5.1 依赖关系
先回顾一下图片框架的架构：
- Doodle作为框架的入口，提供全局参数配置（Config）以及单个图片的请求（Request）;
- Request被很多类所依赖，事实上，Request贯穿了整个请求过程。
添加功能时，一般也是从Request开始，添加变量和方法，然后在后面的流程中寻找注入点，插入控制代码，完成功能添加。 - Dispatcher和Worker是相互依赖的关系，表现为Dispatcher发起启动Worker, Worker将结果反馈给Dispatcher。
- Downloader给Source提供图片文件的InputStream, 图片下载的具体执行为Downloader中的OkHttpClient。、
整个框架以Doodle为起点，以Worker为核心，类之间调用不会太深， 总体上结构还是比较紧凑的。
了解这几个类，就基本上了解整个框架的构成了。
5.2 执行流
这一节，我们结合各个核心类，再次梳理一下执行流程：
上图依然是简化版的执行流，但弄清楚了基本流程，其他细枝末节的流程也都好理解了。
1、图片加载流程，从框架的Doodle.load()开始，返回Request对象；
object Doodle {
fun load(path: String): Request {
return Request(path)
}
}2、封装Request参数之后，以into收尾，由Dispatcher启动请求；
class Request {
fun into(target: ImageView?)
fillSizeAndLoad(viewWidth, viewHeight)
}
private fun fillSizeAndLoad(targetWidth: Int, targetHeight: Int) {
Dispatcher.start(this)
}
}3、先尝试从内存缓存获取bitmap, 无则开启异步请求
internal object Dispatcher {
fun start(request: Request?) {
val bitmap = MemoryCache.getBitmap(request.key)
if (bitmap == null) {
val loader = Worker(request, imageView)
loader.priority(request.priority)
.hostHash(request.hostHash)
.execute()
}
}
}4、核心的工作都在Worker中执行，包括获取文件（解析，下载），解码，变换，及缓存图片等
internal class Worker(private val request: Request, imageView: ImageView?) : UITask<Void, Void, Any>() {
private var fromMemory = false
private var fromDiskCache = false
override fun doInBackground(vararg params: Void): Any? {
var bitmap: Bitmap? = null
var source: Source? = null
try {
bitmap = MemoryCache.getBitmap(key) // 检查内存缓存
if (bitmap == null) {
val filePath = DiskCache[key] // 检查磁盘缓存（结果缓存）
fromDiskCache = !TextUtils.isEmpty(filePath)
source = if (fromDiskCache) Source.valueOf(File(filePath!!)) else Source.parse(request) // 解析
bitmap = Decoder.decode(source, request, fromDiskCache) // 解码
bitmap = transform(request, bitmap) // 变换
if (bitmap != null) {
if (request.memoryCacheStrategy != MemoryCacheStrategy.NONE) {
val toWeakCache = request.memoryCacheStrategy == MemoryCacheStrategy.WEAK
MemoryCache.putBitmap(key, bitmap, toWeakCache) // 缓存到内存
}
if (!fromDiskCache && request.diskCacheStrategy and DiskCacheStrategy.RESULT != 0) {
storeResult(key, bitmap) // 缓存到磁盘
}
}
}
return bitmap
} catch (e: Throwable) {
LogProxy.e(TAG, e)
} finally {
Utils.closeQuietly(source)
}
return null
}
override fun onPostExecute(result: Any?) {
val imageView = target
if (imageView != null) {
imageView.tag = null
}
// 显示结果
Dispatcher.feedback(request, imageView, result, false)
}
}以上代码中，有两点需要提一下：
- Dispatcher启动Worker之前已经检查内存缓存了，为什么Worker中又检查一次？
因为可能存在多个请求的bitmap是相同的（key所决定），只是target不同，然后Worker会串行执行这些请求；
当第一个请求结束，图片已经放到内存缓存了，接下来的请求可以从内存缓存中直接获取bitmap,无需再次解码。
- 为什么没有看到Downloader下载文件？
Downloader出现在Source.parse(request)方法中，主要是返回一个InputStream;
文件的下载过程在发生在Decoder.decode()方法中，边下载边解码。
5、回归Dispatcher, 刷新ImageView
internal object Dispatcher {
fun feedback(request: Request, imageView: ImageView? ...) {
if (bitmap != null) {
imageView.setImageBitmap(bitmap)
}
}
}六、API
前面说了这么多实现细节，那到底最终都实现了些什么功能呢？
看有什么功能，看接口层的三个类就可以了。
6.1 Doodle (框架入口）
| 方法 | 作用 |
|---|---|
| init(Context) : Config | 初始化，传入context, 返回全局配置 |
| trimMemory(int) | 整理内存(LruCache)，传入ComponentCallbacks2的不同level有不同的策略 |
| clearMemory() | 移除LruCache中所有bitmap |
| load(String): Request | 传入图片路径，返回Request |
| load(int): Request | 传入资源ID，返回Request |
| load(Uri): Request | 传入URI，返回Request |
| downloadOnly(String): File? | 仅下载图片文件，不解码。此方法会走网络请求，不可再UI线程调用 |
| getSourceCacheFile(url: String): File? | 获取原图缓存，无则返回null。不走网络请求，可以在UI线程调用 |
| cacheBitmap(String,Bitmap,Boolean) | 缓存bitmap到Doodle的MemoryCache, 相当于开放MemoryCache, 复用代码，统一管理。 |
| getCacheBitmap(String): Bitmap? | 获取缓存在Cache中的bitmap |
| pauseRequest() | 暂停往任务队列中插入请求，对RecycleView快速滑动等场景，可调用此函数 |
| resumeRequest() | 恢复请求 |
| notifyEvent(Any, int) | 发送页面生命周期事件(通知页面销毁以取消请求等） |
6.2 Config （全局配置）
| 方法 | 作用 |
|---|---|
| setUserAgent(String) | 设置User-Agent头，网络请求将自动填上此Header |
| setDiskCachePath(String) | 设置结果缓存的存储路径 |
| setDiskCacheCapacity(Long) | 设置结果缓存的容量 |
| setDiskCacheMaxAge(Long) | 设置结果缓存的最大保留时间（从最近一次访问算起），默认30天 |
| setSourceCacheCapacity(Long) | 设置原图缓存的容量 |
| setMemoryCacheCapacity(Long) | 设置内存缓存的容量，默认为maxMemory的1/6 |
| setCompressFormat(Bitmap.CompressFormat) | 设置结果缓存的压缩格式， 默认为PNG |
| setDefaultBitmapConfig(Bitmap.Config) | 设置默认的Bitmap.Config，默认为ARGB_8888 |
| setGifDecoder(GifDecoder) | 设置GIF解码器 |
6.3 Request （图片请求）
| 方法 | 作用 |
|---|---|
| sourceKey(String) | 设置数据源的key url默认情况下作为Request的key的一部分，有时候url有动态的参数，使得url频繁变化，从而无法缓存。此时可以设置sourceKey,提到path作为Request的key的一部分。 |
| override(int, int) | 指定剪裁大小 并不最终bitmap等大小并不一定等于override指定的大小（优先按照 ScaleType剪裁，向下采样），若需确切大小的bitmap可配合ResizeTransformation实现。 |
| scaleType(ImageView.ScaleType) | 指定缩放类型 如果target为ImageView则会自动从ImageView获取。 |
| memoryCacheStrategy(int) | 设置内存缓存策略，默认LRU策略 |
| diskCacheStrategy(int) | 设置磁盘缓存策略，默认ALL |
| noCache() | 不做任何缓存，包括磁盘缓存和内存缓存 |
| onlyIfCached(boolean) | 指定网络请求是否只从缓存读取（原图缓存） |
| noClip() | 直接解码，不做剪裁和压缩 |
| config(Bitmap.Config) | 指定单个请求的Bitmap.Config |
| transform(Transformation) | 设置解码后的图片变换，可以连续调用（会按顺序执行） |
| priority(int) | 请求优先级 |
| keepOriginalDrawable() | 默认情况下请求开始会先清空ImageView之前的Drawable, 调用此方法后会保留之前的Drawable |
| placeholder(int) | 设置占位图，在结果加载完成之前会显示此drawable |
| placeholder(Drawable) | 同上 |
| error(int) | 设置加载失败后的占位图 |
| error(Drawable) | 同上 |
| goneIfMiss() | 加载失败后imageView.visibility = View.GONE |
| animation(int) | 设置加载成功后的过渡动画 |
| animation(Animation) | 同上 |
| fadeIn(int) | 加载成功后显示淡入动画 |
| crossFate(int) | 这个动画效果是原图从透明度100到0， bitmap从0到100。 当设置placeholder且内存缓存中没有指定图片时， placeholder为原图。 如果没有设置placeholder, 效果和fadeIn差不多。 需要注意的是，这个动画在原图和bitmap宽高不相等时，动画结束时图片会变形。 因此，慎用crossFade。 |
| alwaysAnimation(Boolean) | 默认情况下仅在图片是从磁盘或者网络加载出来时才做动画，可通过此方法设置总是做动画 |
| asBitmap() | 当设置了GifDecoder时，默认情况下只要图片是GIF图片，则用GifDecoder解码。调用此方法后，只取Gif文件第一帧，返回bitmap |
| host(Any) | 参加Task的host |
| cacheInterceptor(CacheInterceptor) | (原图）缓存拦截器，可自定义单个请求的缓存路径，自己管理缓存，以免被LRU或者过时规则删除 |
| preLoad() | 预加载 |
| get(int) : Bitmap? | 当前线程获取图片，加载时阻塞当前线程, 可设定timeout时间(默认3s)，超时未完成则取消任务，返回null。 |
| into(SimpleTarget) | 加载图片后通过SimpleTarget回调图片(加载是不阻塞当前线程) |
| into(ImageView, Callback) | 加载图片图片到ImageView，同时通过Callback回调。如果Callback中返回true, 说明已经处理该bitmap了，则Doodle不会再setBitmap到ImageView了。 |
| into(ImageView?) | 加载图片图片到ImageView |
七、总结
本文从架构，流程等方面入手，详细分析了图片加载框架的各种实现细节。
从文中可以看出，实现过程大量借鉴了Glide和Picasso, 在此对Glide和Picasso的开源工作者表示敬意和感谢。
这里就不做太详细的对比了，这里只比较下方法数和包大小（功能和性能不太好比较）。
| 框架 | 版本 | 方法数 | 包大小 |
|---|---|---|---|
| Glide | 4.8.0 | 3193 | 691k |
| Picasso | 2.71828 | 527 | 119k |
| Doodle | 1.0.8 | 419 | 100k |
Doodle先是用Java写的，后面用Kotlin改写，方法数从200多增加到400多，包大小从60多K增加到100K，真是作啊-_-
Picasso的版本停在2.71828（自然对数e≈2.71828, 刚开始还以为作者弃疗了~）好久了，说要出Picasso 3, 但是时间过去N久了也没见影；
从完备度和稳定性而言，Glide都要优于Picasso，毕竟一直有大量的反馈以及持续的维护。
Doodle在完备度上是不输Picasso的，并且相对前二者有一些微创新；
但毕竟是新项目，一个人的力量有限，必然会有不足的地方。
感兴趣的读者可以参与进来，欢迎提建议和提代码。
项目已发布到jcenter和github, 项目地址：https://github.com/No89757/Doodle
看多遍不如跑一遍，可以Download下来运行一下，会比看文章有更多的收获。
