前言

在內存使用過程中使用不當或者超過heap size limit的時候就會出現OOM，那一般OOM 是怎麼產生的，會導致什麼樣的結果呢？

OOM簡介

OOM全稱爲Out of memory，解釋爲內存溢出。

爲了整個Android系統的內存控制需要，Android系統爲每一個應用程序都設置了一個硬性的Dalvik Heap Size最大限制閾值，這個閾值在不同的設備上會因爲RAM大小不同而各有差異。如果你的應用佔用內存空間已經接近這個閾值，此時再嘗試分配內存的話，很容易引起OutOfMemoryError的錯誤。
ActivityManager.getMemoryClass()可以用來查詢當前應用的Heap Size閾值（prop dalvik.vm.heapgrowthlimit 也可以），這個方法會返回一個整數，表明你的應用的Heap Size閾值是多少Mb(megabates)。

OOM產生原因

關於Native Heap，Dalvik Heap，Pss等內存管理機制比較複雜，這裏不展開描述。簡單的說，通過不同的內存分配方式（malloc/mmap/JNIEnv/etc）對不同的對象（bitmap，etc）進行操作會因爲Android系統版本的差異而產生不同的行爲，對Native Heap與Dalvik Heap以及OOM的判斷條件都會有所影響。在2.x的系統上，我們常常可以看到Heap Size的total值明顯超過了通過getMemoryClass()獲取到的閾值而不會發生OOM的情況，那麼針對2.x與4.x的Android系統，到底是如何判斷會發生OOM呢？

Android 2.x系統 GC LOG中的dalvik allocated + external allocated + 新分配的大小 >= getMemoryClass()值的時候就會發生OOM。例如，假設有這麼一段Dalvik輸出的GC LOG：GC_FOR_MALLOC free 2K, 13% free 32586K/37455K, external 8989K/10356K, paused 20ms，那麼32586+8989+(新分配23975)=65550>64M時，就會發生OOM。
Android 4.x系統 Android 4.x的系統廢除了external的計數器，類似bitmap的分配改到dalvik的java heap中申請，只要allocated + 新分配的內存 >= getMemoryClass()的時候就會發生OOM，如下圖所示（雖然圖示演示的是art運行環境，但是統計規則還是和dalvik保持一致）

如何避免OOM

前面介紹了OOM 的基礎知識，那麼在實踐中有什麼方法來減少OOM的出現呢？總結下來大概分下面幾個方面：

減小對象的內存佔用
內存對象的重複使用
避免對象的內存泄漏
內存使用策略優化

減小對象的內存佔用

1、使用更輕量級的數據結構

例如，我們可以考慮使用ArrayMap/SparseArray而不是HashMap等傳統數據結構，下圖演示了HashMap的簡要工作原理，相比起Android系統專門爲移動操作系統編寫的ArrayMap容器，在大多數情況下，都顯示效率低下，更佔內存。通常的HashMap的實現方式更加消耗內存，因爲它需要一個額外的實例對象來記錄Mapping操作。另外，SparseArray更加高效在於他們避免了對key與value的autobox自動裝箱，並且避免了裝箱後的解箱。

下圖是HashMap 的工作原理：

下面是ArrayMap的delete 原理：

兩者是有區別的

2、避免在Android 中使用enum

Android 官方的Training 中有這樣一句話“Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”

關於enum的效率，請看下面的討論。假設我們有這樣一份代碼，編譯之後的dex大小是2556 bytes，在此基礎之上，添加一些如下代碼，這些代碼使用普通static常量相關作爲判斷值：

增加上面那段代碼之後，編譯成dex的大小是2680 bytes，相比起之前的2556 bytes只增加124 bytes。假如換做使用enum，情況如下：

使用enum之後的dex大小是4188 bytes，相比起2556增加了1632 bytes，增長量是使用static int的13倍。不僅僅如此，使用enum，運行時還會產生額外的內存佔用，如下圖所示：

Android官方強烈建議不要在Android程序裏面使用到enum。

