OOM簡介

OOM全稱為Out of memory，解釋為內(nèi)存溢出。

• 為了整個(gè)Android系統(tǒng)的內(nèi)存控制需要，Android系統(tǒng)為每一個(gè)應(yīng)用程序都設(shè)置了一個(gè)硬性的Dalvik Heap Size最大限制閾值，這個(gè)閾值在不同的設(shè)備上會(huì)因?yàn)镽AM大小不同而各有差異。如果你的應(yīng)用占用內(nèi)存空間已經(jīng)接近這個(gè)閾值，此時(shí)再嘗試分配內(nèi)存的話，很容易引起OutOfMemoryError的錯(cuò)誤。
• ActivityManager.getMemoryClass()可以用來查詢當(dāng)前應(yīng)用的Heap Size閾值（prop dalvik.vm.heapgrowthlimit 也可以），這個(gè)方法會(huì)返回一個(gè)整數(shù)，表明你的應(yīng)用的Heap Size閾值是多少M(fèi)b(megabates)。

OOM產(chǎn)生原因

關(guān)于Native Heap，Dalvik Heap，Pss等內(nèi)存管理機(jī)制比較復(fù)雜，這里不展開描述。簡單的說，通過不同的內(nèi)存分配方式（malloc/mmap/JNIEnv/etc）對(duì)不同的對(duì)象（bitmap，etc）進(jìn)行操作會(huì)因?yàn)锳ndroid系統(tǒng)版本的差異而產(chǎn)生不同的行為，對(duì)Native Heap與Dalvik Heap以及OOM的判斷條件都會(huì)有所影響。在2.x的系統(tǒng)上，我們常?？梢钥吹紿eap Size的total值明顯超過了通過getMemoryClass()獲取到的閾值而不會(huì)發(fā)生OOM的情況，那么針對(duì)2.x與4.x的Android系統(tǒng)，到底是如何判斷會(huì)發(fā)生OOM呢？

• Android 2.x系統(tǒng) GC LOG中的dalvik allocated + external allocated + 新分配的大小 >= getMemoryClass()值的時(shí)候就會(huì)發(fā)生OOM。 例如，假設(shè)有這么一段Dalvik輸出的GC LOG：GC_FOR_MALLOC free 2K, 13% free 32586K/37455K, external 8989K/10356K, paused 20ms，那么32586+8989+(新分配23975)=65550>64M時(shí)，就會(huì)發(fā)生OOM。

• Android 4.x系統(tǒng) Android 4.x的系統(tǒng)廢除了external的計(jì)數(shù)器，類似bitmap的分配改到dalvik的java heap中申請(qǐng)- rt運(yùn)行環(huán)境，但是統(tǒng)計(jì)規(guī)則還是和dalvik保持一致）

  
  
  20180426160641182.png

如何避免OOM

前面介紹了OOM 的基礎(chǔ)知識(shí)，那么在實(shí)踐中有什么方法來減少OOM的出現(xiàn)呢？總結(jié)下來大概分下面幾個(gè)方面：

• 減小對(duì)象的內(nèi)存占用
• 內(nèi)存對(duì)象的重復(fù)使用
• 避免對(duì)象的內(nèi)存泄漏
• 內(nèi)存使用策略優(yōu)化

減小對(duì)象的內(nèi)存占用

1、使用更輕量級(jí)的數(shù)據(jù)結(jié)構(gòu)
例如，我們可以考慮使用ArrayMap/SparseArray而不是HashMap等傳統(tǒng)數(shù)據(jù)結(jié)構(gòu)，下圖演示了HashMap的簡要工作原理，相比起Android系統(tǒng)專門為移動(dòng)操作系統(tǒng)編寫的ArrayMap容器，在大多數(shù)情況下，都顯示效率低下，更占內(nèi)存。通常的HashMap的實(shí)現(xiàn)方式更加消耗內(nèi)存，因?yàn)樗枰粋€(gè)額外的實(shí)例對(duì)象來記錄Mapping操作。另外，SparseArray更加高效在于他們避免了對(duì)key與value的autobox自動(dòng)裝箱，并且避免了裝箱后的解箱。

下圖是HashMap 的工作原理：

20180426165316367.png

2018042616541494.png

20180426170014707.png

20180426170105515.png

20180426200926112.png

