內(nèi)存泄露，是Android開(kāi)發(fā)者最頭疼的事?？赡芤惶幮⌒〉膬?nèi)存泄露，都可能是毀于千里之堤的蟻穴。

怎么才能檢測(cè)內(nèi)存泄露呢？網(wǎng)上教程非常多，不過(guò)很多都是使用Eclipse檢測(cè)的, 其實(shí)1.3版本以后的Android Studio 檢測(cè)內(nèi)存非常方便, 如果結(jié)合上MAT工具,LeakCanary插件,一切就變得so easy了。

熟悉Android Studio界面

工欲善其事,必先利其器。我們接下來(lái)先來(lái)熟悉下Android Studio的界面

一般分析內(nèi)存泄露, 首先運(yùn)行程序,打開(kāi)日志控制臺(tái),有一個(gè)標(biāo)簽Memory ,我們可以在這個(gè)界面分析當(dāng)前程序使用的內(nèi)存情況, 一目了然, 我們?cè)僖膊恍枰嗫嗟脑趌ogcat中尋找內(nèi)存的日志了。

圖中藍(lán)色區(qū)域，就是程序使用的內(nèi)存， 灰色區(qū)域就是空閑內(nèi)存，

當(dāng)然，Android內(nèi)存分配機(jī)制是對(duì)每個(gè)應(yīng)用程序逐步增加, 比如你程序當(dāng)前使用30M內(nèi)存, 系統(tǒng)可能會(huì)給你分配40M, 當(dāng)前就有10M空閑, 如果程序使用了50M了,系統(tǒng)會(huì)緊接著給當(dāng)前程序增加一部分,比如達(dá)到了80M， 當(dāng)前你的空閑內(nèi)存就是30M了。 當(dāng)然,系統(tǒng)如果不能再給你分配額外的內(nèi)存,程序自然就會(huì)OOM(內(nèi)存溢出)了。 每個(gè)應(yīng)用程序最高可以申請(qǐng)的內(nèi)存和手機(jī)密切相關(guān)，比如我當(dāng)前使用的華為Mate7,極限大概是200M,算比較高的了, 一般128M 就是極限了, 甚至有的手機(jī)只有可憐的16M或者32M，這樣的手機(jī)相對(duì)于內(nèi)存溢出的概率非常大了。

我們?cè)趺礄z測(cè)內(nèi)存泄露呢

首先需要明白一個(gè)概念, 內(nèi)存泄露就是指,本應(yīng)該回收的內(nèi)存,還駐留在內(nèi)存中。

一般情況下,高密度的手機(jī),一個(gè)頁(yè)面大概就會(huì)消耗20M內(nèi)存,如果發(fā)現(xiàn)退出界面,程序內(nèi)存遲遲不降低的話,可能就發(fā)生了嚴(yán)重的內(nèi)存泄露。

我們可以反復(fù)進(jìn)入該界面，然后點(diǎn)擊dump java heap 這個(gè)按鈕,然后Android Studio就開(kāi)始干活了,下面的圖就是正在dump

dump成功后會(huì)自動(dòng)打開(kāi) hprof文件,文件以Snapshot+時(shí)間來(lái)命名

通過(guò)Android Studio自帶的界面,查看內(nèi)存泄露還不是很智能,我們可以借助第三方工具,常見(jiàn)的工具就是MAT了,下載地址 http:///mat/downloads.php ,這里我們需要下載獨(dú)立版的MAT. 下圖是MAT一開(kāi)始打開(kāi)的界面, 這里需要提醒大家的是，MAT并不會(huì)準(zhǔn)確地告訴我們哪里發(fā)生了內(nèi)存泄漏，而是會(huì)提供一大堆的數(shù)據(jù)和線索，我們需要自己去分析這些數(shù)據(jù)來(lái)去判斷到底是不是真的發(fā)生了內(nèi)存泄漏。

接下來(lái)我們需要用MAT打開(kāi)內(nèi)存分析的文件, 上文給大家介紹了使用Android Studio生成了 hprof文件, 這個(gè)文件在呢, 在Android Studio中的Captrues這個(gè)目錄中,可以找到

注意,這個(gè)文件不能直接交給MAT, MAT是不識(shí)別的, 我們需要右鍵點(diǎn)擊這個(gè)文件,轉(zhuǎn)換成MAT識(shí)別的。

