バックグラウンド
Android の最大ヒープ サイズは非常に限られており、デバイスごとに最大ヒープが異なります。
一部のアプリでは、内部/外部ストレージだけでなく、メモリ内に物 (通常は画像) をキャッシュする機能が必要です。
もちろん、ビットマップの処理やメモリの使用をできるだけ少なくするためのヒントはたくさんありますが、キャッシュも必要です。
問題
キャッシングの可能な解決策をたくさん読んだことがありますが、キラーキャッシングソリューションとなるような種類のキャッシングを提供するものはありません。私が望んでいるのは、次の機能を持つキャッシュメカニズムです。
メモリ不足を心配することなく、ヒープを無制限に使用できます。アプリにはメモリが必要ですが、十分な空きメモリがありませんか? そのため、いくつかの (参照されていない) アイテム (およびそのキー) を解放します。
スレッドの安全性/並行性。
LRU ベースのキャッシュを提供することで、最近使用されたアイテムが残る可能性が高くなります。
可能な限り生き続けます (ただし、クラッシュは発生しません)。しかし悲しいことに、Android では Java に比べて非常に迅速にソフト/ウィーク参照が GC されます。
実寸を隠した物を扱える能力。Android では、API 10 以下では、ビットマップはヒープ メモリを使用しませんでしたが、ヒープ メモリと見なされていたため、単一の参照 (4バイト程度）。これが、一部のソリューションが、各アイテムのサイズと、アイテムを削除するときに何をすべきかを人為的に伝えることを提案する理由です。
いくつかの良い解決策
LruCache - API 12 のクラス (コードは簡単にコピーできます)。
利点: #2 (?)、#3、#5。
欠点: #1、#4、さらに API 12 で提供されているため、ソース コードをコピーする必要があります。
50ページに示されているように、このレクチャーから取得した、その値のソフト/弱い参照を持つハッシュマップ。
利点: #1 (ただし、キーは削除されません)、#2 ( ConcurrentHashMapを使用する必要があります)
短所: #3、#4、#5
以前のソリューションの高度なバージョンのようなMapMaker ( guavaライブラリから入手可能)。
メリット : #1, #2
短所: #3、#4、#5
guava ライブラリを介したキャッシュ ソリューション。長所と短所は、選択に基づいています。どの構成がニーズに最も適しているか、また Android で正常に動作するかどうかはわかりません。残念ながら、Android 用のライブラリをコンパイルすることさえできません。
Android クエリ- どのように機能するかわかりません。とても使いやすいようですが、メリットとデメリットがよくわかりません。
質問
キラーキャッシングメカニズムを知っている人はいますか?
機能 #5 についてはあまり気にしません。これは非常に高度であり、新しい Android バージョンを使用する人が増えているため、将来的にはあまり必要とされないためです。