关于iOS的后台下载和断点续传，说一说自己的理解(二，接上篇)

因为上一篇有一些细节还是没有说透，特别是断点续传这里，继续和大家聊一聊这里面的问题。
1. 关于resumedata的bug, 目前苹果在10.2中已经解决了，也就是说做适配的同学只需要额外考虑10.x和10.1.x版本。
2. 对于程序被用户手动kill和因代码原因触发的crash，后台下载恢复的行为是不同的（当然，恢复的行为都是基于同一id的backgroundsession）：
a.用户手动kill的情况下，我们在应用再次起来时会收到didcompletewitherror的回调，在这里可以获取到resumedata用来恢复下载;
b.代码原因触发crash的情况下，应用再次起来后之前的任务会基于backgroundsession自动继续下载，不需要我们来恢复。
3. 对于原有的任务，不管是因为什么原因暂停，我们都希望能够知道它的总大小和已下载的大小。resumedata获取到已下载大小的代码：

        NSData *resumeData = self.resumeDataDic[urlString];
        NSDictionary *resumeDictionary = [NSPropertyListSerialization propertyListWithData:resumeData options:NSPropertyListImmutable format:NULL error:nil];
        NSNumber *bytesReceived = resumeDictionary[@"NSURLSessionResumeBytesReceived"];

对于手动kill和应用crash的情况，我们都需要考虑覆盖他们的场景以保证任务可以有继续下载的能力，并且应用在未恢复下载时也能看到相关的进度。要实现所说的效果，我们务必要对相关的size信息进行持久化。
如果仅考虑手动kill的情况，在applicationWillTerminate里面持久化少量信息不失为一个可行的方案；但在代码触发的crash场景下，该代理不会被调用。因此我们需要考虑需要save的点并兼顾效率，进行持久化。

从上面的表格来看，要覆盖表格里的场景，在terminate和pause的时候均需要进行持久化动作。

1. 除了上面这些主要问题以外，我们还需要熟知各个代理方法在不同场景下的回调执行情况和时序问题，从而处理相关的信息保存和恢复。具体的细节大家感兴趣的可以实现一个demo自行研究。

PS:关于此问题，笔者正在封装一个框架，目标是让开发者在无需介入系统实现细节的情况下，高效、强大的完成后台下载和断点续传的工作，敬请期待。

附(resumedata结构，摘自stackoverflow):
actually, the resume data is a plist file. it contains the follows key:

NSURLSessionDownloadURL
NSURLSessionResumeBytesReceived
NSURLSessionResumeCurrentRequest
NSURLSessionResumeEntityTag
NSURLSessionResumeInfoTempFileName
NSURLSessionResumeInfoVersion
NSURLSessionResumeOriginalRequest

NSURLSessionResumeServerDownloadDate so the steps u need to do are:
    check the data is a valid plist;
    check the plist have keys as above;
    check the temp file is exist;