總結iOS開發中的斷點續傳那些事兒

前言斷點續傳概述斷點續傳就是從文件賞賜中斷的地方重新開始下載或者上傳數據，而不是從頭文件開始。當下載大文件的 ...

前言

斷點續傳概述

斷點續傳就是從文件賞賜中斷的地方重新開始下載或者上傳數據，而不是從頭文件開始。當下載大文件的時候，如果沒有實現斷點續傳功能，那麼每次出現異常或者用戶主動的暫停，都會從頭下載，這樣很浪費時間有木有。所以呢，項目中實現大文件下載的時候，斷點續傳功能是必不可少了。當然咯，斷點續傳有一種特殊的情況，就是我們的應用唄用戶kill掉或者應用crash，要實現應用重啟之後的斷點續傳，這種情況就是我們將要解決的問題。

斷點續傳的原理

要實現斷點續傳，伺服器必須是要支持的。目前最常見的兩種方式：FTP和HTTP。

下麵來簡單介紹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開發中的斷點續傳那些事兒