iOS_多线程下载 && 断点续传


源码地址

分析技术选取方案

多线程下载

GCD和OpeationQueue:都是iOS提供的十分方便的多线程实现方案,GCD使用起来方便简单,但是由于可控性较差,反而不如OperationQueue和Operation的组合可定制性更强。

断点续传

NSURLSessionDownloadTask和NSURLSessionDataTask:都可实现断点续传,downloadTask会由系统在下载时在temp文件下生成临时文件,并且返还resumeData供断点续传,但由于temp文件下内容随时会被系统清理掉,且在大文件时存在问题,所以采用dataTask,用http的“Range”字段进行断点续传控制。

结构设计

1.类划分

(1).对于每一个下载链接来说都是一个任务,可以抽象成一个任务模型,DownLoadModel。
(2).下载的具体执行者,由于确定方案是采用operation和operationQueue的方案,则需要重写Operation,完成自己的定制,即具体的下载执行者,DownloadOperation。
(3).下载下来的内容需要存储在本地,并且在每次续传下载时根据存储的数据和源文件大小比对校正后再去续传,防止意外导致的文件损坏,和记录的导致不一致。即存储每次的下载模型和文件管理,FileHelper和DownloadStore>
(4).下载管理中心,提供多线程下载和断点续传的管理入口,并把其余各对象结合起来。
即简单确定下来基本的类:
YHFileDownLoadManager:下载管理中心
YHFileDownLoadModel :下载任务模型
YHFileDownLoadOperation:下载动作具体执行者
YHFileHelper:文件帮助类
YHFileDownloadStore:数据库存储类
借助第三方:
YTKKeyValueStore:用于数据库存储
YYModel:模型和Json的转化

2.功能结构设计

Manager职责:
根据URL和存储目录生成任务模型;判断该任务是否存在;判断存储目录是否存在,不存在则创建;把任务加载到下载队列等待执行;控制任务执行动作:开始,下载,暂停,取消等;存储任务状态到数据库当应用退出或对象销毁时;每次启动时获取上次未完成的下载任务信息。
Model职责:
存储任务的信息,并提供任务的唯一标示,sigleID。
Operation职责:
进行下载或断点续传;每次下载前校正已下载数据大小,维护任务的下载状态。
FileHelper:
文件是否存在与创建;文件夹是否存在与创建;获取文件大小。
Store职责:
将任务模型以键值对的存储方式在数据库表内。

重点事项:

(1).模型的状态维护:模型当前的状态应该是唯一的,即模型的状态改变需要注意,稍不注意就有可能因为多处改动而造成混论,所以:本人在此采用了数组来维护任务模型,其余地方则都是从该数组内获取的对象的引用,并且模型状态的改变除了创建时的初始状态外,改变只交给了Operation,根据下载的变化来调整模型状态。
(2).Operation的重写:
继承自系统的Operation,重写时需注意维护几个变量的状态:executing,finished,cancelled,分别对应了是否正在执行,是否完成,是否取消。因为当opeartion提交到queue中后,什么时候开始执行是有系统决定的,而系统是否启动当前任务,暂停当前任务,取消当前任务以及结束当前任务调取下一任务进入队列,则都是由内部几个变量来进行维护的,系统在每次执行任务时,都会去访问这些变量的值以决定下一步动作,所以,要做好这些状态值的维护(没办法,重写了当然是由自己去维护了。。)

完结

说了这么多,怎么没见代码,show me your code。。。额,重点是分析设计,其次才是代码实现(其实是懒),详细代码实现参见文章开头地址链接,demo示例是在工程的DownloadViewController。
注:在示例demo内:下载任务加进去并没有立刻开始执行,而是处于等待状态,需要自己点击开始执行,并且此下载中心只维护了未完成的下载任务,包括:下载中,等待,开始,失败,暂停等,而完成的任务则会在完成时抛出给你,不在此维护范围之内。demo若需重复观看,最好在下载完成时清理已经下载好的文件,否则在下载队列开始下载时,若发现本地已经有下载好的一份,会瞬间100%已完成。

思考

本人对这个多线程下载&&断点续传尚存在一些可以优化的疑问?有大神知道望不吝赐教,即在创建下载任务时,我是每一个dataTask创建了一个session,这样有多个task就会有多个session,本人认为这点是不合理的,connnection是这样的没问题,但是session是会话,一个session应该可以对应多个task的,但是我看了文档,说是多个task对应一个session将会共用一个delegate,每个task都会有一个taskIdentifier标识,那么按照我的设计实现,在任务对象关联下载执行者时处理就不是最优的,望大神看下源码给个建议,这点略有些晕,还请指点迷津,本人也会继续考虑这个问题。


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

推荐阅读更多精彩内容