4

Web サービスの応答メッセージに関して言えば、どのくらいのデータが多すぎますか?

ネットワークの外で開いている Java で書かれた HTTP サーブレットがあります。データベースを呼び出し、ファイアウォールを介して JSON メッセージを送り返します。パケット ヘッダーを含まない、データのためだけに 344kb を話しています。私はこれを実質的なものとは考えていません。iOS と Android の両方のプラットフォームで応答を受信して​​おり、往復の合計は 1 秒から 15 秒の範囲である可能性があります。平均は多分 > 6 です。私はこれを 5 秒以内で確実に達成したいと思っています。私のタイミングに基づくと、データベースへの Web サービス呼び出しはミリ秒です。ファイアウォールのすぐ後ろに配線しましたが、インターネットの前に (つまり、インターネットを除外して) 配線し、合計でおそらく 1 秒のラウンド トリップが発生しました。

テストとして、返される JSON をトリミングして 1 行のデータ (4kb) のみを返すようにしました。もちろん、大幅な速度の向上が見られます... ネットワークの外では 1 秒未満で安定しています。本当に疑問が生じます.JSONメッセージを返すとき、予想が5秒未満であるモバイルデバイスで消費される最大データサイズはありますか? ワイヤーシャークを実行すると、これが複数のパケットとして配信されていることがわかります。これには多くの関係があると思います。

また、クライアントがメッセージを受信した時間と、それを画面に表示するのにかかる時間も計りました...わずか数ミリ秒です。

プログラムが非常に基本的であり、複数の呼び出しを必要としないことを考えると、クライアント プログラムをさまざまなデータの複数の Web サービス呼び出しに分割するのは嫌です。

どう思いますか？インターネットのせいにして、素敵なスプラッシュ/ロード画面を作るだけですか? :)

**編集：SSLを使用していることを追加するのを忘れていました**

4

2 に答える 2

5

モバイル接続とその遅延の増加が原因です。明示的には、ダウンロード速度でさえありません。むしろ、一定の接続を維持する可能性と、チャンクされていないパケットです。

残念ながら、ここで「正しい」答えを見つけることはできません。

完璧な条件下では、電話の RTT は 1 秒か 2 秒で、すべてのデータが含まれている可能性があります。
理想的ではない状況では、データの到着が終わらない可能性があります。

したがって、重みと頻度のバランスをとる行為にサブスクライブする必要があります。
そして、あなた以外の誰もあなたに比率を与えることはできません.

個人的には、モジュールごとにデータを分割することをお勧めします。
アプリを構成する小さなモジュラー ウィジェットがあり、それぞれが構成データまたはユーザー データを必要とする場合は、それぞれを個別に、疎結合の方法でロードします。

簡単な例として、メッセージ ウィンドウ、オンライン フレンドのリスト、PM のリストがすべて互いに独立して読み込まれるチャット アプリがあるとします。

それぞれが準備ができたときに初期化し、それぞれに独自の「読み込み中」インジケーターがある場合 (進行状況は良いですが、実際には「それに取り組んでいます」)。

アプリがブログ ロールやアイテムのセットのようなもので、画面に表示できるのはほんの一握りである場合は、画面あたりの平均数に基づいてそれらを論理的にチャンクします。
空の応答が返されるまで、それをタイマーに設定するか、成功した読み込みが次の非同期読み込みをトリガーするキューに設定します。

アプリが、数千行の統計情報を読み込む分析スイートのようなものである場合... できることは多くありませんが、アプリが機能していることをユーザーに知らせるようにしてください。最初の結果を含む「合計」フィールドを送信し、これまでにロードした一意の行数に基づいて進行状況をマークできます。
または、日ごとの統計がある場合は、日ごとまたは週ごとにチャンクし、現在利用可能なセットがどれだけ遡るかをバーまたはカレンダーにマークすることができます.

ここには簡単な答えはありませんが、少しでもお役に立てば幸いです:

すべてがストリーミングされ、完了したら機能することがわかるプログラムで 5 秒間待機することは、完成品がポップアップする前に、空白の画面で誰も何も言わない 3 秒間よりも耐えられます。

于 2012-11-02T17:59:21.857 に答える
0

モバイル統合の場合、JSON の 65000 文字数は優れています....送信中に JSON を GZIP でき、受信側で解凍できる場合は、最大 89000 文字を受信する必要があります。JSON のサイズを大きくするには、バッチ処理を使用する必要があります。

より多くの文字の場合、問題は帯域幅に由来します。インターネットの帯域が遅くなると、データが受信できなくなる場合があります（データロスト）。

于 2013-02-28T10:47:16.673 に答える