モバイル·ブラウザ·キャッシュの制限：アンドロイド、IOS、およびウェブOS»ヤフーのユーザーインターフェイスのブログ（YUIBlog）

モバイル·ブラウザ·キャッシュの制限：アンドロイド、IOS、およびウェブOS

中|午前8時45分に2010年6月28日ライアングローブで私の開発、パフォーマンス | 19コメント

アップデート（2010年7月12日）：この資料に記載されている結果はHTMLページの正確なですが、新しいテストでは、CSSとJSのリソースのための非常に異なるキャッシュの限界を明らかにした。更新された結果は、に記載されているモバイル·ブラウザ·キャッシュの制限、再訪。

2008年初めには、ウェイン·シェイとTenni TheurerがオンYUIブログ記事を書いたiPhoneキャッシュ可能彼らはiPhone OS 1.xでMobile Safariのキャッシュの様々な特性と限界の研究の結果を共有するとりわけ、彼らは、475キロバイトと500キロバイトの間の最大合計キャッシュサイズがあったことを25キロバイトより大きい個々のコンポーネントがキャッシュされていないことがわかった、と。

ずっとそれ以来変更されました。私達は非常に対応したブラウザを持つ2つの新しいメジャーリリースとiPhone OS（現在IOS）、および他のいくつかのモバイルデバイスの多くのマイナーリリースでは、iPhoneに挑戦するために登場して見てきました。ストヤンステファノフがあること、2009年後半に見つかりました、 iPhoneのキャッシュの制限が変更された（残念ながら、悪いことのために）。しかし、物事は今どこに立つか？どのようなそれらのIOS以外のブラウザではどうですか？

背景

ブラウザでは、我々はこれらのテストの目的のために関係していることをキャッシュの2つのタイプがあります。

コンポーネントのキャッシュ 、またはオブジェクト·キャッシュは、個々のファイルを格納します。 HTML、CSS、JavaScript、および画像はすべてのコンポーネントのキャッシュに入ります。それは、これらのコンポーネントのいずれかが必要になるたびに、ブラウザは最初のネットワーク要求を行う前にキャッシュをチェックします。
また、バック/フォワードキャッシュと呼ばれるページのキャッシュは 、ページ全体とそのすべてのコンポーネントと同様に、彼らの現在の状態を格納します。あなたが戻ったり、早送りボタンを使用すると、ブラウザは、可能であれば、ページキャッシュからページをロードします。

HTML5のアプリケーションキャッシュは、広く携帯電話のブラウザでサポートされているキャッシュの別のタイプです。ブラウザのメーカーは、すでにアプリケーション·キャッシュの限界を文書化する良い仕事をするので、私は私のテストではそれを含んでいませんでした。後で、アプリケーションのキャッシュの詳細。

テストされるデバイス

私は、次の携帯電話のブラウザ/プラットフォームの組み合わせをテストしました。

アンドロイド2.1（ネクサスワン）
iOSの3.1.3にモバイルSafari（第1回-genをiPhone）
のiOS 3.2のモバイルSafari（アプリ）
のiOS 4.0のモバイルSafari（iPhone 3GS）
のiOS 4.0のモバイルSafari（iPhone 4）
ウェブOS 1.4.1（Palm Preをプラス）

注：IOS 4.0のモバイルSafariの例外を除いて、私はそれぞれのカテゴリで一つのデバイスのみをテストした。個々のデバイスやOSを超えてインストールされているソフトウェアに基づいて、相違点間のばらつきがある場合は、私のテストでは、これらの変化を検出しません。彼らは私がアクセスしていたものだから、これらの特定のデバイスが、私は彼らが他のデバイスよりも重要であると考えていないので、テストされています。

方法論

キャッシュのテストは面倒ですが、比較的簡単です。

