Kingfisher源码解析之ImagePrefetcher

Kingfisher源码解析系列,由于水平有限,哪里有错,肯请不吝赐教

ImagePrefetcher提供了哪些功能

ImagePrefetcher是Kingfisher提供预加载功能的一个类,提供了一下功能

  • start():开启预加载
  • stop():停止预加载
  • maxConcurrentDownloads:设置最大缓存并发量
  • progressBlock和progressSourceBlock:缓存进度的回调
  • completionHandler和completionSourceHandler:缓存结束的回调

ImagePrefetcher预加载的流程图

预加载的流程图

ImagePrefetcher两个问题

当调用stop()函数之后的逻辑

先来看下stop函数的实现,实现比较简单,在预加载的队列里异步的执行把标志位stopped设置为true,并且取消当前所有未完成的下载任务,看起来很简单。

public func stop() {
    pretchQueue.async {
        if self.finished { return }
        self.stopped = true
        self.tasks.values.forEach { $0.cancel() }
    }
}

但是stopped这个标志位只在网络请求结束的回调里去判断了,这就会发生一些歧义,交给读者去判断Kingfisher这么做是否是合理的?当调用stop函数时,会出现以下几种情况以及对应的结果

  1. 调用stop时,已经预加载结束了,由于已经结束,会直接返回
  2. 调用stop时,现在已经有正在下载图片的任务了,会取消所所有请求,然后请求就会走结束的回调,在结束的回调里把剩下的未加载的数据放入到失败的数据源的数组中,调用结束回调
  3. 调用stop时,还没有正在下载的任务,会继续预加载数据,直到结束,或者有一个请求结束

对于情况1和情况2都是合理的,并且是绝大部分都会是情况1和情况2,对于情况3,调用stop时并没有真正的去停止,但是这种情况也是较少出现的。

对于stop方法,喵神的注释是这样的

/// Stops current downloading progress, and cancel any future prefetching activity that might be occuring.

缓存进度和缓存结束的回调为什么要各有2个

我第一次看代码,就想为什么要有2个呢?为什么这么设计呢?这里以缓存进度的回调举例,它们两个的原因是一样的。先来看下定义,

public typealias PrefetcherProgressBlock =
    ((_ skippedResources: [Resource], _ failedResources: [Resource], _ completedResources: [Resource]) -> Void)

public typealias PrefetcherSourceProgressBlock =
    ((_ skippedSources: [Source], _ failedSources: [Source], _ completedSources: [Source]) -> Void)

我们发现基本是一样的,只是回调里的参数类型不一样,一个Resource,另一个Source。如果你对这2个类型比较了解,想必你应该能猜到这么设计的原因了。

Source是一个枚举,Kingfisher中为UIImage提供数据源用的,定义如下,有2个case,一个是关联了Resource,另一个关联了ImageDataProvider

public enum Source {
    case network(Resource)
    case provider(ImageDataProvider)
}

Resource是一个协议,定义如下,提供数据源的真正类型之一,一般用于加载网络图片

public protocol Resource {
    var cacheKey: String { get }
    var downloadURL: URL { get }
}

ImageDataProvider也是一个协议,定义如下,提供数据源的另一个真正类型,一般用于本地图片

public protocol ImageDataProvider {
    var cacheKey: String { get }
    func data(handler: @escaping (Result<Data, Error>) -> Void)
}

回答上面的问题,由于我们一般情况下预加载的都是网络图片,因此提供一个方便我们使用的回调,但为了覆盖到所有情况,就提供了2个情况的回调,这个在ImagePrefetcher的便利初始化方法里我们就能看出来,当使用[URL](注:在URL的扩展里实现了Resource协议)或者[Resource]初始化的时候,就使用PrefetcherProgressBlock,当使用[Source]初始化时,就使用的PrefetcherSourceProgressBlock

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,560评论 4 361
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,104评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,297评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,869评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,275评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,563评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,833评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,543评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,245评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,512评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,011评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,359评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,006评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,062评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,825评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,590评论 2 273
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,501评论 2 268

推荐阅读更多精彩内容