3、減小Bitmap對象的內存佔用

Bitmap是一個極容易消耗內存的大胖子，減小創建出來的Bitmap的內存佔用是很重要的，通常來說有下面2個措施：

inSampleSize：縮放比例，在把圖片載入內存之前，我們需要先計算出一個合適的縮放比例，避免不必要的大圖載入。
decode format：解碼格式，選擇ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差異。

4、使用更小的圖片

在設計給到資源圖片的時候，我們需要特別留意這張圖片是否存在可以壓縮的空間，是否可以使用一張更小的圖片。儘量使用更小的圖片不僅僅可以減少內存的使用，還可以避免出現大量的InflationException。假設有一張很大的圖片被XML文件直接引用，很有可能在初始化視圖的時候就會因爲內存不足而發生InflationException，這個問題的根本原因其實是發生了OOM。

內存對象的重複使用

大多數對象的複用，最終實施的方案都是利用對象池技術，要麼是在編寫代碼的時候顯式的在程序裏面去創建對象池，然後處理好複用的實現邏輯，要麼就是利用系統框架既有的某些複用特性達到減少對象的重複創建，從而減少內存的分配與回收。

1、複用系統自帶的資源

Android系統本身內置了很多的資源，例如字符串/顏色/圖片/動畫/樣式以及簡單佈局等等，這些資源都可以在應用程序中直接引用。這樣做不僅僅可以減少應用程序的自身負重，減小APK的大小，另外還可以一定程度上減少內存的開銷，複用性更好。但是也有必要留意Android系統的版本差異性，對那些不同系統版本上表現存在很大差異，不符合需求的情況，還是需要應用程序自身內置進去。

2、注意在ListView/GridView等出現大量重複子組件的視圖裏面對ConvertView的複用

3、Bitmap對象的複用

4、避免在onDraw方法裏面執行對象的創建

類似onDraw等頻繁調用的方法，一定需要注意避免在這裏做創建對象的操作，因爲他會迅速增加內存的使用，而且很容易引起頻繁的gc，甚至是內存抖動。

5、StringBuilder

在有些時候，代碼中會需要使用到大量的字符串拼接的操作，這種時候有必要考慮使用StringBuilder來替代頻繁的“+”。

避免對象的內存泄漏

內存對象的泄漏，會導致一些不再使用的對象無法及時釋放，這樣一方面佔用了寶貴的內存空間，很容易導致後續需要分配內存的時候，空閒空間不足而出現OOM。顯然，這還使得每級Generation的內存區域可用空間變小，gc就會更容易被觸發，容易出現內存抖動，從而引起性能問題。

最新的LeakCanary開源控件，可以很好的幫助我們發現內存泄露的情況，更多關於LeakCanary的介紹，請看這裏(中文使用說明)。另外也可以使用傳統的MAT工具查找內存泄露，請參考這裏（便捷的中文資料）

1、注意Activity 的泄漏

通常來說，Activity的泄漏是內存泄漏裏面最嚴重的問題，它佔用的內存多，影響面廣，我們需要特別注意以下兩種情況導致的Activity泄漏：

內部類引用導致Activity的泄漏

最典型的場景是Handler導致的Activity泄漏，如果Handler中有延遲的任務或者是等待執行的任務隊列過長，都有可能因爲Handler繼續執行而導致Activity發生泄漏。此時的引用關係鏈是Looper -> MessageQueue -> Message -> Handler -> Activity。爲了解決這個問題，可以在UI退出之前，執行remove Handler消息隊列中的消息與runnable對象。或者是使用Static + WeakReference的方式來達到斷開Handler與Activity之間存在引用關係的目的。

Activity Context被傳遞到其他實例中，這可能導致自身被引用而發生泄漏。

內部類引起的泄漏不僅僅會發生在Activity上，其他任何內部類出現的地方，都需要特別留意！我們可以考慮儘量使用static類型的內部類，同時使用WeakReference的機制來避免因爲互相引用而出現的泄露。

