我正在开发一个web应用程序，使用Comet隐藏iFrame技术将数据从服务器推送到移动浏览器。
在移动Safari上一切都很好，但Android要痛苦得多。似乎需要从服务器发送4 KB的消息才能将消息考虑在内。这适用于每条消息，而不仅仅是第一条消息。
有些人尝试使用XMLHttpRequest流实现Comet，但有相同的4KB问题(http://code.google.com/p/android/issues/detail?id=13044)
有没有人在Android浏览器上实现Comet技术而不需要将消息填充到4KB ?
在Android 2.1、2.2上测试
服务器发送事件似乎不支持甚至在版本Android 4.0http://caniuse.com/eventsource
websocket也一样http://caniuse.com/websockets
感谢seb
不确定它是否符合您当前问题的答案，但一般建议使用一种面向未来的技术，该技术可以退回到相当好的polyfill。
对于您的特定问题，我相信WebSockets是最好的技术，与WebSocket服务器(node.js, Kaazing)相结合，具有良好的后备选项。我更熟悉Kaazing:它在不兼容WebSocket的浏览器上提供的性能几乎与本机WebSocket性能相同。有关WebSocket仿真的更多信息，您可能会发现这篇文章对WebSocket仿真很有用。
这个4KB缓冲区问题已经存在很长时间了，在桌面浏览器和Android Internet上仍然存在。app(我不知道)。
解决方案是在初始连接中发送4KB块。在这种情况下，HTTP流是比HTTP长轮询更好的解决方案。使用流媒体，当有新数据可用时，您将保持连接打开，而不像长轮询，您关闭然后重新打开连接。这种技术意味着最初会有4KB的无用数据块，但超过4KB的所有数据都是实际数据(可用)。我花了好几个小时来处理这个缓冲区大小，有时浏览器之间的缓冲区大小不一致。
但是，有像Caplin Systems这样的公司在他们的企业级应用程序中使用HTTP流，被许多金融机构使用，所以有可能使其始终如一地工作。
有没有人在Android浏览器上实现Comet技术而不需要将消息填充到4KB ?
这是极不可能发生的。而WebSockets(正如@Peter Moskovits所指出的)是这种双向通信(目前强调推送)将在未来跨浏览器实现的方式。对于Android来说，这意味着用户还需要在他们的设备上安装Flash，以便互联网应用程序支持Flash回退技术，因为Android目前不支持WebSockets。
在Android上，和浏览器，和rgd。尚:
-
Firefox Mobile支持(包括最终RFC6455)
-
内置浏览器不支持WS(包括Android 4)
-
Chrome for Mobile(完整RFC6455) ..仅适用于Android 4