完成開發任務的同時，我們總希望自己能夠交付高質量的代碼。代碼質量的測度有很多方法，可擴展性、可復用性是其中的兩項指標。設計模式的理論能夠非常有效地指導代碼設計，但是光談這些理論是非常抽象的，本文針對下載這個場景，結合設計模式的一些理論，談一談如何設計一個結構較為合理的下載模塊。

Step.1 別急，先進行”需求評審“

在著手編碼之前，先明確功能需求、技術需求，然后進行初步的思考。

從目標出發

從目標出發，能夠幫助明確設計過程中的側重點。對于下載這個場景，很直觀可以想到，它涉及到的文件操作、持久化存儲等步驟是會頻繁出現在一個項目中的。所以我會希望為下載模塊寫的大量代碼能夠被良好復用。同時可以預見，下載這一場景是非常容易出現后續需求變更或者增加的，沒準今天只下載視頻，明天又需要添加對音頻、對 zip 文件的支持；對于數據庫存儲框架，可能目前在使用 FMDB，后續又要更換為 WCDB。所以，也對這個模塊的可擴展性、易修改性提出了要求。

結合一點點理論

設計模式中有幾大原則，剛開始接觸我們總感到難以把握。因為它們簡短得像幾字真言，而實際的場景卻有千千萬萬種。那么，就從最易理解的**“單一職責原則”開始。簡單來說，一個單獨的模塊應該只負責一個單獨的任務，任務的粒度越細，它和其他模塊的耦合性越低，它也越容易被復用。而遵循“依賴倒置原則”，則會有效提高代碼的易修改性。比如對于數據庫模塊，在實際使用某一數據庫框架進行存取操作的實現類之上，再抽象出一層接口類。在下載過程中只使用接口類中提供的方法，而接口類中方法的具體實現，則由下層的實現類完成。這樣，當我們把數據庫框架由 FMDB 替換為 WCDB 時，只需對實現類的代碼進行修改，修改的目標則是使用新框架再次實現接口類中聲明的方法，這也就是所謂的“針對接口編程”，而非”針對實現編程“。它帶來的好處是顯而易見的：在數據庫框架的替換過程中，最上層的業務代碼完全無需改動**，只需對數據庫操作的實現類進行修改即可。

模塊化的目的

有一件事是需要明確的，我們常談的“模塊化”，并非對所有模塊都追求任意場景下的可復用。因為模塊會分為業務模塊和通用模塊，通用模塊力求做到任意場景下的可復用，而業務模塊則專注于完成某一需求場景。雖然“下載”這個詞在很多項目中會出現，但不同的項目中對它的定義是不同的。有的“下載”僅僅意指下載單個的文件，而有的下載則指的是某一場景下所有內容的本地緩存。

在這篇文章中，我預設的場景是一個下載任務中會包括各種具體的子任務，舉個例子，一個下載任務可能由三個視頻文件、兩個音頻文件、三張圖片、兩個網絡請求的 JSON 格式結果組成。

因此，我會把本文所說的“下載”歸入業務模塊，它不追求做到任意場景下的可復用，但它能夠很好地完成這個較復雜場景下的下載任務。而這個業務模塊中所包含的文件下載、圖片緩存、文件操作等具體步驟，其實是無關業務的，那么它們便可以歸為通用模塊。在其他進行圖片緩存的場景下，可以使用這里的圖片緩存模塊，而其他的文件操作場景，也可以使用這里的文件操作模塊。它們的具體分析會在下文展開。

Step.2 給出設計方案

結合文章第一部分的分析，著手進行方案的設計。

“下載”不是單單一件事

通常意義上的下載，是指將云端的資源獲取到本地磁盤的過程。對于 iOS 應用，下載的目的多是進行某些內容的離線展示。一個完整的下載過程，應該由以下的步驟組成：

• 文件操作