4、使用更小的圖片
在設(shè)計(jì)給到資源圖片的時(shí)候，我們需要特別留意這張圖片是否存在可以壓縮的空間，是否可以使用一張更小的圖片。盡量使用更小的圖片不僅僅可以減少內(nèi)存的使用，還可以避免出現(xiàn)大量的InflationException。假設(shè)有一張很大的圖片被XML文件直接引用，很有可能在初始化視圖的時(shí)候就會(huì)因?yàn)閮?nèi)存不足而發(fā)生InflationException，這個(gè)問題的根本原因其實(shí)是發(fā)生了OOM。

內(nèi)存對(duì)象的重復(fù)使用

大多數(shù)對(duì)象的復(fù)用，最終實(shí)施的方案都是利用對(duì)象池技術(shù)，要么是在編寫代碼的時(shí)候顯式的在程序里面去創(chuàng)建對(duì)象池，然后處理好復(fù)用的實(shí)現(xiàn)邏輯，要么就是利用系統(tǒng)框架既有的某些復(fù)用特性達(dá)到減少對(duì)象的重復(fù)創(chuàng)建，從而減少內(nèi)存的分配與回收。

1、復(fù)用系統(tǒng)自帶的資源
Android系統(tǒng)本身內(nèi)置了很多的資源，例如字符串/顏色/圖片/動(dòng)畫/樣式以及簡單布局等等，這些資源都可以在應(yīng)用程序中直接引用。這樣做不僅僅可以減少應(yīng)用程序的自身負(fù)重，減小APK的大小，另外還可以一定程度上減少內(nèi)存的開銷，復(fù)用性更好。但是也有必要留意Android系統(tǒng)的版本差異性，對(duì)那些不同系統(tǒng)版本上表現(xiàn)存在很大差異，不符合需求的情況，還是需要應(yīng)用程序自身內(nèi)置進(jìn)去。

2、注意在ListView/GridView等出現(xiàn)大量重復(fù)子組件的視圖里面對(duì)ConvertView的復(fù)用

3、Bitmap對(duì)象的復(fù)用

4、避免在onDraw方法里面執(zhí)行對(duì)象的創(chuàng)建

類似onDraw等頻繁調(diào)用的方法，一定需要注意避免在這里做創(chuàng)建對(duì)象的操作，因?yàn)樗麜?huì)迅速增加內(nèi)存的使用，而且很容易引起頻繁的gc，甚至是內(nèi)存抖動(dòng)。

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

避免對(duì)象的內(nèi)存泄漏
內(nèi)存對(duì)象的泄漏，會(huì)導(dǎo)致一些不再使用的對(duì)象無法及時(shí)釋放，這樣一方面占用了寶貴的內(nèi)存空間，很容易導(dǎo)致后續(xù)需要分配內(nèi)存的時(shí)候，空閑空間不足而出現(xiàn)OOM。顯然，這還使得每級(jí)Generation的內(nèi)存區(qū)域可用空間變小，gc就會(huì)更容易被觸發(fā)，容易出現(xiàn)內(nèi)存抖動(dòng)，從而引起性能問題。

最新的LeakCanary開源控件，可以很好的幫助我們發(fā)現(xiàn)內(nèi)存泄露的情況，更多關(guān)于LeakCanary的介紹，請(qǐng)看這里https://github.com/square/leakcanary(中文使用說明http://www.liaohuqiu.net/cn/posts/leak-canary-read-me/)。另外也可以使用傳統(tǒng)的MAT工具查找內(nèi)存泄露，請(qǐng)參考這里http://android-developers.blogspot.pt/2011/03/memory-analysis-for-android.html（便捷的中文資料http://androidperformance.com/2015/04/11/AndroidMemory-Usage-Of-MAT/）

1、注意Activity 的泄漏

通常來說，Activity的泄漏是內(nèi)存泄漏里面最嚴(yán)重的問題，它占用的內(nèi)存多，影響面廣，我們需要特別注意以下兩種情況導(dǎo)致的Activity泄漏：

• 內(nèi)部類引用導(dǎo)致Activity的泄漏

最典型的場(chǎng)景是Handler導(dǎo)致的Activity泄漏，如果Handler中有延遲的任務(wù)或者是等待執(zhí)行的任務(wù)隊(duì)列過長，都有可能因?yàn)镠andler繼續(xù)執(zhí)行而導(dǎo)致Activity發(fā)生泄漏。此時(shí)的引用關(guān)系鏈?zhǔn)荓ooper -> MessageQueue -> Message -> Handler -> Activity。為了解決這個(gè)問題，可以在UI退出之前，執(zhí)行remove Handler消息隊(duì)列中的消息與runnable對(duì)象。或者是使用Static + WeakReference的方式來達(dá)到斷開Handler與Activity之間存在引用關(guān)系的目的。

