Android 上的 DefaultHttpClient 超时值和重试
我面临的问题是我们的 Android 应用程序的 HTTP 请求经常超时，我需要为超时限制和重试次数找到合理的级别。
使用 apache DefaultHttpClient 的当前实现的解决方案（不是我的实现）正在执行三次手动重试，并增加超时，如下所示：
private static final int[] CONNECTION_TIMEOUTS = new int[] {4000, 5000, 10000};
private static final int[] SOCKET_TIMEOUTS = new int[] {5000, 8000, 15000};
我很难理解当前实现使用增加超时的基本原理以及它试图解决的问题。该应用程序大部分时间在手机连接3G时使用。有谁能解释为什么每次重试增加超时会更好，或者有人有在 3G 网络上处理 HTTP 请求的最佳实践吗？
I'm faced with a problem that our android app's HTTP requests quite often time out and I need to find a reasonable level for the timeout limits and the number of retries.
The current implemented solution (not my implementation) using apache DefaultHttpClient is doing three manual retries with increasing timeouts as followed here:
private static final int[] CONNECTION_TIMEOUTS = new int[] {4000, 5000, 10000};
private static final int[] SOCKET_TIMEOUTS = new int[] {5000, 8000, 15000};
I'm having a hard time understanding the rationale to why the current implementation is using increasing timeouts and what this is trying to solve. The app is most of the time used when the phone is connected to 3G. Does anyone have an explanation to why increasing timeouts with each retry would be preferable or perhaps someone has a best practice for HTTP request handling on 3G networks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我看不出有任何理由这样做，而不仅仅是从一开始就使用最大的超时。不过也许其他人可以。
也许有点离题，但我想提请您注意 这篇文章，建议迁移到
HttpURLConnection，因为它现在并且将来会得到更好的支持。通读全文，了解 HttpURLConnection 相对于 Apache 库的优点和缺点，并决定是否值得切换。I don't see any reason for doing that and not just using the biggest timeout from the start. Maybe someone else can, though.
Maybe a bit offtopic, but I'd like to draw your attention to this article, which suggests migrating to
HttpURLConnection, as it is and will be better supported in the future. Read it in whole, to see the advantages and disadvantages ofHttpURLConnectionover the Apache libs and decide whether or not it is worth it to switch.如果网络速度非常慢，可能需要很长时间才能连接。另一方面，即使在更快的网络上，连接也可能会失败。
因此，在快速网络中连接有点“丢失”的情况下，第一次尝试使用较短的超时时间以便更快地重试是有意义的。但我想不出超时持续增加的原因。
由于网络数量如此之多，因此几乎不可能收集有关典型连接和超时时间的良好数据。我假设您看到的数字不是根据经验选择的。
It's possible that with a really slow network, it might take a long time to connect. And on the other hand, it's possible that a connection would fail even on a faster network.
So it would make sense to have the first attempt with a shorter timeout to retry sooner in the case of a connection getting a bit "lost" in a fast network. But I can't think of a reason for the timeouts to continually increase.
Because there are such a large number of networks, it's almost impossible to collect good data about typical connection and timeout times. I assume that the numbers you see are not chosen empirically.