如何避免OOM?

1.Bitmap優(yōu)化
Bitmap非常消耗內(nèi)存，
而且在A(yíng)ndroid中，讀取bitmap時(shí)，
一般分配給虛擬機(jī)的圖片堆棧只有8M，所以經(jīng)常造成OOM問(wèn)題。
所以有必要針對(duì)Bitmap的使用作出優(yōu)化：

1.1. 圖片顯示：加載合適尺寸的圖片，比如顯示縮略圖的地方不要加載大圖。

1.2. 圖片回收：使用完bitmap，及時(shí)使用Bitmap.recycle()回收。
問(wèn)題：Android不是自身具備垃圾回收機(jī)制嗎？此處為何要手動(dòng)回收。
Bitmap對(duì)象不是new生成的，而是通過(guò)BitmapFactory生產(chǎn)的。
通過(guò)源碼可發(fā)現(xiàn)是通過(guò)調(diào)用JNI生成Bitmap對(duì)象（nativeDecodeStream()等方法）。
所以，
加載bitmap到內(nèi)存里包括兩部分，
Dalvik（ART）內(nèi)存和Linux kernel內(nèi)存。
前者會(huì)被虛擬機(jī)自動(dòng)回收。
而后者必須通過(guò)recycle()方法，
內(nèi)部調(diào)用nativeRecycle()讓linux kernel回收。

1.3. 捕獲OOM異常：程序中設(shè)定如果發(fā)生OOM的應(yīng)急處理方式。

1.4. 圖片緩存：內(nèi)存緩存、硬盤(pán)緩存等

1.5. 圖片壓縮：直接使用ImageView顯示Bitmap時(shí)會(huì)占很多資源，
尤其當(dāng)圖片較大時(shí)容易發(fā)生OOM。
可以使用BitMapFactory.Options對(duì)圖片進(jìn)行壓縮。

1.6. 圖片像素（質(zhì)量）：android默認(rèn)顏色模式為ARGB_8888， 顯示質(zhì)量最高，占用內(nèi)存最大。
若要求不高時(shí)可采用RGB_565等模式。
還可以使用WebP；
圖片大小：圖片長(zhǎng)度 * 寬度 * 單位像素 所占據(jù)字節(jié)數(shù)
ARGB_4444：每個(gè)像素占用2byte內(nèi)存
ARGB_8888：每個(gè)像素占用4byte內(nèi)存 （默認(rèn)）
RGB_565：每個(gè)像素占用2byte內(nèi)存

1.7. 考慮使用inBitmap；圖片優(yōu)化之inBitmap

2. 巧用對(duì)象引用類(lèi)型

• 強(qiáng)引用 strong：Object object=new Object()。
  當(dāng)內(nèi)存不足時(shí)，Java虛擬機(jī)寧愿拋出OOM內(nèi)存溢出異常，
  也不會(huì)輕易回收強(qiáng)引用對(duì)象來(lái)解決內(nèi)存不足問(wèn)題；
  軟引用 soft：只有當(dāng)內(nèi)存達(dá)到某個(gè)閾值時(shí)才會(huì)去回收，常用于緩存；
  弱引用 weak ：只要被GC線(xiàn)程掃描到了就進(jìn)行回收；
  虛引用

• 如果想要避免OOM發(fā)生，則使用軟引用對(duì)象，即當(dāng)內(nèi)存快不足時(shí)進(jìn)行回收；
  如果想盡快回收某些占用內(nèi)存較大的對(duì)象，例如bitmap，可以使用弱引用，能被快速回收。
  不過(guò)如果要對(duì)bitmap作緩存就不要使用弱引用，因?yàn)楹芸炀蜁?huì)被GC回收，導(dǎo)致緩存失敗。
  

3. 使用 池 pool 內(nèi)存對(duì)象的重復(fù)利用

• 對(duì)象池：如果某個(gè)對(duì)象在創(chuàng)建時(shí)，需要較大的資源開(kāi)銷(xiāo)，
  那么可以將其放入對(duì)象池，
  即將對(duì)象保存起來(lái)，下次需要時(shí)直接取出使用，
  而不用再次創(chuàng)建對(duì)象。
  當(dāng)然，維護(hù)對(duì)象池也需要一定開(kāi)銷(xiāo)，故要衡量。

a.ListView/GridView源碼可以看到重用的情況ConvertView的復(fù)用。
RecyclerView中Recycler源碼。
b.Bitmap的復(fù)用
Listview等要顯示大量圖片。
需要使用LRU緩存機(jī)制來(lái)復(fù)用圖片。

• 線(xiàn)程池：與對(duì)象池差不多，
  將線(xiàn)程對(duì)象放在池中供反復(fù)使用，減少反復(fù)創(chuàng)建線(xiàn)程的開(kāi)銷(xiāo)。
  

