6

我遇到了一个真正令人头疼的问题,我希望有人能对我的问题有所了解。

我正在编写的应用程序是一个基于 JS 的客户端,它本质上是一个桌面共享服务。该服务从桌面捕获图像,将它们编码为 base64 编码的 jpeg,然后通过 websocket 将它们发送到 JS 客户端。然后客户端显示这些图像(作为数据 URI),用户可以将鼠标移动到图像上以及单击图像,这些鼠标事件被编码为 XML 中的命令,这些命令被放入队列中,每 15 毫秒在计时器上提供服务,这样可以在发送到服务之前清除队列中的冗余或重复命令。然后执行这些命令(在桌面上生成点击事件、移动鼠标​​等),并生成新的桌面图像并继续循环。

整个系统运行得非常好,除了在 iPad 上的 Safari 上的一些非常不一致的行为。本质上,当用户在屏幕上移动手指时,客户端似乎会阻止(或可能取消优先级)websocket 上的传入消息,而只支持发送传出消息。显而易见的方式是,当您移动手指时,只要您触摸屏幕,显示就不会更新,然后一旦您抬起手指,onMessage() 就会收到大量图像更新,然后快速连续地在屏幕上显示动画。

移动 Safari 是唯一出现这种行为的浏览器,桌面浏览器或我测试过的任何 Android 平板电脑都没有表现出相同的行为。

我已经将登录放入 websocket 上的入站和出站方法,它确认了我所看到的行为。在 Safari 上,我会连续收到大量出站消息,然后是大量入站消息,而在 Android 上,当您在屏幕上拖动手指时,我会看到入站和出站消息交错,因此在 Android 上显示将在您拖动手指时继续更新。

我怀疑websocket是罪魁祸首的主要原因是因为客户端有一个回退机制,所以如果浏览器不支持websocket,就会创建一对XHR对象(一个用于入站,一个用于出站)并使用的 websocket。如果我强制移动 Safari 使用 XHR 而不是 websockets,问题就会消失。在这种情况下,只有通信机制发生了变化(用于捕获输入事件和显示图像的所有代码都保持不变)。

我意识到这是一个非常具体的问题,没有代码将很难诊断,但我选择不发布代码只是因为客户端中的代码量很大。

如果有人看到与我所描述的行为类似的行为,或者知道这种行为的任何潜在原因,我将非常感谢您的意见。

4

1 回答 1

0

根据数据包的大小,您可能会遇到“大”消息的问题,在 Safari(iPad 和桌面)上非常慢。你试过桌面Safari吗?

看看这个页面,看看不同浏览器之间的性能比较。

这可能是你的问题。

于 2013-08-19T19:12:39.787 回答