分析AFN主要设计思路 - 强干弱枝
至于源码,此文章只从零到一探讨了解方法,先主干,再脉络,再再细枝一步步细化,为了尽可能细节阐述思想,案例采用OC展示
破题 - 展示一张图片




更直接一些,set一张高清图片
一样加载出来高清图片展示,那么 setImageWithURL 究竟做了什么,这是目前需要探究的入口
如果目前自己设计一个图片下载展示工具,会设计成什么样子?可以做个猜想,简单推想一下
缓存空间管理
管理缓存 需要对图片进一步封装处理
manager,管理增删查改,如何对缓存进行更新
如果多次请求都发生,要实现复用,又该如何响应
不妨简单模拟一个流程先

根据大致的猜想流程,转变为代码还有一段距离。
缓存的存储设计实现,包括缓存的管理? 相同请求复用队列设计实现,一个请求,响应多个源? 相同url,不同图片,如何做到更新?
相信只要解决以上问题,一个相对标准化的图片请求加载器就算完成了!
入手源码开始


根据入口源码调用,结合之前的猜想,得到一些信息:
1.缓存管理通过下载器获取,并非设计成独立的缓存中心
2.出现了Task类,也就是设计了任务的概念
3.缓存图片通过NSURLRequest 来获取,request里存储了一些不变的信息来定位缓存图片
读取cache逻辑

同时清除干净下载请求信息



下载器是通过关联对象 or 单例获取,而缓存通过下载器拿到,这就保障了实时操作同一份缓存空间,达到了缓存的目的
查看缓存的操作方法有哪些

下载器逻辑



1.因为缓存不可能无限制存放,过期需要删除,删除需要有先后,删除较旧的,保留较新的;
2.请求数量也不是无节制的,不同步处理,没办法保障最大请求数限制
通过url作为唯一标识,标识相同的请求,从 mergedTasks字典中根据标识取出task,新创建response handler,并添加到task中的responseHandlers数组里,此时可以看出task是对NSURLSessionDataTask 的封装处理,额外添加了标识信息,responseHandlers信息


1.封装NSURLSessionDataTask ---> AFImageDownloaderMergedTask:mergedTask
2.新创建responsehandler
3.添加 新创建的responsehandler 到 mergedTask中的 responseHandlers数组里
以下查看 NSURLSessionDataTask 创建逻辑,看AFNetworkSessionManager 做了哪些处理



一个个delegate通过 task存储到字典里, 溯源通过字典获取delegate,继而拿到task,通过task回调 uploadProgress downloadedProgress


目前为止,代码一层层探查得差不多了,但只是取值赋值,具体task handler回调怎么个进行,貌似中断了,别忘了,ios动态特性






Foundation - NSURLSessionDownloadDelegate回调
[task resume] 之后,剩下的NSURLSession 执行网络底层逻辑






简单总结下回调流程

网络下载完成,回到cache处理

1.清除task

2.缓存下载下来的图片

3.回调返回数据

缓存图片

已图片缓存容量超过偏好设置容量 处理(⚠️ 缓存图片不能删除半张)

图片大小获取

网友评论