正文  软件开发 > iphone开发 iOS开发 >

总结iOS开发中的断点续传那些事儿,ios断点续传

总结iOS开发中的断点续传那些事儿,ios断点续传 前言 断点续传概述 断点续传就是从文件赏赐中断的地方重新开始下载或者上传数据,而不是从头文件开始。当下载大文件的时候,如果没有实现断点续传功能...

总结iOS开发中的断点续传那些事儿,ios断点续传

前言

断点续传概述

断点续传就是从文件赏赐中断的地方重新开始下载或者上传数据,而不是从头文件开始。当下载大文件的时候,如果没有实现断点续传功能,那么每次出现异常或者用户主动的暂停,都会从头下载,这样很浪费时间有木有。所以呢,项目中实现大文件下载的时候,断点续传功能是必不可少了。当然咯,断点续传有一种特殊的情况,就是我们的应用呗用户kill掉或者应用crash,要实现应用重启之后的断点续传,这种情况就是我们将要解决的问题。

断点续传的原理

要实现断点续传,服务器必须是要支持的。目前最常见的两种方式:FTPHTTP

下面来简单介绍HTTP断点续传的原理。

HTTP

通过HTTP,可以非常方便的实现断点续传。断点续传主要依赖于HTTP头部定义的Range,应用可以通过HTTP请求曾经获取失败的资源的某一个返回或者部分来恢复下载该资源。当然并不是所有风服务器都支持Range,所以不支持Range的不在我们考虑之内。Range是以字节计算的,请求的时候不比给我结尾字节数,因为请求方并不一定知道资源的大小。
通过这个关键字可以告诉服务器返回哪些数据给我。
比如:
bytes=500-999 表示第500-第999字节
bytes=500- 表示从第500字节往后的所有字节
然后我们再根据服务器返回的数据,将得到的data数据拼接到文件后面,就可以实现断点续传了。

断点续传分析—AFHTTPRequestOperation

在了解了断点续传的原理之后,我们就可以动手来实现iOS中的断点续传了。由于我现在接触到的项目都是部署在HTTP服务器上的,所以断点续传功能也基于HTTP实现。首先我们来最简单的入手,第三方神奇AFNetworking中提供的实现,下面请看详细代码:

 //1.指定下载文件的地址URLString
 //2.获取保存的文件路径filePath
 //3.获得NSURLRquest
    NSString* URLString = @"";
    NSString* filePath = @"";

    NSURLRequest* request = [NSURLRequest requestWithURL:[NSURL URLWithString:URLString]];
    signed long long downloadBytes = 0;
    ([[NSFileManager defaultManager] fileExistsAtPath:filePath]) {
        // 3.1 若之前下载过 , 则在 HTTP 请求头部加入 Range
        // 获取已下载文件的 size
        downloadedBytes = [self fileSizeForPath:filePath];

        // 验证是否下载过文件
        if (downloadedBytes > 0) {
            // 若下载过 , 断点续传的时候修改 HTTP 头部部分的 Range
            NSMutableURLRequest *mutableURLRequest = [request mutableCopy];
            NSString *requestRange =
            [NSString stringWithFormat:@"bytes=%llu-", downloadedBytes];
            [mutableURLRequest setValue:requestRange forHTTPHeaderField:@"Range"];
            request = mutableURLRequest;
        }
    }

    // 4 创建 AFHTTPRequestOperation
    AFHTTPRequestOperation *operation
    = [[AFHTTPRequestOperation alloc] initWithRequest:request];

    // 5 设置操作输出流 , 保存在第 2 步的文件中
    operation.outputStream = [NSOutputStream
                              outputStreamToFileAtPath:filePath append:YES];

    // 6 设置下载进度处理 block
    [operation setDownloadProgressBlock:^(NSUInteger bytesRead,
                                          long long totalBytesRead, long long totalBytesExpectedToRead) {
        // bytesRead 当前读取的字节数
        // totalBytesRead 读取的总字节数 , 包含断点续传之前的
        // totalBytesExpectedToRead 文件总大小
    }]; 

    // 7 设置 success 和 failure 处理 block 
    [operation setCompletionBlockWithSuccess:^(
                                               AFHTTPRequestOperation *operation,
                                               id responseObject) {


    }                                failure:^(AFHTTPRequestOperation *operation,
                                               NSError *error) {

    }];

    // 8 启动 operation
    [operation start];

