LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリの大容量ファイルバックグラウンド転送とは、OSに委ねる継続転送方式

アプリの大容量ファイルバックグラウンド転送とは、動画・書類・写真などの大きなファイルを、アプリが前面に無い状態でもアップロードまたはダウンロードし続けられるように、転送処理をOS側に委ねる実装方式を指します^*1*3。iOSはURLSession(iOSのネットワーク通信を扱う標準API)のバックグラウンド設定、AndroidはWorkManager(Jetpackが提供する永続タスク管理ライブラリ)とForeground service(通知を出しながら継続実行するサービス形態)の組み合わせで、この仕組みを実現します^*1*3。

前面転送のみの実装は、アプリが起動している間しか転送が進みません。ユーザーがアプリを閉じたりOSが強制終了させたりすると、大容量ファイルの転送は途中で止まってしまいます。バックグラウンド転送はOSに転送そのものを引き渡すため、アプリの状態に左右されにくくなる点が特徴です^*1。

iOSの実装——URLSessionのバックグラウンド設定で終了後も再開

iOSでは、URLSessionConfigurationのbackground(withIdentifier:)メソッドで生成した設定を使うと、HTTP・HTTPSのアップロードやダウンロードをバックグラウンドで実行できます^*1。この設定を使ったセッションは転送の制御をシステムに渡し、システムは転送を別プロセスで処理します^*1。その結果、アプリ自体がサスペンド(中断)されたり終了したりしても、転送を継続できます^*1。

ただしこの継続には条件があります。システムが通常の仕組みでアプリを終了し再起動した場合は、同じ識別子で設定とセッションを再生成すれば、終了時点で進行していた転送の状態を取得できます^*1。一方、ユーザーがマルチタスク画面からアプリを終了させた場合は、システムがそのセッションのバックグラウンド転送をすべて取り消します^*1。この差を理解していないと、想定より転送が止まってしまう不具合につながります。

転送完了時の通知も専用の仕組みで受け取ります。sessionSendsLaunchEventsをtrueに設定すると、転送完了時にアプリが起動され、App DelegateのhandleEventsForBackgroundURLSession(_:completionHandler:)が呼び出されます^*2。受け取った完了ハンドラは保持しておき、urlSessionDidFinishEvents(forBackgroundURLSession:)が呼ばれた段階で実行する流れです^*2。earliestBeginDateで転送開始の下限時刻を指定することもできますが、これは保証ではなくシステムの判断による目安です^*2。

Androidの実装——WorkManagerとForeground service(dataSync)

Androidでの標準的な選択肢はWorkManagerです^*3。WorkManagerは、ユーザーが画面を離れたりアプリを終了したり端末を再起動したりしても実行を継続する必要があるタスク向けに設計されています^*3。Kotlinのコルーチンはアプリが閉じると処理が止まってしまうため、アプリ終了後も転送を続けたい大容量ファイルの用途にはWorkManagerが向いています^*3。

WorkManagerには即時実行・長時間実行・遅延実行の3種類があります^*3。長時間実行のタスクではsetForegroundを使い、Foreground service(フォアグラウンドサービス)として通知を出しながら処理を進める形が推奨されています^*3。Foreground serviceは、ユーザーが気づける形で処理を実行するための仕組みで、ステータスバーへの通知表示が必須です^*4。

データ転送用途にはdataSyncというForeground serviceの種類が用意されています^*5。dataSyncは「データのアップロードまたはダウンロード」「デバイスとクラウド間のネットワーク経由のデータ転送」などを対象とする種類として定義されています^*5。利用にはFOREGROUND_SERVICE_DATA_SYNC権限の宣言が必要です^*5。なおAndroid 15以降を対象とするアプリは、BOOT_COMPLETEDのブロードキャストレシーバーからdataSyncのForeground serviceを起動できない制限があります^*5。

ネットワーク条件やバッテリー残量に応じて実行タイミングを制御したい場合は、WorkManagerのConstraints(制約)を使います。無課金のネットワークに接続している時のみ実行する、端末がアイドル状態の時のみ実行する、十分なバッテリーがある時のみ実行するといった条件を宣言的に定義できます^*3。失敗時のリトライも、指数バックオフ(再試行の間隔を段階的に広げる方式)を含む柔軟なポリシーが用意されています^*3。

再開・失敗リトライ・進捗通知——実装で押さえる3つの挙動

大容量ファイルの転送では、再開・失敗リトライ・進捗通知の3つをどう作り込むかで実装の難易度が大きく変わります。まず再開について、iOSは同じ識別子でセッションを再生成すれば進行中の転送を引き継げますが、ユーザーがアプリを明示的に終了させた場合は転送自体が取り消される点に注意が必要です^*1。

失敗リトライは、iOS側はシステムが転送を管理するため個別のリトライ実装は最小限になりますが、Android側はWorkManagerの指数バックオフポリシーを設定で選べます^*3。回線切断や電波状況の変化による失敗をどこまで自動で吸収できるかは、こうしたOS標準機能の使い方に依存します。

