1.靜態變量造成的內存泄漏
public class MainActivity extends Activity{
private static final String TAG = "MainActivity";
private static Context sContext;
private static View sView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//這里直接把當前Activity賦值給了靜態變量sContext
sContext = this;
//這種寫法和上面的類似
sView = new View(this);
}
}
當MainActivity對象完成任務需要回收時，卻有一個靜態變量引用它(靜態變量的生命周期與Application相同)，造成內存泄漏
2.單例模式造成的內存泄漏
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;
}
}
我們來分析下為什么會產生內存泄漏呢？
AppManager appManager=AppManager.getInstance(this);
這句傳入的是Activity的Context，我們都知道，Activty是間接繼承于Context的，當這Activity退出時，Activity應該被回收， 但是單例中又持有它的引用，導致Activity回收失敗，造成內存泄漏。為了以防誤傳Activity的Context , 我們可以修改一下單例的代碼，如下：
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，最終都會使用Applicaton的Context，而我們單例的生命周期和應用的一樣長，這樣就防止了內存泄漏。
3.非靜態內部類創建靜態實例造成的內存泄漏
public class NonStaticActivity extends AppCompatActivity {
private static Config sConfig;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_non_static);
//Config類并不是靜態類，
sConfig = new Config();
}
class Config {
}
}
首先，非靜態內部類默認會持有外部類的引用。
然后又使用了該非靜態內部類創建了一個靜態的實例。
該靜態實例的生命周期和應用的一樣長，這就導致了該靜態實例一直會持有該Activity的引用，導致Activity的內存資源不能正常回收。
正確的做法有兩種，一種是將內部類Config改成靜態內部類，還有就是將Config抽取出來，封裝成一個單例，如上一個例子那樣，但是需要context時單例要切記注意Context的泄漏，使用applicationContext。
4.WebView造成的內存泄漏
即使當我退出頁面時在我的BrowserActivity的onDestroy()方法中進行內存占用回收但并沒有效果：
mWebView.removeAllViews();
mWebView.destroy();
mWebView=null;
當我點開了多少條新聞內存中就存在多少個BrowserActivity的實例，說明我退出時這個BrowserActivity沒有被回收，這樣的話當我瀏覽的新聞比較多時，內存就會累積存在一定的OOM風險，而且新聞界面一般存在大量圖片，所以這個問題是必須要解決的。
a. 不要在.xml文件中定義webview節點
不要再布局文件中定義webview的節點，而是在需要的時候動態生成。你可以在需要webview的布局位置放一個LinearLayout，需要時在代碼中動態生成webview并add進去：
mWebView=new WebView(this);
LinearLayout linearLayout = findViewById(R.id.xxx);
linearLayout.addView(mWebView);
然后在onDestroy()方法中調用：
@Override
protected void onDestroy() {
if( mWebView!=null) {
mWebView.setVisibility(View.GONE);
mWebView.removeAllViews();
mWebView.destroy();
}
super.onDestroy();
}
關于創建webview時mWebView=new WebView(this);到底是傳入ApplicationContext還是Activity的context：個人建議還是傳activity的context。傳ApplicationContext貌似可以防止webview對activity的引用，但是在很多情況下會報錯,很多都有說到webview加載的頁面彈出dialog時會出現報錯；所以傳入activity的context然后做好銷毀工作。
b. 手動刪除引用
這個方法在我的項目中沒有效果，但原文博主說在他的項目中效果很好，也許對其他人的情況有效，在這里也記下來。
public void setConfigCallback(WindowManager windowManager) {
try {
Field field = WebView.class.getDeclaredField("mWebViewCore");
field = field.getType().getDeclaredField("mBrowserFrame");
field = field.getType().getDeclaredField("sConfigCallback");
field.setAccessible(true);
Object configCallback = field.get(null);
if (null == configCallback) {
return;
}
field = field.getType().getDeclaredField("mWindowManager");
field.setAccessible(true);
field.set(configCallback, windowManager);
} catch(Exception e) {
}
}
然后在activity中調用：
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setConfigCallback(WindowManager)getApplicationContext().getSystemService(Context.WINDOW_SERVICE));
}
public void onDestroy() {
setConfigCallback(null);
super.onDestroy();
}
c. 進程
為加載WebView的界面開啟新進程，在該頁面退出之后關閉這個進程。
這個方法我沒有測試，不知道應用和效果如何，有興趣的可以試試。
d.從根源解決（劃重點）
前面的方法都沒有解決我內存泄漏的問題，然后我看到了一篇文章是從源碼角度分析了webview內存泄漏的原因，最后按作者的方法解決了問題，后面會貼上原文地址。這里簡單說一下：
原文里說的webview引起的內存泄漏主要是因為org.chromium.android_webview.AwContents 類中注冊了component callbacks，但是未正常反注冊而導致的。
org.chromium.android_webview.AwContents 類中有這兩個方法 onAttachedToWindow 和 onDetachedFromWindow；系統會在attach和detach處進行注冊和反注冊component callback；
在onDetachedFromWindow() 方法的第一行中：
if (isDestroyed()) return;
如果 isDestroyed() 返回 true 的話，那么后續的邏輯就不能正常走到，所以就不會執行unregister的操作；我們的activity退出的時候，都會主動調用 WebView.destroy() 方法，這會導致 isDestroyed() 返回 true；destroy()的執行時間又在onDetachedFromWindow之前，所以就會導致不能正常進行unregister()。
然后解決方法就是：
讓onDetachedFromWindow先走，在主動調用destroy()之前，把webview從它的parent上面移除掉。
ViewParent parent = mWebView.getParent();
if (parent != null) {
((ViewGroup) parent).removeView(mWebView);
}
mWebView.destroy();
完整的activity的onDestroy()方法：
@Override
protected void onDestroy() {
if( mWebView!=null) {
// 如果先調用destroy()方法，則會命中if (isDestroyed()) return;這一行代碼，需要先onDetachedFromWindow()，再
// destory()
ViewParent parent = mWebView.getParent();
if (parent != null) {
((ViewGroup) parent).removeView(mWebView);
}
mWebView.stopLoading();
// 退出時調用此方法，移除綁定的服務，否則某些特定系統會報錯
mWebView.getSettings().setJavaScriptEnabled(false);
mWebView.clearHistory();
mWebView.clearView();
mWebView.removeAllViews();
mWebView.destroy();
}
super.on Destroy();
}
這個方法親測有效。
5.Handler造成的內存泄漏
我在我的項目中使用了handler，此時mHandler會隱式地持有一個外部類對象引用這里就是MainActivity，當執行postDelayed方法時，該方法會將你的Handler裝入一個Message，并把這條Message推到MessageQueue中，MessageQueue是在一個Looper線程中不斷輪詢處理消息，那么當這個Activity退出時消息隊列中還有未處理的消息或者正在處理消息，而消息隊列中的Message持有mHandler實例的引用，mHandler又持有Activity的引用，所以導致該Activity的內存資源無法及時回收，引發內存泄漏。
public class MainActivity extends AppCompatActivity {
private Handler mHandler = new Handler();
private TextView mTextView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler);
mTextView = (TextView) findViewById(R.id.text);//模擬內存泄露
mHandler.postDelayed(new Runnable() {
@Override
public void run() {
mTextView.setText("test");
}
}, 5 * 60 * 1000);
}
}
解決辦法是 在HandlerActivity onDestroy里面移除消息隊列中所有消息和所有的Runnable。
@Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
mHandler = null;
}
其他原因造成的內存泄漏
造成內存泄漏的原因有很多，我們這里只是列舉了其中比較典型的幾種，當然還有好多原因會造成內存泄漏，比如資源開啟但是未關閉、多線程等等等等。但是我們有LeakCanary這個利器哈。
