2. 程式人生 > >Android記憶體洩露案例和解析

Android記憶體洩露案例和解析

阿新 • • 發佈：2019-02-06

使用過長物件生命週期

靜態引用

靜態變數儲存在方法區，在類載入的時候被載入，除非類被解除安裝了，或者他會一直存活，直到App程序銷燬，也就是說靜態變數的生命期等於整個程序的生命期。

    private Context mContext;
    @OnClick(R.id.btnStaticTest)
    void testClick() {
        finish();
        Toast.makeText(mContext, "mContext洩漏", Toast.LENGTH_SHORT).show();
    }

    @Override
    protected
 
 void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mContext = this;
   }

mContext持有了MainActivity的引用，因為mContext生命期長於MainActivity所以造成記憶體洩漏

單例

單例整個程式只儲存一個物件，因為其也要通過靜態變數來實現，所以他的生命期其實和靜態變數一致也是整個程序的存活期。如果在內部持有了一個生命期較短物件的引用，而且沒有手動釋放的話，那麼也會造成記憶體洩漏。

public class SingleInstance {
    private Context mContext;
    private static SingleInstance instance = new SingleInstance();

    public static SingleInstance getInstance() {
        return instance;
    }

    public void setup(Context context) {
        this.mContext = context
    }
}

解決辦法

使用getApplicationContext代替context

例如在用Toast的時候，我們會盡量選用getApplicationContext()，就是利用Application的上下文生命期會貫穿整個App。

 Toast.makeText(getApplicationContext(), "mContext洩漏", Toast.LENGTH_SHORT).show();

有的使用，我們無法拿到getApplicationContext()因為這個方法是在ContextWrapper這個類裡面，Activity繼承了這個類他自然可以拿到。可以通過下面這種方式去獲取：

public class XApplication extends Application {
    private static Context mContext;

    @Override
    public void onCreate() {
        super.onCreate();
        mContext = this;
        LeakCanary.install(this);
    }
    public static Context getContext() {
        return mContext;
    }
}

使用的時候XApplication.getContext()拿到Context，因為Application和靜態變數生命期一致，所以不會造成記憶體洩漏，如果Application 在程式切換到後臺被後臺殺死，再切換回來重建肯定會執行他的onCreate()方法，再次給mContext賦值，所以不用擔心XApplication.getContext()會報空指標異常。

手動控制釋放

例如在Activity中會用到Activity的上下文mContext，那麼就可以在onDestroy()釋放引用

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        SingleInstance.getInstance().setContext(this);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        SingleInstance.getInstance().setContext(null);
    }

事實上，這種情況還是經常碰到的，例如註冊和反註冊廣播，還有使用EventBus或者otto的時候

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        EventBus.getDefault().register(this);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        EventBus.getDefault().unregister(this);
    }

EventBus.getDefault()的實現

    static volatile EventBus defaultInstance;
    /** Convenience singleton for apps using a process-wide EventBus instance. */
    public static EventBus getDefault() {
        if (defaultInstance == null) {
            synchronized (EventBus.class) {
                if (defaultInstance == null) {
                    defaultInstance = new EventBus();
                }
            }
        }
        return defaultInstance;
    }

很明顯看出他是一個懶漢式（Lazy Loading）的單例，通過unregister方法實現我們所說的手動釋放。

使用非靜態內部類

非靜態內部類包括以下三種
- 成員內部類
- 區域性內部類
- 匿名內部類
非靜態內部類會直接持有外部類的引用，如果非靜態內部類不被回收，他的外部類也不會被回收從而造成記憶體洩漏
例如：

成員內部類

    class A {
    }

    private static A a;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        a = new A();
    }

雖然class A為空，但是因為他存在一個靜態例項，這會導致A的類例項不會被GC回收，從而導致外部類MainActivity不會被回收。

匿名內部類

在點選事件的匿名內部類中，通過Handler.postDelayed()執行一個延遲任務，任務執行在Runnable匿名內部類中實現。

public class MainActivity extends AppCompatActivity {
    public static final String TAG = "MainActivity";
    public final static int DO_WORK = 1;


