android內存泄露例子

㈠ 常見的內存泄漏原因及解決方法

（Memory Leak，內存泄漏）

當一個對象已經不需要再使用本該被回收時，另外一個正在使用的對象持有它的引用從而導致它不能被回收，這導致本該被回收的對象不能被回收而停留在堆內存中，這就產生了內存泄漏。

內存泄漏是造成應用程序OOM的主要原因之一。我們知道android系統為每個應用程序分配的內存是有限的，而當一個應用中產生的內存泄漏比較多時，這就難免會導致應用所需要的內存超過系統分配的內存限額，這就造成了內存溢出從而導致應用Crash。

因為內存泄漏是在堆內存中，所以對我們來說並不是可見的。通常我們可以藉助MAT、LeakCanary等工具來檢測應用程序是否存在內存泄漏。
1、MAT是一款強大的內存分析工具，功能繁多而復雜。
2、LeakCanary則是由Square開源的一款輕量級的第三方內存泄漏檢測工具，當檢測到程序中產生內存泄漏時，它將以最直觀的方式告訴我們哪裡產生了內存泄漏和導致誰泄漏了而不能被回收。

由於單例的靜態特性使得其生命周期和應用的生命周期一樣長，如果一個對象已經不再需要使用了，而單例對象還持有該對象的引用，就會使得該對象不能被正常回收，從而導致了內存泄漏。
示例：防止單例導致內存泄漏的實例

這樣不管傳入什麼Context最終將使用Application的Context，而單例的生命周期和應用的一樣長，這樣就防止了內存泄漏。？？？

例如，有時候我們可能會在啟動頻繁的Activity中，為了避免重復創建相同的數據資源，可能會出現如下寫法：

這樣在Activity內部創建了一個非靜態內部類的單例，每次啟動Activity時都會使用該單例的數據。雖然這樣避免了資源的重復創建，但是這種寫法卻會造成內存泄漏。因為非靜態內部類默認會持有外部類的引用，而該非靜態內部類又創建了一個靜態的實例，該實例的生命周期和應用的一樣長，這就導致了該靜態實例一直會持有該Activity的引用，從而導致Activity的內存資源不能被正常回收。
解決方法 ：將該內部類設為靜態內部類或將該內部類抽取出來封裝成一個單例，如果需要使用Context，就使用Application的Context。

示例：創建匿名內部類的靜態對象

1、從Android的角度
當Android應用程序啟動時，該應用程序的主線程會自動創建一個Looper對象和與之關聯的MessageQueue。當主線程中實例化一個Handler對象後，它就會自動與主線程Looper的MessageQueue關聯起來。所有發送到MessageQueue的Messag都會持有Handler的引用，所以Looper會據此回調Handle的handleMessage()方法來處理消息。只要MessageQueue中有未處理的Message，Looper就會不斷的從中取出並交給Handler處理。另外，主線程的Looper對象會伴隨該應用程序的整個生命周期。
2、 java角度
在Java中，非靜態內部類和匿名類內部類都會潛在持有它們所屬的外部類的引用，但是靜態內部類卻不會。

對上述的示例進行分析，當MainActivity結束時，未處理的消息持有handler的引用，而handler又持有它所屬的外部類也就是MainActivity的引用。這條引用關系會一直保持直到消息得到處理，這樣阻止了MainActivity被垃圾回收器回收，從而造成了內存泄漏。
解決方法 ：將Handler類獨立出來或者使用靜態內部類，這樣便可以避免內存泄漏。

示例：AsyncTask和Runnable

AsyncTask和Runnable都使用了匿名內部類，那麼它們將持有其所在Activity的隱式引用。如果任務在Activity銷毀之前還未完成，那麼將導致Activity的內存資源無法被回收，從而造成內存泄漏。
解決方法 ：將AsyncTask和Runnable類獨立出來或者使用靜態內部類，這樣便可以避免內存泄漏。

