如何正確處理一個排隊代理的排隊nsoperation

Question

在我目前的項目中，幾個視圖控制器（如vc）產生在靜態NSOperationQueue上執行的NSOperation對象（如operation）。當操作正在等待或運行時，它將通過委派報告給視圖控制器（operation.delegate = vc，分配未保留）。

雖然這些操作可能需要一段時間，但同時應用程序可以通過彈出導航控制器的堆棧來釋放視圖控制器。

到目前爲止，一切都是故意的。包含靜態NSOperationQueue的類有辦法恢復操作，因此視圖控制器不保留它們。他們只是alloc/init/autoreleased並放在隊列中。

現在，這也會導致問題。在視圖控制器釋放後，任何對NSOperation的激進委託的調用都會導致訪問衝突。據我所知，不可能檢查指針上的對象是否已被釋放，as stated in this question。

我能想到的一個修復方法是保留操作並將操作設置爲dealloc。但那是我最不喜歡的解決方案，因爲它會引入很多額外的ivars /屬性來跟蹤。

因此，我的問題是，還有其他方法來解決這個問題，如果是的話，你能在這裏畫一個嗎？

乾杯，
EP。

SOLUTION：制定出最適合我的方法是朱利安諾的回答略有變化：

• 實現隊列管理器每個代表協議是不可行的（20個+不同的協議與50+方法），所以我保留了直接委託分配。我所做的改變是讓班級進行分配。這曾經是創建請求的類（和委託），但現在它被卸載到隊列管理器。

• 隊列管理器在將委託分配給操作旁邊還包含輔助可變字典以跟蹤委託/操作對。

• 每個委託實例在釋放時調用[QueueManager invalidateDelegate:self]方法，然後查找屬於該委託的請求並將其刪除。然後字典操作/委託對也被刪除，以允許適當地釋放該操作。

• 最後，在KVO觀察每個操作的isFinished屬性後，可變字典保持清晰，以確保所有操作保留計數實際上在完成後釋放。

感謝Guiliano提供了使用KVO來解決這個問題的提示！

Answer 1

我建議檢查您的架構和移動委託類（假設的QueueManager）管理，而不必在每個操作的代表隊：

• 創建QueueManagerDelegate是 實現方法（）你需要 通知viewControllers

• 在的QueueManager添加志願觀察員每個的NSOperation（的isFinished屬性來完成這個添加操作到前隊列;））

• 在國際志願者組織的回調調用的委託方法（）你只需要當代表是=零

• 添加無效的方法的QueueManager和調用這個方法！ UIViewController中（一個或多個）的dealloc方法

  - （無效）無效 { 自>委託=零; }

的情況下，你需要對志願刷新：Kvo programming guide

Answer 2

這裏最好的建議是查看應用程序的架構以避免這種情況。但是，如果當前代碼無法更改，請使用NSNotificationCenter。每次你的視圖控制器被釋放，你可以發佈通知，這個通知必須通過NSOperationQueue持有者，在通知處理程序中的簡單foreach循環到無解除分配視圖控制器的代表。應該做的伎倆。

Answer 3

您還應該檢查以確保任何代表（如果非零）也能夠響應操作完成中的消息。您可以使用所有NSObject子類所提供的respondsToSelector函數執行此操作。

在我的項目，我已經抽象該檢查到上NSObject的一個類別，讓我安全地調用代表與對象參數的任意數目：

- (void) dispatchSelector:(SEL)selector target:(id)target objects:(NSArray*)objects onMainThread:(BOOL)onMainThread {

if(target && [target respondsToSelector:selector]) { // Do your delegate calls here as you please } }

你可以在這裏看到完整的例子： https://github.com/chaione/ChaiOneUtils/blob/master/Categories/NSObject-Dispatch.m