android如何釋放圖片緩衝

標籤：

 

在你應用程式的UI介面載入一張圖片是一件很簡單的事情，但是當你需要在介面上載入一大堆圖片的時候，情況就變得複雜起來。在很多情況下，（比如使用ListView, GridView 或者 ViewPager 這樣的組件），螢幕上顯示的圖片可以通過滑動螢幕等事件不斷地增加，最終導致OOM。

為了保證記憶體的使用始終維持在一個合理的範圍，通常會把被移除螢幕的圖片進行回收處理。此時記憶體回收行程也會認為你不再持有這些圖片的引用，從而對這些圖片進行GC操作。用這種思路來解決問題是非常好的，可是為了能讓程式快速運行，在介面上迅速地載入圖片，你又必須要考慮到某些圖片被回收之後，使用者又將它重新滑入螢幕這種情況。這時重新去載入一遍剛剛載入過的圖片無疑是效能的瓶頸，你需要想辦法去避免這個情況的發生。

這個時候，使用記憶體緩衝技術可以很好的解決這個問題，它可以讓組件快速地重新載入和處理圖片。下面我們就來看一看如何使用記憶體緩衝技術來對圖片進行緩衝，從而讓你的應用程式在載入很多圖片的時候可以提高響應速度和流暢性。

記憶體緩衝技術對那些大量佔用應用程式寶貴記憶體的圖片提供了快速存取的方法。其中最核心的類是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 的異常。

下面是一個使用 LruCache 來緩衝圖片的例子：

[java]

1234567891011121314151617181920212223242526

