iOS網絡請求依次執(zhí)行之信號量

首先說明需求點:依次發(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

總結:原本不是復雜的場景,但是因為加入了線程的操作而容易出現錯誤,這個方案只是在遇到這個小問題的記錄,如果您有更好的辦法能夠實現這個場景,歡迎您留言!

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容