問題：
ユーザーの写真をデバイスギャラリーからサーバーにアップロードする必要がある写真整理/バックアップ iOS アプリを構築しています。
ユーザーが自分のプロフィールを作成してアプリにログインすると、自分のギャラリーで画像がスキャンされます。アップロードは、マルチパート フォーム データ リクエストとして約 10 ファイルのバッチで行われます。各バッチがアップロードされた後、サーバーに API 呼び出しを行い、完了したばかりのアップロードをコミットする必要があります。サーバーは、以前にコミットされたバッチを処理した後、画像コンテンツなどに基づいてアルバムを作成するなど、独自のコミットを行うこともできます。その場合、クライアントはアップロードのコミット中にサーバーから非同期応答を取得し、アップロードをコミットする前にまずサーバーのコミットをフェッチする必要があります。続いて、次の 10 枚の画像のバッチのアップロードが予定されています。
この目的のために NSURLSessionUploadTask を使用しています。アプリが一時停止状態のときにアップロードが完了すると、アプリが起動し、以下の 1、2、3 または 2、3 のいずれかを実行する必要がある場合があります。
- 以前にコミットされたアップロードに対してサーバーによって行われたコミットを取得します
- 完了したばかりのアップロードをコミットします
- アップロードする 10 枚の画像の次のバッチをスケジュールします
================================================== ==
これはうまくいきません。アップロードの完了後にアプリが起動されたときに、アプリが 1,2,3 または 2,3 を実行するのに十分な時間がありません。バックグラウンド実行時間の要求は、Apple が 180 秒に制限しているため、180 秒を超えることはありません。
サーバーは画像の上書きを開始する前に 100 個の画像のバッファーを持っているため、バッチをコミットせずにバッチをアップロードし続けることはできません。コミットせずにアップロードを続けると、サーバーは以前にアップロードされた画像を上書きし始め、データが失われます。
また、コミットを実行せずに画像の複数のバッチをアップロードしようとしても、進行中のアップロードが終了するとすぐにバックグラウンドで NSURLSessionUploadTask としてスケジュールした最初のタスクが、アップローダー デーモン nsurlsessiond によってすぐに取得されないことを確認しました。5 分後、場合によっては 10 分後に応答することもあります。プロセス全体を通して、私は良好な Wi-Fi 接続を維持しており、それに応じて NSURLSession が構成されています。
上記について、nsurlsessiond キューが空になった場合、すぐに次のタスクを選択しないことを StackOverflow で読みました。実験のために、アプリをアップロードしてバックグラウンドに入れるために3〜4個のバッチを送信しましたが、動作は同じです。2 番目のアップロードは 5 ～ 10 分後まで取得されず、3 番目と 4 番目も同様です。
================================================== ==
位置情報サービスを使用せずに Google フォトが継続的にアップロードされるのを見てきました。Dropboxもそれを行います。それらのコミット アーキテクチャは、私たちのものとは異なる場合があります。しかし現在、追加の API 呼び出しを行う必要があるコミット側全体を無視した後でも、3 ～ 4 バッチの画像を継続的にアップロードすることさえできません。
アプリのバックグラウンド アップロードの解決策を考え出すために、この状況を分析する方法を教えていただけませんか。
再度、感謝します。