總結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開發中的斷點續傳那些事兒
