Androidの WebView(WebKit) 内の処理時間計測は、むずかしい。

操作中のAndroidスマホ Android開発

以前、お仕事でこんな依頼を受けました。

上司
上司

WebViewの通信速度を計測してくれぃ〜

僕

そんな無茶な〜

WebView内でのタップ操作をハンドリングして、そこからレスポンスがあるまでの処理時間を計測したいというものでした。

それって、WebViewを制御するってことだよね…?

WebView(WebKit)とは

Blink (レンダリングエンジン)について、Wikipediaには以下のようにありました。

WebKitから分岐してChromium向けに最適化したエンジンを開発していくことで、プロジェクトのイノベーションを促進して長期的なウェブのエコシステムを健全化していくとしている。

分離元のWebKit側は、V8の排除、JavaScriptCore以外の仕様の排除、描画ライブラリのSkiaの排除、GoogleのビルドシステムGYPの排除などが行われた[5]。

分離したBlink側も、描画ライブラリはSkiaのみ[6]、ビルドシステムはGYPのみとなり、これにより450万行のソースコードを削除する[7]。

つまり、簡単にまとめると以下のようなことが言えます。

  • iOS側   → 分離元の「WebKit」
  • Android側 → 分離した「Blink」

WebViewには onLoadResource() というコールバックがあった。

Android の WebView で、js や css などのリソースをダウンロードするタイミングで onLoadResource() と言うコールバックが存在し、onPageStarted() の前や onPageFinished()の後にもあることがわかりました。

  • onPageStarted() はページ読み込み開始直後ではない
  • onPageFinished() のあともコンテンツのダウンロードは続く可能性はあると言える。

ということがわかりました。

調査不足でした。
こんなメソッドがあったなんて。

まとめ

アプリ→タップ→サーバにアクセス→リソース取得→画面遷移(リソース読み込み)

このような流れで画面遷移が行われると思っていました。

個人の知識としては、onPageStarted,onPageFinishedくらいしか知りませんでした。

ちなみに、プロキシ設定をすることで「Charles」といった通信デバッグ系ツールを使って速度計測を行うことも可能です。
ですが、プロキシを挟むので若干誤差が生じ、厳密な計測時間は見込めないので注意が必要です。

タイトルとURLをコピーしました