如何檢查dispatch_async是否為同一操作更早被調用

Question

我遇到了一個問題。 我的應用程序從服務器下載圖像並顯示在UITableView要下載圖像，我正在使用dispatch_async 。

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    // downloading image from server
    dispatch_async(dispatch_get_main_queue(), ^{
        // update UI for showing downloaded image
    });
});

現在的問題是，如果用戶快速上下滾動，則將為同一圖像觸發多個dispatch_async 。 我有圖像ID。 有什么方法可以通過圖像ID檢查是否為該圖像觸發了dispatch_async ？

Answer 1

您必須建立自己的機制來跟蹤該圖像是否有任何待處理的請求（例如，以圖像URL絕對字符串為關鍵字的字典等等）。 事實是，它並非如此簡單，因為現在需要更新的單元格可能與原始請求的單元格不同（或除此之外）。 這很快變得很難看。

但是我退后一步，問這是根本問題還是更廣泛問題的征兆。 例如，如果用戶相對快速地向下滾動到第100行。 該圖像請求是否積壓在前99行的后面？ 在這種情況下，您描述的問題開​​始變得嚴重，因為如果您現在在其他99張圖片完成下載之前快速向上滾動到頂部，則會發出再次獲取它們的請求。

但是，如果您更改異步圖像檢索以取消對不可見的單元格的請求，則突然，這個嚴重的問題變得有些學術化。 此外，您還有一個好處，就是用戶快速滾動到的第100行的圖像不會積壓在所有其他圖像請求之后，因此它顯示得很快。

這意味着您要采用可取消的異步請求。 因此，這建議使用NSURLSession （如果必須支持NSURLSession之前的操作系統版本，則可以使用基於委托的NSURLConnection ）。 另外，這通常會使操作隊列和子類化的異步NSOperation子類NSOperation而不是您的問題建議的GCD隊列（使它們可取消，異步並限制並發程度）。 然后你必須然后實現利用一切，你已經這么勤奮地創造了這個取消邏輯（例如的代碼UIImageView類別或您的一些圖像請求管理器UITableViewDataSource和/或UITableViewCell子類使用）。

另外，您還想確保使用緩存機制（可能同時用於內存和持久性存儲）。 這樣，如果您已經檢索了特定的圖像，則當您滾動回到該行時，就可以檢索該圖像了，而無需再次進行網絡調用。

我知道您已經說過要自己執行此操作，但這是完成一項正常工作的一項重要工作。 這就是為什么我（和其他人）建議您考慮簽出允許您異步檢索圖像的UIImageView類別之一的原因。 請參閱SDWebImage或AFNetworking提供的UIImageView類別。 如果您要適當地使單元出隊，那么它們將在異步檢索圖像的同時實現非常敏感的UI。 它們有效地取消了對重復使用的信元的請求，從而對可見信元進行了優先排序。 它們還可以緩存結果，從而在您向后滾動時具有良好的性能。

Answer 2

為此，您應該將下載的圖像存儲在某個位置，或者標記它們是否有當前操作。 因此，您基本上將執行圖像緩存機制。 我將建議您改為使用經過良好測試的庫，例如SDWebImage ，該庫可以精確處理下載圖像並將其緩存到內存或磁盤中。

Answer 3

保持簡單：使用NSURLSession而不是嘗試自己進行異步URL提取。 依靠其緩存來避免在先前的下載完成后重復下載。 然后，您需要擔心的是重復請求當前正在進行的下載。

最簡單的方法可能只是保留兩個字典： NSURLSessionDataTask URL和完成處理程序數組的URL。

當單元格想要一個URL時，它將調用這兩個詞典的處理程序，並提供一個完成處理程序。

如果該URL沒有數據任務，則該處理程序創建一個並啟動它，還創建僅包含該完成處理程序的字典。 兩者都放入各自的詞典中。

如果該URL有數據任務，則將完成處理程序添加到第二個字典中的數組。

任務是使用完成模塊創建的，該模塊調用處理程序，該完成模塊將在接收到后將任務從第一個字典中刪除，並在第二個字典中調用數組中的所有內容，然后從那里刪除數組。

鑒於您與視圖相關，該處理程序僅允許從主隊列進行外部調用。 這將確保完成的數據任務之后的工作也可以在主隊列上執行。 這意味着您將沒有並發問題。