使用dispatch_async + dispatch_get_main_queue進行UI更新有什么意義？

Question

在我需要使用的代碼庫中使用AFNetworking（帶有塊）成功的網絡請求后，我看到了很多調度塊：

-(void)someMethodThatPerformsNetworkRequest{

  networkManager.newsList getNewsCallBack:^{

    // Store received and parsed data...

    // Do UI updates. IMHO it's not necessary to warp it inside dispatch_async
    dispatch_async(dispatch_get_main_queue(), ^(){

      // Some UI updates
      // ... table reloads, label changes and etc.

    });
  }
}

據我所知，我們不需要顯式設置要在主線程上執行的回調代碼，因為AFNetworking已經在主線程上執行回調。 我在這里看到的唯一原因是允許父方法完成其工作並“一點點”延遲這些UI更新（將它們放入主線程隊列的末尾）。 但我們可能不需要那樣做，所以這些dispatch_async應該被刪除恕我直言。 有什么想法嗎？

Answer 1

通常，對於異步網絡請求，這是必要的，因為回調發生在后台線程上。 但是，AFNetworking應始終在主線程上調用響應塊，因此在使用AFNetworking時，在您自己的代碼中完成此操作應該完全沒必要。 可能是您以前使用的代碼使用了不同的庫，其中回調沒有出現在主線程上，或者甚至使用自定義編寫的代碼，所以它可能只是剩下的。 無論是那個還是以前的開發人員都不知道AFNetworking回調出現在主線程上。 所以刪除它應該是安全的。

Answer 2

恕我直言，任何框架或庫都是特定線程上的全面調用塊，而不是非常明顯，它正在做一些非常錯誤的事情。

但是，在AFNetworking的特定情況下，看起來它們采用了80/20規則 - 默認回調隊列在主線程上（它在后台使用NSOperationQueue）。 換句話說， AFNetworking不會調用主隊列上的塊 - 它會在配置的隊列上調用它們。 如果未由最終開發人員修改或設置默認配置隊列，則操作將在主線程上運行。

要更改此設置，只需在AFHTTPRequestOperation實例上設置completionQueue即可。

如果你有一個非常強大的線程應用程序，你可能會管理自己的工作隊列，並將其傳遞給AFNetworking。 特別是在這些情況下，在主線程上調度UI更新至關重要（因為它始終如此）。

Answer 3

是AFNetworking塊在主線程上執行，直到您將completionQueue設置為AFHTTPRequestOperation。 如果您沒有做任何花哨的事情（例如不應該鎖定主線程的完整后台網絡代碼），則不必在邏輯中使用該塊。

網絡操作當然是在單獨的線程中完成，直到響應到來才鎖定，但默認情況下總是在主線程上執行完成和失敗塊。