建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
綜述
讓客戶(hù)滿(mǎn)意是我們工作的目標(biāo)，不斷超越客戶(hù)的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶(hù)，將通過(guò)不懈努力成為客戶(hù)在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名申請(qǐng)、網(wǎng)站空間、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、宜昌網(wǎng)站維護(hù)、網(wǎng)站推廣。
內(nèi)存泄漏(memory leak)是指由于疏忽或錯(cuò)誤造成程序未能釋放已經(jīng)不再使用的內(nèi)存。那么在Android中，當(dāng)一個(gè)對(duì)象持有Activity的引用，如果該對(duì)象不能被系統(tǒng)回收，那么當(dāng)這個(gè)Activity不再使用時(shí)，這個(gè)Activity也不會(huì)被系統(tǒng)回收，那這么以來(lái)便出現(xiàn)了內(nèi)存泄漏的情況。在應(yīng)用中內(nèi)出現(xiàn)一次兩次的內(nèi)存泄漏獲取不會(huì)出現(xiàn)什么影響，但是在應(yīng)用長(zhǎng)時(shí)間使用以后，若是存在大量的Activity無(wú)法被GC回收的話，最終會(huì)導(dǎo)致OOM的出現(xiàn)。那么我們?cè)谶@就來(lái)分析一下導(dǎo)致內(nèi)存泄漏的常見(jiàn)因素并且如何去檢測(cè)內(nèi)存泄漏。
導(dǎo)致內(nèi)存泄漏的常見(jiàn)因素
情景一：靜態(tài)Activity和View
靜態(tài)變量Activity和View會(huì)導(dǎo)致內(nèi)存泄漏，在下面這段代碼中對(duì)Activity的Context和TextView設(shè)置為靜態(tài)對(duì)象，從而產(chǎn)生內(nèi)存泄漏。
- import android.content.Context;
- import android.support.v7.app.AppCompatActivity;
- import android.os.Bundle;
- import android.widget.TextView;
- public class MainActivity extends AppCompatActivity {
- private static Context context;
- private static TextView textView;
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_main);
- context = this;
- textView = new TextView(this);
- }
- }
情景二：Thread，匿名類(lèi)，內(nèi)部類(lèi)
在下面這段代碼中存在一個(gè)非靜態(tài)的匿名類(lèi)對(duì)象Thread，會(huì)隱式持有一個(gè)外部類(lèi)的引用LeakActivity，從而導(dǎo)致內(nèi)存泄漏。同理，若是這個(gè)Thread作為L(zhǎng)eakActivity的內(nèi)部類(lèi)而不是匿名內(nèi)部類(lèi)，他同樣會(huì)持有外部類(lèi)的引用而導(dǎo)致內(nèi)存泄漏。在這里只需要將為T(mén)hread匿名類(lèi)定義成靜態(tài)的內(nèi)部類(lèi)即可(靜態(tài)的內(nèi)部類(lèi)不會(huì)持有外部類(lèi)的一個(gè)隱式引用)。
- public class LeakActivity extends AppCompatActivity {
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_leak);
- leakFun();
- }
- private void leakFun(){
- new Thread(new Runnable() {
- @Override
- public void run() {
- try {
- Thread.sleep(Integer.MAX_VALUE);
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- });
- }
- }
情景三：動(dòng)畫(huà)
在屬性動(dòng)畫(huà)中有一類(lèi)無(wú)限循環(huán)動(dòng)畫(huà)，如果在Activity中播放這類(lèi)動(dòng)畫(huà)并且在onDestroy中去停止動(dòng)畫(huà)，那么這個(gè)動(dòng)畫(huà)將會(huì)一直播放下去，這時(shí)候Activity會(huì)被View所持有，從而導(dǎo)致Activity無(wú)法被釋放。解決此類(lèi)問(wèn)題則是需要早Activity中onDestroy去去調(diào)用objectAnimator.cancel()來(lái)停止動(dòng)畫(huà)。
- public class LeakActivity extends AppCompatActivity {
- private TextView textView;
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_leak);
- textView = (TextView)findViewById(R.id.text_view);
- ObjectAnimator objectAnimator = ObjectAnimator.ofFloat(textView,"rotation",0,360);
- objectAnimator.setRepeatCount(ValueAnimator.INFINITE);
- objectAnimator.start();
- }
- }
情景四：Handler
對(duì)于Handler的內(nèi)存泄漏在(Android的消息機(jī)制——Handler的工作過(guò)程)[http://blog.csdn.net/ljd2038/article/details/50889754]這篇文章中已經(jīng)詳細(xì)介紹，就不在贅述。
情景五：第三方庫(kù)使用不當(dāng)
對(duì)于EventBus，RxJava等一些第三開(kāi)源框架的使用，若是在Activity銷(xiāo)毀之前沒(méi)有進(jìn)行解除訂閱將會(huì)導(dǎo)致內(nèi)存泄漏。
使用MAT檢測(cè)內(nèi)存泄漏
對(duì)于常見(jiàn)的內(nèi)存泄露進(jìn)行介紹完以后，在這里再看一下使用MAT(Memory Analysis Tool)來(lái)檢測(cè)內(nèi)存泄露。MAT的下載地址為：http://www.eclipse.org/mat/downloads.php。
下面來(lái)看一段會(huì)導(dǎo)致內(nèi)存泄露的錯(cuò)誤代碼。
- public class LeakActivity extends AppCompatActivity {
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_leak);
- EventBus.getDefault().register(this);
- }
- @Subscribe
- public void subscriber(String s){
- }
- }
在上面這段代碼中有會(huì)導(dǎo)致內(nèi)存泄漏，原因是EventBus沒(méi)有解除注冊(cè)。下面就以這段代碼為例來(lái)看一下如何分析內(nèi)存泄漏。
打開(kāi)AndroidStudio中的Monitors可以看到如下界面。
在這里可以看到在應(yīng)用剛啟動(dòng)的時(shí)候，所占用的內(nèi)存為15M，然后我們現(xiàn)在開(kāi)始操作APP，反復(fù)進(jìn)入退出LeakActicity。點(diǎn)擊上如中的GC按鈕。這時(shí)候我們?cè)诳匆幌聝?nèi)存使用情況。
在這里我們可以看到，內(nèi)存一直在持續(xù)增加，已經(jīng)達(dá)到33M，并且無(wú)法被GC所回收。所以我們可以判斷，這時(shí)候必然出現(xiàn)內(nèi)存泄漏的情形。那么現(xiàn)在再點(diǎn)擊Dump Java Heap按鈕，在captures窗口看到生成得hprof文件。但這時(shí)候所生成的hprof文件不是標(biāo)準(zhǔn)格式的，我們需要通過(guò)SDK所提供的工具h(yuǎn)prof-conv進(jìn)行轉(zhuǎn)化，該工具在SDK的platform-tools目錄下。執(zhí)行命令如下：
- hprof-conv XXX.hprof converted-dump.hprof
當(dāng)然在AndroidStudio中可以省去這一步，可以直接導(dǎo)出標(biāo)準(zhǔn)格式的hprof文件。
這時(shí)候可以通過(guò)MAT工具來(lái)打開(kāi)導(dǎo)出的hprof文件。打開(kāi)界面如下圖所示：
在MAT中我們最常用的就是Histogram和Dominator Tree，他們分別對(duì)應(yīng)上圖中的A和B按鈕。Histogram可以看出內(nèi)存中不同類(lèi)型的buffer的數(shù)量和占用內(nèi)存的大小，而Dominator Tree則是把內(nèi)存中的對(duì)象按照從大到小的順序進(jìn)行排序，并且可以分析對(duì)象之間的引用關(guān)系。在這里再來(lái)介紹一下MAT中兩個(gè)符號(hào)的含義。
- ShallowHeap:對(duì)象自身占用的內(nèi)存大小，不包括他引用的對(duì)象
- RetainedHeap:對(duì)象自身占用的內(nèi)存大小并且加上它直接或者間接引用對(duì)象的大小
Histogram
由于在Android中一般內(nèi)存泄漏大多出現(xiàn)在Acivity中，這時(shí)候可以點(diǎn)擊Histogram按鈕，并搜索Activity。
在這里可以看出LeakActivity存在69個(gè)對(duì)象，基本上可以斷定存在內(nèi)存泄漏的情形，這時(shí)候便可以通過(guò)查看GC對(duì)象的引用鏈來(lái)進(jìn)行分析。點(diǎn)擊鼠標(biāo)右鍵選擇Merge Shortest paths to GC Roots并選擇exclude weak/soft references來(lái)排除弱引用和軟引用。
在排除軟引用和弱引用以后如下圖所示：
在這里可以看出由于EventBus導(dǎo)致的LeakActivity內(nèi)存泄漏。
在Histogram中還可以查看一個(gè)對(duì)象包含了那些對(duì)象的引用。例如，現(xiàn)在要查看LeakActivity所包含的引用，可以點(diǎn)擊鼠標(biāo)右鍵，選擇list objects中的with incoming reference。而with outcoming reference表示選中對(duì)象持有那些對(duì)象的引用。
Dominator Tree
現(xiàn)在我們點(diǎn)擊這時(shí)候可以點(diǎn)擊Dominator Tree按鈕，并搜索Activity。可以看到如下圖所示：
在這里可以看到存在大量的LeakActivity。然后點(diǎn)擊鼠標(biāo)右鍵選擇Path To GC Roots->exclude weak/soft references來(lái)排除弱引用和軟引用。
之后可以看到如下結(jié)果，依然是EventBus導(dǎo)致的內(nèi)存泄漏：
總結(jié)
內(nèi)存泄漏往往被我們所忽略，但是當(dāng)大量的內(nèi)存泄漏以后導(dǎo)致OOM。它所造成的影響也是不容小覷的。當(dāng)然除了上述內(nèi)存泄漏的分析以為我們還可以通過(guò)LeakCanary來(lái)分析內(nèi)存泄漏。對(duì)于LeakCanary的使用在這里就不在進(jìn)行詳細(xì)介紹。
文章標(biāo)題：Android性能優(yōu)化之內(nèi)存泄漏
分享地址：http://www.5511xx.com/article/dhdchhs.html
