Android 1.6丢包
刚刚在 Android 1.6 (Sony Xperia X10) 上遇到以下情况：在同一设备上的 WebView 中使用 XMLHttpRequest 请求数据（例如 127.0.0.1:8080），同时通过 ServerSocket.accept() 提供数据包时，XMLHttpRequest 有时会卡住。调试器告诉我服务器实际上深入到 ServerSocket.accept() 中，例如。他已送达或未收到最后的请求。 WebViewCoreThread 被困在
Object.wait() line: 288
Request.waitUntilComplete() line: 381
RequestHandle.waitUntilComplete() line: 262
Network.requestURL(String, Map, byte[], LoadListener, boolean) line: 195
FrameLoader.handleHTTPLoad() line: 204
FrameLoader.executeLoad() line: 131
...
等待它的 http0 ... http3 线程，所有这些线程都在等待，
Object.wait(long, int) line: not available [native method]
RequestQueue(Object).wait() line: 288
ConnectionThread.run() line: 93
首先我以为请求数据包刚刚丢失。但这并不能解释为什么所有 http.. 线程都处于相同的等待位置，因为一个线程应该等待响应，而其他线程则等待来自 WebView 的新作业。有什么想法吗？
just encountered the following on Android 1.6 (Sony Xperia X10): When requesting data with XMLHttpRequest in a WebView on the same device (eg. 127.0.0.1:8080) while serving packets via ServerSocket.accept(), the XMLHttpRequest sometimes get stuck. The debugger tells me that the server actually is deep into ServerSocket.accept(), eg. he has served or not received the last request. The WebViewCoreThread is stuck at
Object.wait() line: 288
Request.waitUntilComplete() line: 381
RequestHandle.waitUntilComplete() line: 262
Network.requestURL(String, Map, byte[], LoadListener, boolean) line: 195
FrameLoader.handleHTTPLoad() line: 204
FrameLoader.executeLoad() line: 131
...
supposedly waiting for it's http0 ... http3 threads, that all wait at
Object.wait(long, int) line: not available [native method]
RequestQueue(Object).wait() line: 288
ConnectionThread.run() line: 93
First I thought the request packet just got lost. But that doesn't explain why all http.. threads are at the same waiting position, as one should wait for response, while the others for new jobs from WebView then. Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看来这确实是 Android 中的一个错误。可以通过在发送响应之前向服务器添加延迟来规避此问题。
This is indeed a bug in Android it seems. It can be circumvented by adding a delay to the server before the response is sent.