分析Android常見的內存泄露和解決方案
目前 java 垃圾回收主流算法是虛擬機采用 GC Roots Tracing 算法。算法的基本思路是：通過一系列的名為 GC Roots （GC 根節點）的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑，當一個對象到GC Roots沒有任何引用鏈相連（圖論說：從GC Roots 到這個對象不可達）時， 證明此對象是不可用的。
關于可達性的對象，便是能與 GC Roots 構成連通圖的對象，如下圖：
根搜索算法的基本思路就是通過一系列名為 'GC Roots' 的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑稱為引用鏈 ( Reference Chain)，當一個對象到 GC Roots 沒有任何引用鏈相連時，則證明此對象是不可用的。
從上圖，reference1、reference2、reference3 都是 GC Roots，可以看出：
reference1-> 對象實例1；
reference2-> 對象實例2；
reference3-> 對象實例4；
reference3-> 對象實例4 -> 對象實例6；
可以得出對象實例1、2、4、6都具有 GC Roots 可達性，也就是存活對象，不能被 GC 回收的對象。
而對于對象實例3、5直接雖然連通，但并沒有任何一個 GC Roots 與之相連，這便是 GC Roots 不可達的對象，這就是 GC 需要回收的垃圾對象。
在了解 GC 之后，開始去了解 Android 的內存泄露情況了。
二、Android 內存泄露場景下面會詳細介紹一些常見的內存泄露場景，以及對應的修復辦法。
2.1、非靜態內部類的靜態實例比如我們在 Activity 內部定義了一個內部類InnerClass，同時定義了一個靜態變量inner，并給予賦值。假設你在 onDestory 的時候沒有將 inner 置 null；那么就會引起內存泄露。原因是靜態變量持有了內部類的實例，內部類會對外部類有個引用，從而導致 Activity 得不到釋放。
private static Object inner;void createInnerClass() { class InnerClass { } inner = new InnerClass();}View icButton = findViewById(R.id.ic_button); icButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) {createInnerClass();nextActivity(); }});
記得在生命周期結束的時候，將不需要的靜態變量置 null。
2.2、多線程相關的匿名內部類/非靜態內部類和非靜態內部類一樣，匿名內部類也會持有外部類實例的引用。多線程相關的類有 AsyncTask 類，Thread 類和 Runnable 接口的類等，它們的匿名內部類如果做耗時操作
就可能發生內存泄露，這里以 AsyncTask 的匿名內部類舉例，如下所示：
void startAsyncTask() { new AsyncTask<Void, Void, Void>() {@Override protected Void doInBackground(Void... params) { while(true);} }.execute();}super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);View aicButton = findViewById(R.id.at_button);aicButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) {startAsyncTask();nextActivity(); }});
當異步任務在后臺執行耗時任務期間，Activity 不幸被銷毀了（比如：用戶退出，系統回收），這個被 AsyncTask 持有的 Activity 實例就不會被垃圾回收器回收，直到異步任務結束。
解決方法是繼承 AsyncTask 新建一個靜態內部類，用靜態內部類創建實例就不會存在對外部實例的引用了。
2.3、Handler 內存泄露同樣道理，Handler 的 message 被傳遞到消息隊列MessageQueue中，在Message消息沒有被處理之前，handler 的實例也不無法被回收，如果 handler 實例不是靜態的，就會導致引用它的 activity 或者 service 不能被回收，于是就會發生內存泄漏。
void createHandler() { new Handler() {@Override public void handleMessage(Message message) { super.handleMessage(message);} }.sendMessageDelayed(Message.obtain(), 60000);}View hButton = findViewById(R.id.h_button);hButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) {createHandler();nextActivity(); }});
對于上述問題，有兩種解決辦法，一種是使用一個靜態的 handler 內部類，并且其持有的對象都改成弱引用形式進行引用。還有一種是在銷毀 activity 的時候，將發送的消息進行移除。
myHandler.removeCallbackAndMessages(null);
這種有個問題就是 Handler 中的消息可能無法全部被處理完。
另外還有一個要注意的是，最好不要直接使用 View#post 來做一些操作。如果要用，確保要用的話，確保 view 已經被 attach 到了 window。
2.4、靜態 Activity 或 View在類中定義了靜態Activity變量，把當前運行的Activity實例賦值于這個靜態變量。如果這個靜態變量在Activity生命周期結束后沒有清空，就導致內存泄漏。因為 static 變量是貫穿這個應用的生命周期的，所以被泄漏的Activity就會一直存在于應用的進程中，不會被垃圾回收器回收。
static Activity activity;void setStaticActivity() { activity = this;}View saButton = findViewById(R.id.sa_button);saButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { setStaticActivity(); nextActivity(); }});
為了能夠被回收，需要在不需要使用的時候進行置 null 操作。比如銷毀當前 activity 的時候。
特殊情況：如果一個 View 初始化耗費大量資源，而且在一個Activity生命周期內保持不變，那可以把它變成 static，加載到視圖樹上 (View Hierachy)，像這樣，當Activity被銷毀時，應當釋放資源。
static view;void setStaticView() { view = findViewById(R.id.sv_button);}View svButton = findViewById(R.id.sv_button);svButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { setStaticView(); nextActivity(); }});
同樣的，為了解決內存泄露的問題，在 Activity 銷毀的時候把這個 static view 置 null 即可，但是還是不建議用這個 static view的方法。
2.5、Eventbus 等注冊監聽造成的內存泄露相信很多同學都在項目里面會用到 Eventbus。對于一些沒有經驗的同學在使用的時候經常會出現一些問題。比如說在 onCreate 的時候進行注冊，卻忘了反注冊，或者說，在onStop的時候進行反注冊，這些都會導致 Eventbus 的內存泄露。
@Overridepublic void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); EventBus.getDefault().register(this);// 注意在onCreate()方法中注冊}@Overridepublic void onDestroy() { EventBus.getDefault().unregister(this);// 注意在onDestory()方法中注冊 super.onDestroy();}
注冊和反注冊（取消注冊）是對應的，必須要添加，否則會引起組件的內存泄漏。因為注冊的時候組件是被 EventBus 內部的單例隊列所持有引用的。
如果你是在 View 里面注冊 Eventbus 的，記得是在 View 的生命周期 onAttachedToWindow 和 onDetachedFromWindow 的時候進行注冊和反注冊。
最近跟我的同事進行聊天的時候發現，他們為了解決 eventbus 導致的內存泄露問題（已經成對注冊和反注冊還是存在內存泄露問題），于是打算創建一個 object 的實例，用這個來進行注冊與反注冊，這樣即使發生內存泄露也只會占用很小的內存空間。
2.6、單例引起的內存泄露項目中，經常會存在很多單例。有時候需要我們將當前 Activity 實例傳給單例，然后去做一些事情。如下面的代碼：
public class SingleInstance { private Context mContext; private static SingleInstance instance; private SingleInstance(Context context) {this.mContext = context; } public static SingleInstance getInstance(Context context) {if (instance == null) { instance = new SingleInstance(context);}return instance; }}
上述單例中傳入一個 context ，就會導致 context 的生命時長和應用的生命時長一樣。就會造成內存泄露。
對于這種有三種解決辦法：
1、采用弱引用的方式進行引用，確保能夠被回收；
2、在對應的 context 要被銷毀的時候，進行置 null；確保不會長于原本的生命時長；
3、看是否能夠使用 APP context；這樣就不會存在內存泄露的問題了。
2.7、資源對象沒關閉造成內存泄漏當我們打開資源時，一般都會使用緩存。比如讀寫文件資源、打開數據庫資源、使用 Bitmap 資源等等。當我們不再使用時，應該關閉它們，使得緩存內存區域及時回收。雖然有些對象，如果我們不去關閉，它自己在 finalize() 函數中會自行關閉。但是這得等到 GC 回收時才關閉，這樣會導致緩存駐留一段時間。如果我們頻繁的打開資源，內存泄漏帶來的影響就比較明顯了。
解決辦法：及時關閉資源
2.8、WebView不同的Android 版本的 webView 會有差異，加上不同的廠商定制的 ROM 的 webView 差異，這就導致 webView 存在很大的兼容性問題。weView 都會存在內存泄露問題，在應用中只要使用一次，內存就不會被釋放。通常的做法是為 webView 單獨開一個進程，使用 AIDL 與應用的主進程進程通信。webView 進程可以根據業務的需求，在合適的時機進行銷毀。
以上就是分析Android常見的內存泄露和解決方案的詳細內容，更多關于Android 內存泄露和解決方案的資料請關注好吧啦網其它相關文章！
相關文章：
網公網安備