2、考慮使用Application Context而不是Activity Contex

對於大部分非必須使用Activity Context的情況（Dialog的Context就必須是Activity Context），我們都可以考慮使用Application Context而不是Activity的Context，這樣可以避免不經意的Activity泄露。

3、Bitmap 對象的及時回收

雖然在大多數情況下，我們會對Bitmap增加緩存機制，但是在某些時候，部分Bitmap是需要及時回收的。例如臨時創建的某個相對比較大的bitmap對象，在經過變換得到新的bitmap對象之後，應該儘快回收原始的bitmap，這樣能夠更快釋放原始bitmap所佔用的空間。

需要特別留意的是Bitmap類裏面提供的createBitmap()方法：

這個函數返回的bitmap有可能和source bitmap是同一個，在回收的時候，需要特別檢查source bitmap與return bitmap的引用是否相同，只有在不等的情況下，才能夠執行source bitmap的recycle方法。

4、注意監聽器的註銷

在Android程序裏面存在很多需要register與unregister的監聽器，我們需要確保在合適的時候及時unregister那些監聽器。自己手動add的listener，需要記得及時remove這個listener。

5、注意緩存容器中的對象泄漏

有時候，我們爲了提高對象的複用性把某些對象放到緩存容器中，可是如果這些對象沒有及時從容器中清除，也是有可能導致內存泄漏的。例如，針對2.3的系統，如果把drawable添加到緩存容器，因爲drawable與View的強應用，很容易導致activity發生泄漏。而從4.0開始，就不存在這個問題。解決這個問題，需要對2.3系統上的緩存drawable做特殊封裝，處理引用解綁的問題，避免泄漏的情況。

6、注意WebView的泄漏

Android中的WebView存在很大的兼容性問題，不僅僅是Android系統版本的不同對WebView產生很大的差異，另外不同的廠商出貨的ROM裏面WebView也存在着很大的差異。更嚴重的是標準的WebView存在內存泄露的問題，看這裏WebView causes memory leak - leaks the parent Activity。所以通常根治這個問題的辦法是爲WebView開啓另外一個進程，通過AIDL與主進程進行通信，WebView所在的進程可以根據業務的需要選擇合適的時機進行銷燬，從而達到內存的完整釋放。

7、注意Cursor對象是否及時關閉
在程序中我們經常會進行查詢數據庫的操作，但時常會存在不小心使用Cursor之後沒有及時關閉的情況。這些Cursor的泄露，反覆多次出現的話會對內存管理產生很大的負面影響，我們需要謹記對Cursor對象的及時關閉。

內存使用策略優化

1、Try catch 某些大內存的操作

在某些情況下，我們需要事先評估那些可能發生OOM的代碼，對於這些可能發生OOM的代碼，加入catch機制，可以考慮在catch裏面嘗試一次降級的內存分配操作。例如decode bitmap的時候，catch到OOM，可以嘗試把採樣比例再增加一倍之後，再次嘗試decode。

2、謹慎使用static 對象

static是Java中的一個關鍵字，當用它來修飾成員變量時，那麼該變量就屬於該類，而不是該類的實例。不少程序員喜歡用static這個關鍵字修飾變量，因爲他使得變量的生命週期大大延長啦，並且訪問的時候，也極其的方便，用類名就能直接訪問，各個資源間傳值也極其的方便，所以，它經常被我們使用。但如果用它來引用一些資源耗費過多的實例（Context的情況最多），這時就要謹慎對待了。

 public class ClassName {  
      private static Context mContext;  
      //省略  
}

以上的代碼是很危險的，如果將Activity賦值到麼mContext的話。那麼即使該Activity已經onDestroy，但是由於仍有對象保存它的引用，因此該Activity依然不會被釋放，並且，如果該activity裏面再持有一些資源，那就糟糕了。

