😎

WebViewとは何か？そしてバックグラウンドで使おうとして詰んだ話

に公開
Android
個人開発
設計
WebView
バックグラウンド処理
idea

Android開発をしていると、WebView というコンポーネントを使う場面がたまにあります。

この記事ではまず

  • WebViewとは何か
  • どんな用途で使われるものなのか

を整理した上で、

「WebViewをバックグラウンドで使おうとして失敗した理由」 を、
設計の観点から一般化して解説します。

特定のアプリやサービスに依存しない内容なので、
これからAndroid開発を始める人にも参考になれば幸いです。

WebViewとは何か？

WebViewは、

Androidアプリ内でWebページを表示するためのUIコンポーネント

です。

Chromeなどのブラウザと同じく、内部では

  • HTML
  • CSS
  • JavaScript

を解釈・実行できますが、
あくまで アプリの画面の一部としてWebを表示するためのもの です。

WebViewでできること

WebViewを使うと、例えば次のようなことができます。

  • アプリ内にWebページを表示する
  • Webサービスのログイン画面を埋め込む
  • JavaScriptを実行してDOMを操作する
  • Cookieやセッションを保持した状態で通信する

「APIが用意されていないWebサービスを扱いたい」ときに、
WebViewは非常に便利です。

なぜWebViewをバックグラウンドで使いたくなるのか

WebViewが便利なため、次のような発想に至りがちです。

  • Cookie付き通信がそのまま使える
  • JavaScript実行結果も取得できる
  • API実装を考えなくてよい

その結果、

「この処理、バックグラウンドでも回せないかな？」

と考えてしまいます。

が、ここからがハマるポイントでした。

最初に考えた構成

バックグラウンド対応を考えたとき、
よく思いつく構成は次のようなものです。

  • フォアグラウンド用 WebView
  • バックグラウンド用 WebView
  • 状況に応じて使い分ける

一見すると合理的に見えます。

  • 表示用と処理用を分離
  • バックグラウンドでも処理継続

しかし、実際には問題が連続します。

実際に起きた問題

1. バックグラウンドに入るとWebViewが止まる

Androidでは、アプリがバックグラウンドに入ると

  • Activity が停止
  • View が非アクティブ

になります。

WebViewは UIコンポーネント であるため、
バックグラウンド状態では以下が発生します。

  • JavaScript実行が止まる
  • 読み込みが中断される
  • タイミング次第で破棄される

「たまに動く」ように見えるのが一番厄介です。

2. Activityライフサイクルで破棄される

画面回転やメモリ不足時などで、

  • Activity 再生成
  • View 再構築

が発生すると、WebViewは簡単に失われます。

バックグラウンド前提の処理では、

  • 状態保持
  • 再開処理

のコストが一気に跳ね上がります。

3. Cookie・Sessionの扱いが不安定

WebViewのCookieは

  • プロセス
  • WebViewインスタンス

に依存します。

そのため、

  • 再生成時にセッションが切れる
  • 意図しないログアウト

といった現象が頻発します。

4. メモリ消費が想像以上に大きい

WebViewは非常に重いコンポーネントです。

  • Chromiumベース
  • JavaScriptエンジン内包

複数WebViewを持つ構成は、

  • メモリ消費増大
  • OSによる強制Kill

を招きやすくなります。

「Serviceで動かせばいいのでは？」という罠

次に考えがちなのが Foreground Service です。

  • バックグラウンドでも生存
  • 処理継続が可能

しかし、ここでも問題があります。

  • WebViewは Service 向けに設計されていない
  • UIを持たない前提と相性が悪い

無理に組み合わせると、

  • 非公式な挙動
  • 端末依存の不安定動作

に繋がります。

結論：WebViewをバックグラウンド処理に使うのは設計ミス

ここまで試して分かったのは、

WebViewは「画面表示前提」のコンポーネント

という事実です。

技術的に動かせる場面があっても、

  • 安定性
  • 保守性
  • 将来のOSアップデート

を考えると、
バックグラウンド処理の中核に据えるべきではありません。

現実的な代替案

用途に応じて、次の選択肢を検討すべきです。

1. フォアグラウンド時に取得し、キャッシュをバックグラウンドで使う

最も現実的で、安定性が高いアプローチがこれです。

  • WebViewは フォアグラウンド時のみ 使用する

  • 必要な情報を取得した時点で

    • HTML
    • 解析結果
    • 必要なデータ構造
      をローカルにキャッシュする

  • バックグラウンドでは WebViewを一切使わず キャッシュを参照する

この構成のメリットは以下です。

  • WebViewのライフサイクル問題を回避できる
  • バックグラウンド処理が安定する
  • OS制約の影響を受けにくい

一方で、

  • リアルタイム性は下がる
  • データ更新タイミングの設計が必要

というトレードオフはあります。

しかし、

「バックグラウンドでWebViewを動かしたい」

という要求自体を分解すると、
この方式で十分なケースは非常に多い です。

2. Cookie付き通信が目的の場合

  • OkHttp + CookieJar
  • 明示的なCookie管理

WebViewに依存せず、
通信レイヤーとして切り出すことで
バックグラウンド処理が可能になります。

3. JavaScript実行が必要な場合

  • サーバーサイドで処理
  • Headless環境の利用

JS実行が本当に必要かどうかを一度見直すと、
設計が大きくシンプルになることがあります。

4. WebViewが本当に必要なケース

  • フォアグラウンド限定
  • ユーザー操作前提

表示・操作が前提の処理であれば、
WebViewは正しい選択です。

「バックグラウンドで回したい」と思った時点で、
設計を一段見直す価値があります。

まとめ

  • WebViewはUIコンポーネント
  • バックグラウンド処理とは根本的に相性が悪い
  • 無理に使うより設計を切り替えた方が早い

技術的に可能かどうか と
プロダクトとして正しいかどうか は別問題です。

同じところで詰まっている人の判断材料になれば幸いです。

ブログでもUnityや個人開発ネタを発信中です！

開発ノウハウやアプリ制作過程、Unity連携系のハマりポイントなど
より深掘りした内容をブログにまとめています。
▶ https://syunpp.com

公開中のアプリ一覧はこちら！

実際にUnityで開発してリリース済みのアプリ一覧をまとめています。
▶ https://syunpp.com/公開中のアプリ一覧/

YouTubeショートでもゲーム開発の裏側を公開中！

Unityで制作中のゲームの進捗や演出テスト、実装の様子を
ショート動画でタイムラプス形式にまとめて発信しています。
▶ https://www.youtube.com/@syunpp_8413/shorts

Discussion