對於使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等資源，應該在Activity銷毀時及時關閉或者注銷，否則這些資源將不會被回收，從而造成內存泄漏。

1）比如在Activity中register了一個BraodcastReceiver，但在Activity結束後沒有unregister該BraodcastReceiver。
2）資源性對象比如Cursor，Stream、File文件等往往都用了一些緩沖，我們在不使用的時候，應該及時關閉它們，以便它們的緩沖及時回收內存。它們的緩沖不僅存在於 java虛擬機內，還存在於java虛擬機外。如果我們僅僅是把它的引用設置為null，而不關閉它們，往往會造成內存泄漏。
3）對於資源性對象在不使用的時候，應該調用它的close()函數將其關閉掉，然後再設置為null。在我們的程序退出時一定要確保我們的資源性對象已經關閉。
4）Bitmap對象不在使用時調用recycle()釋放內存。2.3以後的bitmap應該是不需要手動recycle了，內存已經在java層了。

初始時ListView會從BaseAdapter中根據當前的屏幕布局實例化一定數量的View對象，同時ListView會將這些View對象緩存起來。當向上滾動ListView時，原先位於最上面的Item的View對象會被回收，然後被用來構造新出現在下面的Item。這個構造過程就是由getView()方法完成的，getView()的第二個形參convertView就是被緩存起來的Item的View對象（初始化時緩存中沒有View對象則convertView是null）。

構造Adapter時，沒有使用緩存的convertView。
解決方法 ：在構造Adapter時，使用緩存的convertView。

我們通常把一些對象的引用加入到了集合容器（比如ArrayList）中，當我們不需要該對象時，並沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。
解決方法 ：在退出程序之前，將集合里的東西clear，然後置為null，再退出程序。

當我們不要使用WebView對象時，應該調用它的destory()函數來銷毀它，並釋放其佔用的內存，否則其長期佔用的內存也不能被回收，從而造成內存泄露。
解決方法 ：為WebView另外開啟一個進程，通過AIDL與主線程進行通信，WebView所在的進程可以根據業務的需要選擇合適的時機進行銷毀，從而達到內存的完整釋放。

1、在涉及使用Context時，對於生命周期比Activity長的對象應該使用Application的Context。凡是使用Context優先考慮Application的Context，當然它並不是萬能的，對於有些地方則必須使用Activity的Context。對於Application，Service，Activity三者的Context的應用場景如下：

其中，NO1表示Application和Service可以啟動一個Activity，不過需要創建一個新的task任務隊列。而對於Dialog而言，只有在Activity中才能創建。除此之外三者都可以使用。

2、對於需要在靜態內部類中使用非靜態外部成員變數（如：Context、View )，可以在靜態內部類中使用弱引用來引用外部類的變數來避免內存泄漏。
3、對於不再需要使用的對象，顯示的將其賦值為null，比如使用完Bitmap後先調用recycle()，再賦為null。
4、保持對對象生命周期的敏感，特別注意單例、靜態對象、全局性集合等的生命周期。
5、對於生命周期比Activity長的內部類對象，並且內部類中使用了外部類的成員變數，可以這樣做避免內存泄漏：
1）將內部類改為靜態內部類
2）靜態內部類中使用弱引用來引用外部類的成員變數

Android內存泄漏總結

㈡ android開發什麼叫內存泄露

下面圖片是解決內存泄露的例子。例子來自android學習手冊，android學習手冊，裡面有源碼。android學習手冊包含9個章節，108個例子，源碼文檔隨便看，例子都是可交互，可運行，源碼採用android studio目錄結構，高亮顯示代碼，文檔都採用文檔結構圖顯示，可以快速定位。360手機助手中下載,圖標上有貝殼

在android程序開發中，當一個對象已經不需要再使用了，本該被回收時，而另外一個正在使用的對象持有它的引用從而導致它不能被回收，這就導致本該被回收的對象不能被回收而停留在堆內存中，內存泄漏就產生了。

