WebViewとは、HTMLブラウズ機能を持つGUIパーツである。
割と一般的な名前のため同名のアプリがいくつかあるが、ここでは解説しない。
概要
アプリ開発ではボタンやチェックボックスなどのGUI部品を組み合わせてユーザーインターフェースを作るのだが、その際にWebViewという部品が使用できる。
内部にはChromeなどのブラウザと同じHTMLレンダリング(描画)エンジンが入っており、WebViewの部品内ではWebコンテンツと同じ手法(HTML + CSS + JavaScript)でインタラクティブなプログラムの製作が可能になる。
採用環境
アプリ一覧に名前が表示されるAndroid以外でもiOS・Windows・MacOSなどの各種プラットフォーム、JavaFX・FlutterなどのマルチプラットフォームGUIフレームワーク等に(若干名前にバリエーションはあるが)幅広く存在する。
使用しているエンジンは、AndroidではChromeと同じBlinkエンジンだが、他はSafariと同じWebKitを使用しているものが多い。が、元をたどれば同じだ。WindowsはEdgeのエンジンを使用していたが、EdgeがChromiumベースになってからは、WebView2という名前でBlinkエンジンを使用したWebViewが提供されるようになった。
ブラウザとの違い
ブラウザとの違いとしては、あくまでもGUI部品の一つなので、アプリ内の他の部品や機能と連携が可能という点である。ブラウザはセキュリティ上の問題からサンドボックスモデルを採用しているので、原則としてブラウザ内の要素からブラウザ外に働きかけることは出来ない。
先述のようにAndroidではアプリ一覧に表示されるが、あくまでも部品なのでWebView単独でアプリとして起動することはできない。
用途
ブラウザとして
極端な話をすれば、WebViewを一つだけウィンドウいっぱいに貼り付けてGoogleやYahoo! Japanのトップページを表示させただけで、世界シェアトップのブラウザであるGoogle Chromeに匹敵するHTML描画能力を持つブラウザアプリが製作出来てしまうと言っても過言ではない(もっとも既存ブラウザの丸パクリだし、機能も色々足りてないが)。
そこまで極端でなくとも、表示した任意のWebページに何らかの操作を加えるという使い方もできる。どういう操作をするかはアプリ開発者の工夫のしどころである。
Single Page Application
実際のところは、WebViewを一つ貼り付けるだけというところまでは上記と一緒だが、SPA(Single Page Application)と呼ばれる1つのHTMLページだけでアプリの全機能をまかなうタイプのものを表示させるという使い方が多い。ネイティブ機能はガワのWebViewだけなので、ガワネイティブと呼ぶことがある。WebView外部とはハードウェアへのアクセスの際に連携するといった使い方になる。
たとえば、メルカリのようなフリーマーケットアプリであれば、閲覧や購入機能はWebView上で実装し、品物を出品する際の写真撮影でカメラ機能と連携するといった具合である。
HTML Viewerとして
マニュアル・ヘルプファイルをローカルHTML文書として作成して、それを表示させるのに使うこともできる。同じ理屈でWebサイトにアクセスさせれば、「運営からのお知らせ」的なものの配信もできる。表示される文書に外部へのリンクが含まれていると意図しないページを表示できてしまうので注意が必要なのは言うまでもない。
メリットとデメリット
メリット
プラットフォーム環境の充実
プラットフォーム側としては、オープンソースになっているブラウザのレンダリングエンジンを取り込めば、タダで高機能のGUI部品を提供することができる。
開発コストの削減
アプリ開発者側としては、商用サイト構築などで大きな発展を遂げたWeb関連の開発技術・ライブラリをそのまま転用できるし、WebViewで表示させるHTML部分さえ書けば他のプラットフォームのWebViewに容易に移植できる。Webサイトに使用しているHTMLを流用することも考えられる。
ユーザー体験の向上
ユーザー側としては、各プラットフォームやWebページとの間で操作感が統一され、操作方法をいちいち覚え直さずに済む。また、製作コストの低下によりアプリの品質向上にリソースが回ってくるかもしれない。
デメリット
パフォーマンスの低下
ブラウザのエンジンを介することや、内部でスクリプト言語であるJavaScriptを使用していることなどにより、ネイティブアプリ開発を行った場合に比べると動作速度はやや遅くなる傾向がある。
ただし、ハードウェアの性能は年々向上しているので、体感速度には影響が出ないことも多い。
セキュリティ対応の負担
基本的にブラウザと同じなので、ブラウザと同じセキュリティホールを突かれる可能性がある。ネイティブ開発プラットフォームにも脆弱性問題は存在するのでWebViewに限ったことではないが、多機能だけにシンプルな部品を使用した場合には起きない予想外の組み合わせが発生する可能性もある。
WebViewはプラットフォーム側からセキュリティアップデートが配信されるため気にしなくても大丈夫な場合も多い。しかし、解決策が見つかる前に世間に脆弱性が知れ渡るゼロデイ問題などで、緊急かつ深刻な影響を受ける場合には、アプリ側でWebViewの利用あるいはアプリそのものの利用を一時停止させるといった対策が必要となる。
バージョンアップ対応の負担
先述のようにWebViewのバージョンは各アプリではなくプラットフォーム側が管理している。最近のブラウザはローリングリリース方式を取るものが主流なので、WebViewもそれにあわせて頻繁に自動アップデートを繰り返すことになる。結果として、アプリ側は変化していないのにWebView側が勝手にアップデートしたせいでアプリが動かなくなるという、何もしてないのに壊れた的展開が起こることがある。
ユーザー側ができる対策としてWebViewを古いバージョンに戻すという方法が考えられるが、OSごとに以下のような問題点がある。
- 全プラットフォームに共通する問題として、WebViewを利用している他のアプリも影響を受けるという点がある。すなわち、新しいWebViewにあわせて作られたアプリが逆に動かなくなる可能性がある。
- AndroidではWebViewの更新を削除すると直前のバージョンではなく初期状態にまで戻ってしまうため、バージョンアップで蓄積されていたセキュリティ対策も全てなくなる。また、アプリが動いていたのは直前のバージョンのWebViewである。初期状態のWebViewで別の不具合が発生しないという保証はどこにもない。
- iOSやmacOSではアップデートの取り消しにはOSの再インストールに近い手順が必要であり、失敗するとアプリどころかOS自体が使用不能になるリスクが残る。
- Windows Updateでは一部の更新だけを取り消すことが可能なため、リスクを最小限にしつつトラブルを回避できるが、他のアプリやセキュリティへの影響を避けるため、不具合が解消されたら再更新することが望ましい。
関連動画
関連項目
- ブラウザ / Web / オープンソース
- Safari / WebKit / Chrome / Blink
- アプリ / ユーザーインターフェース / GUI
- マルチプラットフォーム
- Android / iOS / Windows / .NET / MacOS / JavaFX / Flutter
- React
- HTML / CSS / JavaScript
- Gmail / LINE: WebViewを利用していて2021年3月23日に不具合を起こしたアプリ
- プログラミング関連用語の一覧
- 0
- 0pt