javascript - 移动 Safari 上 JavaScript websocket 中的明显阻塞行为

Question

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

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

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

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

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

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

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

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

Answer 1

根据数据包的大小，您可能会遇到“大”消息的问题，在 Safari(iPad 和台式机)上速度极慢。您是否尝试过桌面版 Safari？

看看this page , 以查看不同浏览器之间的性能比较。

这可能是您的问题。