IOS网络连接失败的政策建议

Question

我要找的建议，来处理iPhone应用程序（iOS9/Swift2/Xcode7）网络连接问题，提供最好的用户体验，因为我们知道，移动数据网络是最好的方式不可靠的。我有我的编码选项，但我想知道其他有经验的技术人员的工作情况。这里有很多信息，但没有什么我可以找到特定于在发生连接失败时发生的策略。

这是我对付失败的连接基本策略，我想实现（与问题）：

1. 应用程序发送请求api.myserver.com，请求失败
2. 等待X秒（S）和尝试要求再次api.myserver.com（多少次尝试，并在什么时间间隔你会建议？）
3. 尝试ping一些其他的服务器（即google.com），看看我们是否可以访问其他资源比api.myserver.com
4. 如果我们可以ping google.com然后w Ë知道我们的互联网是工作，所以如果这最后ping失败然后我们提醒，我们不能因为某种原因通信，并稍后再试

用户我们再次尝试ping api.myserver.com

我使用苹果技术，这在一般意味着你随时检查您的服务器的连接首先，使用可达性作为一个独立的检查，以保证手机的硬件可推荐this SO answer列出的理念。

在过程中如果可以访问是假，则我们会把我们的请求队列中的这个过程中随时可以再次尝试恢复手机硬件连接时。

我想我已经得到了所涉及的代码手柄，但寻找像见解：“这是什么工作对我们的应用程序，并给出了在连接问题的良好的用户体验......，并获准在苹果应用应用商店...”。我理解在出现故障时尝试/重试连接并提醒用户（目前我的代码已成功执行此操作）的概念，但仍然不适用于我应该尝试重新连接多次的良好策略以及间隔？

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）这里最后要说明一点，因为我经常把它看作失败的根源：这些请求应该是幂等的。是的，即使那些POST创建新的资源，检查您的购物车，或任何其他。当您无法安全地重复请求时，您最终会看到请求已完成但客户端从未收到确认的情况，因此看起来像是失败。通过对相同请求进行重试（自动或用户触发）来恢复比从重复请求中检测和恢复要容易得多。

Answer 2

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

如果您的WiFi网络上的时候，你也必须做同样的，因为无线网络的可达性只有WiFi连接检查没有进行网络访问。