對于所下載的文件，需要確定它在本地的存儲路徑；給定某個 key 值，需要獲取對應文件的存儲路徑；對于某個指定的路徑，會有檢查文件存在性、完整性等操作；下載過程中不斷進行文件寫入，刪除已下載內容時涉及文件刪除、目錄刪除；除此之外，還有獲取各個系統目錄、獲取磁盤空間數據等常規操作。若涉及安全性需求，還會有文件加密、解密操作。因此，將文件操作封裝為一個單獨模塊是一個明智的選擇。文件操作不僅僅會在下載這個場景中出現，因此，在這個模塊的實現過程中應該盡量剝離業務相關的內容，力求成為一個通用的工具模塊。

• 數據庫操作

基于文章第一部分中給出的場景，這里的下載任務應該是結構化的數據。無論網絡狀況是否正常，已下載的內容都能夠正常展示，所以下載記錄應該被持久化存儲?；谝陨蟽牲c，數據庫的使用是自然的選擇。應該明確的是，數據庫存儲的是下載任務記錄，或叫做日志，而非下載的文件。考慮到 iOS 中數據庫框架的多樣性和業務方對數據庫性能的持續追求，很容易預見到數據庫框架在未來的替換工作。因此對于這個模塊，上文也進行了分析，那就是依照依賴倒置原則，分成抽象的接口類和具體的實現類。

• 較大體積文件的下載

在下載的需求中，視頻、音頻、zip 文件等體積較大的文件是很常見的。因此一個只針對較大體積文件的下載模塊模塊必不可少。它不涉及任何具體的業務細節，它的任務僅僅是根據給定的文件 url 和本地存儲的路徑，完成該文件的下載。做到這個模塊的高內聚是比較容易的，因此強烈建議將這部分封裝為一個通用模塊，以滿足任何場景下的文件下載需求。為減少通用模塊之間的橫向依賴，一個思路是本地路徑由上層的業務模塊調用文件操作模塊獲得，然后傳遞給本模塊，而非本模塊直接調用文件操作模塊；對于文件寫入操作，可直接使用系統的 NSFileManager。同時也有另一種思路，大文件下載和文件操作之間的依賴是自然、可接受的，允許下載模塊依賴文件操作模塊。這些沒有標準答案，可以自行取舍。

• 圖片的下載

有時候下載任務中會包含圖片下載，按照體積來看，將圖片下載歸入文件類型也不為過。但是圖片的緩存在iOS的開發中是一個積淀已深的話題，我們擁有 YYWebImage、SDWebImage 等優秀的圖片緩存框架，有什么理由再去重復造一個性能未必更優的輪子呢？除此之外，剛剛提到的兩個圖片框架基本應用在了絕大多數的iOS網絡應用中，所以很有可能出現的場景是：已經下載過的圖片，在項目中的某處不相關的地方用上述圖片框架進行加載。如果圖片下載使用這些框架的緩存器來實現，那么在上述場景下，**框架會從本地緩存中尋找到目標圖片，避免重復的云端下載，達到了有效且明顯的優化效果?；诰植啃栽?#xff0c;這種情景的命中率還是不可忽略的。**因此，建議將圖片的下載拆分為一個內部實現使用上述框架的圖片緩存器。

• 網絡請求結果的緩存

有的下載場景中，需要對網絡請求進行緩存。網絡請求的結果多為 JSON 格式的數據，體積較小，屬于輕量的下載內容。我的實現是網絡請求緩存和圖片緩存作為 cache 模塊的一部分，整體封裝一個 cache 模塊。也可以將這兩者分開模塊化，視具體業務需求靈活決定。

• 特定場景下載的業務模塊

以上列出的模塊，基本都可以向可廣泛復用的通用模塊努力。上文提到，模塊化中，也包括專注具體場景的業務模塊。在本文的業務場景下，我封裝了一個業務模塊。它的職責是：持久化維護已下載和正在下載任務的list；根據按固定格式提交的下載任務，解析出結構化的任務結構；對于不同類型的子任務，使用上述對應的通用模塊完成下載；同時負責協調各子任務之間的同步關系；在所有子任務完成下載后，檢查整個結構的文件完整性；通過完整性校驗后，進行數據庫存儲操作，存儲該次下載日志；在整個活動周期內，模塊還負責下載任務狀態的更新。

