Wpadłem na prawdziwego drapacza głowy i miałem nadzieję, że ktoś tam rzuci trochę światła na mój problem.

Aplikacja, którą piszę, jest klientem opartym na JS, służącym zasadniczo do udostępniania pulpitu usłudze. Usługa przechwytuje obrazy z pulpitu, koduje je, jako jpeg zakodowane w formacie base64 i wysyła je za pośrednictwem sieci Web do klienta JS. Następnie klient wyświetla te obrazy (jako identyfikatory URI danych), użytkownicy mogą przesuwać kursor myszy nad obrazem, a także klikać obraz, te zdarzenia myszy są kodowane jako polecenia w języku XML, które są umieszczane w kolejce i obsługiwane co minutę co 15 ms. W ten sposób kolejka może zostać usunięta z nadmiarowych lub zduplikowanych poleceń przed wysłaniem do usługi. Polecenia te są następnie wykonywane (generowanie zdarzeń kliknięcia na pulpicie, poruszanie myszą itp.) I generowane są nowe obrazy pulpitu i cykl jest kontynuowany.

Cały system działa bardzo dobrze, z wyjątkiem niektórych bardzo niespójnych zachowań w Safari na iPadzie. Zasadniczo, gdy użytkownik porusza palcem po ekranie, klient wydaje się blokować (lub być może de-priorytetyzować) przychodzące wiadomości na serwerze internetowym, na rzecz wysyłania tylko wiadomości wychodzących. Sposób, w jaki się to manifestuje, polega na tym, że podczas przesuwania palcem po ekranie, ekran nie wydaje się aktualizować tak długo, jak dotykasz ekranu, a gdy podniesiesz palec, onMessage otrzyma powódź aktualizacji obrazu (), które są szybko animowane na ekranie.

Mobile Safari to jedyna przeglądarka, która zachowuje się w ten sposób, żadna z przeglądarek komputerowych ani żaden z tabletów z Androidem, które testowałem, nie wydaje się wykazywać takiego samego zachowania.

Połączyłem logowanie do metod przychodzących i wychodzących na serwerze internetowym i potwierdza ono zachowanie, które widziałem. Na Safari dostanę wiele wiadomości wychodzących z rzędu, a następnie liczne wiadomości przychodzące, podczas gdy na Androidzie zobaczę wiadomości przychodzące i wychodzące przeplatane podczas przeciągania palcem po ekranie, w rezultacie na ekranie Android będzie kontynuował aktualizację, gdy przeciągasz palcem.

Głównym powodem, dla którego podejrzewam, że przyczyną problemów z serwerem jest winowajca, jest to, że klient ma mechanizm awaryjny, więc jeśli przeglądarka nie obsługuje sieci Web, tworzona jest para obiektów XHR (jedna dla ruchu przychodzącego i jedna dla ruchu wychodzącego) i używana zamiast tego WebSocket. Jeśli zmusię mobilne Safari do używania XHR zamiast gniazd sieciowych, problem zniknie. W tym przypadku zmienia się tylko mechanizm komunikacji (cały kod do przechwytywania zdarzeń wejściowych i wyświetlania obrazów pozostaje taki sam).

Zdaję sobie sprawę, że jest to dość specyficzny problem i bez kodu będzie bardzo trudno go zdiagnozować, ale zdecydowałem się nie pisać kodu po prostu z powodu ogromnej ilości kodu w kliencie.

Jeśli ktoś widzi zachowanie podobne do opisanego przeze mnie lub zna jakieś potencjalne powody takiego zachowania, byłbym bardzo wdzięczny za Twój wkład.