private LruCache<String, Bitmap> mMemoryCache;  @Overrideprotected void onCreate(Bundle savedInstanceState) {     // 擷取到可用記憶體的最大值，使用記憶體超出這個值會引起OutOfMemory異常。     // LruCache通過建構函式傳入緩衝值，以KB為單位。     int maxMemory = (int) (Runtime.getRuntime().maxMemory() /1024);     // 使用最大可用記憶體值的1/8作為緩衝的大小。     int cacheSize = maxMemory / 8;     mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {         @Override        protected int sizeOf(String key, Bitmap bitmap) {             // 重寫此方法來衡量每張圖片的大小，預設返回圖片數量。             return bitmap.getByteCount() / 1024;         }     }; }     public void addBitmapToMemoryCache(String key, Bitmap bitmap) {     if (getBitmapFromMemCache(key) == null) {         mMemoryCache.put(key, bitmap);     } }     public Bitmap getBitmapFromMemCache(String key) {     return mMemoryCache.get(key); }

在這個例子當中，使用了系統分配給應用程式的八分之一記憶體來作為緩衝大小。在中高配置的手機當中，這大概會有4兆(32/8)的緩衝空間。一個全螢幕的 GridView 使用4張 800x480解析度的圖片來填充，則大概會佔用1.5兆的空間(800*480*4)。因此，這個緩衝大小可以儲存2.5頁的圖片。

當向 ImageView 中載入一張圖片時,首先會在 LruCache 的緩衝中進行檢查。如果找到了相應的索引值，則會立刻更新ImageView ，否則開啟一個後台線程來載入這張圖片。

[java]

1234567891011

public void loadBitmap(int resId, ImageView imageView) {     final String imageKey = String.valueOf(resId);     final Bitmap bitmap = getBitmapFromMemCache(imageKey);     if (bitmap != null) {         imageView.setImageBitmap(bitmap);     } else {         imageView.setImageResource(R.drawable.image_placeholder);         BitmapWorkerTask task = new BitmapWorkerTask(imageView);         task.execute(resId);     } }

BitmapWorkerTask 還要把新載入的圖片的索引值對放到緩衝中。

[java]

 

12345678910

class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {     // 在後台載入圖片。     @Override    protected Bitmap doInBackground(Integer... params) {         final Bitmap bitmap = decodeSampledBitmapFromResource(                 getResources(), params[0], 100, 100);         addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);         return bitmap;     } }

 

 

 

 

 

對於確切的釋放一個Drawable或者Bitmap圖片的記憶體:

 

需要手動釋放的bitmap映像通常都是不放入控制項中的bitmap，也就是說沒有其他的對象對該bitmap繼續保持引用了，此時調用recycle手動釋放bitmap資源。

理論片類型的drawable，又沒有被放入view中的話，也是需要getbitmap.recycle的。

若一個drawable，bitmap做為圖片資源放入程式的view(例如做為ImageView的resource)中，那麼此時不需要手動釋放資源了，系統會在該view銷毀時幫你釋放掉該資源的。特殊情況是，一個對象不能被釋放是因為這個對象被其他的對象所引用，導致系統不敢回收，例如聲明了一個static Drawable對象，並且綁定了資源圖片。此時如果我們想最大利用記憶體，盡量減少到期或者臨時不需要的對象在記憶體中遲遲不能被回收，這時我們就考慮用drawable.setCallback(null)來消除這個drawable的引用。但是盡量不要這樣使用static Drawable，如果忘記回收，極易造成記憶體流失！

但是根據另一篇文章，android對於直接通過資源id載入的資源其實是做了cache的了，這樣下次再需要此資源的時候直接從cache中得到，這也是為效率考慮。但這樣做也造成了用過的資源都會在記憶體中，這樣的設計不是很適合使用了很多大圖片資源的應用，這樣累積下來應用的記憶體峰值是很高的。

http://m.blog.csdn.net/blog/tanghaibo001/11691777

最近在xoom上開發應用，碰到ui設計都是使用圖片，而且是多個activity。開始沒覺得怎麼樣，就開始做唄。等做完了，開始在前三個activity運行沒問題，一切ok。但在最後一個activity裡，會經常出現oom（out of memory），由於在最後一個activity，需要開啟一個pdf，然後render，隨著multi-touch，reander的pdf頁縮放，由於reander的圖片本身就比較大（比如，如果pdf放大到當前螢幕的兩倍，pdf圖片佔用的記憶體為1280＊800＊4＊2／（1024＊1024），約等於8m），而且由於為了視覺上感受好，會在其中緩衝圖片（為了不讓使用者在使用過程中感受操作有停滯感），所以總是導致oom異常。

oh，my god！最怕碰到這種情況，android對於記憶體heap size限制讓人比較崩潰，ios雖然也號稱一個應用有記憶體限制，但是在實際使用中一個應用使用的記憶體往往可以超過100m，所以還是挺容易做一個效能滿意的應用程式。

我的應用程式到底哪些地方使用了這麼多記憶體，因為android3.0預設heap size為48m，按道理來說還是可以接受的，怎麼應用沒跑幾下就oom呢？沒辦法，只能通過ddms來分析，在ddms中“update heap”－》“cause gc”，來查看應用的記憶體使用量情況，發現每進入一個activity，1-byte array(byte[], boolean[])的值總是會相應的增加，到最後一個activity的時候啥都不幹，heap size已經快30m了，oh。。。怎麼會這樣。。。冷靜冷靜。。。通過分析，1-byte array就是bitmap的佔用空間，這就說明不斷有新的bitmap在記憶體中。由於ui使用了很多圖片，比如大背景圖，按鈕圖片等等，看來是這些圖片都會存在記憶體中，即使當前activity已經銷毀進入下一個activity，前一個activity的圖片資源也沒有銷毀。

原因找到了，但不是太想得通。因為在onCreate中我用mBtn.setBackgroundResource(R.drawable.splash)為控制項設定背景圖，然後在onDestroy中會用((BitmapDrawable)mBtn.getBackground()).setCallback(null)清理背景圖。按道理來說圖片資源應該已經清理掉了的。百思不得其解，仔細看Bitmap的原始碼，它其實起的作用是銷毀java對象BitmapDrawable，而android為了提高效率，Bitmap真正的位元影像資料是在ndk中用c寫的，所以用setCallback是不能銷毀位元影像資料的，應該調用Bitmap的recycle()來清理記憶體。

所以想當然的在onDestroy加上((BitmapDrawable)mBtn.getBackground()).getBitmap().recycle()，這樣跑下來，記憶體情況很理想，不管在哪個activity中，使用的資源僅僅是當前activity用到的，就不會象之前到最後一個activity的時候，所有之前使用的資源都累積在記憶體中。在每個activity資源和class等使用的記憶體都在10m左右，已經很理想了（當然如果是在android低版本比如1.5,16時還是不行的，這得重新構架應用），可以為顯示pdf預留了比較多記憶體了。

但新的問題又出現了，當返回之前的activity時，會出現“try to use a recycled bitmap"的異常。這真是按了葫蘆起了瓢啊，內心那個沮喪。。。沒辦法，繼續分析。看來是後加上recycle引起的， 位元影像肯定在記憶體中有引用，在返回之前的activity時，因為位元影像資料其實已經被銷毀了，所以才造成目前的情況。在看了setBackgroundResource的源碼以後，恍然大悟，android對於直接通過資源id載入的資源其實是做了cache的了，這樣下次再需要此資源的時候直接從cache中得到，這也是為效率考慮。但這樣做也造成了用過的資源都會在記憶體中，這樣的設計不是很適合使用了很多大圖片資源的應用，這樣累積下來應用的記憶體峰值是很高的。看了sdk後，我用：

Bitmap bm = BitmapFactory.decodeResource(this.getResources(), R.drawable.splash);
BitmapDrawable bd = new BitmapDrawable(this.getResources(), bm);

mBtn.setBackgroundDrawable(bd);

來代替mBtn.setBackgroundResource(R.drawable.splash)。

銷毀的時候使用：

BitmapDrawable bd ＝ (BitmapDrawable)mBtn.getBackground();

mBtn.setBackgroundResource(0);//別忘了把背景設為null，避免onDraw重新整理背景時候出現used a recycled bitmap錯誤

bd.setCallback(null);
bd.getBitmap().recycle();

這樣調整後，避免了在應用裡緩衝所有的資源，節省了寶貴的記憶體，而其實這樣也不會造成太大效率問題，畢竟重新載入資源是非常快速，不會對效能造成很嚴重的影響，在xoom裡我沒有感受到和之前有什麼區別。

總之，在android上使用大量位元影像是個比較痛苦的事，記憶體限制的存在對應用是個很大的瓶頸。但不用因噎費食，其實弄明白了它裡面的機制，應用可以突破這些限制的。這隻是其中的一種處理方法，還可以考慮BitmapFactory.Options的inSampleSize來減少記憶體佔用。

 

轉：http://blog.csdn.net/lizhenmingdirk/article/details/46378905

　　http://my.oschina.net/u/1753339/blog/223379

android如何釋放圖片緩衝