模塊整體結構

通過對整個下載過程的分析，我們拆分出了幾個模塊。依照單一職責原則，將每個模塊的職責劃分到了較為合適的粒度，都能夠做到一定程度上的復用。對于其中擴展可能較高的模塊，依照依賴倒置原則，抽象出了一層接口類，避免了未來底層修改時對上層業務代碼的影響。在模塊化的應用上，也做到了目的明確、合理拆分。

下圖即是整體的示意圖：

Step.3 完成具體實現吧！

其實寫完第二部分，本文的寫作目的已經差不多達到。大家從標題可以感受到，本文側重點在于對”下載“這個場景運用一些理論的指導進行較為合理的代碼結構設計。不過為做到有始有終——“從理論分析開始，用具體實現來結尾”，這部分對實現細節進行一些討論，提供一些“干貨”，這些方案面對不同場景會有不同的優劣表現，僅供參考。

• 文件操作模塊

這部分我的實現是使用系統的 NSFileManager 進行文件存在性判斷等基本操作。對于本地存儲的目標路徑，生成規則為文件 URL 做 md5 操作，再添加具體的文件類型后綴。在安全性較高的場景中，所下載的文件都來自自有的服務器，那么文件正確性校驗可以由后端提供部分支持，如對于每個文件都返回特定的校驗值，在本地下載完成后，使用由已下載文件生成的校驗值和后端提供的進行比對。

• 數據庫模塊

對于數據庫中需要存儲什么字段，我的意見是這樣的：對于某個具體的文件，存儲初始 url、文件在本地存儲的路徑、文件大小、更新時間等基本信息。對于結構化的整條下載記錄，則將還原初始下載任務的所需字段都進行存儲。具體解釋下，初始下載任務的提交時多是使用業務方的數據類型，比如一篇微博展示時的 model ，一篇文章展示時的 model。而下載任務提交到下載模塊后，我們會將初始的數據類型轉化為下載模塊的規定的數據格式。若涉及到斷點續傳等場景，便會存在 app 重啟后，由從數據庫中取得的下載模塊所用數據格式向初始業務方數據格式的逆轉化，這時就需要初始任務所有必要的狀態信息，從而進行現場恢復，繼續進行下載。

上文說到，下載管理業務模塊需要維護下載中、已下載任務的 list，用什么來區分狀態呢？我的實現是為下載記錄添加標識是否完成的字段，這樣當 app 重啟后，從數據庫中取得所有的下載記錄，若某條記錄被標識為未完成，那么它便是需要還原為初始下載任務的記錄，被歸入下載中 list。

• 大體積文件下載模塊

關于這部分的討論已經有很多，本文不再贅述。值得一提的是，這個通用組件依然會面臨底層實現更換或者版本升級的問題，所以依照依賴倒置抽象出接口層的思路在這里依然適用。

• 緩存模塊

關于圖片的緩存在上文已經詳細討論。對于 JSON 格式的網絡請求結果，iOS 中一般使用 NSDictionary 存儲，它支持 NSCoding 協議，因此 YYCache、EGOCache等緩存框架都是可以使用的。這部分的接口設計比較直白，為指定 key 對應的值進行緩存，根據給定 key 返回對應的緩存值，以及移除給定 key 對應的內容。抽象接口層的思路，照例適用。

• 下載管理業務模塊

在項目的很多地方可能都需要獲知當前下載模塊的狀態，所以這里使用單例實現是一個比較好的選擇。在整個下載過程的最初，它根據提交的每一個初始任務數據，解析出具體的子任務類型，調用對應的子模塊完成子任務的下載。同一下載任務下的各子任務之間應該是異步的，所以 dispatch group 是一個直觀的選擇。順序提交的所有初始任務之間，則是同步的關系，這里可以使用類似隊列的結構來管理。下面給出一個示意圖：

對于下載中、已下載這兩種狀態的區分，這里提供一個改進思路：在某個初始任務真正開始下載之前，就向數據庫中插入一條新的下載記錄，設置狀態字段為未完成，當所有子任務均完成且通過完整性校驗后，更新狀態字段為完成。

