iOS网络哀求依次实行之信号量

藏宝库编辑 · 2024-9-12 15:51:42

起首分析需求点：依次发起哀求op1、op2、op3，要求op1乐成后再发起op2，若失败，则后续op2、op3不实行，回调失败结果；同理，若op1乐成后，发起op2哀求失败，则op3不实行，回调失败结果。
终极参考代码：Demo
先看一段网络常见示例：

从结果上看，满意哀求的次序实行，但是实际利用后，环境变得不一样了：

从结果日志上看，op2并未期待op1哀求竣过后再发起，这就导致了无法根据op1的哀求结果来判断op2是否可以或许发起，这就无法实现文章开始提到的结果。
修改方案：利用信号量来控制线程的实行：

从哀求结果看，这个已经满意了利用需求，但是这并没有竣事，出现的主线程死锁。
从结果可以看到，由于requestAction的回调是在主线程中实行的，而此时主线程又在期待回调后的信号量以继承实行，从而形成了死锁，更有甚者，如果UI上存在动画大概loading的，此时也会卡死。
那么这种环境下改怎样处置惩罚？
办理方法：

制止将dispatch_semaphore_wait() 放置于主线程中，而是放置到对应的子线程中举行，终极修改后的代码：

总结：原本不是复杂的场景，但是由于加入了线程的操纵而轻易出现错误，这个方案只是在碰到这个小题目的记录，如果您有更好的办法可以或许实现这个场景，欢迎您留言！

iOS网络哀求依次实行之信号量

所属分类: 问答交流

新帖推荐: 30日

推荐作品