データを返すために単一のWebサービスを使用しているiOSおよびAndroid用に作成されたモバイルアプリがあります。このサービスによって返されるデータは、1日に約1回、またはユーザーが場所を変更したときに変更されます。現在、1つの大きなメッセージ（約700kb）をダウンロードし、ユーザーセッションに必要なすべてのデータをアプリに入力しています。
問題は、最初のメッセージがすべてのデータをローカルデータベース（sqlite）テーブルに処理するのに約30秒かかることです。これにより、データの小さなチャンクをダウンロードし、必要に応じてデータを処理することを検討するようになりましたか？これにより、アプリ内でクリックするたびに待ち時間が短くなる可能性があります。
上で説明したタイプのシナリオで最高のユーザーエクスペリエンスにつながるパフォーマンスに基づく最適なアプローチは何ですか？
私はこのような他の質問を見ましたが、それらは決定的な答えを欠いています。 回答/意見を入力してから投票してください。そうすれば、この議論を休ませることができます。
一般に、whiteagle が示した理由から、1 つの HTTP 要求が最適です。ただし、最初のアクティビティで少量のデータしか役に立たない場合は、ダウンロードを分割することを検討してください。最初に必要なものだけを直接ロードし、この情報を使用して最初の画面を更新 (!) します。
リクエストが返された後、すぐに後続の 1 つのリクエストで他のすべてのもののダウンロードを開始します。最初の画面の情報が役立つ場合、ユーザーは次のビューに進む前に少なくとも少し時間がかかります。
もちろん、通常のベスト プラクティスに注意する必要があります。
バックグラウンドですべてのダウンロードを行います。
ダウンロードが完了していなくてもユーザーに何かを表示し、ダウンロード後に UI を更新します。
本当に新しいものだけがダウンロードされるように、ダウンロードを最小限に抑えるようにしてください。
そして最も重要なことは、積極的にキャッシュすることです。
確かに、応答時間の観点からは、1 つのフェッチ要求に対して 1 つの接続を使用する方が適切です。モバイル環境では、DNS キャッシング、キープアライブ チェックなど (PC での作業を容易にするこれらすべての小さなこと) がほとんどないため、各接続の確立 (ハンドシェイク) にはかなりの時間がかかり、場合によっては最大 1 秒かかります。ケース。したがって、フィードを異なる接続に分割する場合は、すべてのハンドシェイクを合計する必要があります。
あなたの場合、処理遅延の問題があると述べているので、このプロセスをバックグラウンドスレッドに入れてデータをチャンクで埋めるのは良い考えでしょうか? つまり、フィード全体をダウンロードして、(たとえば) 100 のステップで処理ルーチンを起動し、何らかのリターンを得るということです。