    private Handler mHandler = new Handler(new Handler.Callback() {
        @Override
        public boolean handleMessage(Message msg) {
            if (msg.what == DO_WORK) {
                //do something
            }
            return false;
        }
    });
    @BindView(R.id.btnHandler)
    Button btnHandler;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        ButterKnife.bind(this);
        btnHandler.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                MainActivity.this.finish();
                mHandler.sendEmptyMessage(DO_WORK);
                mHandler.postDelayed(new Runnable() {
                    @Override
                    public void run() {
                        Toast.makeText(MainActivity.this, "btnHandler", Toast.LENGTH_SHORT).show();
                    }
                }, 15 * 1000);
            }
        });
    }
}

這裡存在2處記憶體溢位：
1. finish()掉這個Activity，任務延遲15s，在延後的這15S過程中，造成了15S的記憶體洩漏。
2. 在public boolean handleMessage(Message msg)收到傳送過來的訊息，執行一些任務

修改方式：有兩種方案：

  1. 手動取消 。 在關閉Activity時（finish/onStop等函式中），取消還在排隊的Message：
    mHandler.removeCallbacksAndMessages(null);

  2. 使用弱引用。 使用WeakReference截斷StrongReference。問題的癥結既然是內部類持有外部類物件的引用，那我不用內部類就行了，直接使用靜態成員類。但mHandler又需要與Activity物件互動，那就來個WeakReference，指向外部Activity物件。

public class MainActivity extends AppCompatActivity {
    public static final String TAG = "MainActivity";
    public final static int DO_WORK = 1;

    private MyHandler mHandler;
    @BindView(R.id.btnHandler)
    Button btnHandler;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mHandler = new MyHandler(this);
        ButterKnife.bind(this);
        btnHandler.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                MainActivity.this.finish();
                mHandler.sendEmptyMessage(DO_WORK);
                mHandler.postDelayed(new Runnable() {
                    @Override
                    public void run() {
                        Toast.makeText(MainActivity.this, "btnHandler", Toast.LENGTH_SHORT).show();
                    }
                }, 15 * 1000);
            }
        });
    }

//方案一
    @Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
        if (mHandler != null) {
            mHandler = null;
        }
    }
//方案二
    private static class MyHandler extends Handler {
        private WeakReference<AppCompatActivity> wr;

        public MyHandler(AppCompatActivity aty) {
            wr = new WeakReference<>(aty);
        }


        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            if (wr.get() != null) {
                if (msg.what == DO_WORK) {
                //dosomething
                }
            }
        }
    }


}

耗時操作

直接開啟子執行緒，匿名內部類

public class MainActivity extends AppCompatActivity {
    public static final String TAG = "MainActivity";
    private static int count = 0;

    @BindView(R.id.btnHandler)
    Button btnHandler;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        ButterKnife.bind(this);
        new Thread(new Runnable() {
            @Override
            public void run() {
                while (true) {
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    count++;
                    Log.d(TAG, "run: " + count);
                }
            }
        }).start();
    }
}

根據我們剛才分析的，使用弱引用來解除，Thread對Activity持有的引用

public class MainActivity extends AppCompatActivity {
    public static final String TAG = "MainActivity";
    private static int count = 0;

    @BindView(R.id.btnHandler)
    Button btnHandler;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        ButterKnife.bind(this);
        new MyThread(new Runnable() {
            @Override
            public void run() {
                while (true) {
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    count++;
                    Log.d(TAG, "run: " + count);
                }
            }
        }).start();
    }

    private class MyThread extends Thread {
        private WeakReference<Runnable> wr;

        public MyThread(Runnable runnable) {
            super(runnable);
            wr = new WeakReference<Runnable>(runnable);
        }

        @Override
        public synchronized void start() {
            if (wr.get() == null) {
                return;
            }
            super.start();
        }
    }
}

但是執行後發現，這樣做沒有作用。因為我們開始建立的Thread的時候有兩個匿名內部類，修改後Runnable還是持有Activity的引用。
這裡我們可以利用，執行緒池的特性在Activity停止的時候取消任務

