Видимое поведение блокировки в веб-сокете JavaScript на мобильном Safari
Я столкнулся с настоящим головокружением, и я надеялся, что кто-то там сможет пролить свет на мою проблему.
Приложение, которое я пишу, является клиентом на основе JS для того, что по сути является службой для совместного использования рабочего стола. Служба захватывает изображения с рабочего стола, кодирует их в виде jpegs в формате base64 и отправляет их через веб-сокет клиенту JS. Затем клиент отображает эти изображения (как URI данных), пользователи могут перемещать указатель мыши над изображением, а также нажимать на изображение, эти события мыши кодируются как команды в XML, которые помещаются в очередь и обслуживаются по таймеру каждые 15 мс. Таким образом, очередь может быть очищена от избыточных или дублирующих команд перед отправкой в службу. Затем эти команды выполняются (генерирование событий щелчка на рабочем столе, перемещение мыши и т. Д.), Создаются новые изображения рабочего стола и цикл продолжается.
Вся система работает очень хорошо, за исключением некоторых очень противоречивых действий в Safari на iPad. По сути, когда пользователь перемещает палец по экрану, клиент, кажется, блокирует (или, возможно, удаляет приоритеты) входящие сообщения в веб-сокете, в пользу только отправки исходящих сообщений. Это проявляется в том, что при перемещении пальца дисплей не будет обновляться до тех пор, пока вы касаетесь экрана, а затем, как только вы поднимете палец, onMessage() получит поток обновлений изображения, которые затем анимируются на экране в быстрой последовательности.
Mobile Safari - единственный браузер, который ведет себя таким образом, ни один из настольных браузеров или планшеты Android, которые я тестировал, не демонстрируют такого же поведения.
Я поместил регистрацию во входящие и исходящие методы на веб-сокете, и это подтверждает поведение, которое я видел. В Safari я получу множество исходящих сообщений подряд, за которыми следуют многочисленные входящие сообщения, тогда как в Android я буду видеть входящие и исходящие сообщения, чередующиеся при перемещении пальца по экрану, в результате чего на Android отображается будет продолжать обновлять, как вы таскаете пальцем.
Основная причина, по которой я подозреваю, что веб-сокет является виновником, заключается в том, что у клиента есть резервный механизм, поэтому, если браузер не поддерживает веб-сокет, создается пара объектов XHR (один для входящего и один для исходящего) и используется вместо него. паутины. Если я заставлю мобильный Safari использовать XHR вместо веб-сокетов, проблема исчезнет. В этом случае изменяется только механизм связи (весь код для ввода входных событий и отображения изображений остается неизменным).
Я понимаю, что это довольно специфическая проблема, и без кода ее будет очень трудно диагностировать, но я решил не публиковать код просто из-за огромного объема кода в клиенте.
Если кто-то видит поведение, подобное тому, что я описал, или знает о возможных причинах такого поведения, я был бы очень благодарен за ваш вклад.
1 ответ
В зависимости от размера пакетов вы можете столкнуться с проблемой "больших" сообщений, поскольку в Safari они работают очень медленно (как на iPad, так и на настольном компьютере). Вы пробовали настольное Safari?
Загляните на эту страницу, чтобы увидеть сравнение производительности разных браузеров.
Возможно, это ваша проблема.