然后用MAT打開(kāi)導(dǎo)出的hprof(File->Open heap dump) MAT會(huì)幫我們分析內(nèi)存泄露的原因

LeakCanary

上面介紹了MAT檢測(cè)內(nèi)存泄露, 再給大家介紹LeakCanary。

項(xiàng)目地址：https://github.com/square/leakcanary

LeakCanary會(huì)檢測(cè)應(yīng)用的內(nèi)存回收情況，如果發(fā)現(xiàn)有垃圾對(duì)象沒(méi)有被回收，就會(huì)去分析當(dāng)前的內(nèi)存快照，也就是上邊MAT用到的.hprof文件，找到對(duì)象的引用鏈，并顯示在頁(yè)面上。這款插件的好處就是,可以在手機(jī)端直接查看內(nèi)存泄露的地方,可以輔助我們檢測(cè)內(nèi)存泄露

使用：

在build.gradle文件中添加，不同的編譯使用不同的引用：

在應(yīng)用的Application onCreate方法中添加LeakCanary.install(this)，如下

應(yīng)用運(yùn)行起來(lái)后，LeakCanary會(huì)自動(dòng)去分析當(dāng)前的內(nèi)存狀態(tài)，如果檢測(cè)到泄漏會(huì)發(fā)送到通知欄，點(diǎn)擊通知欄就可以跳轉(zhuǎn)到具體的泄漏分析頁(yè)面。

Tips：就目前使用的結(jié)果來(lái)看，絕大部分泄漏是由于使用單例模式hold住了Activity的引用，比如傳入了context或者將Activity作為listener設(shè)置了進(jìn)去，所以在使用單例模式的時(shí)候要特別注意，還有在Activity生命周期結(jié)束的時(shí)候?qū)⒁恍┳远x監(jiān)聽(tīng)器的Activity引用置空。

關(guān)于LeakCanary的更多分析可以看項(xiàng)目主頁(yè)的介紹，還有這里http://www./cn/posts/leak-canary-read-me/

追蹤內(nèi)存分配

如果我們想了解內(nèi)存分配更詳細(xì)的情況,可以使用Allocation Traker來(lái)查看內(nèi)存到底被什么占用了。

用法很簡(jiǎn)單：

點(diǎn)一下是追蹤， 再點(diǎn)一下是停止追蹤， 停止追蹤后 .alloc文件會(huì)自動(dòng)打開(kāi),打開(kāi)后界面如下:

當(dāng)你想查看某個(gè)方法的源碼時(shí),右鍵選擇的方法,點(diǎn)擊Jump to source就可以了

查詢方法執(zhí)行的時(shí)間

Android Studio 功能越來(lái)越強(qiáng)大了, 我們可以借助AS觀測(cè)各種性能,如下圖:

如果我們要觀測(cè)方法執(zhí)行的時(shí)間,就需要來(lái)到CPU界面

點(diǎn)擊Start Method Tracking, 一段時(shí)間后再點(diǎn)擊一次, trace文件被自動(dòng)打開(kāi),

非獨(dú)占時(shí)間: 某函數(shù)占用的CPU時(shí)間,包含內(nèi)部調(diào)用其它函數(shù)的CPU時(shí)間。

獨(dú)占時(shí)間: 某函數(shù)占用CPU時(shí)間,但不含內(nèi)部調(diào)用其它函數(shù)所占用的CPU時(shí)間。

我們?nèi)绾闻袛嗫赡苡袉?wèn)題的方法？

通過(guò)方法的調(diào)用次數(shù)和獨(dú)占時(shí)間來(lái)查看，通常判斷方法是：

1. 如果方法調(diào)用次數(shù)不多，但每次調(diào)用卻需要花費(fèi)很長(zhǎng)的時(shí)間的函數(shù)，可能會(huì)有問(wèn)題。

2. 如果自身占用時(shí)間不長(zhǎng)，但調(diào)用卻非常頻繁的函數(shù)也可能會(huì)有問(wèn)題。

綜述

上面給大家介紹了若干使用Android Studio檢查程序性能的工具,工具永遠(yuǎn)是輔助,不要因?yàn)楣ぞ叩⒄`太長(zhǎng)時(shí)間。如果有問(wèn)題，歡迎大家糾正。