4. 使用更加輕量的數(shù)據(jù)結(jié)構(gòu)：
考慮適當(dāng)?shù)那闆r下，
使用更加高效的安卓專(zhuān)門(mén)為手機(jī)研發(fā)的數(shù)據(jù)結(jié)構(gòu)類(lèi)
ArrayMap/SparseArray/SparseLongMap/SparseIntMap/SparseBoolMap去
替代HashMap等傳統(tǒng)數(shù)據(jù)結(jié)構(gòu)。
HashMap.put(string,Object);Object o = map.get(string);會(huì)導(dǎo)致一些沒(méi)必要的自動(dòng)裝箱和拆箱。
HashMap,HashMap更耗內(nèi)存，
因?yàn)樗枰?code>額外的實(shí)例對(duì)象來(lái)記錄Mapping操作，
SparseArray更加高效，
因?yàn)樗苊饬?code>Key Value的自動(dòng)裝箱，和裝箱后的解箱操作；

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

6.避免在類(lèi)似onDraw這樣的方法中創(chuàng)建對(duì)象，
因?yàn)樗鼤?huì)迅速占用大量?jī)?nèi)存，引起頻繁的GC甚至內(nèi)存抖動(dòng)

參考文章

• Android 高級(jí)面試題
• Android之內(nèi)存管理及優(yōu)化
• Android學(xué)習(xí)筆記之性能優(yōu)化SparseArray
• 集合中對(duì)象沒(méi)清理造成的內(nèi)存泄漏

Memory Analyzer Tool(MAT)簡(jiǎn)述、下載、安裝

• 一個(gè)強(qiáng)大的Java Heap 工具，
  相對(duì)于Memory Profiler（MP）的簡(jiǎn)單分析，
  MAT可以對(duì)Java內(nèi)存做一個(gè)深入的分析；

• MP不能確認(rèn)問(wèn)題，確認(rèn)問(wèn)題需要MAT

• MAT下載鏈接
  這里可以下載獨(dú)立版的MAT工具；

MAT安裝及使用教程
文件下載下來(lái)的是一個(gè)zip壓縮包，

解壓壓縮包，
進(jìn)入到如下目錄，
雙擊對(duì)應(yīng)的exe文件，
即可開(kāi)始使用：

工具初始界面如下：

• 轉(zhuǎn)換：hprof-conv 原文件路徑 轉(zhuǎn)換后文件路徑

內(nèi)存泄漏解決實(shí)戰(zhàn)

• 程序使用Bitmap來(lái)舉例，
  因?yàn)閷?duì)于一般程序，最大的問(wèn)題往往都在Bitmap上，
  因?yàn)樗牡膬?nèi)存非常多，
  將其作為內(nèi)存泄漏的案例，效果會(huì)比較明顯；

定義類(lèi)似觀(guān)察者的一個(gè)接口CallBack
以及類(lèi)似被觀(guān)察者的一個(gè)實(shí)現(xiàn)類(lèi)CallBackManager：

public interface CallBack {
    void dpOperate();
}

----

public class CallBackManager {

    public static ArrayList<CallBack> sCallBacks = new ArrayList<>();

    public static void addCallBack(CallBack callBack) {
        sCallBacks.add(callBack);
    }

    public static void removeCallBack(CallBack callBack) {
        sCallBacks.remove(callBack);
    }

}

activity_memoryleak.xml：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <ImageView
        android:id="@+id/iv_memoryleak"
        android:layout_width="50dp"
        android:layout_height="50dp" />

</LinearLayout>

MemoryLeakActivity.java：

/**
 * 模擬內(nèi)存泄露的Activity
 */
public class MemoryLeakActivity extends AppCompatActivity implements CallBack{

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memoryleak);
        ImageView imageView = findViewById(R.id.iv_memoryleak);
        Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.mipmap.splash);
        imageView.setImageBitmap(bitmap);

        CallBackManager.addCallBack(this);
    }

    @Override
    public void dpOperate() {
        // do sth
    }
}

• dpOperate()模擬操作業(yè)務(wù)的邏輯方法；
  在反復(fù)地退出關(guān)閉和打開(kāi)進(jìn)入 以上界面的時(shí)候，
  就可能引起內(nèi)存泄漏；

• 運(yùn)行程序，打開(kāi)MP，初始曲線(xiàn)圖是平穩(wěn)的：

• 建立一個(gè)簡(jiǎn)單的界面，如MainActivity，
  可以點(diǎn)擊進(jìn)入MemoryLeakActivity，
  然后不斷地在MainActivity和MemoryLeakActivity之間切換，
  即反復(fù)地退出關(guān)閉和打開(kāi)進(jìn)入 MemoryLeakActivity，
  這時(shí)候可以看到MP的圖示，內(nèi)存曲線(xiàn)在階梯狀上升，
  也就是說(shuō)我們的可用內(nèi)存在逐漸減少了，?。?！
  出現(xiàn)了這種情況，我們基本就可以斷定，界面可能就是出現(xiàn)了內(nèi)存泄漏?。。。?/strong>

/**
 * 模擬內(nèi)存泄露的Activity
 */
public class MemoryLeakActivity extends AppCompatActivity implements CallBack{

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memoryleak);
        ImageView imageView = findViewById(R.id.iv_memoryleak);
        Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.mipmap.splash);
        imageView.setImageBitmap(bitmap);

        CallBackManager.addCallBack(this);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        CallBackManager.removeCallBack(this);
    }

    @Override
    public void dpOperate() {
        // do sth
    }
}