iOS 网络连接失败策略建议
iOS Network Connection Failure Policy suggestions
我正在寻找有关处理 iPhone 应用程序 (iOS9/Swift2/Xcode7) 网络连接问题的最佳方法的建议，以提供最佳用户体验，因为我们知道移动数据网络是不可靠。我有我的编码选项，但我想知道什么对其他有经验的技术人员来说效果很好。那里有很多信息，但我找不到特定于连接失败时发生的策略的信息。
这是我想实施的处理失败连接的基本策略（以及问题）：
- 应用向api.myserver.com发送请求，请求失败
- 等待 X 秒，然后再次尝试请求 api.myserver.com（您建议尝试多少次以及在什么时间间隔尝试？）
- 尝试 ping 其他服务器（即 google.com）以查看我们是否可以访问 api.myserver.com
以外的资源
- 如果我们可以成功 ping google.com，那么我们就知道我们的互联网正在工作，所以我们再次尝试 ping api.myserver.com
- 如果最后一次 ping 失败，我们会提醒用户由于某种原因我们无法通信，稍后再试
我正在使用 Apple 技术人员推荐的 this SO answer 中概述的理念，这通常意味着您始终首先检查与服务器的连接，使用可达性作为单独检查以确保 phone 硬件可用。
在此过程中的任何时候，如果 Reachability 为 false，那么我们会将我们的请求放入队列中，以便在 phone 硬件连接恢复时再次尝试。
我想我已经掌握了所涉及的代码，但正在寻找像 "this is what worked for our app and gives a good user experience during connection issues...and was approved for use in the Apple app store..." 这样的见解。我理解 trying/retrying 连接失败并提醒用户的概念（目前我的代码已经成功地做到了这一点），但在我应该尝试重新连接多少次的良好策略上仍然不可靠每隔多长时间？
对于我开发的大多数应用程序，定义几个具有不同规则的请求类别很有用。对于每个类别，请考虑重试是否合适，以及在将请求视为失败之前您真正能够等待多长时间。
- 最敏感的是阻塞请求，用户必须允许它们完成才能继续。登录、结帐、一些编辑操作等。对于这些通常不值得重试 (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
我不会假设这是真的，我也不认为向第三方发出额外请求会帮助您对何时尝试访问您自己的系统做出有用的预测。这似乎是构建和维护的额外工作，并且可能比有价值的信息更容易成为误导性结果的来源。您认为这会在什么情况下为您的应用或其用户提供有用的信息？
可能不是您要找的答案，希望它仍然有用。
免责声明：我的经验偏向于具有一组相当简单的 REST 或 RPC 样式网络请求的应用程序。如果您正在处理需要流数据、P2P 连接或其他一些场景的问题，那么不要从这些假设开始。
(1) 这里有一个尾注，因为我经常将其视为失败的根源：这些请求确实应该是幂等的。是的，即使是那些创建新资源、检查您的购物车等的 POST。当您不能安全地重复请求时，您最终会看到请求已完成但客户端从未收到确认的情况，因此看起来像是失败。通过重试（自动或用户触发）同一请求来恢复比检测重复请求并从中恢复要容易得多。
为了更好的网络性能。在我的应用程序中，我使用在每个 API 请求之前 ping Google 服务器，如果它可以访问，然后我调用我的服务器 API 否则没有网络警报。
如果你在 wifi 网络上，那么你也必须这样做，因为 wifi 可达性只检查 wifi 连接而不检查网络访问。
我正在寻找有关处理 iPhone 应用程序 (iOS9/Swift2/Xcode7) 网络连接问题的最佳方法的建议，以提供最佳用户体验，因为我们知道移动数据网络是不可靠。我有我的编码选项，但我想知道什么对其他有经验的技术人员来说效果很好。那里有很多信息，但我找不到特定于连接失败时发生的策略的信息。
这是我想实施的处理失败连接的基本策略（以及问题）：
- 应用向api.myserver.com发送请求，请求失败
- 等待 X 秒，然后再次尝试请求 api.myserver.com（您建议尝试多少次以及在什么时间间隔尝试？）
- 尝试 ping 其他服务器（即 google.com）以查看我们是否可以访问 api.myserver.com 以外的资源
- 如果我们可以成功 ping google.com，那么我们就知道我们的互联网正在工作，所以我们再次尝试 ping api.myserver.com
- 如果最后一次 ping 失败，我们会提醒用户由于某种原因我们无法通信，稍后再试
我正在使用 Apple 技术人员推荐的 this SO answer 中概述的理念，这通常意味着您始终首先检查与服务器的连接，使用可达性作为单独检查以确保 phone 硬件可用。
在此过程中的任何时候，如果 Reachability 为 false，那么我们会将我们的请求放入队列中，以便在 phone 硬件连接恢复时再次尝试。
我想我已经掌握了所涉及的代码，但正在寻找像 "this is what worked for our app and gives a good user experience during connection issues...and was approved for use in the Apple app store..." 这样的见解。我理解 trying/retrying 连接失败并提醒用户的概念（目前我的代码已经成功地做到了这一点），但在我应该尝试重新连接多少次的良好策略上仍然不可靠每隔多长时间？
对于我开发的大多数应用程序，定义几个具有不同规则的请求类别很有用。对于每个类别，请考虑重试是否合适，以及在将请求视为失败之前您真正能够等待多长时间。
- 最敏感的是阻塞请求，用户必须允许它们完成才能继续。登录、结帐、一些编辑操作等。对于这些通常不值得重试 (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
我不会假设这是真的，我也不认为向第三方发出额外请求会帮助您对何时尝试访问您自己的系统做出有用的预测。这似乎是构建和维护的额外工作，并且可能比有价值的信息更容易成为误导性结果的来源。您认为这会在什么情况下为您的应用或其用户提供有用的信息？
可能不是您要找的答案，希望它仍然有用。
免责声明：我的经验偏向于具有一组相当简单的 REST 或 RPC 样式网络请求的应用程序。如果您正在处理需要流数据、P2P 连接或其他一些场景的问题，那么不要从这些假设开始。
(1) 这里有一个尾注，因为我经常将其视为失败的根源：这些请求确实应该是幂等的。是的，即使是那些创建新资源、检查您的购物车等的 POST。当您不能安全地重复请求时，您最终会看到请求已完成但客户端从未收到确认的情况，因此看起来像是失败。通过重试（自动或用户触发）同一请求来恢复比检测重复请求并从中恢复要容易得多。
为了更好的网络性能。在我的应用程序中，我使用在每个 API 请求之前 ping Google 服务器，如果它可以访问，然后我调用我的服务器 API 否则没有网络警报。
如果你在 wifi 网络上，那么你也必须这样做，因为 wifi 可达性只检查 wifi 连接而不检查网络访问。