iOS 网络连接失败策略建议

Question

我正在寻找有关处理 iPhone 应用程序 (iOS9/Swift2/Xcode7) 网络连接问题的最佳方法的建议，以提供最佳用户体验，因为我们知道移动数据网络不可靠。我有我的编码选项，但我想知道什么对其他有经验的技术人员来说效果很好。那里有很多信息，但我找不到任何特定于连接失败时发生的策略的信息。

这是我处理我想要实现的失败连接的基本策略(以及问题):

App 向 api.myserver.com 发送请求，请求失败

等待 X 秒，然后再次尝试向 api.myserver.com 发出请求(您建议尝试多少次以及在什么时间间隔？)

尝试 ping 其他服务器(即 google.com)以查看我们是否可以访问 api.myserver.com 以外的资源

如果我们可以成功 ping google.com，那么我们就知道我们的互联网正在工作，所以我们再次尝试 ping api.myserver.com

如果最后一次 ping 失败，我们会提醒用户由于某种原因我们无法通信并稍后重试

我正在使用 this SO answer 中概述的理念由 Apple 技术人员推荐，这通常意味着您始终首先检查与服务器的连接，使用可达性作为单独检查以确保手机硬件可用。

在此过程中的任何时候，如果 Reachability 为 false，那么我们会将我们的请求放入队列中，以便在电话硬件连接恢复时再次尝试。

我想我已经掌握了所涉及的代码，但正在寻找诸如“这对我们的应用程序有效并在连接问题期间提供良好的用户体验......并被批准在 Apple 应用程序商店中使用.. .”。我理解在失败的情况下尝试/重试连接并提醒用户的概念(目前我的代码已经成功地做到了这一点)，但仍然没有确定我应该尝试重新连接多少次以及在什么情况下使用的好策略间隔？

Answer 1

对于我处理过的大多数应用程序，定义几个具有不同规则的请求类别很有用。对于每个类别，请考虑重试是否合适，以及在考虑请求失败之前您真的可以等待多长时间。

最敏感的是阻塞请求，用户在继续之前必须允许完成的事情。登录、结帐、一些编辑操作等。对于这些通常不值得重试 (1) 并且需要立即将失败传达给用户:如果设备离线，让用户决定何时重试，如果请求失败你可能已经让用户等待太久了。由于故障往往会阻止用户，因此它们通常也需要突出显示。

不太敏感的通常使用已启动但非阻塞的操作:下拉刷新、加载所选集合项的详细信息或执行搜索。您的用户可能正在等待查看结果，但可能可以随意放弃或在应用程序中的其他地方导航，稍后再回来查看。仍然需要传达失败，以便用户可以选择重试或至少知道停止等待，但这些失败的通知可能不那么突出。这里重试开始有意义。我通常首先尝试从用户的角度定义时间限制，在应用程序被破坏之前他们将等待多长时间，然后将其作为请求可以等待连接或进行任意次数重试响应的时间限制到失败的连接。

更不敏感的是仅由您的用户间接触发的请求；轮询更新、加载非必要图像、预热缓存。这些您可能会重试，但失败的影响通常很小，可能无关紧要。

在所有这些请求中，您的重试策略实际上只影响 #2，因此我会确保您在担心之前确实有这种类型的请求。假设这些确实适用于您的应用程序......

Wait X second(s) and try request to api.myserver.com again (how many tries and at what time interval would you suggest?)

我会在这里设置一些时间间隔(几十到几百毫秒，取决于你的正常 api 性能)以避免意外的请求泛滥。当我没有充分的理由时，我不想建议一个精确的数字。

我的经验是，优化此值不太可能对您的用户产生明显的影响，因为请求通常需要数百毫秒才能失败，而用户只愿意等待几千毫秒，因此在此期间发出 1、5 或 10 个请求并没有真正改变最终结果。如果您能够为用户设定不同的期望，那么您的结果可能会有所不同。

Try pinging some other server (i.e. google.com) to see if we can access a resource other than api.myserver.com If we can successfully ping google.com then we know our internet is working, so we try once again to ping api.myserver.com

我不认为这是真的，我也不认为向第三方提出额外请求将有助于您对何时尝试访问自己的系统做出有用的预测。这似乎是构建和维护的额外工作，并且可能比有值(value)的信息更容易产生误导性结果。您认为在什么情况下这会为您的应用或其用户提供有用的信息？

也许不是您正在寻找的答案，希望它仍然有用。

免责声明:我的经验偏向于具有一组相当简单的 REST 或 RPC 样式网络请求的应用程序。如果您正在处理一个需要流数据、P2P 连接或其他一些场景的问题，那么不要从这些假设开始。

(1) 这里有一个结尾说明，因为我经常将其视为失败的根源:这些请求应该真的是幂等的。是的，即使是那些创建新资源、查看购物车或其他内容的帖子。当您无法安全地重复请求时，您最终会看到请求已完成但客户端从未收到确认，因此看起来像是失败的情况。通过相同请求的重试(自动或用户触发)进行恢复比检测和从重复请求中恢复要容易得多。