內存泄漏有什麼影響呢？它是造成應用程序OOM的主要原因之一。由於android系統為每個應用程序分配的內存有限，當一個應用中產生的內存泄漏比較多時，就難免會導致應用所需要的內存超過這個系統分配的內存限額，這就造成了內存溢出而導致應用Crash。

了解了內存泄漏的原因及影響後，我們需要做的就是掌握常見的內存泄漏，並在以後的android程序開發中，盡量避免它。下面小編搜羅了5個android開發中比較常見的內存泄漏問題及解決辦法，分享給大家，一起來看看吧。

一、單例造成的內存泄漏

Android的單例模式非常受開發者的喜愛，不過使用的不恰當的話也會造成內存泄漏。因為單例的靜態特性使得單例的生命周期和應用的生命周期一樣長，這就說明了如果一個對象已經不需要使用了，而單例對象還持有該對象的引用，那麼這個對象將不能被正常回收，這就導致了內存泄漏。

如下這個典例：

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;

}

}

這是一個普通的單例模式，當創建這個單例的時候，由於需要傳入一個Context，所以這個Context的生命周期的長短至關重要：

1、傳入的是Application的Context：這將沒有任何問題，因為單例的生命周期和Application的一樣長 ；

2、傳入的是Activity的Context：當這個Context所對應的Activity退出時，由於該Context和Activity的生命周期一樣長（Activity間接繼承於Context），所以當前Activity退出時它的內存並不會被回收，因為單例對象持有該Activity的引用。

所以正確的單例應該修改為下面這種方式：

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，而單例的生命周期和應用的一樣長，這樣就防止了內存泄漏。

二、非靜態內部類創建靜態實例造成的內存泄漏

有的時候我們可能會在啟動頻繁的Activity中，為了避免重復創建相同的數據資源，會出現這種寫法：

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(mManager == null){

mManager = new TestResource();

}

//...

}

class TestResource {

//...

}

}

這樣就在Activity內部創建了一個非靜態內部類的單例，每次啟動Activity時都會使用該單例的數據，這樣雖然避免了資源的重復創建，不過這種寫法卻會造成內存泄漏，因為非靜態內部類默認會持有外部類的引用，而又使用了該非靜態內部類創建了一個靜態的實例，該實例的生命周期和應用的一樣長，這就導致了該靜態實例一直會持有該Activity的引用，導致Activity的內存資源不能正常回收。正確的做法為：

將該內部類設為靜態內部類或將該內部類抽取出來封裝成一個單例，如果需要使用Context，請使用ApplicationContext 。

三、Handler造成的內存泄漏

Handler的使用造成的內存泄漏問題應該說最為常見了，平時在處理網路任務或者封裝一些請求回調等api都應該會藉助Handler來處理，對於Handler的使用代碼編寫一不規范即有可能造成內存泄漏，如下示例：

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);

}

}

這種創建Handler的方式會造成內存泄漏，由於mHandler是Handler的非靜態匿名內部類的實例，所以它持有外部類Activity的引用，我們知道消息隊列是在一個Looper線程中不斷輪詢處理消息，那麼當這個Activity退出時消息隊列中還有未處理的消息或者正在處理消息，而消息隊列中的Message持有mHandler實例的引用，mHandler又持有Activity的引用，所以導致該Activity的內存資源無法及時回收，引發內存泄漏，所以另外一種做法為：

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);

}

}

創建一個靜態Handler內部類，然後對Handler持有的對象使用弱引用，這樣在回收時也可以回收Handler持有的對象，這樣雖然避免了Activity泄漏，不過Looper線程的消息隊列中還是可能會有待處理的消息，所以我們在Activity的Destroy時或者Stop時應該移除消息隊列中的消息，更准確的做法如下：

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);是移除消息隊列中所有消息和所有的Runnable。當然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();來移除指定的Runnable和Message。

四、線程造成的內存泄漏

對於線程造成的內存泄漏，也是平時比較常見的，如下這兩個示例可能每個人都這樣寫過：

//——————test1

