Android性能優(yōu)化之常見的內(nèi)存泄漏

前言

對(duì)于內(nèi)存泄漏敷待,我想大家在開發(fā)中肯定都遇到過间涵,只不過內(nèi)存泄漏對(duì)我們來說并不是可見的,因?yàn)樗窃诙阎谢顒?dòng)讼撒,而要想檢測程序中是否有內(nèi)存泄漏的產(chǎn)生浑厚,通常我們可以借助LeakCanary、MAT等工具來檢測應(yīng)用程序是否存在內(nèi)存泄漏根盒,MAT是一款強(qiáng)大的內(nèi)存分析工具钳幅,功能繁多而復(fù)雜,而LeakCanary則是由Square開源的一款輕量第三方內(nèi)存泄漏檢測工具炎滞,當(dāng)它檢測到程序中有內(nèi)存泄漏的產(chǎn)生時(shí)敢艰,它將以最直觀的方式告訴我們?cè)搩?nèi)存泄漏是由誰產(chǎn)生的和該內(nèi)存泄漏導(dǎo)致誰泄漏了而不能回收,供我們復(fù)查册赛。

最近騰訊bugly也推出了三篇關(guān)于Android內(nèi)存泄漏調(diào)優(yōu)的文章:

  1. 內(nèi)存泄露從入門到精通三部曲之基礎(chǔ)知識(shí)篇
  2. 內(nèi)存泄露從入門到精通三部曲之排查方法篇
  3. 內(nèi)存泄露從入門到精通三部曲之常見原因與用戶實(shí)踐

Realm同樣給出了性能優(yōu)化文章:

10條提升Android性能的建議

內(nèi)存泄漏

為什么會(huì)產(chǎn)生內(nèi)存泄漏钠导?

當(dāng)一個(gè)對(duì)象已經(jīng)不需要再使用了震嫉,本該被回收時(shí),而有另外一個(gè)正在使用的對(duì)象持有它的引用從而導(dǎo)致它不能被回收牡属,這導(dǎo)致本該被回收的對(duì)象不能被回收而停留在堆內(nèi)存中票堵,這就產(chǎn)生了內(nèi)存泄漏。

內(nèi)存泄漏對(duì)程序的影響逮栅?

內(nèi)存泄漏是造成應(yīng)用程序OOM的主要原因之一悴势!我們知道Android系統(tǒng)為每個(gè)應(yīng)用程序分配的內(nèi)存有限,而當(dāng)一個(gè)應(yīng)用中產(chǎn)生的內(nèi)存泄漏比較多時(shí)措伐,這就難免會(huì)導(dǎo)致應(yīng)用所需要的內(nèi)存超過這個(gè)系統(tǒng)分配的內(nèi)存限額特纤,這就造成了內(nèi)存溢出而導(dǎo)致應(yīng)用Crash。

Android中常見的內(nèi)存泄漏匯總

單例造成的內(nèi)存泄漏

單例模式非常受開發(fā)者的喜愛侥加,不過使用的不恰當(dāng)?shù)脑捯矔?huì)造成內(nèi)存泄漏捧存,由于單例的靜態(tài)特性使得單例的生命周期和應(yīng)用的生命周期一樣長,這就說明了如果一個(gè)對(duì)象已經(jīng)不需要使用了担败,而單例對(duì)象還持有該對(duì)象的引用昔穴,那么這個(gè)對(duì)象將不能被正常回收氢架,這就導(dǎo)致了內(nèi)存泄漏傻咖。
如下這個(gè)典例:

public class AppManager {
    private static AppManager instance;
    private Context context;
    private AppManager(Context context) {
        this.context = context;
    }
    public static AppManager getInstance(Context             context) {
        if (instance != null) {
            instance = new AppManager(context);
        }
        return instance;
    }
}

這是一個(gè)普通的單例模式,當(dāng)創(chuàng)建這個(gè)單例的時(shí)候岖研,由于需要傳入一個(gè)Context,所以這個(gè)Context的生命周期的長短至關(guān)重要:

  1. 傳入的是Application的Context:這將沒有任何問題警检,因?yàn)閱卫纳芷诤虯pplication的一樣長
  2. 傳入的是Activity的Context:當(dāng)這個(gè)Context所對(duì)應(yīng)的Activity退出時(shí)孙援,由于該Context和Activity的生命周期一樣長(Activity間接繼承于Context),所以當(dāng)前Activity退出時(shí)它的內(nèi)存并不會(huì)被回收扇雕,因?yàn)閱卫龑?duì)象持有該Activity的引用拓售。

