你好,歡迎來到IOS教程網

 Ios教程網 >> IOS編程開發 >> IOS開發基礎 >> 實現項目下載需求時遇過的那些坑

實現項目下載需求時遇過的那些坑

編輯:IOS開發基礎

cave-555727_640.jpg

導語

當前市面上的APP,凡有涉及到視頻、期刊、或其它大型文件傳輸、浏覽等用途的,添加下載或緩存至本地的功能以避免網速的限制及依賴,毫無疑問都將給用戶帶來更好的體驗。而談到下載技術,就又不得不牽扯到了斷點續傳,隊列任務等老生常談的問題。這不,本人當前的項目,就恰好遇到了這樣的需求。然而在經過大量調研之後,本人竟無法找到一篇總結得很好的文檔,對此進行全面的介紹;能夠尋到的一些活躍度並不高的開源項目,卻又不能恰如其分並抱之以信賴滿足項目的需求。所以仔細斟酌後,不得不選擇自己動手,豐衣足食。鑽研的過程中遇到了不少坑、不少困難,有些個別的地方真是不用不知道,一用才知道是如此得蹩腳,難怪很少有人對此進行系統完整的介紹。現將本人在實現下載模塊時所用到的技術總結如下,相信本文中所蘊涵的干貨一定不會令費心閱讀的你感到失望!

話休絮煩。首先,說下載就離不開網絡請求。而當今iOS開發技術當中,最廣泛使用的網絡請求框架無疑要屬AFNetworking。經過對其進行簡單研究後,你就會尋到最適合用來完成下載這件“小事”的組件,叫做AFHTTPRequestOperation

現假定我們的需求是最常見,也是最能體現技術問題的一個,叫做:

下載隊列在某一時刻,最多僅能有一個下載任務處於正在下載的狀態中!

-- 敘述的節奏似乎稍稍快了些

那就先來看下實現隊列下載、斷點續傳等需求的關鍵示例代碼吧!

    NSError * error = nil;
    // 創建下載隊列
    NSOperationQueue * downloadOperationQueue = [[NSOperationQueue alloc]init];
    //  規定operationQueue中,最大可以同時執行的operation數量為1
    downloadOperationQueue.maxConcurrentOperationCount = 1;
    // 創建單個下載任務(訪問已下載部分的文件,實現斷點續傳)
    NSMutableURLRequest * downloadRequest = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:DOWNLOAD_URL_STRING]];
    [[NSURLCache sharedURLCache] removeCachedResponseForRequest:downloadRequest];
    AFHTTPRequestOperation * downloadOperation = [[AFHTTPRequestOperation alloc]initWithRequest:downloadRequest];
    unsigned long long downloadedPartFileSize = 0;
    if ([[NSFileManager defaultManager] fileExistsAtPath:DOWNLOADED_PART_FILE_PATH]) {
        NSDictionary * fileAttributes = [[NSFileManager defaultManager]attributesOfItemAtPath:DOWNLOADED_PART_FILE_PATH error:&error];
        downloadedPartFileSize = [fileAttributes fileSize];
        NSString * headerRangeFieldValue = [NSString stringWithFormat:@"bytes=%llu-", downloadedPartFileSize];
        [downloadRequest setValue:headerRangeFieldValue forHTTPHeaderField:@"Range"];
    }
    downloadOperation.outputStream = [NSOutputStream outputStreamToFileAtPath:DOWNLOADED_PART_FILE_PATH append:YES];
    [downloadOperation setDownloadProgressBlock:^(NSUInteger bytesRead, long long totalBytesRead, long long totalBytesExpectedToRead) {
        NSLog(@"%lld/%lld", totalBytesRead + downloadedPartFileSize, totalBytesExpectedToRead + downloadedPartFileSize);
    }];
    [downloadOperation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
        NSLog(@"downloadOperation completion block invoked");
    } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
        NSLog(@"downloadOperation failure block invoked");
    }];
    //  將單個下載任務加入到下載隊列當中
    [downloadOperationQueue addOperation:downloadOperation];
    //  暫停某下載任務
    [downloadOperation pause];
    //  繼續某下載任務
    [downloadOperation resume];
    //  取消某下載任務(同時應將其已下載部分的文件刪除)
    [downloadOperation cancel];
    [[NSFileManager defaultManager] removeItemAtPath:DOWNLOADED_PART_FILE_PATH error:&error];
    //  取消全部下載任務
    [downloadOperationQueue cancelAllOperations];
    //  此外還有若干方法用以判斷相應一見其名便知其義的狀態...
    downloadOperation.isReady
    downloadOperation.isExecuting
    downloadOperation.isPaused
    downloadOperation.isCancelled
    downloadOperation.isFinished
    //  判斷downloadOperation是否存在在downloadOperationQueue當中
    [downloadOperationQueue.operations containsObject:downloadOperation]