public class MainActivity extends AppCompatActivity {
    public static final String TAG = "MainActivity";
    private static int count = 0;

    @BindView(R.id.btnHandler)
    Button btnHandler;
    private Future future;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        ButterKnife.bind(this);
        Callable<Boolean> callable = new Callable() {
            @Override
            public Object call() throws Exception {
                while (true) {
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                        return false;
                    }
                    count++;
                    Log.d(TAG, "run: " + count);

                }
            }
        };
        ExecutorService es = Executors.newSingleThreadExecutor();
        future = es.submit(callable);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        future.cancel(true);
    }
}

注意：不要使用Runnable取代Callable,這並不能中斷任務執行，下面是錯誤的範例

        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                {
                    while (true) {
                        try {
                            Thread.sleep(1000);
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                        count++;
                        Log.d(TAG, "run: " + count);
                    }
                }
            }
        };
        ExecutorService es = Executors.newSingleThreadExecutor();
        future = es.submit(runnable);

這樣寫 並不能取消執行

相關推薦

Android記憶體洩露案例和解析

使用過長物件生命週期 靜態引用 靜態變數儲存在方法區，在類載入的時候被載入，除非類被解除安裝了，或者他會一直存活，直到App程序銷燬，也就是說靜態變數的生命期等於整個程序的生命期。 private Context mContext;

Android記憶體洩露檢測工具和實際開發中遇到的記憶體洩露問題解析

介紹 記憶體洩露是平常開發中經常遇到的，有些時候稍不注意就會發生，而且還不易察覺，這就需要工具來幫助檢測。本文主要介紹記憶體檢測工具和我在開發中遇到的記憶體洩露問題和解決方案。 記憶體洩露的原理 具體的原理涉及到虛擬機器垃圾回收機制知識，這裡只為下文作

Android 記憶體洩露和效能檢測

Android Studio的記憶體分析介面 一般分析記憶體洩露, 首先執行程式,開啟日誌控制檯,有一個標籤Memory ,我們可以在這個介面分析當前程式使用的記憶體情況, 一目瞭然, 我們再也不需要苦苦的在logcat中尋找記憶體的日誌了。圖中藍色區域，就是程式使用的

Android記憶體洩露分析

一，記憶體洩露 記憶體洩露：一個不在被使用的物件被另一個存活著的物件引用，在這種情況下垃圾回收器會跳過他，因為這種引用關係足以讓該物件駐留在記憶體中，記憶體洩露是在組織垃圾回收器為未來的記憶體分配提供空間，這些洩露的物件一直佔據著記憶體，導致我們的堆記憶體空間變得更小。也加劇了垃圾回

轉載：Android 記憶體洩露分析實戰演練

版權宣告：本文為博主原創文章，未經博主允許不得轉載。 https://mp.csdn.net/postedit/82736058 轉載自任玉剛微信推文，非常全面所以記錄下來 1. 記憶體洩露簡介 記憶體洩露，即Memory Leak，指程式中不再使用到的物件因某種原因從而無法被GC正常回

Android記憶體洩漏查詢和解決adb shell dumpsys meminfo packagement

1.通過adb shell dumpsys meminfo packageName來檢視記憶體使用狀況 在沒有開啟應用的情況下，該命令返回的資料是這樣的: 2.開啟這個應用的MainActivity，再通過命令檢視: 可以看到打印出來很多的資訊，而對於我們檢

android記憶體洩露深入研究

首先抄上百科 隱式記憶體洩漏：程式在執行過程中不停的分配記憶體，但是直到結束的時候才釋放記憶體。嚴格的說這裡並沒有發生記憶體洩漏，因為最終程式釋放了所有申請的記憶體。但是對於一個伺服器程式，需要執行幾天，幾周甚至幾個月，不及時釋放記憶體也可能導致最終耗盡系統的所有記憶體。所

Android記憶體洩露利器（hprof篇）

set processName=com.sec.android.app.dialertab;android.process.acore;com.sec.android.provider.logsprovider