私は小さなシナトラアプリ（書いたGitHub上でそれをフォーク！擬似ランダム英数字と空白要求されたバイト数から成る応答を生成します）。応答はどちらgzipで圧縮されたまたは圧縮されていない提供することができます。以下の遠い未来の期限レスポンスヘッダは、すべての応答がキャッシュ可能とみなされていることを確認するために送信されています。

のCache-Control：max-ageの= 315360000
有効期限：金、2020年5月1日午前3時47分24秒GMTを

私のローカルネットワーク上で、私は、手動でコンポーネントのキャッシュをテストする各デバイスで次の手順を実行しました。

キャッシュ·テストの索引ページをロードします。
5キロバイトから20メガバイトまでの特定のサイズのコンポーネントへのリンクをタップし、それが読み込みが完了するまで待機します。
[戻る]ボタンをタップします。
もう一度同じリンクをタップします。ランダムな文字列が同一であるかどうか、およびサーバーのコンソールコンポーネントは、ステップ2にキャッシュされたかどうかを判断するために、要求ごとにログエントリを出力するかどうかを確認します。
キャッシュされる最大コンポーネントのサイズを決定するために必要に応じてコンポーネントのサイズを繰り返して調整します。

ページキャッシュをテストするために、私は本質的にではなく、手順4でリンクを再度タップすることを除いて同じ手順を実行し、私はそれがページキャッシュではなく、コンポーネントのキャッシュを使用する原因は、ブラウザの[進む]ボタンをタップ。

をサポートしETagやLast-Modified微調整、適切な送信するためにサーバによって決定されETagやLast-Modified応答ヘッダを（別々のテスト）と遠未来の有効期限ヘッダを省略する。私は、ブラウザが予期送信したかどうかを確認するために、サーバーが受信したリクエストヘッダの検査If-None-MatchまたはIf-Modified-Sinceステップ4のヘッダーを。

結果

私は有効と無効の両方gzipでテストされますが、私はgzipは任意のデバイス上のキャッシュ機能に影響を及ぼさなかったことがわかった。圧縮されていないコンポーネントのサイズにかかわらず、そのコンポーネントがgzipで圧縮され提供されるかどうかにかかわらず、すべてのケースで重要なものです。このように、ここに記載されているすべてのコンポーネントのサイズが圧縮されていないサイズです。

以下の表は、私の全体的な所見を示しています。

表：モバイルブラウザのキャッシュ特性
ブラウザ/ OS /デバイス	単一コンポーネントの制限	合計コンポーネントの制限	ページキャッシュのサイズ制限	Last-Modifiedのサポートしています	ETagをサポートしています	パワーサイクルに耐える
アンドロイド2.1（ネクサスワン）	〜2MB（〜2048000 B）	〜2MB（〜2048000 B）	^∞2	はい	はい	はい
Mobile Safariには、IOS 3.1.3（1〜世代iPhone）	0B ¹	0B ¹	^∞2	なし	なし	なし
Mobile Safariには、IOS 3.2（アプリ）	25.6キロバイト（26214 B）	〜281.6キロバイト（〜288354 B）	25.6キロバイト（26214 B）	はい	はい	なし
Mobile Safariには、IOS 4.0（iPhone 3GS）	51.199キロバイト（52428 B）	〜1.05メガバイト（〜1100988 B）	^∞2	はい	はい	なし
Mobile Safariには、IOS 4.0（iPhone 4）	102.399キロバイト（104857 B）	〜1.9メガバイト（〜1992283 B）	^∞2	はい	はい	なし
ウェブOS 1.4.1（Palm Preをプラス^3）	〜1MB（〜1,048,576）	？	〜1MB（〜1,048,576）	なし	なし	はい

注意：

iOSの3.1.3で¹モバイルSafariはページのキャッシュを除いて、サイズにかかわらず、 すべてのコンポーネントをキャッシュするように表示されません。これは故意またはバグであるかどうかは不明だ。

アンドロイド2.1、IOS 3.1.3、およびiOS 4.0（なくiOSの3.2）で²ページキャッシュは、それが個々のページのサイズになると、使用可能なRAMによってのみ制限されて表示されます。私は別のページが一度にページ·キャッシュ内に共存することが正確に何を決定しようとしていませんでした。

