lrucacheandroid
① android 什麼情況會用lrucache
內存緩存技術對那些大量佔用應用程序寶貴內存的圖片提供了快速訪問的方法。其中最核心的類是LruCache (此類在android-support-v4的包中提供) 。這個類非常適合用來緩存圖片，它的主要演算法原理是把最近使用的對象用強引用存儲在 LinkedHashMap 中，並且把最近最少使用的對象在緩存值達到型敬閉預設定值之前從內存中移除。
在過去，我們經常會使用一種非常流行的內存緩存技術的實現，即軟引用或弱引用 (SoftReference or WeakReference)。但是現在已經不再推薦使用這種方式了，因為從 Android 2.3 (API Level 9)開始，垃圾回收器卜裂會更傾向於回收持有軟引用或弱引用的對象，這讓軟引用和弱引用變得不再可靠。另外，Android 3.0 (API Level 11)中，圖片的數據會存儲在本地的內存當中，因而無法用一種可預見的方式將其釋放，這就有潛在的風險造成應用程序的內存溢出並崩潰。
為了能夠選擇一個合適的緩存大小給LruCache, 有以下多個因素應該放入考慮范圍內，例如：
你的設備可以為每個應用程序分配多大的內存？
設備屏幕上一次最多能顯示多少張圖片？有多少圖片需要進行稿灶預載入，因為有可能很快也會顯示在屏幕上？
你的設備的屏幕大小和解析度分別是多少？一個超高解析度的設備（例如 Galaxy Nexus) 比起一個較低解析度的設備（例如 Nexus S），在持有相同數量圖片的時候，需要更大的緩存空間。
圖片的尺寸和大小，還有每張圖片會占據多少內存空間。
圖片被訪問的頻率有多高？會不會有一些圖片的訪問頻率比其它圖片要高？如果有的話，你也許應該讓一些圖片常駐在內存當中，或者使用多個LruCache 對象來區分不同組的圖片。
你能維持好數量和質量之間的平衡嗎？有些時候，存儲多個低像素的圖片，而在後台去開線程載入高像素的圖片會更加的有效。
並沒有一個指定的緩存大小可以滿足所有的應用程序，這是由你決定的。你應該去分析程序內存的使用情況，然後制定出一個合適的解決方案。一個太小的緩存空間，有可能造成圖片頻繁地被釋放和重新載入，這並沒有好處。而一個太大的緩存空間，則有可能還是會引起 java.lang.OutOfMemory 的異常。
② android dislrucache清除緩存怎麼做
一：下載個類似手機管家的軟體，這類軟體都有清理垃圾的功能，非常容易就能清楚手機緩存。 二：這類軟體的使用步驟大致相同。一般就是打開軟體，在首頁上都可以看到類似清理垃圾的功能鍵，點擊即可。 三：清除緩存的好處：1、手機運行更快，一般不會卡。 2、手機上網更快。 3、手機有更多的空間下載想要下載的東西。
③ android volley ImageLoader+ImageCache+LruCache內存緩存的
Volley是Google在Google I/O 2013上發布的一個網路框架，主要功能：web介面請求，網路圖片非同步下載，支持緩存。volley只是定義了緩存以及Request的介面，具體實現可以自己定義，例如lru磁碟緩存，內存緩存,下載圖片的ImageRequest.
Volley的源代碼里包含了一些實現，都在com.Android.volley.toolbox包里，包括磁碟緩存、json請求,圖片請求。還定義了一個繼承自ImageView的NetworkImageView,可以非同步載入網路圖片。
④ android disklrucache怎麼使用
下面是一個簡單的DiskLruCache實現。然而推薦的實現DiskLruCache方案請參考Android4.0中（libcore/luni/src/main/java/libcore/io/DiskLruCache.java）源碼。本文使用的是之前版本中的簡單實現（Quick Search中是另外的實現）.
顯示是簡單實現DiskLruCache更新後的例子：
private DiskLruCache mDiskCache;
private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MB
private static final String DISK_CACHE_SUBDIR = "thumbnails";
@Override
protected void onCreate(Bundle savedInstanceState) {
...
// Initialize memory cache
...
File cacheDir = getCacheDir(this, DISK_CACHE_SUBDIR);
mDiskCache = DiskLruCache.openCache(this, cacheDir, DISK_CACHE_SIZE);
...
}
class BitmapWorkerTask extends AsyncTask {
...
// Decode image in background.
@Override
protected Bitmap doInBackground(Integer... params) {
final String imageKey = String.valueOf(params[0]);
// Check disk cache in background thread
Bitmap bitmap = getBitmapFromDiskCache(imageKey);
if (bitmap == null) { // Not found in disk cache
// Process as normal
final Bitmap bitmap = (
getResources(), params[0], 100, 100));
}
// Add final bitmap to caches
addBitmapToCache(String.valueOf(imageKey, bitmap);
return bitmap;
}
...
}
public void addBitmapToCache(String key, Bitmap bitmap) {
// Add to memory cache as before
if (getBitmapFromMemCache(key) == null) {
mMemoryCache.put(key, bitmap);
}
// Also add to disk cache
if (!mDiskCache.containsKey(key)) {
mDiskCache.put(key, bitmap);
}
}
public Bitmap getBitmapFromDiskCache(String key) {
return mDiskCache.get(key);
}
// Creates a unique subdirectory of the designated app cache directory. Tries to use external
// but if not mounted, falls back on internal storage.
public static File getCacheDir(Context context, String uniqueName) {
// Check if media is mounted or storage is built-in, if so, try and use external cache dir
// otherwise use internal cache dir
final String cachePath = Environment.getExternalStorageState() == Environment.MEDIA_MOUNTED
|| !Environment.isExternalStorageRemovable() ?
context.getExternalCacheDir().getPath() : context.getCacheDir().getPath();
return new File(cachePath + File.separator + uniqueName);
}
內存緩存檢查在UI線程中做，磁碟緩存的檢查在後台線程中。硬碟操作不應在UI線程中。圖片處理完成後應將其加入正在使用的內存、磁碟緩存中。