1

Dive Into HTML5 のオフラインに関する章を読んでいて、いくつか疑問が残りました。

それは言う

オフライン Web アプリケーションのいずれかのリソースに変更を加えるたびに、キャッシュ マニフェスト ファイル自体を変更する必要があります。これは、単一の文字を変更するのと同じくらい簡単です。これを達成するために私が見つけた最も簡単な方法は、コメント行にリビジョン番号を含めることです。コメントのリビジョン番号を変更すると、Web サーバーは新しく変更されたキャッシュ マニフェスト ファイルを返します。ブラウザーはファイルの内容が変更されたことを認識し、プロセスを開始して、リストされているすべてのリソースを再ダウンロードします。マニフェスト。

しかし、同じ記事で説明されているウィキペディアの例を見てみましょう。記事が編集されるたびに、編集内容を反映するようにマニフェスト ファイルを変更する必要があります。ページをオフラインで保存したユーザーは、マニフェストで明示的に言及されていないため、ページを失います。これは本当に望ましい行動ですか？はいの場合、次のことを行ってみませんか。

  1. マニフェストが変更された場合でも、明示的に削除されるまでファイルをオフライン キャッシュに保存します
  2. ファイルが変更されたときにキャッシュ内のファイルを更新します (たとえば、サーバーが 304 Not modified を返さない場合)。

上記の 2 点で説明されている動作を取得した場合、彼の選択肢は何でしょうか? ローカルストレージなどを使用しますか?

4

1 に答える 1

3

まず、 appcachefacts.infoをチェックして、この紛らわしい仕様をよりよく理解してください。

Jake Archibald がブログ投稿Application Cache is a Douchebagで説明しているように、AppCache はしばしば予期しない方法で動作します。

その中で、上記の動作は iframe マジックを実行することによって実現されます。静的ページを appcache マニフェストに追加し、onClick などの外部イベントに基づいて、キャッシュされていないフラグメント ページの AJAX 呼び出しを介して本文コンテンツを読み込み、将来の (おそらくオフラインの) 参照のために本文データを WebSQL データベースに保存するだけで済みました。 . これにより、実質的に、私のオフライン アプリは完全に JavaScript ベースになり、ページをリロードする必要がなくなりました。

WebSQL の代わりに HTML5 ローカル ストレージを使用することもできますが、5MB のストレージ制限に不安を感じるかもしれません。

理由については、推測するしかありません。私はそれを考えます：

  1. Appcache は、明示的に削除されるまでファイルを保存しないため、appcache のサイズは適度なままです。ウィキペディアの例では、アクセスしたすべてのページをキャッシュし、ページをクリア (おそらく削除) しないのは悪い考えのようです。
  2. マニフェスト内のファイルは、ページをリロードするたびに再チェックされるわけではありません。これは、サーバー リクエストが爆発的に増加することを意味するためです。マニフェスト ファイルに 30 個のファイルが含まれている場合、ページが読み込まれるたびに 30 個の追加のリクエストが送信されます。それらが非同期で実行されたとしても、これは受け入れられません。
于 2013-09-02T19:58:07.210 に答える