³ウェブOSのテスト結果が矛盾していましたし、様々なポイントでキャッシュには、電話機の電源を再投入になるまで完全に動作を停止するように見えた。私はこれらの結果は決定的考慮していない、あるいは信頼できるが、それらは比較のためにここに記載されています。

アンドロイド

Androidのブラウザは、テストのすべてのデバイスの最高のキャッシュの動作を示した。それは個々のコンポーネントのサイズに制限はありませんように見えるが、合計キャッシュ·サイズは、個々のコンポーネントを効果的に同様に2MBに制限されていることを意味し、約2MBに制限されているようだ。

ページキャッシュは喜んで利用可能なRAMが枯渇し、ブラウザがクラッシュされるまで、私はそれで投げたすべてのバイトをキャッシュし、個々のページのサイズに制限はありませんように見えた。

私は愉快にAndroidのコンポーネントのキャッシュがブラウザの再起動や電源サイクルの両方を生き延びたことを知って驚いたが、iOSデバイスの特技はどれも一致することができませんでした。

可能性警告：のレビューAndroidのWebKitのソースツリーはそのキャッシュの制限はRAMの量および/ またはそれが走っている上の特定のデバイス上で使用可能なフラッシュメモリに基づいて適応させることができると信じて私をリードしています。 trueの場合、これらの数字は、Nexus Oneのに適切であるかもしれません。キャッシュ·サイズが使用されていないメモリではなく、メモリの合計に基づいて適応している場合、実際には、これらの数字は私のネクサスOneにも適用可能である。

私は間違っていますが、iPhone 3GSとiPhone 4のiOS 4.0テスト結果の違いは、この理論をサポートすることができます。（AndroidとMobile Safariには、両方のWebKitベースのブラウザなので、一般的にこの動作をする場合があります。）は、WebKitのソースに精通していると、この上でより多くの光を当てることができたら、私に連絡してください。

iOSの

結果は、IOSの最新の3つのバージョン間で激しく変化した。驚くほど、IOS 3.1.3上のモバイルSafariは明らかに無限のページキャッシュのサイズを有するにもかかわらず、 任意のサイズのコンポーネントをキャッシュしませんでした 。それがiOS 3.1.3のユーザーはおそらく彼らは無線LANを使用していない場合は特に、次善のブラウジング体験を得ていることを意味しているので、これは厄介です。それだけで戻る/進むナビゲーションのために戦場に出るので、無制限にページキャッシュのサイズは、ここで少しいいません。この動作は、他の人が以前のIOSリリースで観察されたものから大幅な変更であり、私はそれのために何か良い理由を想像することはできませんので、私はこれはバグかもしれないと思う。

のiOS 3.2のモバイルSafariは（アプリでのみ使用可能である）このバグは発生しません。その25.6キロバイトコンポーネントの制限と〜281.6キロバイト合計キャッシュの制限がないよりはましですが、彼らはまだ試験した他のデバイスに比べて微々たるように見える。一意iOSデバイスの間で、iPadは25.6キロバイト、そのコンポーネントのサイズの上限と同じにページキャッシュ内のページのサイズを制限するために表示されます。

のiOS 4.0のモバイルSafariはiPhone 3GSでと制限が使用可能なRAMに基づいて適応させる（;テスト両方のデバイスはフラッシュメモリ32GBのを持っていたiPhone 4が512メガバイトている間iPhone 3GSは256MBを持っている）ことを意味するiPhone 4、上の別の限界を示した。 iPhone 3GSで、IOS 4.0 51.199キロバイトコンポーネントのサイズ制限と〜1.05メガバイト合計コンポーネントのキャッシュ·サイズを持っています。

