5

私は、Comet Hidden iFrame 技術を使用してサーバーからモバイル ブラウザーにデータをプッシュする Web アプリケーションを開発しています。

Mobile Safari ではすべて正常に動作しますが、Android ではもっと面倒です。メッセージを考慮するには、サーバーから 4 KB のメッセージを送信する必要があるようです。これは、最初のメッセージだけでなく、各メッセージに対するものです。

XMLHttpRequest ストリーミングを使用して Comet を実装しようとした人もいますが、同じ 4KB の問題があります (http://code.google.com/p/android/issues/detail?id=13044)。

メッセージを 4KB にパディングする必要なく、Android ブラウザーに Comet テクニックを実装できた人はいますか?

Android 2.1、2.2 でテスト済み

サーバー送信イベントはバージョン Android 4.0 でもサポートされていないようです http://caniuse.com/eventsource

websocket http://caniuse.com/websocketsについても同じ

ありがとう

-セブ

4

3 に答える 3

2

それがあなたの当面の問題への答えとして適格であるかどうかはわかりませんが、一般的な推奨事項は、適度に優れたポリフィルにフォールバックする将来性のある技術を使用することです。

あなたの特定の問題については、WebSocketは、優れたフォールバックオプションを備えたWebSocketサーバー（node.js、Kaazing）と組み合わせた最高のテクノロジーであると私は信じています。私はKaazingに精通しています。これは、WebSocketに準拠していないブラウザーで、ネイティブのWebSocketのパフォーマンスと実質的に同じパフォーマンスを提供します。WebSocketエミュレーションの詳細については、この投稿がWebSocketエミュレーションで役立つ場合があります。

于 2011-11-23T07:50:05.760 に答える
1

この 4KB のバッファの問題は長い間存在しており、デスクトップ ブラウザや Android Internet.app (私は知りませんでした) でも依然として発生しています。

解決策は、最初の接続で 4KB のチャンクを送信することです。これは、 HTTP ストリーミングがHTTP ロングポーリングよりも優れたソリューションであるシナリオの 1 つです。ストリーミングでは、接続を閉じてから再度開くロングポーリングとは異なり、新しいデータが利用可能になったときに接続を開いたままにします。この手法は、最初の不幸な 4KB の役に立たないデータのチャンクがあることを意味しますが、それを超えるデータはすべて実際のデータ (使用可能) です。私はこのバッファ サイズをいじるのに何時間も費やしてきましたが、Web ブラウザ間で一貫性がない場合があります。

しかし、企業レベルのアプリケーションで HTTP ストリーミングを使用しているCaplin Systemsなどの企業があり、多くの金融機関で使用されているため、これを一貫してうまく機能させることができます。

メッセージを 4KB にパディングする必要なく、Android ブラウザーに Comet テクニックを実装できた人はいますか?

これが起こる可能性は非常に低いです。そして、WebSockets (@Peter Moskovits が指摘) は、この双方向通信 (現時点ではプッシュに重点を置いています) が将来クロスブラウザーで実現される方法です。Android の場合、これは、インターネット アプリケーションが Flash フォールバック技術をサポートするためにデバイスに Flash をインストールする必要があることを意味します。これは、現時点では Android が WebSocket をネイティブにサポートしていないためです。

于 2011-11-23T17:39:27.570 に答える