核心 - 數據+ AFNetworking + UI更新（響應速度）

Question

這裏的情景：

我正在寫一個DownloadManager，允許用戶下載，暫停，取消，下載所有，並暫停所有。該DownloadManager是一個單身人士，並使用AFNetworking下載文件。它擁有自己的專用管理對象上下文，以便用戶可以自由使用應用程序的其他部分（通過添加，編輯，刪除）核心數據對象。我有一個核心數據實體DownloadInfo，其存儲下載信息，即fileURL,fileSize,bytesRead等。DownloadManager更新DownloadInfo（每個文件一個）的下載進度。

我有一個DownloadManagerViewController它使用NSFetchedResultsController向用戶顯示下載狀態。此下載視圖控制器正在使用主要的管理對象上下文。

現在我們假設在下載隊列中有20個文件。假設只允許3個併發下載。下載管理器應該下載文件，並顯示下載進度。

問題：

的DownloadInfo對象正在由DownloadManager以非常高的速率更新。 DownloadManagerViewController（負責顯示下載進度）正在使用NSFetchedResultsControllerDelegate方法更新列表。結果是主隊列中發生了很多事情，並且應用程序的響應能力很差。

我該如何解決這個問題？如何讓應用程序響應，同時顯示下載進度？

1. 我不知道怎麼回事到DownloadManager和DownloadManagerViewController的下載狀態通信。有沒有更好的方法來做到這一點？

2. 由於上述原因，我不想在我的DownloadManager中使用主管理對象上下文。請注意，DownloadManager使用AFNetworking異步處理請求，但最終DownloadInfo對象在主線程中更新（作爲回調方法的結果）。也許有辦法在後臺線程中處理下載和狀態更新操作？但是如何？我將如何在主線程和後臺線程之間進行通信，即如何告訴後臺線程排隊另一個文件進行下載？

謝謝。

Answer 1

與其觀察對託管對象上下文的每個更改，不如考慮爲您實際想要更新屏幕的事件實施一個或多個通知。如果通知是從後臺線程發佈的，請確保在觸發任何UI更新之前切換回主線程。

或者，當調用FRC委託方法時，您會收到有關實際更改內容的信息。您可以分析這一點並篩選出最常見和最不有意義的更改，並阻止它們導致UI更新。

Answer 2

您是否嘗試過使用Instruments來查看ViewController中發生了什麼？ Time Profiler將告訴你CPU在哪裏花費更多時間，並幫助你找出問題的根源。不知道這一點，我們無法確切知道你應該做什麼性能調整。

使用儀器後，如果NSFetchedResultsController迫使您的VC進行大量更新，則應考慮不要從CoreData讀取進度。我已經看到很多我的表或視圖花費更多的時間從CoreData讀取，而不是執行繪製。猜測你的問題與CoreData讀取有關，我會嘗試從NSMutableDictionary讀取進度，並在下載通過certan閾值時更新UI。