android BitMap回收

標籤：

第一種方法--及時回收bitmap記憶體：

一般而言，回收bitmap記憶體可以用到以下代碼

if(bitmap != null && !bitmap.isRecycled()){ 
bitmap.recycle(); 
bitmap = null; 
} 
System.gc(); 
bitmap.recycle()方法用於回收該bitmap所佔用的記憶體，接著將bitmap置空，最後，別忘了用System.gc()調用一下系統的記憶體回收行程。

在這裡要聲明一下，bitmap可以有多個（以為著可以有多個if語句），但System.gc()最好只有一個（所以我將它寫在了if語句外），因為System.gc()

每次調用都要將整個記憶體掃描一遍，因而如果多次調用的話會影響程式啟動並執行速度。為了程式的效率，我將它放在了所有回收語句之後，

這樣已經起到了它的效果，還節約的時間。

回收bitmap已經知道了，那麼“及時”怎麼理解呢？

根據我的實際經驗，bitmap發揮作用的地方要麼在View裡，要麼在Activity裡（當然肯定有其他地區，但是原理都是類似的），

回收bitmap的地方最好寫在這些地區剛剛不使用bitmap了的時刻。

比如說View如果使用了bitmap,就應該在這個View不再繪製了的時候回收，或者是在跳轉到的下一個地區的代碼中回收；

再比如說SurfaceView，就應該在onSurfaceDestroyed這個方法中回收；

同理，如果Activity使用了bitmap,就可以在onStop或者onDestroy方法中回收......

結合以上的共同點，“及時回收”的原理就是在使用了bitmap的地區結束時或結束後回收。

第二種方法--壓縮圖片：

這個方法當然很簡單了，就是使圖片體積大小變小，

可以有兩種方式：

一種是使圖片品質降低（解析度不變），

另一種是使圖片解析度降低（解析度改變）。

總之，使圖片大小變小就行了。

實踐證明，使圖片品質降低（解析度不變）可以大幅度地減小體積，而且品質的差異肉眼看上去並不明顯。

我剛開始使用的就是這兩種方法，原理很簡單，可是，我的BUG發生雖然沒那麼頻繁了，但是它依然存在！！

後來經過幾天的努力與嘗試，結合我項目的一些具體情況，我終於解決了這個令人頭痛的BUG，但是事實卻有點出乎我的意料。

當我使用了上述兩種方法BUG依然還沒解決的時候，我開始懷疑，bitmap超過8M會報錯，可現在我把前前後後的bitmap都回收了，

不可能還有8M了，那為什麼還會報錯呢？

終於我發現了這個原因：當記憶體中已經被一些bitmap使用過之後，無論被回收與否，它都會變得特別“敏感”，這個時候，

如果bitmap突然要佔用大量的記憶體，即使和之前已經剩下的記憶體加起來不到8M，系統也會報錯，原因是它變“敏感”了！

我不知道這個用底層原理如何解釋比較好，但是我想“敏感”這個詞應該可以很形象地進行解釋。

於是，為了順應記憶體的“敏感性”，我將那個需要同時裝載多個大體積bitmap的地方進行了修改，用到了以下方法：

//壓縮，用於節省BITMAP記憶體空間--解決BUG的關鍵步驟 
BitmapFactory.Options opts = new BitmapFactory.Options(); 
opts.inSampleSize = 2; //這個的值壓縮的倍數（2的整數倍），數值越小，壓縮率越小，圖片越清晰 

//返回原圖解碼之後的bitmap對象 
bitmap = BitmapFactory.decodeResource(Context, ResourcesId, opts); 
即先將圖片縮小一倍，再將這縮小了一倍的圖片作為bitmap存入記憶體，這樣一來，它佔用的bitmap記憶體大大減小。

後來經測試，BUG果然解決了。圖片縮小一倍後，順應了記憶體的“敏感性”，也就不會再報錯了。

以上方法應該足以解決大多數bitmap記憶體溢出問題，但是具體情況還是要具體分析。

android BitMap回收