最后，為大家提供一個業務模塊的樣例偽代碼，用以展示整個下載流程。

//下載管理業務模塊的接口列表(大意展示)//業務方的model @class OriginModel;@interface DownloadManager : NSObject //獲取下載管理對象（單例） + (instancetype)sharedInstance; //獲取下載中的任務 - (NSArray<OriginModel *> *)getDownloadingItems; //獲取已下載的任務 - (NSArray<OriginModel*> *)getDownloadedItems; //根據id獲取已下載的item - (OriginModel *)getDownloadedItemById:(id<NSCopying>)itemId; //是否下載過指定id的item - (BOOL)didDownloadedItem:(id<NSCopying>)itemId; //批量下載 - (void)downloadItems:(NSArray<OriginModel*> *)items; //暫停下載 - (void)pauseDownloadForItem:(id<NSCopying>)itemId; //恢復下載 - (void)resumeDownloadForItem:(id<NSCopying>)itemId; //取消下載 - (void)cancelDownloadForItem:(id<NSCopying>)itemId; @end 復制代碼//下載管理業務模塊的主要實現@implementation DownloadManager- (void)downloadItems:(NSArray<OriginModel *> *)items {// 解析任務結構，將所有任務push進任務隊列MissionStruct *oneStruct = [self analyzeMission];for (MissionItem *item in oneStruct) {[self.missionList pushItem:item];}... // 若非空，從任務隊列中取出任務元素if (![self.missionList isEmpty]) {MissionItem *oneMission = [self.missionList pop];[self handleMission:oneMission];} }- (void)handleMission:(MissionItem *)mission {// 調用數據庫模塊，插入一條新紀錄[DatabaseManager insertMission:mission];dispatch_group_t downloadGroup;// 下載視頻for (videoMission in mission.videos) {dispatch_group_enter(downloadGroup);// 調用文件管理模塊，獲取該url對應的文件路徑targetPath = [FileManager pathForURL:videoMission.url];// 調用大文件下載模塊，下載該視頻[FileDownloadManager downloadFile:videoMission.urltargetPath:targetPathsuccess:^(){dispatch_group_leave(downloadGroup);}];}// 下載音頻for (audioMission in mission.audios) {dispatch_group_enter(downloadGroup);// 調用文件管理模塊，獲取該url對應的文件路徑targetPath = [FileManager pathForURL:audioMission.url];// 調用大文件下載模塊，下載該音頻[FileDownloadManager downloadFile:audioMission.urltargetPath:targetPathsuccess:^(){dispatch_group_leave(downloadGroup);}];}// 緩存圖片for (imageMission in mission.images) {dispatch_group_enter(downloadGroup);// 調用圖片緩存模塊，緩存該圖片[ImageCacheManager cacheImage:imageMission.urlsuccess:^(){dispatch_group_leave(downloadGroup);}];}// 緩存網絡請求for (contentMission in mission.contents) {dispatch_group_enter(downloadGroup);// 調用網絡請求緩存模塊，緩存該網絡請求[RequestCacheManager cacheRequest:contentMission.urlsuccess:^(){dispatch_group_leave(downloadGroup);}];}...// 所有子任務均完成dispatch_group_notify(downloadGroup, dispatch_get_global_queue(0, 0), ^{// 通過完整性校驗if ([self verifyAllSubMission:mission]) {// 調用數據庫模塊，更新該下載紀錄[DatabaseManager updateMission:mission];} else {// 未通過完整性校驗，移除數據庫對應記錄[DatabaseManager removeMission:mission];}}); }@end 復制代碼

知識小集是一個團隊公眾號，主要定位在移動開發領域，分享移動開發技術，包括 iOS、Android、小程序、移動前端、React Native、weex 等。每周都會有 原創 文章分享，我們的文章都會在公眾號首發。歡迎關注查看更多內容。

總結

以上是生活随笔為你收集整理的有始有终，设计一个结构合理的下载模块的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。