12

キャッシングの最初のレイヤーをAndroidアプリに実装することを考えています。確かにOOM例外を回避するためにSoftReferencesを検討していましたが、Androidがこれらを「早すぎる」解放する方法についての記事がたくさんあるので、android.util.LruCacheキャッシュを調べることにしました。

質問：実際のデバイスに合わせて適切にサイズを変更するにはどうすればよいですか？LRUキャッシュが実際のソリューションであり、SoftReferencesではないことは非常に良いことのように思えますが、OOM Exceptionsを避けたい場合は、メガバイト単位のハードリファレンスを使用するのは非常に危険です。あなたが私に尋ねるなら、それはただ危険です。とにかく、これが唯一の選択肢のようです。getMemoryClassを調べて、実際のデバイス上のアプリのヒープサイズを調べていました（+キャッシュのサイズを変更する前に空きヒープサイズを確認しました）。ベースラインは16メガバイトで問題ないように聞こえますが、デバイス（たとえば、昔はG1）が約5メガバイトのヒープサイズ（Eclipse MATによる）のOOM例外をスローするのを見てきました。G1が非常に古いことは知っていますが、重要なのは、私の経験が、ドキュメントに記載されている16メガベースのベースラインと実際には一致していないということです。だらか、私' m合理的に取得できる最大のものが必要な場合、LRUキャッシュをどのようにスケールアップする必要があるかが完全にわかりません。（8メガで満足し、低スペックのデバイスでは1メガで十分です）

ヒントをありがとう。

編集：私が参照しているAndroid LRUキャッシュクラス：http：//developer.android.com/reference/android/util/LruCache.html

4

2 に答える 2

14

LruCacheサイズを計算するための有効なソリューションは、開発ガイドに概説されていると思います。

int memClass = ( ( ActivityManager )context.getSystemService( Context.ACTIVITY_SERVICE ) ).getMemoryClass();
int cacheSize = 1024 * 1024 * memClass / 8;

詳細については、http： //developer.android.com/training/displaying-bitmaps/cache-bitmap.htmlをご覧ください。

于 2012-05-03T15:52:43.587 に答える
0

あなたの質問から、あなたが何を求めているのかを理解するのは少し混乱します。試してみましょう。

さまざまなキャッシュ製品のAppFabric、memcached、ncache、scaleoutには、オブジェクトごとに1Mの制限があります。スケールアウトはある種のカスタマイズを提供すると思います。

しかし、これらはすべてサーバーサイド製品です。したがって、おそらく単一ホストのローカルキャッシュのみであるAndroidデバイスの場合、おそらく最大64kbを使用します。つまり、デバイス上のオブジェクトごとに64kb以上が必要なのはなぜですか。ただ私の推測。

私があなたなら、memcached（最も有名なオープンソースキャッシングソリューション）を勉強します。また、スケールアウトを使用してHello Worldを簡単に機能させることができるため、スケールアウトになる可能性があります。そして比例して決定します。

于 2012-02-22T18:12:22.853 に答える