在我們?nèi)粘ｉ_發(fā)的過程中，我們的項目中可能都會遇到一個需求就是去下載一個文件，然后將文件保存到本地，但是在下載的過程中一定是異步的，也就是說我們可能會有其它的操作，這個時候可能我們的程序會遇到一些意外造成閃退的問題亦或是用戶在下載中用戶就退出了程序，如果用戶下次進入程序的時候就需要重新進行下載那么一定會造成極差的用戶體驗，所以我們一定需要知道用戶下載的進度。

最近我們的項目中就在做相關(guān)的問題，官方文檔上NSUrlSessionDownloadTask章節(jié)中沒有找到我想要的方案，于是我百度了一下相關(guān)的答案，找到的一個稍微有點用的方案竟然是創(chuàng)建一個輪詢的timer，間隔一段時間在異步線程中將程序暫停獲取到數(shù)據(jù)后存儲到本地，這樣就能保證用戶最多只是小部分?jǐn)?shù)據(jù)的丟失，但是在我看來這樣的方案一定是極差的。因為每次暫停文件的轉(zhuǎn)移都需要花費大量的時間，然后再去resume下載任務(wù)肯定不合理。我就去嘗試了一下愛奇藝的電影的下載，我發(fā)現(xiàn)愛奇藝可以做到后臺看到的下載進度，在后臺殺死后，再開啟從上次進度繼續(xù)下載，于是我就很好奇他們的實現(xiàn)方案。

當(dāng)時我想到一種方案是利用Application中- (void)applicationWillTerminate:(UIApplication*)application通知，在每次程序?qū)⒁粴⑺赖臅r候如果有正在下載的任務(wù)將之暫停然后進行下載，為此我專門去看了對應(yīng)的官方文檔，在這個方法中我們可以做一些數(shù)據(jù)釋放和數(shù)據(jù)保存相關(guān)的操作而且有將近5秒的操作時間，其實這個時候還是一個問題就是文檔上說如果用戶是在后臺殺死程序的話這個方法一樣是不會被調(diào)用的，雖然有這樣的問題，但是我還是想嘗試一下單純從前臺是不是能夠?qū)崿F(xiàn)。我起初只是寫了一個簡單的異步線程，但是發(fā)現(xiàn)內(nèi)部的打印不會執(zhí)行，所以我就用了下邊的方案進行測試，發(fā)現(xiàn)我的打印被執(zhí)行了。我想也許我找到了一種解決方案。代碼如下

但是當(dāng)我在項目中加入這個通知的時候我發(fā)現(xiàn)這個時候是無法執(zhí)行到的，代碼大致如下

也許是系統(tǒng)默認就將我的這個線程殺死不在讓我繼續(xù)去執(zhí)行了，所以顯然這樣的方案就行不通了，我后來嘗試了一些其它的方案都沒有什么效果。也漸漸的理解了在百度上為什么能夠搜到那樣的解決方案，而且Google也沒有找到很好地方案。但是在我一次次失敗的過程中，我發(fā)現(xiàn)一件好玩的事情，就是如果我們每次系統(tǒng)手動殺死程序，下次進入程序的時候我們都會執(zhí)行NSURLSessionTaskDelegate中的一個代理方法，代碼如下。

后續(xù)的開發(fā)過程中我格外的關(guān)注這個方法，我發(fā)現(xiàn)無論是我們下載過程中發(fā)生錯誤還是我們在下載過程中出現(xiàn)網(wǎng)絡(luò)中斷等情況都會走這個代理方法。我想也許這就是說蘋果留個開發(fā)者解決這一類問題的入口，于是我打印其中的錯誤信息大致如下

這個時候我打印一下每次暫停的時候，系統(tǒng)給我們返回的相關(guān)的數(shù)據(jù)，系統(tǒng)返回數(shù)據(jù)如下

通過上邊的數(shù)據(jù)，我開始有一個大膽的猜測，我可以使用錯誤中的error進行繼續(xù)下載，然后我嘗試著用error的userinfo中的resumeData去繼續(xù)下載，發(fā)現(xiàn)這樣的方案完全能夠?qū)崿F(xiàn)我的想法。

通過上邊的嘗試，我發(fā)現(xiàn)雖然在文檔上我沒有找到斷點續(xù)傳如何實現(xiàn)，但是其實系統(tǒng)是幫我實現(xiàn)好了的。我們?nèi)绻螺d中斷，在下一次進入的時候，系統(tǒng)會告訴我們中斷的位置，而不需要做復(fù)雜的存儲過程。這樣我們就完成了一次斷點續(xù)傳。

為本文寫了一個簡單的demo:下載地址

如對本文有任何疑問，煩請留言區(qū)提出，看到馬上都會回復(fù)。如果本文中有任何錯誤，請您指正，我會馬上進行更改。