1

Jake Wharton の DiskLruCache libを使用しています。

ビューとアプリケーション全体の両方でキャッシュを使用して、アプリのパフォーマンス、キャッシュ戦略に興味があります。ほとんどの場合、イメージは変わりません。

たとえば、サーバーに 320x320 の写真があるとします。ストリームを開き、画像を保存します。

  1. リスト ビューではビットマップを表示し、詳細ビューではより大きな画像を表示します。サムネイルのビットマップも保存する必要がありますか? その方が効率的ですか？

  2. アプリ全体でキャッシュ「オブジェクト」を共有した経験はどうですか (同じデータを利用する可能性のある複数のビューがあるとします。これにはどのような問題がありますか?

  3. パフォーマンスと通貨のために、サーバー上で画像が変更された場合はどうなりますか。変更されたことを知るための最善の戦略は何ですか? 変更日へのアクセス権がありません。サイズだけですが、毎回サイズを照会したくもありません。サーバー上のアプリにフラグを設定してから、フラグを照会しますか?

    1. 従来のアプリケーション (そのようなものがある場合) で、時々キャッシュをクリアするためのベスト プラクティスは何ですか? (インデントがおかしくなった。)

(iOS での Facebook によるパフォーマンスの改善をすべて見て、これを書くように促されました。キャッシングを行うための数十億はありませんが、少なくともそれについて賢くしたいと思います! 笑)

4

1 に答える 1

3

これらの回答の多くは、作成しているアプリの種類、画像の更新の重要性 (および画像が変更される可能性など)、および生成される画像の総数によって異なります。ディスク キャッシングとは別に、メモリ キャッシングも使用する必要があります。特に、同じ画像が繰り返しスクロールされる ListView やその他の領域ではそうです。LruCache を見て、Google のCaching Bitmapsエントリを読んでください。

320x320 はおそらくリストビューには大きすぎるため、サムネイルを作成することをお勧めします (デバイスやリストビューの実装方法によって異なります)。

1) ディスク キャッシュをかなり積極的に使用する必要があります (それを定義する方法は、作成しているアプリ次第です)。外部ストレージ ディレクトリを使用します。数 GB が残っている場合、たとえばアプリに 100 MB を使用しても問題ありません。とにかく必要な場合は、すべてクリアできます。

2) 問題はないはずです。ディスク IO (フラッシュ メディアに対しても) は、メイン スレッドで処理しないでください。AsyncTasks を使用して画像を読み込みます。とにかく、一度に 1 つの主要なフォアグラウンド アクティビティしか存在できません。また、アクティビティがスリープしている間は、ディスクからの読み取りを試みてはなりません。

3) 繰り返しますが、これはアプリの実装方法によって異なります。ファイルを取得するときに追加情報を取得できるはずです (Apache でさえ、アプリの最終更新日を知ることができます)。3.1) 特定の画像が使用される頻度と最新の読み取りを追跡する sqllite db を持つことができます。最新の読み取りが数日前の場合は、そのイメージの有効期限が切れます。

編集: Jake Wharton の Picasso という名前のライブラリがあり、これを使用することをお勧めします。これは、ネットワーク/ローカル IO と、メモリとディスクのキャッシュを処理します。ここで確認してください: http://square.github.io/picasso/。必要なことの多くは、1 行で実行できます。Picasso.with(this).load(imageFileURL).into(imageView);

于 2012-09-27T15:53:23.130 に答える