new AsyncTask<Void, Void, Void>() {

@Override

protected Void doInBackground(Void... params) {

SystemClock.sleep(10000);

return null;

}

}.execute();

//——————test2

new Thread(new Runnable() {

@Override

public void run() {

SystemClock.sleep(10000);

}

}).start();

上面的非同步任務和Runnable都是一個匿名內部類，因此它們對當前Activity都有一個隱式引用。如果Activity在銷毀之前，任務還未完成， 那麼將導致Activity的內存資源無法回收，造成內存泄漏。正確的做法還是使用靜態內部類的方式，如下：

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的內存資源泄漏，當然在Activity銷毀時候也應該取消相應的任務AsyncTask::cancel()，避免任務在後台執行浪費資源。

五、資源未關閉造成的內存泄漏

對於使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等資源的使用，應該在Activity銷毀時及時關閉或者注銷，否則這些資源將不會被回收，造成內存泄漏。

㈢ Android技術分享｜Android 中部分內存泄漏示例及解決方案

內存泄漏：

舉例：

請注意以下的例子是虛構的

內存抖動

源自Android文檔中的 Memory churn 一詞，中文翻譯為內存抖動。

指快速頻繁的創建對象從而產生的性能問題。

引用Android文檔原文：

Java內存泄漏的根本原因是 長生命周期 的對象持有 短生命周期 對象的引用就很可能發生內存泄漏。

盡管短生命周期對象已經不再需要，但因為長生命周期依舊持有它的引用，故不能被回收而導致內存泄漏。

靜態集合類引起的內存泄漏

如果僅僅釋放引用本身(tO = null)， ArrayList 依然在引用該對象，GC無法回收。

監聽器

在Java應用中，通常會用到很多監聽器，一般通過 addXXXXListener() 實現。但釋放對象時通常會忘記刪除監聽器，從而增加內存泄漏的風險。

各種連接

如資料庫連接、網路連接（Socket）和I/O連接。忘記顯式調用 close() 方法引起的內存泄漏。

內部類和外部模塊的引用

內部類的引用是很容易被遺忘的一種，一旦沒有釋放可能會導致一系列後續對象無法釋放。此外還要小心外部模塊不經意的引用，內部類是否提供相應的操作去除外部引用。

單例模式

由於單例的靜態特性，使其生命周期與應用的生命周期一樣長，一旦使用不恰當極易造成內存泄漏。如果單利持有外部引用，需要注意提供釋放方式，否則當外部對象無法被正常回收時，會進而導致內存泄漏。

集合類泄漏

如集合的使用范圍超過邏輯代碼的范圍，需要格外注意刪除機制是否完善可靠。比如由靜態屬性 static 指向的集合。

單利泄漏

以下為簡單邏輯代碼，只為舉例說明內存泄漏問題，不保證單利模式的可靠性。

AppManager 創建時需要傳入一個 Context ，這個 Context 的生命周期長短至關重要。

1. 如果傳入的是 Application 的 Context ，因為 Application 的生命周期等同於應用的生命周期，所以沒有任何問題。

2. 如果傳入的是 Activity 的 Context ，則需要考慮這個 Activity 是否在整個生命周期都不會被回收了，如果不是，則會造成內存泄漏。

非靜態內部類創建靜態實例造成的內存泄漏

應該將該內部類單獨封裝為一個單例來使用。

匿名內部類/非同步線程

Runnable都使用了匿名內部類，將持有MyActivity的引用。如果任務在Activity銷毀前未完成，將導致Activity的內存無法被回收，從而造成內存泄漏。

解決方法：將Runnable獨立出來或使用靜態內部類，可以避免因持有外部對象導致的內存泄漏。

Handler造成的內存泄漏

Handler屬於TLS(Thread Local Storage)變數，生命周期與Activity是不一致的，容易導致持有的對象無法正確被釋放

當Android應用程序啟動時，該應用程序的主線程會自動創建一個Looper對象和與之關聯的MessageQueue。