所以正確的單例應(yīng)該修改為下面這種方式:

public class AppManager {
    private static AppManager instance;
    private Context context;
    private AppManager(Context context) {
        this.context = context.getApplicationContext();
    }
    public static AppManager getInstance(Context context) {
        if (instance != null) {
            instance = new AppManager(context);
        }
        return instance;
    }
}

這樣不管傳入什么Context最終將使用Application的Context,而單例的生命周期和應(yīng)用的一樣長镶奉,這樣就防止了內(nèi)存泄漏

非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實(shí)例造成的內(nèi)存泄漏

有的時(shí)候我們可能會(huì)在啟動(dòng)頻繁的Activity中础淤,為了避免重復(fù)創(chuàng)建相同的數(shù)據(jù)資源,可能會(huì)出現(xiàn)這種寫法:

public class MainActivity extends AppCompatActivity {
    private static TestResource mResource = null;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        if(mResource == null){
            mResource = new TestResource();
        }
        //...
    }
    class TestResource {
    //...
    }
}

這樣就在Activity內(nèi)部創(chuàng)建了一個(gè)非靜態(tài)內(nèi)部類的單例哨苛,每次啟動(dòng)Activity時(shí)都會(huì)使用該單例的數(shù)據(jù)鸽凶,這樣雖然避免了資源的重復(fù)創(chuàng)建,不過這種寫法卻會(huì)造成內(nèi)存泄漏建峭,因?yàn)榉庆o態(tài)內(nèi)部類默認(rèn)會(huì)持有外部類的引用玻侥,而又使用了該非靜態(tài)內(nèi)部類創(chuàng)建了一個(gè)靜態(tài)的實(shí)例,該實(shí)例的生命周期和應(yīng)用的一樣長亿蒸,這就導(dǎo)致了該靜態(tài)實(shí)例一直會(huì)持有該Activity的引用凑兰,導(dǎo)致Activity的內(nèi)存資源不能正痴谱回收。正確的做法為:將該內(nèi)部類設(shè)為靜態(tài)內(nèi)部類或?qū)⒃搩?nèi)部類抽取出來封裝成一個(gè)單例姑食,如果需要使用Context波岛,請(qǐng)使用ApplicationContext

Handler造成的內(nèi)存泄漏

Handler的使用造成的內(nèi)存泄漏問題應(yīng)該說最為常見了,平時(shí)在處理網(wǎng)絡(luò)任務(wù)或者封裝一些請(qǐng)求回調(diào)等api都應(yīng)該會(huì)借助Handler來處理音半,對(duì)于Handler的使用代碼編寫一不規(guī)范即有可能造成內(nèi)存泄漏则拷,如下示例:

public class MainActivity extends AppCompatActivity {
    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
        //...
        }
    };
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        loadData();
    }
    private void loadData(){
        //...request
        Message message = Message.obtain();
        mHandler.sendMessage(message);
    }
}

這種創(chuàng)建Handler的方式會(huì)造成內(nèi)存泄漏,由于mHandler是Handler的非靜態(tài)匿名內(nèi)部類的實(shí)例祟剔,所以它持有外部類Activity的引用隔躲,我們知道消息隊(duì)列是在一個(gè)Looper線程中不斷輪詢處理消息,那么當(dāng)這個(gè)Activity退出時(shí)消息隊(duì)列中還有未處理的消息或者正在處理消息物延,而消息隊(duì)列中的Message持有mHandler實(shí)例的引用宣旱,mHandler又持有Activity的引用,所以導(dǎo)致該Activity的內(nèi)存資源無法及時(shí)回收叛薯,引發(fā)內(nèi)存泄漏浑吟,所以另外一種做法為:

public class MainActivity extends AppCompatActivity {
    private MyHandler mHandler = new MyHandler(this);
    private TextView mTextView ;
    private static class MyHandler extends Handler {
        private WeakReference<Context> reference;
        public MyHandler(Context context) {
        reference = new WeakReference<>(context);
        }
        @Override
        public void handleMessage(Message msg) {
            MainActivity activity = (MainActivity) reference.get();
            if(activity != null){
            activity.mTextView.setText("");
            }
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = (TextView)findViewById(R.id.textview);
        loadData();
    }

