GlideのMemoryCacheSizeとBitmapPoolSizeの違い

Question

私は、MemorySizeCalculatorについてGlideについて不思議です。デフォルトメモリキャッシュサイズはgetMemoryCacheSize()から、ビットマッププールサイズはgetBitmapPoolSize()から取得できます。

MemorySizeCalculator：

/** 
* Returns the recommended memory cache size for the device it is run on in bytes. 
*/ 
public int getMemoryCacheSize() { 
    return memoryCacheSize; 
} 

/** 
* Returns the recommended bitmap pool size for the device it is run on in bytes. 
*/ 
public int getBitmapPoolSize() { 
    return bitmapPoolSize; 
} 

私は同様にメモリキャッシュの概念を理解ではなく、ビットマップ・プールのサイズを確認しますので、私は、このリンクからいくつかの情報が見つかりました：https://medium.com/@ali.muzaffar/performance-improvement-and-bitmap-pooling-in-android-f97b380cf965

ビットマップ・プーリングは簡単です（毎回 が複雑になりますが）毎回 という新しいビットマップを作成するのではなく、ビットマップを再利用することを目指しています。簡単に言えば、ビットマップが必要なときは、 ビットマップスタックをチェックして、使用可能なビットマップがあるかどうかを確認します。 ビットマップがない場合は、新しいビットマップを作成します。それ以外の場合は、スタックから ビットマップをポップして再利用します。その後、ビットマップ で作業を終えたら、スタックに置くことができます。

スタックにプッシュされたビットマップもメモリにキャッシュされていると思います。このコンセプトを理解するのを手助けできる人はいますか？

Answer 1

1. ビットマッププールは ビットマップを作成するための時間を節約するために使用汚いビットマップを、キャッシュされました。私たちは memoryCacheにキャッシュされたすべてのビットマップを約束できないからです。
2. 以前使用していたmemoryCacheキャッシュビットマップ。

Answer 2

イメージ重いアプリケーションは多くのイメージをデコードする必要があります。そのため、アプリケーションのメモリの割り当てと割り当ての解除が継続されます。その結果、ガベージコレクタ（GC）が頻繁に呼び出されます。また、GCを何度も呼び出すと、アプリケーションのUIがフリーズします。 Glideでは、イメージを効率的に読み込むためにBitmap Pool Conceptを使用します。ビットマッププールを使用してアプリケーションのメモリの割り当てと割り当てを継続的に回避すると、GCオーバーヘッドが削減され、スムーズに実行されるアプリケーションになります。

基本原則は単純です。ビットマップを処理するときは、ビットマップ2がビットマップ1と同じかどうかを確認する必要があります。そのためには、それらを比較する必要があります。その場合、ビットマップ1をinbitmapとして再利用して同じメモリ空間を再利用してgitmap 2を処理し、その後GCをスキップすることができます。

メモリキャッシュは、各アプリケーションに割り当てられたメモリスペースです。 1つのアプリケーションが他のアプリケーションのキャッシュメモリにアクセスできません。サイズは限られています。