Видимое поведение блокировки в веб-сокете JavaScript на мобильном Safari

Мы столкнулись с настоящим умом, и я надеялся, что кто-нибудь сможет пролить свет на мою проблему.

Приложение, которое яm writing - это клиент на основе JS, который, по сути, является службой общего доступа к рабочему столу. Служба захватывает изображения с рабочего стола, кодирует их в виде jpegs в формате base64 и отправляет их через веб-сокет клиенту JS. Затем клиент отображает эти изображения (как URI данных), пользователи могут перемещать мышь над изображением, а также щелкать изображение, эти события мыши кодируются в виде команд в XML, которые помещаются в очередь и обслуживаются по таймеру каждые 15 мс. Таким образом, очередь может быть очищена от избыточных или дублирующих команд перед отправкой в службу. Затем эти команды выполняются (генерирование событий щелчка на рабочем столе, перемещение мыши и т. Д.), Создаются новые изображения рабочего стола и цикл продолжается.

Вся система работает очень хорошо, за исключением некоторых очень противоречивых действий в Safari на iPad. По сути, когда пользователь перемещает палец по экрану, клиент, кажется, блокирует (или, возможно, удаляет приоритеты) входящие сообщения в веб-сокете, в пользу только отправки исходящих сообщений. Это проявляется в том, что когда вы двигаете пальцем, дисплей не будет обновляться, пока вы касаетесь экрана, а затем, как только вы поднимете палец, onMessage () получит поток обновлений изображения, которые затем анимируются на экране в быстрой последовательности.

Mobile Safari - единственный браузер, который, по-видимому, ведет себя таким образом, ни один из настольных браузеров или планшеты AndroidЯ проверил, кажется, показывают то же самое поведение.

поместили вход в методы входящего и исходящего трафика в веб-сокете, и это подтверждает поведение I 'видел. На сафари яя получу множество исходящих сообщений подряд, за которыми последуют многочисленные входящие сообщения, тогда как на Android явы будете видеть входящие и исходящие сообщения, чередующиеся при перемещении пальца по экрану, в результате дисплей на Android будет продолжать обновляться по мере перемещения пальцем по экрану.

Основная причина, по которой я подозреваю, что веб-сокет является виновником, заключается в том, что у клиента есть резервный механизм, поэтому, если браузер не поддерживает веб-сокет, создается пара объектов XHR (один для входящего и один для исходящего) и используется вместо него. паутины. Если я заставлю мобильный Safari использовать XHR вместо веб-сокетов, проблема исчезнет. В этом случае изменяется только механизм связи (весь код для ввода входных событий и отображения изображений остается неизменным).

Я понимаю, что это довольно специфическая проблема, и без кода ее будет очень трудно диагностировать, но я решил не публиковать код просто из-за огромного объема кода в клиенте.

Если кто-то видит поведение, похожее на то, что яописал или знаю какие-либо потенциальные причины такого поведения, яБуду очень благодарен за ваш вклад.

Ответы на вопрос(1)

Ваш ответ на вопрос