    private void loadData() {
        //...request
        Message message = Message.obtain();
        mHandler.sendMessage(message);
    }
}

簡書作者注:
非static的inner class里面都會(huì)有一個(gè)this$0的字段保存它的父對(duì)象。在Java中耗溜,非靜態(tài)(匿名)內(nèi)部類會(huì)默認(rèn)隱性引用外部類對(duì)象组力。而靜態(tài)內(nèi)部類不會(huì)引用外部類對(duì)象。一個(gè)編譯后的inner class 很可能是這樣的:

class parent$inner {
    synthetic parent this$0;
    parent$inner(parent this$0) {
        this.this$0 = this$0;
        this$0.foo();
    }
}

創(chuàng)建一個(gè)靜態(tài)Handler內(nèi)部類抖拴,然后對(duì)Handler持有的對(duì)象使用弱引用燎字,這樣在回收時(shí)也可以回收Handler持有的對(duì)象,這樣雖然避免了Activity泄漏阿宅,不過Looper線程的消息隊(duì)列中還是可能會(huì)有待處理的消息候衍,所以我們?cè)贏ctivity的Destroy時(shí)或者Stop時(shí)應(yīng)該移除消息隊(duì)列中的消息,更準(zhǔn)確的做法如下:

public class MainActivity extends AppCompatActivity {
    private MyHandler mHandler = new MyHandler(this);
    private TextView mTextView ;
    private static class MyHandler extends Handler {
        private WeakReference<Context> reference;
        public MyHandler(Context context) {
        reference = new WeakReference<>(context);
        }
        @Override
        public void handleMessage(Message msg) {
            MainActivity activity = (MainActivity) reference.get();
            if(activity != null){
            activity.mTextView.setText("");
            }
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = (TextView)findViewById(R.id.textview);
        loadData();
    }

    private void loadData() {
        //...request
        Message message = Message.obtain();
        mHandler.sendMessage(message);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
    }
}

使用mHandler.removeCallbacksAndMessages(null);是移除消息隊(duì)列中所有消息和所有的Runnable洒放。當(dāng)然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();來移除指定的Runnable和Message蛉鹿。

線程造成的內(nèi)存泄漏

對(duì)于線程造成的內(nèi)存泄漏,也是平時(shí)比較常見的往湿,異步任務(wù)和Runnable都是一個(gè)匿名內(nèi)部類妖异,因此它們對(duì)當(dāng)前Activity都有一個(gè)隱式引用。如果Activity在銷毀之前领追,任務(wù)還未完成他膳,那么將導(dǎo)致Activity的內(nèi)存資源無法回收,造成內(nèi)存泄漏蔓腐。正確的做法還是使用靜態(tài)內(nèi)部類的方式矩乐,如下:

static class MyAsyncTask extends AsyncTask<Void, Void, Void> {
    private WeakReference<Context> weakReference;

    public MyAsyncTask(Context context) {
        weakReference = new WeakReference<>(context);
    }

    @Override
    protected Void doInBackground(Void... params) {
        SystemClock.sleep(10000);
        return null;
    }

    @Override
    protected void onPostExecute(Void aVoid) {
        super.onPostExecute(aVoid);
        MainActivity activity = (MainActivity) weakReference.get();
        if (activity != null) {
        //...
        }
    }
}
static class MyRunnable implements Runnable{
    @Override
    public void run() {
        SystemClock.sleep(10000);
    }
}
//——————
new Thread(new MyRunnable()).start();
new MyAsyncTask(this).execute();

這樣就避免了Activity的內(nèi)存資源泄漏,當(dāng)然在Activity銷毀時(shí)候也應(yīng)該取消相應(yīng)的任務(wù)AsyncTask::cancel(),避免任務(wù)在后臺(tái)執(zhí)行浪費(fèi)資源散罕。

資源未關(guān)閉造成的內(nèi)存泄漏

對(duì)于使用了BraodcastReceiver分歇,ContentObserver,F(xiàn)ile欧漱,Cursor职抡,Stream,Bitmap等資源的使用误甚,應(yīng)該在Activity銷毀時(shí)及時(shí)關(guān)閉或者注銷缚甩,否則這些資源將不會(huì)被回收,造成內(nèi)存泄漏窑邦。

一些建議
  1. 對(duì)于生命周期比Activity長的對(duì)象如果需要應(yīng)該使用ApplicationContext

  2. 對(duì)于需要在靜態(tài)內(nèi)部類中使用非靜態(tài)外部成員變量(如:Context擅威、View ),可以在靜態(tài)內(nèi)部類中使用弱引用來引用外部類的變量來避免內(nèi)存泄漏