進捗通知は、AndroidではdataSyncのForeground serviceに紐づく通知をユーザーへ常時表示する必要があります^*4*5。iOSは進捗の可視化を強制されませんが、ユーザー体験の観点からアプリ内で進捗率を表示する実装を併用するケースが実務上は多くなります。いずれの場合も、転送量が大きいほど失敗時の手戻りコストが増えるため、進捗と再開の両立が実装の要になります。

省電力・通信量への配慮と大容量ファイルの分割アップロード

大容量ファイルの転送は、通信量とバッテリー消費への配慮も欠かせません。iOSではisDiscretionary(転送タイミングをシステムの裁量に委ねる設定)をtrueにすると、Wi-Fi接続時や充電中といった最適な条件を見計らって転送するよう促せます^*2。大量のデータを転送する場合は、このプロパティをtrueにすることが推奨されています^*2。

Androidでも同様に、WorkManagerのConstraintsで無課金ネットワーク限定・端末アイドル時のみ・十分なバッテリー残量時のみといった条件を組み合わせられます^*3。これにより、モバイル通信中に大容量ファイルの転送が走ってしまい、通信量の上限を圧迫するといった事態を避けやすくなります。

ファイル自体が非常に大きい場合は、分割アップロード(ファイルを複数のパートに分けて送信し、失敗したパートだけ再送する方式)を独自に実装する選択肢もあります。iOSのURLSessionは、同じセッションで複数の転送タスクを一括して開始し完了時にまとめて再開する運用が想定されており、単発のダウンロードを繰り返し起動するとシステムによる遅延(レート制限)が増える点も踏まえた設計が必要です^*2。分割アップロードを自前で組む場合は、パートごとの再送ロジックとサーバー側の結合処理を両方実装する必要があり、開発負荷はOS標準機能を使う場合より高くなります。

前面転送・バックグラウンド転送・独自分割——3方式の比較

ここまでの内容を整理すると、大容量ファイルの転送方式は大きく3つに分けられます。方式ごとの特徴を比較すると次の通りです。

小容量のファイルや利用頻度が低い機能であれば、前面転送のみでも実務上は成立します。動画や書類など数十MB以上のファイルを扱うアプリでは、OS標準のバックグラウンド転送を基本形にし、要件次第で独自の分割アップロードを組み合わせる構成が現実的な選択になります。

内製と外注の分かれ目——iOS/Android両実装の工数で判断

OS標準のバックグラウンド転送そのものは、AppleとGoogleが仕組みを公式に提供しているため、片方のOSだけを対象にした小規模な機能であれば内製でも対応できる場合があります。判断が分かれるのは、iOS・Android両方に対応し、再開・リトライ・進捗通知・省電力配慮までを一貫して仕上げる場面です。

この作業を内製で担うには、URLSessionのライフサイクルとApp Delegateの連携、WorkManagerのConstraintsとForeground serviceの通知実装、両OSでの検証端末を用いたテストなど、複数領域の知識が要ります^*1*3*4。既存の開発チームが通常業務と並行して対応する場合、検証に割ける時間が限られることもあります。

専門パートナーに委託する場合は、要件整理の段階で、対象ファイルの想定サイズ・同時転送数・オフライン再開の必要性・対応OSバージョンをすり合わせておくと、見積もりの精度が上がります。iOS・Androidどちらの実装も一貫して依頼できるかどうかも、委託先選定の確認事項になります。

まとめ：大容量ファイルのバックグラウンド転送実装で押さえる3つの判断軸

本稿ではアプリの大容量ファイルバックグラウンド転送について、iOS・Androidそれぞれの実装方式を公式情報をもとに整理しました。要点は3つに集約できます。第一に、iOSはURLSessionのバックグラウンド設定、AndroidはWorkManagerとForeground service(dataSync)を使うことで、アプリが前面に無い状態でも転送を継続できます^*1*3*5。第二に、再開・失敗リトライ・進捗通知・省電力配慮の作り込み方が、前面転送のみ・OS標準のバックグラウンド転送・独自の分割アップロードという3方式の選択を左右します。第三に、iOS・Android両対応で一貫した品質を求める場合は、対応範囲と工数を早い段階で見積もることが、内製と外注の判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apple Developer Documentation「URLSessionConfiguration.background(withIdentifier:)」（https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1407496-background）
2. *2　出典：Apple Developer Documentation「Downloading Files in the Background」（https://developer.apple.com/documentation/foundation/downloading-files-in-the-background）
3. *3　出典：Android Developers「WorkManager」（https://developer.android.com/topic/libraries/architecture/workmanager）
4. *4　出典：Android Developers「Foreground services overview」（https://developer.android.com/develop/background-work/services/foreground-services）
5. *5　出典：Android Developers「Foreground service types」（https://developer.android.com/develop/background-work/services/fgs/service-types）

Tweet