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

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

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

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

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

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

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

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