分析技術(shù)選取方案
多線程下載
GCD和OpeationQueue:都是iOS提供的十分方便的多線程實(shí)現(xiàn)方案，GCD使用起來方便簡單，但是由于可控性較差，反而不如OperationQueue和Operation的組合可定制性更強(qiáng)。
斷點(diǎn)續(xù)傳
NSURLSessionDownloadTask和NSURLSessionDataTask：都可實(shí)現(xiàn)斷點(diǎn)續(xù)傳，downloadTask會(huì)由系統(tǒng)在下載時(shí)在temp文件下生成臨時(shí)文件，并且返還resumeData供斷點(diǎn)續(xù)傳，但由于temp文件下內(nèi)容隨時(shí)會(huì)被系統(tǒng)清理掉，且在大文件時(shí)存在問題，所以采用dataTask,用http的“Range”字段進(jìn)行斷點(diǎn)續(xù)傳控制。
結(jié)構(gòu)設(shè)計(jì)
1.類劃分
(1).對(duì)于每一個(gè)下載鏈接來說都是一個(gè)任務(wù)，可以抽象成一個(gè)任務(wù)模型，DownLoadModel。
(2).下載的具體執(zhí)行者，由于確定方案是采用operation和operationQueue的方案，則需要重寫Operation,完成自己的定制，即具體的下載執(zhí)行者，DownloadOperation。
(3).下載下來的內(nèi)容需要存儲(chǔ)在本地，并且在每次續(xù)傳下載時(shí)根據(jù)存儲(chǔ)的數(shù)據(jù)和源文件大小比對(duì)校正后再去續(xù)傳，防止意外導(dǎo)致的文件損壞，和記錄的導(dǎo)致不一致。即存儲(chǔ)每次的下載模型和文件管理，F(xiàn)ileHelper和DownloadStore>
(4).下載管理中心，提供多線程下載和斷點(diǎn)續(xù)傳的管理入口，并把其余各對(duì)象結(jié)合起來。
即簡單確定下來基本的類：
YHFileDownLoadManager:下載管理中心
YHFileDownLoadModel :下載任務(wù)模型
YHFileDownLoadOperation：下載動(dòng)作具體執(zhí)行者
YHFileHelper：文件幫助類
YHFileDownloadStore：數(shù)據(jù)庫存儲(chǔ)類
借助第三方：
YTKKeyValueStore：用于數(shù)據(jù)庫存儲(chǔ)
YYModel：模型和Json的轉(zhuǎn)化
2.功能結(jié)構(gòu)設(shè)計(jì)
Manager職責(zé)：
根據(jù)URL和存儲(chǔ)目錄生成任務(wù)模型；判斷該任務(wù)是否存在；判斷存儲(chǔ)目錄是否存在，不存在則創(chuàng)建；把任務(wù)加載到下載隊(duì)列等待執(zhí)行；控制任務(wù)執(zhí)行動(dòng)作：開始，下載，暫停，取消等；存儲(chǔ)任務(wù)狀態(tài)到數(shù)據(jù)庫當(dāng)應(yīng)用退出或?qū)ο箐N毀時(shí)；每次啟動(dòng)時(shí)獲取上次未完成的下載任務(wù)信息。
Model職責(zé):
存儲(chǔ)任務(wù)的信息，并提供任務(wù)的唯一標(biāo)示，sigleID。
Operation職責(zé)：
進(jìn)行下載或斷點(diǎn)續(xù)傳；每次下載前校正已下載數(shù)據(jù)大小，維護(hù)任務(wù)的下載狀態(tài)。
FileHelper:
文件是否存在與創(chuàng)建；文件夾是否存在與創(chuàng)建；獲取文件大小。
Store職責(zé)：
將任務(wù)模型以鍵值對(duì)的存儲(chǔ)方式在數(shù)據(jù)庫表內(nèi)。
重點(diǎn)事項(xiàng)：
(1).模型的狀態(tài)維護(hù)：模型當(dāng)前的狀態(tài)應(yīng)該是唯一的，即模型的狀態(tài)改變需要注意，稍不注意就有可能因?yàn)槎嗵幐膭?dòng)而造成混論，所以：本人在此采用了數(shù)組來維護(hù)任務(wù)模型，其余地方則都是從該數(shù)組內(nèi)獲取的對(duì)象的引用，并且模型狀態(tài)的改變除了創(chuàng)建時(shí)的初始狀態(tài)外，改變只交給了Operation,根據(jù)下載的變化來調(diào)整模型狀態(tài)。
(2).Operation的重寫：
繼承自系統(tǒng)的Operation,重寫時(shí)需注意維護(hù)幾個(gè)變量的狀態(tài)：executing，finished，cancelled,分別對(duì)應(yīng)了是否正在執(zhí)行，是否完成，是否取消。因?yàn)楫?dāng)opeartion提交到queue中后，什么時(shí)候開始執(zhí)行是有系統(tǒng)決定的，而系統(tǒng)是否啟動(dòng)當(dāng)前任務(wù)，暫停當(dāng)前任務(wù)，取消當(dāng)前任務(wù)以及結(jié)束當(dāng)前任務(wù)調(diào)取下一任務(wù)進(jìn)入隊(duì)列，則都是由內(nèi)部幾個(gè)變量來進(jìn)行維護(hù)的，系統(tǒng)在每次執(zhí)行任務(wù)時(shí)，都會(huì)去訪問這些變量的值以決定下一步動(dòng)作，所以，要做好這些狀態(tài)值的維護(hù)（沒辦法，重寫了當(dāng)然是由自己去維護(hù)了。。）
完結(jié)
說了這么多，怎么沒見代碼，show me your code。。。額，重點(diǎn)是分析設(shè)計(jì)，其次才是代碼實(shí)現(xiàn)（其實(shí)是懶），詳細(xì)代碼實(shí)現(xiàn)參見文章開頭地址鏈接，demo示例是在工程的DownloadViewController。
注：在示例demo內(nèi)：下載任務(wù)加進(jìn)去并沒有立刻開始執(zhí)行，而是處于等待狀態(tài)，需要自己點(diǎn)擊開始執(zhí)行，并且此下載中心只維護(hù)了未完成的下載任務(wù)，包括：下載中，等待，開始，失敗，暫停等，而完成的任務(wù)則會(huì)在完成時(shí)拋出給你，不在此維護(hù)范圍之內(nèi)。demo若需重復(fù)觀看，最好在下載完成時(shí)清理已經(jīng)下載好的文件，否則在下載隊(duì)列開始下載時(shí)，若發(fā)現(xiàn)本地已經(jīng)有下載好的一份，會(huì)瞬間100%已完成。
思考
本人對(duì)這個(gè)多線程下載&&斷點(diǎn)續(xù)傳尚存在一些可以優(yōu)化的疑問？有大神知道望不吝賜教，即在創(chuàng)建下載任務(wù)時(shí)，我是每一個(gè)dataTask創(chuàng)建了一個(gè)session,這樣有多個(gè)task就會(huì)有多個(gè)session，本人認(rèn)為這點(diǎn)是不合理的，connnection是這樣的沒問題，但是session是會(huì)話，一個(gè)session應(yīng)該可以對(duì)應(yīng)多個(gè)task的，但是我看了文檔，說是多個(gè)task對(duì)應(yīng)一個(gè)session將會(huì)共用一個(gè)delegate,每個(gè)task都會(huì)有一個(gè)taskIdentifier標(biāo)識(shí)，那么按照我的設(shè)計(jì)實(shí)現(xiàn)，在任務(wù)對(duì)象關(guān)聯(lián)下載執(zhí)行者時(shí)處理就不是最優(yōu)的，望大神看下源碼給個(gè)建議，這點(diǎn)略有些暈，還請指點(diǎn)迷津，本人也會(huì)繼續(xù)考慮這個(gè)問題。
看~灰機(jī)~灰機(jī)灰過來了~灰機(jī)又灰過去了~
