問題タブ [android-lru-cache]

LruCache の使用例に基づいて、このアダプター クラスを作成しました。私が遭遇した問題は次のとおりです。

高速スワイプを実行し、GridView が非常に下または上にスクロールすると (ビットマップがまだキャッシュされていない場合)、画像は空のままではなく、間違ったビットマップで描画されます。最終的に正しいものが読み込まれるまで、GridView がまだ (スクロールしていない) 間、画像は変化し続け、その後、すべてが本来の状態になります。コードに問題が見当たりません...これを回避する方法について何か考えはありますか?

Picasso と okhttp を使用して、画像をディスクにダウンロードしてキャッシュします。以下のコード スニペットを使用して 10MB のキャッシュを okhttp クライアントに設定し、それを Picasso に使用しています。

これは、ほとんどの場合、オフラインの場合でも画像のキャッシュとリロードを完全に機能させますが、問題は、画像キャッシュを完全にクリアする場合があることです。

念のため画像キャッシュのサイズをチェックしていますが、2 MB を超えたことはありません。

キャッシュがクリアされる理由は他にありますか?

LruCache でオブジェクト モデルをキャッシュする ActiveAndroid の既定の動作を無効にする方法を知っている人はいますか?

プロジェクトから完全に無効にしたい。Cache.clear();を使用してキャッシュを手動でクリアできました。しかし、クリアする必要があるたびにそれを続ける必要があります。構成を介してすべてを無効にしたいだけです。

JSONからデータベースにデータを保存するルーチンを実装しました。その後、ユーザーがオフラインになると、すべてのデータを見ることができます。ただし、ピカソは最初の実行後に画像をロードしません。しかし、アプリケーションをオンライン モードで 2 回実行すると、その後 picasso はオフライン モードでキャッシュから画像を読み込むことができます。(最初の実行時に画像をキャッシュする必要がありますが、機能していません)

提案をいただければ幸いです

私は Android 開発の世界に足を踏み入れており、Volley と LruCache を使用して基本的なニュース リーダー アプリを作成しています。

各セルに Volley ライブラリの NetworkImageView が含まれるリサイクラー ビューがあります。そのセルをタップすると、別のアクティビティが開きます。これは、セル内の画像の拡大版を表示する一種の詳細ビューです。NetworkImageView で setImageURL メソッドを使用するときに同じ URL を使用しますが、NetworkImageView がイメージを LruCache にキャッシュするために使用するキーにイメージのサイズを追加することが明らかになりました。これは、URL が同じであっても、サイズの異なる 2 つの NetworkImageView が、1 つのネットワーク呼び出しではなく 2 つのネットワーク呼び出しと、キャッシュへの 1 つの呼び出しを作成することを意味します。

いくつかの点でこれは理にかなっていますが、なぜ必要以上に大きな画像をキャッシュするのでしょうか? ただし、サイズ変更された画像ではなく、元の画像をキャッシュできるかどうか疑問に思っていましたか?

それが理にかなっているといいのですが、ありがとう、デビッド。

親愛なる StackOverflower 様

私のAndroidアプリケーションでは、ffmpeg-android-javaを使用してビデオからフレームをすばやく取得してImageView. 問題は、典型的なffmpeg's -ssseek コマンドを使用すると、出力をメモリに書き込む必要があることです。これは、パフォーマンスに大きな影響を与えると思います。

ffmpeg -ss 00:23:00 -i Mononoke.Hime.mkv -frames:v 1 out1.jpg

上記のような一般的なコマンドの実行には、約 700 ～ 1200 ミリ秒かかります。LruCacheですから、メモリに書き込むのではなく、より良いパフォーマンスを達成することを願って書き込みたいと思います。

問題は、コマンドffmpeg-android-javaを実行するためのラッパーであるため、コマンドのアドレスffmpegを正しく指定する方法がわかりません。LruCache

以下は私のコードスニペットです：

私は2つのアプローチを考えています

• JSON 応答を JSON ファイルとしてキャッシュする
• Reservoir を使用して Java POJO をキャッシュします (JSON 応答は、Retrofitを使用して既にシリアル化解除されています)。

データの説明:
ここでキャッシュしたいデータは、e コマース サイトの 20 個の製品のリストです。これらは複雑なオブジェクトではなく、jsonapi.org の仕様がここで使用されているため、ネストはありません。Retrofit を使用すると、Product が 10 個未満の属性を持つ Java モデル クラスである 20 個の Product POJO を既に取得できます。

どちらのアプローチが優れているか、またその理由は?

SQLite データベースは、より高価で、次の場合にのみ適していると思うので、考慮していません。

• データの整合性が必要
• ショッピングカートなどの書き込み操作があります
• 複雑な関係を持つ大量のデータ

私のアプリには、いくつかのサムネイルを含む別のリスト ビューがあります。今日、私はリファクタリングを開始し、LRU キャッシングを実装したいと考えています。私は Android のガイドラインに従っていますが、アプリ全体に対して 1 つの LRU キャッシュのみを初期化する方がよいのか、それともリスト ビューごとに LRU キャッシュを初期化する方がよいのか疑問に思っています。outOfMemory が怖いです。したがって、私自身では答えられない次の質問があります: - シングルトン パターンで初期化された 1 つの LRU キャッシュは良い考えですか? - メモリが少ない場合、次の LRU キャッシュの初期化で outOfMemory 状況が発生しますか?

• メモリが少ない場合、LRU キャッシュは自動的に解放されますか? LRU キャッシュを使用すると、アプリがメモリを解放する際に問題が発生するかどうか疑問に思っています (メモリ不足のためアプリがクラッシュしますか?)

• アプリ全体で LRU キャッシュが 1 つしかありませんが、問題になる可能性はありますか?

• アプリ全体に複数の LRU キャッシュがありますが、問題になる可能性はありますか?

ドキュメントを見て、LruCache がアプリの残りの部分とヒープ リソースを競合しているかどうか、または実際に精巧なディスク スワッピング メカニズムを使用しているかどうかを理解しようとしています。

私が尋ねている理由は、デバイスがインターネット接続を失った場合に大量の画像データをローカルに保持できるように、キャッシュに大量のメモリを割り当てたい (ギグなど) ことです。ただし、LruCache がアプリのヒープ メモリ割り当てのサイズによって制約されている場合、これは明らかに機能しません。

この機能がどのように機能するか、また、これがこのニーズを処理するのに適切な機能ではない場合、自分でロールバックする必要がある場合、または Android ネイティブ ディスク スワップ メモリ クラスがおそらくLruCacheと組み合わせる必要があることを見落としています（または完全に単独で使用しますか？）