Android Bitmap Caching Bitmaps（渣翻譯）

標籤：android   style   blog   ar   color   使用   sp   java   on   

三、緩衝映像

1.使用記憶體緩衝
記憶體緩衝在提高佔用APP記憶體的情況下，提供快速存取映像的便利。
提倡使用LruCache來引用映像（早在API4的Support Library中已經提供該類），通過強引用LinkedHashMap來緩衝LruCache，保持最新最近使用的LruCache，移除最後使用的LruCache，從而避免記憶體溢出。
在過去的緩衝引用方式中，比較流行使用SoftReference或者WeakReference來引用映像，然而，在API 9（Android 2.3）開始，資源回收器加強了對它們的回收力度，從而導致它們相當的無效。

為了建立一個大小合適的LruCache，需要考慮一些因素：
A、你的Activity/APP運行後還剩餘多大的可用記憶體（未達到應用的記憶體限制）
B、一次性載入多少圖片到螢幕上；需要（在記憶體中）準備多少可用的圖片來載入到螢幕上，讓螢幕上先顯示一部分載入好的圖片，再繼續載入其他未載入的圖片，讓使用者有事可幹而不是漫長的等待
C、螢幕的大小和裝置的顯示密度；載入相同數量的映像到緩衝中，高顯示密度的裝置 xhdpi（如Galaxy Nexus）比低一點的顯示密度的裝置hdpi（如Galaxy Nexus S）消耗的記憶體多
D、載入到記憶體的映像是什麼尺寸和配置以及每張映像佔多少記憶體
E、緩衝映像的訪問頻率；哪些映像訪問頻率要高於其他的，對於訪問頻率高的映像，可能需要將它們更優先緩衝在記憶體中，或者建立多重LruCache
D、平衡品質與數量；有時候，緩衝大量的低品質映像的方式比開啟一個線程去載入一個高品質映像要好的多

基本上沒有一個特定的大小或準則來使用所有的應用，這隻能取決於你對使用狀況的分析以及構思出一個合適的解決方案。畢竟，載入一個太小的無用緩衝只會造成浪費，而太大可能會導致java.lang.OutOfMemory
異常或APP可用記憶體偏低（未達到應用的記憶體限制）

首先需要擷取VM可用的最大記憶體值（Mb），超過這個值會觸發OutOfMemory異常，需要注意的是，儲存在LruCache中的映像是以Kb計算的，在計算儲存大小的時候記得單位轉換

final int maxMemory = (int)(Runtime.getRuntime().maxMemery() / 1024);//假設去1/8的maxMemory來緩衝映像final int cacheSize = maxMemory / 8;LruCache<String, Bitmap> mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {    @Override    protected int sizeOf(String key, Bitmap bitmap) {        // The cache size will be measured in kilobytes rather than        // number of items.        return bitmap.getByteCount() / 1024;    }};//緩衝映像if (mMemoryCache.get(key) == null) {    mMemoryCache.put(key, bitmap);}

2.使用本機快取
記憶體緩衝在快速存取最近顯示過的映像是很有用，然而你不能過分依賴這些載入過在記憶體裡的映像。像GridView這類組件，當載入大量資料的時候很容易就填滿記憶體緩衝。
你的應用會因一個其他的任務（如來電電話）的攔截而被置於後台，你的應用可能會被kill並且緩衝被回收掉（系統殺人劫貨啦）。當你的應用再從onResume()方法中恢複時，
應用不得不再次去載入每一個映像。

Android Bitmap Caching Bitmaps（渣翻譯）