私は本当のヘッドスクラッチャーに遭遇しました.誰かが私の問題に光を当てることができることを望んでいました.
私が書いているアプリケーションは、基本的にデスクトップ共有サービス用の JS ベースのクライアントです。このサービスは、デスクトップから画像をキャプチャし、base64 でエンコードされた jpeg としてエンコードし、Websocket を介して JS クライアントに送信します。次に、クライアントはこれらの画像を (データ URI として) 表示します。ユーザーはマウスを画像の上に移動したり、画像をクリックしたりできます。これらのマウス イベントは XML のコマンドとしてエンコードされ、キューに入れられ、15 ミリ秒ごとにタイマーで処理されます。 、このようにして、サービスに送信される前に、キューから冗長または重複したコマンドをスクラブできます。次に、これらのコマンドが実行され (デスクトップでのクリック イベントの生成、マウスの移動など)、新しいデスクトップ イメージが生成され、サイクルが続行されます。
iPad 上の Safari で非常に一貫性のない動作がいくつかあることを除けば、システム全体は非常にうまく機能します。基本的に、ユーザーが画面上で指を動かすと、クライアントは Websocket の着信メッセージをブロック (または優先度を下げて) し、発信メッセージのみを送信するように見えます。これが明らかな方法は、指を動かしても、画面に触れている限りディスプレイが更新されないように見え、指を離すと大量の画像更新が onMessage() によって受信されることです。次に、画面にすばやく連続してアニメーション化されます。
Mobile Safari は、このように動作するように見える唯一のブラウザであり、デスクトップ ブラウザのどれも、または私がテストした Android タブレットのどれも、同じ動作を示すようには見えません。
Websocket のインバウンドおよびアウトバウンド メソッドにログを記録したところ、私が見た動作が確認されました。Safari では、多数の送信メッセージが連続して受信され、その後に多数の受信メッセージが続きます。一方、Android では、画面上で指をドラッグすると、受信メッセージと送信メッセージがインターリーブされて表示されます。指をドラッグすると、更新が続行されます。
私が Websocket が原因ではないかと疑う主な理由は、クライアントにフォールバック メカニズムがあるためです。ブラウザーが Websocket をサポートしていない場合、XHR オブジェクトのペアが作成され (インバウンド用とアウトバウンド用に 1 つずつ)、代わりに使用されます。ウェブソケットの。モバイル Safari で WebSocket の代わりに XHR を使用するように強制すると、問題は解決します。この場合、通信メカニズムのみが変更されます (入力イベントをキャプチャして画像を表示するためのコードはすべて同じままです)。
これは非常に具体的な問題であり、コードがなければ診断が非常に難しいことは理解していますが、クライアントのコードの量が非常に多いため、コードを投稿しないことにしました。
私が説明したのと同様の動作を見たことがある人、またはこの動作の潜在的な理由を知っている人がいる場合は、ご意見をお寄せください.