2013年10月27日日曜日

Geckoのリロードとメモリキャッシュ

ローカルデータのビューアを作るためにGeckoが使えないかと色々試しています。 というわけで以前のネタに続きGeckoFxのメモリキャッシュについて調べてみました。 コードをちょっと変更してリロードボタンを追加、メモリキャッシュが動いているか確認です。

コードは以前のものを流用しました。 MainWindow.xamlはこう変更。

MainWindow.xaml.csはこうしました。

GeckoWebBrowserのリロードはデフォルトでキャッシュを使用します。 キャッシュを無視してリロードするにはGeckoLoadFlags.BypassCacheを指定してリロード。

まずはGeckoにローカルの画像ファイルをリロードしたときメモリキャッシュを使っているのかファイルにアクセスしているのかを確認。 Process Monitorというツールを使いました。

Process Monitorはファイルシステム、レジストリ、プロセスの挙動を監視するツールです。 アプリケーションがハードディスクにアクセスする詳細なログなどを確認することができます。

実際に調べてみると、どうやら普通のリロードだろうがキャッシュを無視したリロードだろうが、ローカルの画像を表示するときはハードディスクにアクセスしているようですね。 メモリキャッシュは使っていませんでした。 先読み機能などを実装した軽いビューアを作りたいときはGeckoのキャッシュ機能は使えないようですね。 ちょっと残念。

一応、Process Monitorの使い方をメモ。 このツールの実行には管理者権限が必要です。 UACの問い合わせにGOサインを出して実行するとFilterの設定ダイアログが開きます。 ここでマッチしたログだけ表示したり、マッチしたログを除外したりすることができます。

図の(1)のところで絞り込み/除外対象を選択します。 絞込みの対象はPath、Process Name、Userなどから選択できます。 isのところはis not、begins with、containsなどに変更できます。 その右のテキストボックスには絞り込みのための文字列を指定。 最後のInclude/Excludeのコンボボックスで絞込みか除外かを指定します。

絞り込み/除外対象ができたら(2)のAddボタンでフィルター一覧に追加します。

今回は(1)のように画像ファイルのパスを監視対象に登録しました。 一応(3)Process Name = サンプルコード(WpfGeckoFxTest.vshost.exe)も追加。 OKボタンを押してFilterの設定ダイアログを閉じてサンプルコードを実行すると、監視対象の画像ファイルにアクセスがあったときだけProcess Monitorにログが流れます。

Process Monitorの使い方についてはここまで。

ネット上の画像ファイルにアクセスしたときのキャッシュの使用も確かめました。 サンプルコードの

の部分のコメントアウトを入れ替えてチェック。 使ったツールはMicrosoft Network Monitorです。 使い方は過去の投稿参照。

デフォルト設定で適当にキャプチャーしてパケットの様子を見ました。 Microsoft Network Monitorはプロセスごとに表示が分かれるハズです。 デバッグ実行なのでUnavailableにログが出てました。

まずは最初のアクセス。 ログには画像データがwikimedia.orgから送られてくる様子が書かれていました。

画像要求に対するHTTP:Responseのフレームナンバーが14、それに続く「Continuation to #14」が画像の中身です。 当然Geckoはサーバ上のデータを表示します。

次に普通にリロード。 ログに「Continuation to #??」の文字はありませんでした。 つまり画像の中身は受信していません。 レスポンスの詳細を見ると

「StatusCode: 304, Not modified」の文字が。 Geckoの画面が更新されているのでキャッシュを使っていることが分かります。

キャッシュ無視リロードをしてログに「Continuation to #??」の文字を確認。 Geckoは画像の中身を受信して画面を更新しました。

まとめると、Geckoはローカルだろうとリモートだろうと、普通のリロードだろうとキャッシュを無視したリロードだろうと対象にアクセスします。 サーバに普通のリロードでアクセスした場合はデータの中身が送られてこないのでキャッシュを使う、という事のようですね。