全方位帶你徹底搞懂Android記憶體洩露

1Java記憶體回收方式 Java判斷物件是否可以回收使用的而是可達性分析演算法。 在主流的商用程式語言中(Java和C#)，都是使用可達性分析演算法判斷物件是否存活的。

使用命令列檢測Android記憶體洩露

首先我們用電腦連線裝置，用cmd執行adb的記憶體檢測的命令 adb shell dumpsys meminfo com.screening 後面的com.screening是包名，要改成自己的 執行後顯示的資訊 這裡面需要關心的有：HeapSi

效能優化篇---記憶體管理之Android記憶體洩露

記憶體洩漏：當你不再需要某個例項後，但是這個物件卻仍然被引用，防止被垃圾回收。這個情況就叫做記憶體洩露(Memory Leak)。 常見洩漏場景： 1.Handler 導致的記憶體洩漏 12345678910111213141516171819202122 publ

Linux下利用Valgrind工具進行記憶體洩露檢測和效能分析

Valgrind通常用來成分析程式效能及程式中的記憶體洩露錯誤 一 Valgrind工具集簡紹 Valgrind包含下列工具：     1、memcheck：檢查程式中的記憶體問題，如洩漏、越界、非法指標等。     2、callgrind：檢測程式程式碼的執行

瞭解關於Android記憶體洩露等相關問題的處理方式

我們在開發過程中，不時會遇到一些記憶體洩露等問題，比如說，開啟一個Activity,會findViewById到一些需要的控制元件來進行ADUS等操作。。        而當我們在結束一些Activity或Fragment之後，之前findViewById到的一些控制元件仍然

Android記憶體洩露分析工具—Android Monitor

記憶體洩露大家應該不會陌生了，通常是因為該被釋放的物件被佔用，不能及時對其釋放，導致GC無法正常回收。我們可以使用一些工具來監控和分析導致記憶體洩露的位置和原因。用Eclipse的同志應該都知道MAT(Memory Analysis Tools)，Android

Android記憶體洩露分析簡要思路

工作中遇到挺多需要分析記憶體洩露問題的情況，現在大致簡要寫下思路，等之後時間相對比較充裕再進行補充。 1.明白記憶體洩露的判斷依據？ 個人總結為：持續增加，只增不減！ 理解一下這8個字，配合幾個命令和工具來確定一下你的應用是否存在記憶體洩露問題，這是很關鍵的，如果一開始就判斷錯誤了

Android記憶體洩漏監控和優化技巧總結

前言對於Android平臺的應用程式來說，記憶體優化一直是個熱門話題，與傳統PC應

JAVA記憶體洩露分析和解決方案及WINDOWS自帶檢視工具

Java記憶體洩漏是每個Java程式設計師都會遇到的問題,程式在本地執行一切正常,可是佈署到遠端就會出現記憶體無限制的增長,最後系統癱瘓,那麼如何最快最好的檢測程式的穩定性,防止系統崩盤,作者用自已的親身經歷與各位分享解決這些問題的辦法.作為Internet最流行的程式語言之一,Java現正非常流行.我們的網

android 記憶體基本原理和機制管理

java語言相對於c/c++語言來說人性化的一點就是java有專門管理回收的垃圾回收器。而c/c++語言只能是“誰造成，誰處理”。 GC 1，GC是垃圾收集的意思（Gabage Collection） 2，Java提供的GC功能可以自動監測物件是否超過

Android記憶體洩露常見問題總結

概念梳理 在介紹記憶體洩漏之前很有必要提及一下Android系統的垃圾回收機制。Java GC（Garbage Collection，垃圾收集，垃圾回收）機制，是Java與C++/C的主要區別之一，作為Java開發者，不需要專門編寫記憶體回收和垃圾清理

Android記憶體洩露場景分析

原文地址：http://www.cnblogs.com/qianxudetianxia/p/3645106.html大部分內容來自以上原文，有的內容從別的部落格中整理而來Context作為最基本的上下文，承載著Activity，Service等最基本元件。當有物件引用到Act