當主線程中實例化一個Handler對象後，它就會自動與主線程Looper的MessageQueue關聯起來。所有發送到MessageQueue的Messag都會持有Handler的引用，所以Looper會據此回調Handle的handleMessage()方法來處理消息。只要MessageQueue中有未處理的Message，Looper就會不斷的從中取出並交給Handler處理。

另外，主線程的Looper對象會伴隨該應用程序的整個生命周期。

在Java中，非靜態內部類和匿名類內部類都會潛在持有它們所屬的外部類的引用，但是靜態內部類卻不會。

當該 Activity 被 finish() 掉時，延遲執行任務的 Message 還會繼續存在於主線程中，它持有該 Activity 的 Handler 引用，所以此時 finish() 掉的 Activity 就不會被回收了從而造成內存泄漏（因 Handler 為非靜態內部類，它會持有外部類的引用，在這里就是指 SampleActivity）。

避免不必要的靜態成員變數

對於BroadcastReceiver、ContentObserver、File、Cursor、Stream、Bitmap等資源的使用，應在Activity銷毀前及時關閉或注銷。

不使用WebView對象時，應調用`destroy()`方法銷毀。

㈣ 關於Android EditText導致的內存泄漏的問題

泄露信息如下：

====================================

    HEAP ANALYSIS RESULT

    ====================================

    1 APPLICATION LEAKS

    References underlined with "~~~" are likely causes.

    Learn more at https://squ.re/leaks.

    Displaying only 1 leak trace out of 4 with the same signature

    Signature:

    ┬───

    │ GC Root: System class

    │

    ├─ android.os.AsyncTask class

    │    Leaking: NO (a class is never leaking)

    │    ↓ static AsyncTask.SERIAL_EXECUTOR

    │                      ~~~~~~~~~~~~~~~

    ├─ android.os.AsyncTask$SerialExecutor instance

    │    Leaking: UNKNOWN

    │    ↓ AsyncTask$SerialExecutor.mTasks

    │                              ~~~~~~

    ├─ java.util.ArrayDeque instance

    │    Leaking: UNKNOWN

    │    ↓ ArrayDeque.elements

    │                ~~~~~~~~

    ├─ java.lang.Object[] array

    │    Leaking: UNKNOWN

    │    ↓ Object[].[0]

    │              ~~~

    ├─ android.os.AsyncTask$SerialExecutor$1 instance

    │    Leaking: UNKNOWN

    │    Anonymous class implementing java.lang.Runnable

    │    ↓ AsyncTask$SerialExecutor$1.val$r

    │                                ~~~~~

    ├─ android.widget.TextView$3 instance

    │    Leaking: UNKNOWN

    │    Anonymous class implementing java.lang.Runnable

    │    ↓ TextView$3.this$0

    │                ~~~~~~

    ├─ androidx.appcompat.widget.AppCompatEditText instance

    │    Leaking: YES (View.mContext references a destroyed activity)

    │    View not part of a window view hierarchy

    │    View.mAttachInfo is null (view detached)

    │    View.mID = R.id.input_edit

    │    View.mWindowAttachCount = 1

    │    mContext instance of RoomMainActivity with mDestroyed = true

    │    ↓ View.mContext

    ╰→ RoomMainActivity instance

        Leaking: YES (ObjectWatcher was watching this because RoomMainActivity

        received Activity#onDestroy() callback and Activity#mDestroyed is true)

        key = cb388a5c-0ff2-452f-a9b0-6ea7d03a5105

        watchDurationMillis = 37631

        retainedDurationMillis = 32630

        mApplication instance of ChatApplication

        mBase instance of androidx.appcompat.view.ContextThemeWrapper

    ====================================

原因分析：

1、引用鏈結構：AsyncTask的SerialExecutor執行器引用了EditText對象，而EditText對象中的mContext引用到了RoomMainActivity中context，導致RoomMainActivity 無法銷毀。

查看源碼得知在TextView中有updateTextServicesLocaleAsync()方法，調用了AsyncTask.execute(）向其中傳入了匿名內部類Runnable，而持有了控制項對象。

2、解決方法：因為在源碼層面無法修改源碼，在引用端切斷引用鏈。

給EditText使用Application的上下文，在EditText使用的頁面退出銷毀時移除EditText控制項，包括置空它的監聽器、清除它的焦點。

import android.content.Context;

import android.os.Build;

import android.text.TextWatcher;

import android.util.AttributeSet;

import android.view.ViewGroup;

import androidx.appcompat.widget.AppCompatEditText;

/**

* 關於Android EditText導致的內存泄漏的問題

*/

public class NoMemoryLeakEditTextextends AppCompatEditText {

public NoMemoryLeakEditText(Context context) {

super(context.getApplicationContext());

    }

public NoMemoryLeakEditText(Context context, AttributeSet attrs) {

super(context.getApplicationContext(), attrs);

    }

public NoMemoryLeakEditText(Context context, AttributeSet attrs, int defStyleAttr) {

super(context.getApplicationContext(), attrs, defStyleAttr);

    }

public void clearMemoryLeak(TextWatcher watcher, ViewGroup container) {

clearFocus();

        setOnTouchListener(null);

        setOnClickListener(null);

        setOnDragListener(null);

        setOnKeyListener(null);

        setOnLongClickListener(null);

        setOnEditorActionListener(null);

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT_WATCH) {

(null);

        }

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {

setOnScrollChangeListener(null);

        }

setOnFocusChangeListener(null);

        removeTextChangedListener(watcher);

        container.removeView(this);

    }

}

最後在頁面銷毀的地方調用clearMemoryLeak方法

㈤ Android ValueAnimator --內存泄漏

不是成功來得太慢，只是下的功夫還不夠

最近在寫一個關於貝塞爾曲線水波紋渣尺的小DEMO，發現關閉當前視圖時報出內存泄漏的問兆游題，檢查下內存泄如猜高漏信息，經過排查發現是ValueAnimator的監聽事件引起的，
先上解決方法：
在Activity/Fragment銷毀時調用如下方法：

找到問題就好辦了，查源碼

檢查發現在ValueAnimator start()方法中有個 addAnimationCallback(0); 調用，繼續檢查發現

這里就發現問題了， AnimationHandler.getInstance(); 這個是單例獲取，所以在退出Activity時，ValueAnimator沒有被釋放，找到問題就好辦了，就在Activity或者Fragment被銷毀時，主動把動畫監聽取消掉。最後上一下我Demo的效果圖 得意

㈥ 排查內存泄漏最簡單和直觀的方法

內存泄漏無疑會嚴重影響用戶體驗，一些本應該廢棄的資源和對象無法被釋放，導致手機內存的浪費，app使用的卡頓，那麼如何排查內存泄漏呢？

當然，首先我門有google的官方文檔可以參考：

大部分博客的方法也來自於此。總的來說，就是使用android studio 的monitor memory功能監測app主進程佔用的內存，觸發GC操作，而後觀察內存的佔用情況，如果在使用的過程中內存不斷增加，沒有回落， 很有可能 發生了內存泄漏，這時候就需要導出內存分配的具體詳情進行深入分析了。

但是事實上，通過觀察這個內存曲線的曾場來或者是觀察allocate tracker中的allocate data數值的增長來檢測是否有內存泄漏問題，真的很玄，因為往往內存泄漏發生了，但是GC仍然可以通過回收其他對象的方式騰出空間，導致這個數據的變化基本看不出來，甚至是減小的，所以我覺得這種方式， 就像是讓你用手掌去感知嬰兒的體溫，去檢測確定這個嬰兒有沒有發燒一樣，非常不靠譜不準確。

那麼，重點來了，我的方法，簡單直觀，保准你一學就會！

先說一個terminal指令： 

這條指令是用來查詢這個進程所佔用的內存的具體詳情的，通過這條指令可以看到當前app在手機中佔用的具體的堆內存大小，view的數量， activity的數量 ，等等。如下圖：

其中activity數目是非常關鍵的一個信息，可以幫助我們快速地檢測出內存泄漏。我們可以反復地進入退出需要測試的目標activity，如果在反復進入退出之後，用terminal執行上面的語句查詢當前的內存情況，如果發現activity數量一直在增長，那麼內存泄露一定是發生了！

內存泄漏已經發生，如何定位原因呢？

如下圖，在android studio中開始memory monitor，點擊init GC，反復進入退出發生了內存泄漏的activity，這時候點擊生成內存文件，這之後android studio會自動打開生成的.hprof文件。選中該文件轉化成標準的hrof文件。

用MAT工具打開生成的.hprof文件，點擊如下所示的圖標，可以看到內存中的對象列表。

考慮到大內存的泄漏都是因為Activity被destroy之後卻仍然被其他對象持有而造成的，因此首先解決棘手問題，直接搜索Activity，如下。發現有Activity的實例個數是3，跟實際不符，明顯這個activity導致內存泄漏了，按照如圖的方式找到它的引用，也就是導致內存泄漏的幕後兇手！

可以看到這個例子中的內存泄漏是由一個HandlerThread引發的，那麼找到這個問題的位置，在合適的地方（如ondestroy）將這個handler thread釋放即可。

如下圖所示： 在android studio中打開生成的hprof文件，在右側邊欄會出現的Analyzer Tasks工具，點擊執行圖標，即可出現檢測分析的結果，得到哪些activity被泄漏了，這些被泄漏的activity被誰引用了。

可以看到內存泄漏由AsyncHandler引起，需要在activity生命周期結束的時候進行釋放。

方法2不用安裝MAT工具，更加便捷哦～

 有問題可以留言，謝謝您的閱讀～～

㈦ 使用ConnectivityManager的內存泄漏隱患

Android裡面內存泄漏問題最突出的就是Activity的泄漏，而泄漏的根源大多在於單例的使用，也就是一個靜態實例持有了Activity的引用。靜態變數的生命周期與應用（Application）是相同的，而鍵啟Activity生命周期通常比它短，也就會造成在Activity生命周期結束後，還被引用導致無法被系統回收釋放。

生成靜態引用內存泄漏可能有兩種情況：

這個主要講下系統級的情況，這樣的情況可能也有很多，舉個最近發現的問題ConnectivityManager。

通常我們獲取系統服務時採用如下方式：

在Android6.0系統上，如果這里的Context如果是Activity的實例，那麼即使你什麼也不幹也會造成內存泄漏。

用LeakCanary可以直接看到內存泄漏：

一步一步來分析下。

先從Context的getSystemService方法開始，我們知道Activity是從ContextWrapper繼承而來的，ContextWrapper中持有一個mBase實例，這個實例指向一個ContextImpl對象，同時ContextImpl對象持有一個OuterContext對象，對於Activity來說，這個OuterContext就是Activity對象。所以調用getSystemService最終會調用到ContextImpl的getSystemService方法。

在6.0上 ContextImpl 的getSystemService方法調用 SystemServiceRegistry 來完成。

SystemServiceRegistry提供ConnectivityManager的實例。

在6.0上， ConnectivityManager 實現為單例：

精彩的部分來了，ConnectivityManager 持慶亮賀有了一個Context的引用：

這個Context在ConnectivityManager 創建時傳入，這個Context在中由ContextImpl對象轉換為OuterContext，與就是Activity對象，所以最終ConnectivityManager的單實例持有了Activity的實例引用。這樣即使Activity退出後仍然無法釋放，導致譽派內存泄漏。

這個問題僅在6.0上出現，在5.1上ConnectivityManager實現為單例但不持有Context的引用，在5.0有以下版本ConnectivityManager既不為單例，也不持有Context的引用。

其他服務沒認真研究，不確定有沒有這個問題。不過為了避免類似的情況發生，最好的解決辦法就是：