Alamofire如何维护请求顺序？答案

【问题标题】：Alamofire how to maintain request order?Alamofire如何维护请求顺序？
【发布时间】：2021-12-26 16:22:45
【问题描述】：

我使用单个串行队列作为根队列/请求/序列化队列

let queue = DispatchQueue(label: "APIManager.rootQueue")
a.session = Session(configuration: sessionConfiguration,
                    delegate: a,
                    rootQueue: queue,
                    startRequestsImmediately: true,
                    requestQueue: queue,
                    serializationQueue: queue,
                    interceptor: nil,
                    serverTrustManager: nil,
                    redirectHandler: nil,
                    cachedResponseHandler: nil,
                    eventMonitors: [])

但是请求似乎是按照创建顺序的随机顺序完成的

完成打印到控制台：

[2][Request]: GET https://...
[1][Request]: GET https://...
[4][Request]: GET https://...
[3][Request]: GET https://...
[5][Request]: GET https://...

[]中的数字代表创建顺序 PS：序列化的时候顺序也是错误的

队列是串行的，但结果看起来像是并发的

如何保持请求和结果的 FIFO 顺序

【问题讨论】：

Completion is underorder，而“launch”是按顺序进行的...想象一下您的第五个请求需要 5 秒才能完成，但第一个很重的请求需要 30 秒，这似乎很正常对我来说。如果您只想在第一个请求启动后启动第二个请求，请在启动前监听第一个请求的完成情况。以此类推。
我希望在前一个火箭着陆后立即发射下一个火箭，例如。串行行为......这也很重要，因此服务器不会像启动应用程序时那样停滞不前，假设执行了多个请求并且服务器同时受到攻击
requestQueue 的文档：DispatchQueue on which to perform URLRequest creation. By default this queue will use the rootQueue as its target. A separate queue can be used if it's determined request creation is a bottleneck, but that should only be done after careful testing and profiling. nil by default. 在您的情况下，这只是串行的创建。它们会在可能的情况下启动，但不能保证它们的完成。毕竟，这就像一个默认的URLSession.shared.dataTask(...).resume()，如果您启动其中的10个，则无法保证完成顺序。
好的，问题仍然存在：“如何维护请求和结果的 FIFO 顺序”
否则，包装 Alamofire 并将请求加入队列也可能是一种方式......

标签： swift alamofire dispatch-queue alamofire-request alamofire5

【解决方案1】：

如果您想按顺序而不是并行发出请求，您可以：

嵌套它们。在上一个请求的完成处理程序中启动下一个请求。
将 Alamofire 请求包装在 Operations 中，并设置操作之间的依赖关系，以便它们按照您想要的顺序执行。
使用 Alamofire 的 Combine 集成发布第一个请求的响应，然后在下一个请求中发布 flatMap。
使用 Swift 的新并发功能来包装 Alamofire 的完成处理程序，以便您可以使用 async-await 语法。 Alamofire 将在即将发布的版本中直接支持此功能。

最终，您可能想要重新评估 FIFO 是否是您真正想要的，或者您是否可以构建一个不关心请求何时完成的系统。这样的系统可能会更容易管理，因为您消除了请求之间的依赖关系，并且性能更高，因为您消除了确保请求按正确顺序所需的任何等待。

【讨论】：