  3. 對(duì)于不再需要使用的對(duì)象冈钦,顯示的將其賦值為null郊丛,比如使用完Bitmap后先調(diào)用recycle(),再賦為null

  4. 保持對(duì)對(duì)象生命周期的敏感瞧筛,特別注意單例厉熟、靜態(tài)對(duì)象、全局性集合等的生命周期

  5. 對(duì)于生命周期比Activity長的內(nèi)部類對(duì)象较幌,并且內(nèi)部類中使用了外部類的成員變量揍瑟,可以這樣做避免內(nèi)存泄漏:

  6. 將內(nèi)部類改為靜態(tài)內(nèi)部類

  7. 靜態(tài)內(nèi)部類中使用弱引用來引用外部類的成員變量

  8. 在涉及到Context時(shí)先考慮ApplicationContext,當(dāng)然它并不是萬能的乍炉,對(duì)于有些地方則必須使用Activity的Context绢片,對(duì)于Application整陌,Service库车,Activity三者的Context的應(yīng)用場景如下:


其中:NO1表示Application和Service可以啟動(dòng)一個(gè)Activity恍涂,不過需要?jiǎng)?chuàng)建一個(gè)新的task任務(wù)隊(duì)列座每。而對(duì)于Dialog而言,只有在Activity中才能創(chuàng)建

轉(zhuǎn)載:http://hanhailong.com/2015/12/27/Android性能優(yōu)化之常見的內(nèi)存泄漏

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末勿璃,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌随珠,老刑警劉巖,帶你破解...
    沈念sama閱讀 217,509評(píng)論 6 504
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件猬错,死亡現(xiàn)場離奇詭異窗看,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī)倦炒,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,806評(píng)論 3 394
  • 文/潘曉璐 我一進(jìn)店門显沈,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事拉讯〉咏剑” “怎么了?”我有些...
    開封第一講書人閱讀 163,875評(píng)論 0 354
  • 文/不壞的土叔 我叫張陵魔慷,是天一觀的道長只锭。 經(jīng)常有香客問我,道長院尔,這世上最難降的妖魔是什么蜻展? 我笑而不...
    開封第一講書人閱讀 58,441評(píng)論 1 293
  • 正文 為了忘掉前任,我火速辦了婚禮邀摆,結(jié)果婚禮上纵顾,老公的妹妹穿的比我還像新娘。我一直安慰自己栋盹,他們只是感情好施逾,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,488評(píng)論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著贞盯,像睡著了一般音念。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上躏敢,一...
    開封第一講書人閱讀 51,365評(píng)論 1 302
  • 那天闷愤,我揣著相機(jī)與錄音,去河邊找鬼件余。 笑死讥脐,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的啼器。 我是一名探鬼主播旬渠,決...
    沈念sama閱讀 40,190評(píng)論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢(mèng)啊……” “哼端壳!你這毒婦竟也來了告丢?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,062評(píng)論 0 276
  • 序言:老撾萬榮一對(duì)情侶失蹤损谦,失蹤者是張志新(化名)和其女友劉穎岖免,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體照捡,經(jīng)...
    沈念sama閱讀 45,500評(píng)論 1 314
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡颅湘,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,706評(píng)論 3 335
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了栗精。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片闯参。...
    茶點(diǎn)故事閱讀 39,834評(píng)論 1 347
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡瞻鹏,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出鹿寨,到底是詐尸還是另有隱情新博,我是刑警寧澤,帶...
    沈念sama閱讀 35,559評(píng)論 5 345
  • 正文 年R本政府宣布释移,位于F島的核電站叭披,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏玩讳。R本人自食惡果不足惜涩蜘,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,167評(píng)論 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望熏纯。 院中可真熱鬧同诫,春花似錦、人聲如沸樟澜。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,779評(píng)論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽秩贰。三九已至霹俺,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間毒费,已是汗流浹背丙唧。 一陣腳步聲響...
    開封第一講書人閱讀 32,912評(píng)論 1 269
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留觅玻,地道東北人想际。 一個(gè)月前我還...
    沈念sama閱讀 47,958評(píng)論 2 370
  • 正文 我出身青樓,卻偏偏與公主長得像溪厘,于是被迫代替她去往敵國和親胡本。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,779評(píng)論 2 354

推薦閱讀更多精彩內(nèi)容