這與解析相關，但可能與任何對基於雲的數據的調用相關。通過一個回調塊觸發一個異步調用，並通過鏈路調節器進行100％數據包丟失測試會帶來挑戰。我有一個模板管理這一切，取消該進程，停止運行內部模塊的代碼應該以往任何時候都決定返回，取消優異的異步呼叫？
但..
的實際調用，保持滾動，在這種情況下，解析的（例如）SaveInBackgroundWithBlock ...只是似乎不斷嘗試和嘗試，即使應用程序正在滾動到其他東西。
我還沒有找到任何能夠聯繫並殺死這些電話的參考資料，並且想到如果可能的話在這裏詢問如何去做。
它通常是一個棘手的問題。
首先，沒有辦法停止任何後臺任務（當然，沒有，我會永遠不敢在我的iOS代碼中使用）。您只能禮貌地要求後臺任務停止，例如通過調用「取消」方法。
因此，如果你寫一個任務在後臺運行，應該可以取消，它需要一個「取消」方法，你的代碼需要不時檢查是否取消，在這種情況下，停止做工作並告訴其他人取消（NSOperationQueue對此有一些支持，這是IMO與GCD相比的唯一優勢）。
如果您已經啓動了一個無法取消的異步操作，那麼您將被卡住。抱歉。異步操作需要檢查自身，如果沒有內置功能，則不能從外部停止。因此，如果取消是不可能的，則唯一可以做的事情是確保無論該操作如何，如果成功，結果不能再使用，並且如果失敗，則不應向用戶顯示錯誤。
您需要一些描述符或對您開始的任務的引用。如果Parse不提供任何這些信息，您可能無法取消該任務。
解析的異步調用本質上是黑盒子，所以我猜想，直到他們決定打開這個部分，我們留下了執行代碼的遺留位。這可能會影響我的唯一時間是在提交審覈期間，當鏈接調節器設置爲100％丟包時，希望它不會中止接受。 編輯：也許我說得太快了。現在看看BFTask，那裏可能有線索。 –
所有Parse的{Action} InBackgroundWithBlock方法都返回void，但{Action} InBackground返回BFTask。不確定爲什麼，因爲這會殺死取消任務的能力，但我們可以取消其他人。太糟糕了。我會直接問。 –