• Activity Context被傳遞到其他實(shí)例中，這可能導(dǎo)致自身被引用而發(fā)生泄漏。
  內(nèi)部類引起的泄漏不僅僅會(huì)發(fā)生在Activity上，其他任何內(nèi)部類出現(xiàn)的地方，都需要特別留意！我們可以考慮盡量使用static類型的內(nèi)部類，同時(shí)使用WeakReference的機(jī)制來避免因?yàn)榛ハ嘁枚霈F(xiàn)的泄露。

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

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

3、Bitmap 對(duì)象的及時(shí)回收
雖然在大多數(shù)情況下，我們會(huì)對(duì)Bitmap增加緩存機(jī)制，但是在某些時(shí)候，部分Bitmap是需要及時(shí)回收的。例如臨時(shí)創(chuàng)建的某個(gè)相對(duì)比較大的bitmap對(duì)象，在經(jīng)過變換得到新的bitmap對(duì)象之后，應(yīng)該盡快回收原始的bitmap，這樣能夠更快釋放原始bitmap所占用的空間。

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

2018042620264266.png

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

4、注意監(jiān)聽器的注銷
在Android程序里面存在很多需要register與unregister的監(jiān)聽器，我們需要確保在合適的時(shí)候及時(shí)unregister那些監(jiān)聽器。自己手動(dòng)add的listener，需要記得及時(shí)remove這個(gè)listener。

5、注意緩存容器中的對(duì)象泄漏
有時(shí)候，我們?yōu)榱颂岣邔?duì)象的復(fù)用性把某些對(duì)象放到緩存容器中，可是如果這些對(duì)象沒有及時(shí)從容器中清除，也是有可能導(dǎo)致內(nèi)存泄漏的。例如，針對(duì)2.3的系統(tǒng)，如果把drawable添加到緩存容器，因?yàn)閐rawable與View的強(qiáng)應(yīng)用，很容易導(dǎo)致activity發(fā)生泄漏。而從4.0開始，就不存在這個(gè)問題。解決這個(gè)問題，需要對(duì)2.3系統(tǒng)上的緩存drawable做特殊封裝，處理引用解綁的問題，避免泄漏的情況。

6、注意WebView的泄漏
Android中的WebView存在很大的兼容性問題，不僅僅是Android系統(tǒng)版本的不同對(duì)WebView產(chǎn)生很大的差異，另外不同的廠商出貨的ROM里面WebView也存在著很大的差異。更嚴(yán)重的是標(biāo)準(zhǔn)的WebView存在內(nèi)存泄露的問題，看這里WebView causes memory leak - leaks the parent Activity。所以通常根治這個(gè)問題的辦法是為WebView開啟另外一個(gè)進(jìn)程，通過AIDL與主進(jìn)程進(jìn)行通信，WebView所在的進(jìn)程可以根據(jù)業(yè)務(wù)的需要選擇合適的時(shí)機(jī)進(jìn)行銷毀，從而達(dá)到內(nèi)存的完整釋放。

7、注意Cursor對(duì)象是否及時(shí)關(guān)閉
在程序中我們經(jīng)常會(huì)進(jìn)行查詢數(shù)據(jù)庫的操作，但時(shí)常會(huì)存在不小心使用Cursor之后沒有及時(shí)關(guān)閉的情況。這些Cursor的泄露，反復(fù)多次出現(xiàn)的話會(huì)對(duì)內(nèi)存管理產(chǎn)生很大的負(fù)面影響，我們需要謹(jǐn)記對(duì)Cursor對(duì)象的及時(shí)關(guān)閉。

內(nèi)存使用策略優(yōu)化

1、Try catch 某些大內(nèi)存的操作
在某些情況下，我們需要事先評(píng)估那些可能發(fā)生OOM的代碼，對(duì)于這些可能發(fā)生OOM的代碼，加入catch機(jī)制，可以考慮在catch里面嘗試一次降級(jí)的內(nèi)存分配操作。例如decode bitmap的時(shí)候，catch到OOM，可以嘗試把采樣比例再增加一倍之后，再次嘗試decode。

