我遇到了一个真正令人头疼的人，我希望有人能澄清我的问题。
我正在编写的应用程序是一个基于JS的客户端，本质上是一个共享服务的桌面。该服务从桌面捕获图像，将其编码为base64编码的jpegs，并通过websocket将其发送到JS客户端。然后，客户端显示这些图像（作为数据URI），用户可以将鼠标移到图像上，也可以点击图像，这些鼠标事件被编码为XML命令，这些命令被放入队列中，并每隔15毫秒在计时器上提供服务，这样，在发送到服务之前，队列中就可以清除冗余或重复的命令。然后执行这些命令（在桌面上生成点击事件、移动鼠标等），生成新的桌面图像，并继续循环。
整个系统运行得非常好，除了iPad上Safari上的一些非常不一致的行为。本质上，当用户在屏幕上移动手指时，客户端似乎会阻止（或可能取消优先级）websocket上的传入消息，而只发送传出消息。显而易见的是，当你移动手指时，只要你触摸屏幕，显示器就不会显示更新，然后一旦你抬起手指，onMessage（）就会收到大量的图像更新，然后快速连续地在屏幕上显示动画。
Mobile Safari是唯一一款表现出这种行为的浏览器，我测试过的桌面浏览器或任何安卓平板电脑都没有表现出同样的行为。
我已经将日志记录放入websocket上的入站和出站方法中，它证实了我所看到的行为。在Safari上，我会连续收到许多出站消息，然后是许多入站消息，而在Android上，当你在屏幕上拖动手指时，我会看到入站和出站消息交错，因此，当你拖动手指时Android上的显示将继续更新。
我怀疑websocket是罪魁祸首的主要原因是因为客户端有一个回退机制，因此如果浏览器不支持websocket，就会创建一对XHR对象（一个用于入站，一个用于出站）并使用它来代替websocket。如果我强制移动Safari使用XHR而不是websocket，问题就会消失。在这种情况下，只有通信机制改变（用于捕获输入事件和显示图像的所有代码保持不变）。
我意识到这是一个非常具体的问题，如果没有代码，很难诊断，但我选择不发布代码，只是因为客户端中的代码量太大了。
如果有人看到了与我描述的类似的行为，或者知道这种行为的任何潜在原因，我将非常感谢您的意见。
根据数据包的大小，您可能会面临"大"消息的问题，在Safari上（在iPad和桌面上）速度非常慢。你试过桌面Safari吗？
请查看此页面，查看不同浏览器之间的性能比较。
这可能是你的问题。