iPhone 4に、コンポーネントのサイズ制限は102.399キロバイトで、ほぼ正確にiPhone 3GSの2倍の限界だった。総部品·キャッシュ·サイズは、約1.9メガバイトであった。のiOS 3.2およびiOS 4.0が別々に開発が共通祖先から分岐していたかもしれないので、IOS 4.0のページキャッシュのサイズはちょうどiOSの3.1.3のように、テストされ、両方のデバイス上で使用可能なRAMによって制限されるように表示されます。

ただ、実際にブラウザを殺すことなく、アプリケーションを切り替えるときにキャッシュを保持しなかったがiOSデバイスのいずれも、強制的にブラウザの再起動やデバイスの電源サイクルを通して永続キャッシュの内容を保存しません。

ウェブOS

ウェブOSの私のテスト結果は、私は彼らに少し自信を持っているので、矛盾していました。私は完全を期すために純粋に収集するために管理なけなしのデータが含まれていました。塩の多額の粒とそれを取るしてください。

などの近くに私が決定することができたとして、WebOSは、ページキャッシュ内に一致するページ·サイズの制限で、1MB程度の個々のコンポーネントのサイズ制限があるかもしれません 。私は同軸することができませんでしたIf-None-MatchするかIf-Modified-Sinceがサポートしていないことを意味するウェブOSからのリクエストヘッダETagとLast-Modified 。

いくつかのテストでは、それはウェブOSの最大コンポーネントのサイズが1MBよりも大きいように見えたが、これは矛盾していました。私の知る限り、WebOSは最大合計キャッシュ·サイズに達すると、されたときに電話は電源を再投入するまで、特定のポイント·おそらく後にキャッシュだけで完全に完全に動作を停止し、厄介なバグを持っているように見えます。いくつかのケースでも、パワーサイクルは、キャッシュの破損を修正していないので、私は最終的に問題とウェブOSキャッシュの正確な限界の正確な原因を確立しようとしてあきらめた。

勧告

これらの結果に基づいて、私がテストしたデバイス用のWebアプリケーションを開発する人には、次の推奨事項を提供しています：

遠未来のキャッシュの有効期限ヘッダを使用します。これは条件付きGET要求を送信することからブラウザを防ぐことができますし、サポートしていません。ウェブOSでキャッシュ機能を向上させETagやLast-Modified 。
のiOS 4.0はiPadに到着するまで、少なくとも圧縮されていない、25.6キロバイト以下に個々のコンポーネントのサイズを制限しようとする。あなたのiPhoneユーザーはできるだけ早くのiOS 4.0にアップグレードするよう強くお勧めします。
あなたのウェブサイトは、それが25.6キロバイトよりも大きいコンポーネントを必要とする場合、IOS 3.1.3ユーザー（可能性がある）をサポート、またはすべてのコンポーネントの合計サイズが281.6キロバイトより大きい場合は、HTML5のアプリケーションキャッシュを使用することを検討しなければならない場合のlocalStorage 、またはデータベースストレージコンポーネントを格納する。アレックス状況についての最近のYUIブログの記事、オフラインアプリケーションでのYUI 3を使用しての概要は、このアプローチを検討してYUI 3開発者のために興味があるかもしれません。
独自のテストを行います。これらの結果はテストブラウザまたはデバイスのいずれかの任意の将来のバージョンに適用されることを前提としないでください。出発点として、これらの結果を使用していますが、あなたがモバイルキャッシュの制限に関する仮定に基づいて主要な決定を下す前に自分で確認してください。雷のペースでモバイルブラウザの世界が変化するため、本研究では非常に短い貯蔵寿命を持ちます。

私はしましたGitHub上の私のテストコードが利用可能になって、私はあなたが、それを使用してそれをforkし、あなたが学んだことを共有することをお勧めします。

ドキュメントの呼び出し

ブラウザメーカーは、ブラウザのキャッシュの制限を文書化し公開を検討してください。これらの制限は一般的に非問題になるように高いデスクトップの世界では、ドキュメントは必要ありませんでした。携帯電話の世界では、ブラウザのキャッシュの制限は、Web開発者は魅力的な機能とパフォーマンスの高いWebサイトを作成するために持つ必要がある重要な情報です。

