首先說明需求點:依次發(fā)起請求op1、op2、op3,要求op1成功后再發(fā)起op2,若失敗,則后續(xù)op2、op3不執(zhí)行,回調失敗結果;同理,若op1成功后,發(fā)起op2請求失敗,則op3不執(zhí)行,回調失敗結果。
最終參考代碼:Demo
先看一段網絡常見示例:
網上常見示例
從結果上看,滿足請求的順序執(zhí)行,但是實際使用后,情況變得不一樣了:
實際使用結果
從結果日志上看,op2并未等待op1請求結束后再發(fā)起,這就導致了無法根據op1的請求結果來判斷op2是否能夠發(fā)起,這就無法實現文章開始提到的效果。
修改方案:使用信號量來控制線程的執(zhí)行:
信號量實現方案
信號量請求結果
從請求結果看,這個已經滿足了使用需求,但是這并沒有結束,出現的主線程死鎖。
主線程死鎖
從結果可以看到,因為requestAction的回調是在主線程中執(zhí)行的,而此時主線程又在等待回調后的信號量以繼續(xù)執(zhí)行,從而形成了死鎖,更有甚者,如果UI上存在動畫或者loading的,此時也會卡死。
那么這種情況下改如何處理?
解決方法:
避免將dispatch_semaphore_wait() 放置于主線程中,而是放置到對應的子線程中進行,最終修改后的代碼:
Final
總結:原本不是復雜的場景,但是因為加入了線程的操作而容易出現錯誤,這個方案只是在遇到這個小問題的記錄,如果您有更好的辦法能夠實現這個場景,歡迎您留言!