2、謹(jǐn)慎使用static 對(duì)象
static是Java中的一個(gè)關(guān)鍵字，當(dāng)用它來修飾成員變量時(shí)，那么該變量就屬于該類，而不是該類的實(shí)例。 不少程序員喜歡用static這個(gè)關(guān)鍵字修飾變量，因?yàn)樗沟米兞康纳芷诖蟠笱娱L啦，并且訪問的時(shí)候，也極其的方便，用類名就能直接訪問，各個(gè)資源間 傳值也極其的方便，所以，它經(jīng)常被我們使用。但如果用它來引用一些資源耗費(fèi)過多的實(shí)例（Context的情況最多），這時(shí)就要謹(jǐn)慎對(duì)待了。

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

以上的代碼是很危險(xiǎn)的，如果將Activity賦值到么mContext的話。那么即使該Activity已經(jīng)onDestroy，但是由于仍有對(duì)象保存它的引用，因此該Activity依然不會(huì)被釋放，并且，如果該activity里面再持有一些資源，那就糟糕了。

上面是直接的引用泄露，我們?cè)倏磄oogle文檔中的一個(gè)例子：

 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, 是一個(gè)靜態(tài)的變量，但是我們發(fā)現(xiàn)，我們并沒有顯式的保存Contex的引用，但是，當(dāng)Drawable與View連接之后，Drawable就將View 設(shè)置為一個(gè)回調(diào)，由于View中是包含Context的引用的，所以，實(shí)際上我們依然保存了Context的引用。這個(gè)引用鏈如下：
Drawable->TextView->Context
所以，最終該Context也沒有得到釋放，也發(fā)生了內(nèi)存泄露。
那我們?nèi)绾蔚谋苊膺@種泄露的發(fā)生呢？

• 應(yīng)該盡量避免static成員變量引用資源耗費(fèi)過多的實(shí)例，比如Context。
• Context盡量使用Application Context，因?yàn)锳pplication的Context的生命周期比較長，引用它不會(huì)出現(xiàn)內(nèi)存泄露的問題。
• 使用WeakReference代替強(qiáng)引用。比如可以使用WeakReference<Context> mContextRef;
  該部分的詳細(xì)內(nèi)容也可以參考Android文檔中Article部分。

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

4、珍惜service 資源
如果你的應(yīng)用需要在后臺(tái)使用service，除非它被觸發(fā)并執(zhí)行一個(gè)任務(wù)，否則其他時(shí)候Service都應(yīng)該是停止?fàn)顟B(tài)。另外需要注意當(dāng)這個(gè)service完成任務(wù)之后因?yàn)橥Ｖ箂ervice失敗而引起的內(nèi)存泄漏。 當(dāng)你啟動(dòng)一個(gè)Service，系統(tǒng)會(huì)傾向?yàn)榱吮Ａ暨@個(gè)Service而一直保留Service所在的進(jìn)程。這使得進(jìn)程的運(yùn)行代價(jià)很高，因?yàn)橄到y(tǒng)沒有辦法把Service所占用的RAM空間騰出來讓給其他組件，另外Service還不能被Paged out。這減少了系統(tǒng)能夠存放到LRU緩存當(dāng)中的進(jìn)程數(shù)量，它會(huì)影響應(yīng)用之間的切換效率，甚至?xí)?dǎo)致系統(tǒng)內(nèi)存使用不穩(wěn)定，從而無法繼續(xù)保持住所有目前正在運(yùn)行的service。 建議使用IntentService，它會(huì)在處理完交代給它的任務(wù)之后盡快結(jié)束自己。更多信息，請(qǐng)閱讀Running in a Background Service。

5、優(yōu)化布局層次，減少內(nèi)存消耗
越扁平化的視圖布局，占用的內(nèi)存就越少，效率越高。我們需要盡量保證布局足夠扁平化，當(dāng)使用系統(tǒng)提供的View無法實(shí)現(xiàn)足夠扁平的時(shí)候考慮使用自定義View來達(dá)到目的。

6、謹(jǐn)慎使用“抽象”編程
很多時(shí)候，開發(fā)者會(huì)使用抽象類作為”好的編程實(shí)踐”，因?yàn)槌橄竽軌蛱嵘a的靈活性與可維護(hù)性。然而，抽象會(huì)導(dǎo)致一個(gè)顯著的額外內(nèi)存開銷：他們需要同等量的代碼用于可執(zhí)行，那些代碼會(huì)被mapping到內(nèi)存中，因此如果你的抽象沒有顯著的提升效率，應(yīng)該盡量避免他們。