以上代碼創建了一個AFHTTPRequestOperation對象作為單個下載任務,並將其加入到NSOperationQueue中。仿照上例,我們可以創建多個AFHTTPRequestOperation對象並加入到NSOperationQueue中,即形成了下載隊列

做到這裡,你是不是認為已經沒有神馬技術問題啦?只要把operation一個個地添加到queue裡, 下載任務就可以一個接一個地自動執行了!而如果我們將上一個operation暫停、取消,或是它自然地下載完成了,又或是它下載中途失敗了,下一operation就會聰明地自動啟動,繼續其下載任務了!!?

錯!!!!

接下來筆者將要告訴你的,就是本文最最核心的干貨,絕對顛覆你的想象!!

只要你親手動手試一試,就會發現如下大跌眼球的驚恐現象!!

驚人事實 1: 對queue中前一個下載operation執行pause方法,下一個operation並不能自動啟動進入正在執行的狀態!!

驚人事實 2: 如果queue中前一個下載operation執行失敗了(可用下載中途斷網進行模擬),它將從queue中自動地被移除掉!!

驚人事實 3: 注意到代碼裡那個failure回調的block了沒?它不僅僅將在operation執行失敗的時候被調用,還會在operation被cancel的時候被調用!!所以對於神馬叫做“operation的失敗”,你要重新建立起你的世界觀了!!

驚人事實 4: 如果對一個正處於pause狀態的operation執行cancel會怎麼樣?答案是這個operation還保留在queue中!!並且仍然保持著pause狀態!!僅有的一點變化,是它的isCancelled屬性,變成了YES!!

......未完待續,本文要令你感到驚詫的,還有很多

由於這些問題間相互關系的錯綜復雜,為了清晰條理地予以說明,特將本人實驗中所觀察到operation的行為總結如下表。

1.jpg

有木有感到AFHTTPRequestOperation和NSOperationQueue是個多麼坑爹的東東?為何就不能像我們想象中一樣用得舒爽?

原因就在於AFHTTPRequestOperation的父類NSOperation,在設計之處就不是為了下載的操作而生的!人家開始就僅僅是用來處理多線程的啊!!所以造成了AFNetworking在擴展這個類的時候,可用的資源、接口等等就非常少。對於什麼下載任務暫停/繼續,下載中途失敗等等情況,很多問題幾乎就是沒有辦法理想地解決的,只好用NSOperation中僅有的幾種狀態予以並不貼切的表示。於是乎就出現了上表中種種詭異的情況

補充幾點干貨。然後告訴你一個本文之前偷偷誤導了你的大坑!!

驚人事實 5:如果一個queue中有一個下載operation正在執行,此時對另一處在isReady狀態的operation執行start方法會怎麼樣?你很可能會說:“沒用的,因為之前設了queue.maxConcurrentOperationCount = 1嘛!” 可事實恰好相反,這個operation也會立刻被啟動執行!!於是乎你不忍心看到的事情就出現了,這時queue將會有兩個任務被同時執行!!maxConcurrentOperationCount完全失效了!!

驚人事實 6:承接上一點,如果此時另一條的狀態不是isReady,而是isPaused暫停狀態,你對其執行resume方法,此時會怎麼樣呢?哈哈,沒錯,你吸取了上一條的經驗,終於猜對了!這個operation也會立刻啟動被執行,不管當前的queue有沒有另一個operation正在被執行!!從中我們就可以意識到,maxConcurrentOperationCount這個屬性,只能管得自動啟動每一operation時,先檢查下是否正在執行的operation的數量已經超過那個數字了;可是如果你要手動start某一operation,對不起,這條限制半點都沒有用處了......

驚人事實 7:從上表中我們可以看到,無論是一個operation自然地執行完畢,還是中途失敗,還是被執行了cancel方法,都會被標記為isFinished,從operation中被移除掉,operation所認為的“完成”可完全不像我們想象中的那麼狹義!問題來了,此時如果再對這個operation執行start方法會怎麼樣?對不起!沒有任何用處!:sob:所以你如果想要讓一個已失敗的operation從斷點處繼續再開始執行下載該怎麼辦?不好意思,只好新建operation重新再來了......

