如何实现一个图片加载框架
一、前言
图片加载的轮子有很多了,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下来运行一下,会比看文章有更多的收获。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
应用加密1;非对称加密算法揭秘
非对称加密算法 使用过程: 乙方生成两把密钥(公钥和私钥) 甲方获取乙方的公钥,然后用它对信息加密。 乙方得到加密后的信息,用私钥解密,乙方也可用私钥加密字符串 甲方获取乙方私钥加密数据,用公钥解密 优点: 更安全,密钥越长,它就越难破解 缺点: 加密速度慢 常用算法: RSA、Elgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法) 非对称加密方法 1公钥私钥的使用原则 ①每一个公钥都对应一个私钥。 ②密钥对中,让大家都知道的是公钥,不告诉大家,只有自己知道的,是私钥。 ③如果用其中一个密钥加密数据,则只有对应的那个密钥才可以解密。 ④如果用其中一个密钥可以进行解密数据,则该数据必然是对应的那个密钥进行的加密。 非对称密钥密码的主要应用就是公钥加密和公钥认证。 2公钥加密、解密 加密的目的,是不希望第三者看到当前两个通讯用户的通讯内容。 2.1加密 A(客户)想给B(服务器)发送一段文字,但是不想让别人看到,因此想使用非对称加密方法来加密这段文字,当然,B需要有一对公钥和私钥: ① B将他的公钥发送给A ② A用B给他的公钥加密这段文字,然后传给B ③ B用他的私钥解...
- 下一篇
加强版异步任务框架
一、前言 为了提高流畅性,耗时任务放后台线程运行,已是APP开发的常识了。关于异步有很多方案,当前最流行的,莫过于RxJava了;更早一些时候,还有AsyncTask(骨灰级的API)。 总的来说,AsyncTask构思精巧,代码简洁,使用方便,有不少地方值得借鉴。当然问题也有不少,比如不能随Activity销毁而销毁导致的内存泄漏,还有不适合做长时间的任务等。 笔者以AsyncTask为范本,写了一个“加强版的异步任务框架”:保留了AsyncTask的所有用法,解决了其中的一些问题,同时引入了一些新特性。接下来给大家介绍一下这“加强版”的框架,希望对各位有所启发。 二、任务调度 2.1 AsyncTask的Executor AsyncTask的任务调度主要依赖两个Executor:ThreadPoolExecutor 和 SerialExecutor。代码如下: private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors(); private static final int CORE_P...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果