使用以上代码 , 断点续传功能就实现了,应用重新启动或者出现异常情况下 , 都可以基于已经下载的部分开始继续下载。关键的地方就是把已经下载的数据持久化。接下来简单看下AFHTTPRequestOperation是怎么实现的。通过查看源码 , 我们发现 AFHTTPRequestOperation 继承自 AFURLConnectionOperation,而AFURLConnectionOperation 实现了 NSURLConnectionDataDelegate 协议。

处理流程如图所示:

可以看到,这里的AFNetworking采取自线程调一步接口的方式,是因为直接在主线程调用异步接口会有一个Runloop的问题。当主线程调用[[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:YES]时,请求发出之后的监听任务会加到主线程中的Runloop中,我们知道RunloopMode默认为NSDefuaultRunloopMode,这个表示只有当前线程的Runloop处理NSDefaultRunloopMode时,这个任务才会执行。而当用户正在滚动tableview和scrollview的时候,主线程的Runloop处于NSEventTrackingRunloop模式下,就不会执行NSDefaultRunloopMode的任务。

另外由于采取子线程调用接口的方式,所以这边的DownloadProgressBlock,success 和 failure Block 都需要回到主线程来处理。

断点续传实战

NSURLConnecttion的实现

NSURLConnecttion这家伙已经在2015年就已经被苹果遗弃,所以在这里我们不做过多讨论,请注意啊,我是省略号……

NSURLSessionDataTask

苹果在iOS7开始,推出一个新的类NSURLSession,它具备了NSURLConnection所具备的方法,并且更加强大。所以我更加推荐大家使用这个类去实现下载和续传。NSURLConnection 和 NSURLSession delegate 方法的映射关系 , 如下图所示。所以关键是要满足 NSURLSessionDataDelegate 和 NSURLsessionTaskDelegate。

文件下载和暂停的实现

当使用NSURLSessionDownloadTask进行下载的时候,系统会在cache文件夹下创建一个下载的路径,路径下会有一个以”CFNetworking”打头的.tmp文件(以下简称”下载文件”防止混淆),这个就是我们正在下载中的文件。而当我们调用了cancelByProducingResumeData:方法后,会得到一个data文件,通过String格式化后,发现是一个XML文件,里面包含了关于.tmp文件的一些关键点的描述,包括”Range”,”key”,”下载文件的路径”等等.而原本存在于download文件下的下载文件,则被移动到了系统tmp文件夹目录下.而当我们再次进行resume操作的时候,下载文件则又被移回到了download文件夹下。

程序被杀掉的断点续传resumeData

根据上面的分析,基本可以得到以下结论:

  • DownloadTask每次进行断点续传的时候,会根据data文件中的”路径Key”去寻找下载文件,然后校验后再根据”Range”属性去进行断点续传。

  • download文件夹中存放的只会是下载中的文件,一旦暂停就会被移动到tmp文件夹下。

  • 每个暂停得到的data文件,与下载文件一一对应。

  • 断点续传只与tmp文件夹中的文件有关。

所以我们可以这么做,设置一个Bool变量用来判断是否正在下载中,同时用一个周期事件每隔一段时间暂停一次。然后保存data文件和拷贝tmp文件夹下的下载文件到安全目录下(因为tmp文件夹据说随时可能清空)。
当再次下载的时候,先是从安全目录下取到下载文件,删除tmp文件夹中原有的同名文件,然后copy到tmp目录下,最后利用保存的data文件进行再次downloadTaskWithResumeData操作,就可以实现再次下载了。

原文链接:总结iOS开发中的断点续传那些事儿