基於實驗我們又可以得出了這樣的一張流程圖:

blob.png

頭痛、抓狂得很啊!!本人剛開始實現下載模塊相關需求的時候,就被這些問題坑了個體無完膚。最後得出了本文最大的關鍵結論,也就是前面所說的“大坑”:

不能夠使用NSOperationQueue來進行多下載任務的管理!!!

理由如下:

  1. 你無法妥善地實現“隊列中最多僅能有一個下載任務正在進行”這條產品經理臆測會讓開發變簡單的需求!!比方說,你讓NSOperationQueue中一個operation暫停後,下一個任務並不會自動啟動啊!有人說可以手動去start下一個operation,如果這個姑且算做可以接受,可是問題又來了:我們沒有辦法手動將一個operation置為isReady狀態啊!!處於isReady狀態的operation,要麼是還未加入queue,要麼是加入了還未輪到執行,但是它只要一執行,就再也回不到isReady的狀態了!那我們要讓暫停的operation恢復到等待下載狀態該怎麼搞?此時可能還有另一operation正在執行啊!!反之筆者搞了半天,是無能為力了

  2. 下載是需要一定時間的過程,需要不停地向服務器進行請求,那麼就永遠避免不了因為網絡等原因中途會失敗的問題。可要命的是,一旦下載失敗,operation就會毫不妥協地從queue中被移除掉啊!!你能在這時候讓你的下載任務從UI界面上消失掉嗎?顯然大BOSS是不會允許你這麼干的。有人說可以重建operation再加入到queue中,可那樣你只能將operation插到隊尾,列表順序就被打亂了啊!!你去瞧瞧看,operationQueue.operations,那可只是一個只讀屬性啊!!

  3. ......自己去體會吧,反正坑多的已經無力吐槽,再堅持下去也是枉費心思了。

不幸的事情來了。筆者最後只得放棄NSOperationQueue,使用古老原始的工具--NSMutableArray來進行多下載任務的管理。這樣的話所有operation的啟動、移除等操作都必須依靠手動來執行。這個辦法雖然辦法土了些,可是起碼對於每個operation的控制權又重新回到了我們手裡。有得必有失嘛!當能恰當地實現了項目需求的時候,這點犧牲也就算不上神馬了

在使用AFHTTPRequestOperation時我們還需要注意以下幾點:

  1. 對isReady狀態的operation執行resume、pause、cancel等方法是沒有任何用處的,所以為了確保執行正確,在對operation執行resume、pause、cancel前,都要首先執行[operation start]。(對已經start過的operation執行start不會造成任何影響)

  2. 對處於isPaused的operation執行cancel方法是無法得到正確結果的,所以每次執行cancel方法前,都要先執行一下[operation resume]。 (同樣對於正處於isExecuting狀態的operation來說,執行resume方法也是不會造成任何影響的)

  3. 對於下載模塊這個糾結之處來說,本地持久化下載記錄的相關數據也是必不可少的,理由如下:

    1. AFHTTPRequestOperation、NSMutableArray這些都是運行時的東西,一關掉app,這些東西自然也都消失得無影無蹤了。我們能讓下載記錄就此消失得無影無蹤麼?NO!顯然是不能接受的 

    2. 我們下載得到的那個文件,可能是已下載完成的,可能是只下載了部分的;而只下載了部分這種的,又可能是下載中途暫停了的,失敗的,被取消的等等情況。請問單憑這個文件如何判斷它是屬於哪種情況?而且這還不夠,有些下載任務根本可能就還未生成相應的下載文件,app就已經被關了啊!你能就把這種的下載任務扔掉嗎?顯然是絕不可以的

    3. 不使用operationQueue我們同樣無法手動將operation標記為隊列等待的isReady狀態,怎麼辦?只有將operation設定為paused,然後相應的數據記錄標記為isReady狀態好了(本人使用的是CoreData進行本地持久化存儲)

    4. ......用operation外的數據模型記錄下載任務的狀態好處還有很多,但同時帶來的同步更新問題也有很多,具體就留給大家自己去體會了!

以上就是本人總結下載模塊實現時需要注意到的種種內容。當然各位大神如果有更好的方案提出,比如用本人掌握得還不夠好的stream如何實現上述需求,本人也願虛心聽取以將此處完善得更好。歡迎直言批評與不吝賜教!!

  1. 上一頁:
  2. 下一頁:
蘋果刷機越獄教程| IOS教程問題解答| IOS技巧綜合| IOS7技巧| IOS8教程
Copyright © Ios教程網 All Rights Reserved