Android 定时 http 请求饥饿
你好，我正在开发一个使用 std web 视图和 chrome 浏览器的 adroid 应用程序。 我需要每 500 毫秒向服务器执行 1 个 http 请求，但我发现线程以某种方式停止或延迟，调用服务器的 php 使用请求时间执行登录到我的数据库，并且在某些时间我没有收到任何请求，我一下子收到一堆请求后不久。
是否对线程执行任何锁定或睡眠？
我做了一些测试，该操作一开始是由 javascript 执行的，并且遇到了同样的问题，所以我将控制权移到了 android 线程上，以避免 js 上的问题，但即使是 android 应用程序旁边的线程也有同样的问题。
我们发现，如果我们移动平板电脑并强制页面旋转，应用程序将再次激活并重新开始工作。
有什么想法吗？
我不直接开发Android应用程序，我负责应用程序的Web部分（服务器端应用程序和html + js）。所以我的Android经验有点有限，我在网络上搜索，没有找到任何可以帮助我的朋友解决这个问题的方法 。
感谢大家
Hello i'm developing an adroid app that uses the std web view and chrome browser.
I need to perform 1 http request every 500 millisec to the server but i see that the thread is somehow stopped or delayed, the php called to the server performs a log into my database with the request time and at certain time i receive no requests, a little time after i receive a stack of reqeusts all at once.
Is there any lock or sleep performed over threads ?
I made a couple of tests and the action was performed by javascript in the beginning and had same problem so i moved the control over an android thread to avoid problems over the js but even the thread iside the android app have the same issue.
We discovered that if we move the tablet and force a page rotation the app goes alive again and start working again.
Any idea ?
I'm not developing the android app directly i take care of the web part of the app (server side application and html+js. So my android experience is a bit limited, i searched over web and found nothing to help my friend solve this out.
Thanks to all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我敢打赌，代码中的时序逻辑有点损坏。 500 毫秒并不比您在许多 3G 和 4G 网络上看到的典型往返延迟长多少。如果代码没有正确考虑请求花费的时间比重复时间更长的可能性，您可能会遇到代码等待时间越来越长的错误。
这是一个类比：假设你应该每小时去一次商店。现在是 1:00，你正要去商店。您意识到您下次需要在 2:00 去商店。所以你去商店然后回来。现在你需要等到2:00。但如果已经是 2:05，您就会等待太久。
My bet is the timing logic in the code is a bit broken. 500 milliseconds is not much more than typical round trip latency you might see on many 3G and 4G networks. If the code doesn't correctly account for the possibility that the request will take longer than the repeat time, you may get bugs where the code winds up waiting longer and longer.
Here's an analogy: Say you are supposed to go to the store every hour. It's 1:00 and you're about to go to the store. You realize that you need to go to the store next at 2:00. So you go to the store and come back. Now you need to wait until it's 2:00. But if it's already 2:05, you'll be waiting way too long.