Android浏览器的替代服务器推送/ Comet实现，而不发送4KB消息？

Question

我正在开发一个web应用程序，它使用Comet Hidden iFrame技术将数据从服务器推送到移动浏览器。

一切都在Mobile Safari上运行得很好，但Android要痛苦得多。似乎需要从服务器发送4KB的消息，才能将消息考虑在内。这是针对每条消息的，而不仅仅是第一条消息。

有些人尝试使用XMLHttpRequest流实现Comet，但遇到了相同的4KB问题(http://code.google.com/p/android/issues/detail?id=13044)

有没有人能够在Android浏览器上实现Comet技术，而不需要将消息填充到4KB？

在Android 2.1、2.2上测试

服务器发送的事件似乎不支持，即使在版本Android4.0 http://caniuse.com/eventsource上也不支持

websocket http://caniuse.com/websockets也是如此

谢谢

-seb

Answer 1

我不确定它是否有资格作为您当前问题的解决方案，但一般的建议是使用一种面向未来的技术，这种技术可以退回到一个相当好的polyfill。

对于您的特定问题，我认为WebSockets是最好的技术，与WebSocket服务器(node.js、Kaazing)相结合，具有良好的后备选项。我更熟悉Kaazing:它在非WebSocket兼容的浏览器上提供与原生WebSocket性能几乎相同的性能。

Answer 2

这个4KB的缓冲区问题已经存在很长一段时间了，在桌面浏览器和安卓Internet.app (我不知道这一点)上仍然存在这个问题。

解决方案是在初始连接中发送一个4KB的块。在这种情况下，HTTP Streaming是比HTTP Long-Polling更好的解决方案。使用流，您可以在新数据可用时保持连接打开，这与长轮询不同，长轮询需要关闭连接，然后重新打开连接。这种技术意味着，最初不幸的是有4KB的无用数据块，但在此之后的所有数据都是实际数据(可用)。我花了几个小时的时间来处理这个缓冲区大小，有时它在不同的浏览器之间是不一致的。

但是，像Caplin Systems这样的公司在他们的企业级应用程序中使用HTTP流，许多金融机构都在使用它，因此有可能让它一直很好地工作。

有没有人能够在安卓浏览器上实现Comet技术，而不需要将消息填充到4KB？

这种情况发生的可能性非常小。和WebSockets (正如@Peter Moskovits指出的那样)是这种双向交流(目前重点是推送)将在未来跨浏览器实现的方式。对于安卓来说，这确实意味着用户还需要在他们的设备上安装闪存，以使互联网应用程序支持闪存回退技术，这是必需的，因为安卓目前还不支持WebSockets。

Answer 3

在Android上，在浏览器和rgd上。WebSockets：

• Firefox移动版支持(包括最终的RFC6455)
• builtin浏览器不支持任何WS (包括安卓4)移动版
• Chrome(完整RFC6455版) ..仅适用于Android 4