localStorageを、アプリケーションキャッシュなどの新機能の限界は、通常、十分に文書化されています。同様に、コンポーネントのキャッシュにドキュメントのこのレベルを拡張してください。

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

19コメント

素晴らしいもの、これを行うためのおかげで、ライアン！
ベンダーは、ドキュメントのためのあなたのコールを聞くために待っている間に、これらのチェックがbrowserscope.orgに追加されているようにクールになる。ボランティア？ :)
によるコメントストヤン - 2010年6月28日＃
これらの結果を公開してくれてありがとう！私は最近、自分の上に同様の研究を実行し、またAndroidの電話は電源を入れ直した後も生き残ったキャッシュされたコンポーネントを、どのように扱うかに感銘を受けました。
私はまた、メモリキャッシュと "ディスク"キャッシュ、フルブラウザを再起動または電源サイクルを存続そのうち後者を区別することが重要だというのが私の研究で見いだされた。ユーザーがページからページを参照されており、私はこのユースケースは、コンポーネントのサイズが（私は2メガバイトコンポーネントのサイズまでテスト済み）はるかに大きいことが分かったときは、メモリキャッシュはメモリに常駐します。キャッシュ制御と、遠い将来の有効期限と、ページからページをブラウズするetagsの除去、モバイルSafariもアンドロイドどちらも、サーバーへのラウンドトリップを作る。しかし数分後、両方のブラウザでは、ファイルがまだクライアントのメモリに常駐されたことを示す、304を送り返すだろう最大のコンポーネント（この場合は2メガバイト）、およびサーバのステータスを確認するには往復になるだろう。数分の経過のブラウザは、コンポーネントのサイズに応じて降順で、各コンポーネントに対してこれを行うには続けた。
私はTechPulse紙のための研究を行ったが、私はよりよい私の調査結果を整理し、それらを公開することができます場合、私は表示されます。
最後の思考：残念ながら、これらはAndroidユーザーの大半を占めるように、それはアンドロイド1.5 1.6の研究を見ても面白いかもしれません。これらのユーザーは、Androidのドキュメント（申し訳ありませんが、私は今のリンクを提供することはできません）で更新された公式統計によれば、Androidユーザーのわずか50％以上を表しています。私はこれがウェブOSのユーザーに比べて、より多くのユーザーを表し理解するものから、これだけアンドロイド1.5/1.6の拡張研究は、おそらく、より適切であろう。
最後に、私のラップトップとして謝罪はショップであり、私は私のiPhone上でこれをタイプしている。私はおそらく勲章か何かに値する！
によるコメントデビッド·カルフーン - 2010年6月28日＃
DOHは、私はそれがiPhoneは（伝統的なキャッシング、などの新しいキャッシュ技術とは対照的に）キャッシングとひどいであることを偶然だとは思わないことに言及し忘れていました。私は、彼らがFlashをサポートしていないとやったのと同じように、意図的に強制的に封筒をプッシュするためにこれをやったと思う。それは基本的にFlashの除去は、開発者が新しいCSS3の変換やアニメーションを使用する方法を学習せざるを得なくなったように、開発者はキャッシュ·マニフェストとローカルストレージを使用する方法を学ぶことを余儀なくされている。
によるコメントデビッド·カルフーン - 2010年6月28日＃
小さなタイプミス "テスト両方のデバイスは、フラッシュメモリ32MBのあった"、32GB読むべきではありません。
更新された結果のおかげで、これは本当に便利です！
ニコラスによるコメント- 2010年6月28日＃
@ストヤン：素晴らしいアイデア！
@デビッド：興味深い。私は多くの時間が私のリクエストの間を通過することはできませんでしたので、私はあなたが記述の検証要求を気付きませんでした。私はあなたの調査結果の残りの部分を見てみたい。
@ニコラス：良いキャッチ。私が訂正して記事を更新しました。ありがとう！
によるコメントライアン·グローブ - 2010年6月28日＃
私は、ウェブOSのキャッシュの不足を確認することができます。この事はあっても確実にシンプルなページが表示されます（このような）キャッシュされません。：（
によるコメントリチャード - 2010年6月28日＃
いい仕事ライアン
によるコメントフィリップ·テリス - 2010年6月28日＃
素晴らしい記事！ライアンは感謝しています。
しかし、私はそれを "3.1.3で3G/3GS"私のためにトライを与え、彼らは正しくリソースをキャッシュするように見えた。
あなたは、2GのiPhoneとして "1次の世代のiPhone"を意味しませんでしたか？
私も3.1.3で、OS 3G/3GSは、2G（第一世代）とは異なる動作を推測する。
私はこれが役立つかもしれないと思います。
デュアンによるコメント- 2010年6月29日＃
したがって、アンドロイドでも最高のブラウザとFlashを持っています。 FUはiPaid！
おかげでライアン、素敵な仕事と非常に便利。
コメントby フェリックス·ナーゲル - 2010年6月29日＃
偉大な仕事が、私はこれは良いテストではないと思います。ユーザーは、特定のIMGやスタイルシートのURLをクリックすることはほとんどありません - その代わりに、彼らは、ページ間でナビゲートします。より適切であることがテストでは、キャッシュは典型的なWebワークフローの中にどのように動作するかを確認する必要があります。デイビッドと同様に、私は別のページにまたがって移動したような大きなリソースが（> 1MB）キャッシュされた示されたモバイルSafariでテストを実施しました。これは、より一般的なユーザーシナリオです。だから、例えば、iPhone 3のみのキャッシュは52Kと言って見当違いのようです。最低でも、我々は別の列を必要としています。それはコードがGitHub上で稼働していることを素晴らしいことだが、人々が試みることができることがテストのホステッドバージョンがあった場合、それは良くなると思います。ニースの仕事 - 私はこれは実際のユーザーが経験しているかを明確にしないと思います。直接私にpingを実行し、我々はより徹底的なテスト設計スコープ外にすることができます。
コメントby スティーブSouders - 2010年6月29日＃
@スティーブ：私は、テスト方法の改善を図るためのあなたの結果とあなたのアイデアについての詳細を聞いてみたい。私はあなたにメールを送った。
によるコメントライアン·グローブ - 2010年6月29日＃
"ページ·キャッシュには、喜んで利用可能なRAMが枯渇し、ブラウザがクラッシュされるまで、私はそれで投げたすべてのバイトをキャッシュし、個々のページのサイズに制限はありませんように見えた。"
このクラッシュが望ましい動作ですか？ iOSとWebOSは上のブラウザでもクラッシュするのですか？もっとケチキャッシュの制限は、クラッシュを制限するように設計されている場合がありちょうど考え、私が今まで私にモバイルサファリクラッシュを持って覚えていないことができます。
@フェリックスは、どのようにこれらの結果は、Androidが "最高のブラウザ"を持っている意味ですか？単にキャッシュの動作よりも "最高"にだけではありません。
大によるコメント- 2010年6月30日＃
@大：クラッシュが望ましいことはありませんが、このケースでは、問題を引き起こすことが5メガバイト以上のコンポーネントをしました。 1次の世代のiPhoneのMobile Safariには5MBの周りに問題を抱えている傾向があり、10メガバイトの周り3GSで、私はそれがあっても20メガバイトでiPhone 4上でクラッシュを得ることができませんでした。 Nexus OneのAndroidのは10MBの周りに問題を抱えて開始する傾向がみられた。 WebOSはページキャッシュのサイズを制限するために登場し、他の人のようにクラッシュしませんでしたが、私が記事で書いたように、それ自身の問題を抱えていた。
も関与してテストがダウンロードされたデータを表示するので、これはメモリ使用量に貢献したであろう。私は表示されない、または単にファイルシステムにダウンロードされているリソースと同じ動作を期待していないだろう。
によるコメントライアン·グローブ - 2010年6月30日＃
使用iCab：IOSとiPhone、iPad、およびiPodのタッチについて。
iCabのブラウザは、任意のモバイル·プラットフォーム上で最良のモバイル·ブラウザ·キャッシュを備えています。それは全体のWebページを保存しますので、何も再ダウンロードする必要はありません。あなたは、Webサイト全体のWebページを保存するを選択することができます。それは、デスクトップブラウザにそれが似ているようにするにはタブや他の機能を備えています。
iCab。
それは非常に満足のWebブラウジング体験への答えです。
ジェームズKATTによるコメント- 2010年7月1日＃
こんにちは！レビューをありがとうございました。株式1以外にもAndroidマーケットにおける他の多くのブラウザがあるので、私はそれは例えば、ドルフィン[HD]のような他の広く使われているブラウザをテストするために理にかなっていると思います。私は最近、ドルフィンはSDカードにコンテンツをキャッシュするオプションが含まれていることに気づいた...
によるコメントウラジミールケルマン - 2010年7月2日＃
私はあなたの努力を称賛し、ライアンを仕事だけでなく、スティーブのコメントをエコーします。君たちが生成されるものを楽しみにしています。
あなたが認識しているかどうかわから注意：Androidブラウザのディスクキャッシュアルゴリズムは、webkitのレポ（ブラウザのネットワーキングは、Java層ではないwebkitのC / C + +層によって処理されます）実際にはありません。でCacheManager.java見http://bit.ly/azhsGH 。ディスクキャッシュが6メガバイトより大きい場合、アルゴリズムはほぼすべての5のネットワーク要求は、それがトリミングされていること。また、あなたの研究が見つかりましたように2MBにディスクキャッシュされたコンポーネントのサイズを制限する定数CACHE_MAX_SIZEを見ることができます。あなたが経験したクラッシュは6メガバイトのトリム制限に関連している可能性がある場合、私は驚かないだろう。（私は一度クライアントのOSのソース内のキャッシュのバグを修正しなければならなかったので、奇妙な私はこれを知っている。）
私は、あなたが認識して確信しているようにとにかく、この手段は実際にはそれが正確なキャッシュの制限（アンドロイド例えばリバースエンジニアリングをすることは困難であることができるということですか、結果は5番目のネットワーク要求したかどうかに応じて異なる場合がありますかどうか - 誰がiphoneアルゴリズムが何であるか知っている）、あなたのような解読いくつかの使用可能なガイドラインはここで行われ、パブリッシュするメーカーを尋ねてきたものの、依然として有用である。
によるコメントイシャンアナンド - 2010年7月2日＃
@イシャン：余分なアプリの詳細についてはありがとう！それは非常に役に立ちます。スティーブと私は現在、いくつかの新しいテストに取り組んでおり、すぐにこれに多くの光を当てることができるように願っています。
によるコメントライアン·グローブ - 2010年7月2日＃
あれば私も興味がありUIWebViewつがモバイルSafariと同じ制限があります。iOSアプリケーションに含めることができます。 stackoverflowの質問を示しUIWebViewでHTML5のキャッシュマニフェストは動作しません。
ケビンHakansonによるコメント- 2010年7月6日＃
これらの結果を公開してくれてありがとう！それは基本的にFlashの除去は、開発者が新しいCSS3変換し、アニメーションを使用する方法を学習せざるを得なくなったのと同様に、開発者はキャッシュ·マニフェストとローカルストレージを使用する方法を学ぶことを余儀なくされている。
によるコメント技術ブログ - 2010年7月18日＃

申し訳ありませんが、コメントフォームは、この時点でクローズされます。

を搭載ワードプレスでヤフーウェブホスティング。

ヤフーユーザーインターフェイスブログ（YUIBlog）