Android記憶體管理分析

 

很多開發人員都是從j2me或j2ee上過來的，對於記憶體的使用和理解並不是很到位，Android開發網本次給大家一些架構上的指導，防止出現豆腐渣工程的出現。Android作為以Java語言為主的智能平台對於我們開發一些高效能和品質的軟體來說瞭解Android程式記憶體管理機制是必須的。
Android的Dalvik VM在基礎方面和SUN JVM沒有什麼大的區別僅僅是位元組碼的最佳化，我們要知道什麼時候用gc什麼時候用recycle以及到底用不用finalization，因為Java對記憶體的分配只需要new開發人員不需要顯示的釋放記憶體，但是這樣造成的記憶體泄露問題的幾率反而更高。

    1.對於常規開發人員而言需要瞭解 Java的四種引用方式，比如強引用，軟引用，弱引用以及虛引用。一些複雜些的程式在長期運行很可能出現類似OutOfMemoryError的異常。

    2.並不要過多的指望gc，不用的對象可以顯示的設定為空白，比如obj=null，這裡提示大家，java的gc使用的是一個有向圖，判斷一個對象是否有效看的是其他的對象能到達這個對象的頂點，有向圖的相對於鏈表、二叉樹來說開銷是可想而知。

    3.Android為每個程式分配的對記憶體可以通過Runtime類的totalMemory() freeMemory() 兩個方法擷取VM的一些記憶體資訊，對於系統heap記憶體擷取，可以通過Dalvik.VMRuntime類的getMinimumHeapSize() 方法擷取最小可用堆記憶體，同時顯示釋放軟引用可以調用該類的gcSoftReferences() 方法，擷取更多的運行記憶體。

    4.對於多線程的處理，如果並發的線程很多，同時有頻繁的建立和釋放，可以通過concurrent類的線程池解決線程建立的效率瓶頸。

    5. 不要在迴圈中建立過多的本地變數。

   很多時候我們需要考慮Android平台上的記憶體管理問題，Dalvik VM給每個進程都分配了一定量的可用堆記憶體，當我們處理一些耗費資源的操作時可能會產生OOM錯誤(OutOfMemoryError)這樣的異常，觀察了下國內的類似Market用戶端設計，基本上都沒有採用很好的記憶體管理機制和緩衝處理。

  如果細心的網友可能發現Android Market用戶端載入時，每個清單項目的表徵圖是非同步重新整理顯示的，但當我們快速的往下滾動到一定數量比如50個，再往復原動時可能我們看到了部分App的表徵圖又重新開始載入，當然這一過程可能是從SQLite資料庫中緩衝的，但是在記憶體中已經通過類似SoftReference的方式管理記憶體。

  在Java中記憶體管理，引用分為四大類，強引用HardReference、弱引用WeakReference、軟引用SoftReference和虛引用PhantomReference。它們的區別也很明顯，HardReference對象是即使虛擬機器記憶體吃緊拋出OOM也不會導致這一引用的對象被回收，而WeakReference等更適合於一些數量不多，但體積稍微龐大的對象，在這四個引用中，它是最容易被記憶體回收的，而我們對於顯示類似Android Market中每個應用的App Icon時可以考慮使用SoftReference來解決記憶體不至於快速回收，同時當記憶體短缺面臨Java
VM崩潰拋出OOM前時，軟引用將會強制回收記憶體，最後的虛引用一般沒有實際意義，僅僅觀察GC的活動狀態，對於測試比較實用同時必須和ReferenceQueue一起使用。

  對於一組資料，我們可以通過HashMap的方式來添加一組SoftReference對象來臨時保留一些資料，同時對於需要反覆通過網路擷取的不經常改變的內容，可以通過本地的檔案系統或資料庫來儲存緩衝。