iOS 网络连接失败策略建议

Question

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

这是我想实施的处理失败连接的基本策略（连同问题）：

1. App 向 api.myserver.com 发送请求，请求失败
2. 等待 X 秒，然后再次尝试向 api.myserver.com 发出请求（您建议尝试多少次以及以什么时间间隔？）
3. 尝试 ping 其他服务器（即 google.com），看看我们是否可以访问 api.myserver.com 以外的资源
4. 如果我们可以成功 ping google.com，那么我们就知道我们的互联网正在工作，所以我们再次尝试 ping api.myserver.com
5. 如果最后一次 ping 失败，我们会提醒用户由于某种原因我们无法通信并稍后重试

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

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

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

Answer 1

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

1. 最敏感的是阻塞请求，用户必须允许完成这些操作才能继续。登录、结帐、一些编辑操作等。对于这些通常不值得重试 (1) 并且需要立即将失败通知给用户：如果设备离线，让用户决定何时重试，如果请求失败你可能已经让用户等待太久了。由于故障往往会阻止用户，因此通常还需要在显着位置进行沟通。
2. 不太敏感的通常是使用已启动但非阻塞的操作：拉动刷新、加载所选集合项的详细信息或执行搜索。您的用户可能正在等待查看结果，但可能会放弃或在应用程序的其他位置导航并稍后再回来查看。仍然需要传达失败，以便用户可以选择重试或至少知道停止等待，但这些失败的通知可能不那么突出。这里重试开始有意义。我通常首先尝试从用户的角度定义一个时间限制，他们将在应用程序感到损坏之前等待多长时间，然后将其作为请求可以等待连接或进行任意次数重试响应的时间限制到失败的连接。
3. 更不敏感的是仅由您的用户间接触发的请求；轮询更新、加载非必要图像、加热缓存。这些您可能会重试，但失败的影响通常很小，可能无关紧要。

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

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

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

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

尝试 ping 其他服务器（即 google.com），看看我们是否可以访问 api.myserver.com 以外的资源 如果我们可以成功 ping google.com，那么我们知道我们的互联网正在工作，所以我们再次尝试 ping api.myserver.com

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

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

---

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

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

Answer 2

为了更好的网络性能。在我的应用程序中，我会在每个 API 请求之前 ping Google 服务器，如果它可以访问，那么我调用我的服务器 API，否则没有网络警报。

如果您在 wifi 网络上，那么您也必须这样做，因为 wifi 可达性只检查 wifi 连接而不是网络访问。