上面是直接的引用泄露，我們再看google文檔中的一個例子：

 private static Drawable sBackground;   
 
  @Override  
  protected void onCreate(Bundle state) {  
    super.onCreate(state);   
 
    TextView label = new TextView(this);  
    label.setText("Leaks are bad");   
 
    if (sBackground == null) {  
      sBackground = getDrawable(R.drawable.large_bitmap);  
    }  
    label.setBackgroundDrawable(sBackground);   
 
    setContentView(label);  
  }

sBackground, 是一個靜態的變量，但是我們發現，我們並沒有顯式的保存Contex的引用，但是，當Drawable與View連接之後，Drawable就將View 設置爲一個回調，由於View中是包含Context的引用的，所以，實際上我們依然保存了Context的引用。這個引用鏈如下：
Drawable->TextView->Context
所以，最終該Context也沒有得到釋放，也發生了內存泄露。
那我們如何的避免這種泄露的發生呢？

應該儘量避免static成員變量引用資源耗費過多的實例，比如Context。
Context儘量使用Application Context，因爲Application的Context的生命週期比較長，引用它不會出現內存泄露的問題。
使用WeakReference代替強引用。比如可以使用WeakReference<Context> mContextRef;
該部分的詳細內容也可以參考Android文檔中Article部分。

3、特別留意單例模式的不合理持有

4、珍惜service 資源

如果你的應用需要在後臺使用service，除非它被觸發並執行一個任務，否則其他時候Service都應該是停止狀態。另外需要注意當這個service完成任務之後因爲停止service失敗而引起的內存泄漏。當你啓動一個Service，系統會傾向爲了保留這個Service而一直保留Service所在的進程。這使得進程的運行代價很高，因爲系統沒有辦法把Service所佔用的RAM空間騰出來讓給其他組件，另外Service還不能被Paged out。這減少了系統能夠存放到LRU緩存當中的進程數量，它會影響應用之間的切換效率，甚至會導致系統內存使用不穩定，從而無法繼續保持住所有目前正在運行的service。建議使用IntentService，它會在處理完交代給它的任務之後儘快結束自己。更多信息，請閱讀Running in a Background Service。

5、優化佈局層次，減少內存消耗
越扁平化的視圖佈局，佔用的內存就越少，效率越高。我們需要儘量保證佈局足夠扁平化，當使用系統提供的View無法實現足夠扁平的時候考慮使用自定義View來達到目的。
6、謹慎使用“抽象”編程
很多時候，開發者會使用抽象類作爲”好的編程實踐”，因爲抽象能夠提升代碼的靈活性與可維護性。然而，抽象會導致一個顯著的額外內存開銷：他們需要同等量的代碼用於可執行，那些代碼會被mapping到內存中，因此如果你的抽象沒有顯著的提升效率，應該儘量避免他們。

最後

如果你看到了這裏，覺得文章寫得不錯就點個贊唄？如果你覺得那裏值得改進的，請給我留言。一定會認真查詢，修正不足。謝謝。

最後針對Android開發的同行，小編這邊給大家整理了一些資料，其中分享內容包括但不限於【高級UI、性能優化、移動架構師、NDK、混合式開發（ReactNative+Weex）微信小程序、Flutter等全方面的Android進階實踐技術】希望能幫助大家學習提升進階，也節省大家在網上搜索資料的時間來學習，也是可以分享給身邊好友一起學習的！

爲什麼某些人會比你優秀，是因爲他本身就很優秀還一直在持續努力變得更優秀，而你是不是還在滿足於現狀內心在竊喜！希望讀到這的您能轉發分享和關注一下我，以後還會更新技術乾貨，謝謝您的支持！

轉發+點贊+關注，加入Android開發交流羣（820198451）獲取小編爲大家收錄的進階資料和麪試題庫

Android架構師之路很漫長，一起共勉吧！
——————分割線——————
最近剛留意到簡書點贊可以有好幾種贊，長按點贊按鈕就會有選項，大家點讚的時候，麻煩點個超讚，讓我感受下這個功能……

十年Android程序員：OOM 分析最後

前言

OOM簡介

OOM產生原因