1.靜態(tài)變量造成的內(nèi)存泄漏
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賦值給了靜態(tài)變量sContext
sContext = this;
//這種寫法和上面的類似
sView = new View(this);
}
}
當MainActivity對象完成任務(wù)需要回收時，卻有一個靜態(tài)變量引用它(靜態(tài)變量的生命周期與Application相同)循头，造成內(nèi)存泄漏
2.單例模式造成的內(nèi)存泄漏
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;
}
}
我們來分析下為什么會產(chǎn)生內(nèi)存泄漏呢齿椅？
AppManager appManager=AppManager.getInstance(this);
這句傳入的是Activity的Context锭部，我們都知道筛圆，Activty是間接繼承于Context的捏顺，當這Activity退出時六孵，Activity應(yīng)該被回收， 但是單例中又持有它的引用幅骄，導(dǎo)致Activity回收失敗劫窒，造成內(nèi)存泄漏。為了以防誤傳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;
}
}
這樣子修改主巍，不管外面?zhèn)魅胧裁碈ontext，最終都會使用Applicaton的Context挪凑，而我們單例的生命周期和應(yīng)用的一樣長孕索，這樣就防止了內(nèi)存泄漏。
3.非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實例造成的內(nèi)存泄漏
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類并不是靜態(tài)類躏碳，
sConfig = new Config();
}
class Config {
}
}
首先搞旭，非靜態(tài)內(nèi)部類默認會持有外部類的引用。
然后又使用了該非靜態(tài)內(nèi)部類創(chuàng)建了一個靜態(tài)的實例菇绵。
該靜態(tài)實例的生命周期和應(yīng)用的一樣長肄渗，這就導(dǎo)致了該靜態(tài)實例一直會持有該Activity的引用，導(dǎo)致Activity的內(nèi)存資源不能正骋ё睿回收翎嫡。
正確的做法有兩種，一種是將內(nèi)部類Config改成靜態(tài)內(nèi)部類永乌，還有就是將Config抽取出來钝的，封裝成一個單例翁垂，如上一個例子那樣，但是需要context時單例要切記注意Context的泄漏硝桩，使用applicationContext沿猜。
4.WebView造成的內(nèi)存泄漏
即使當我退出頁面時在我的BrowserActivity的onDestroy()方法中進行內(nèi)存占用回收但并沒有效果：
mWebView.removeAllViews();
mWebView.destroy();
mWebView=null;
當我點開了多少條新聞內(nèi)存中就存在多少個BrowserActivity的實例，說明我退出時這個BrowserActivity沒有被回收碗脊，這樣的話當我瀏覽的新聞比較多時啼肩，內(nèi)存就會累積存在一定的OOM風險，而且新聞界面一般存在大量圖片衙伶，所以這個問題是必須要解決的祈坠。
a. 不要在.xml文件中定義webview節(jié)點
不要再布局文件中定義webview的節(jié)點，而是在需要的時候動態(tài)生成矢劲。你可以在需要webview的布局位置放一個LinearLayout赦拘，需要時在代碼中動態(tài)生成webview并add進去：
mWebView=new WebView(this);
LinearLayout linearLayout = findViewById(R.id.xxx);
linearLayout.addView(mWebView);
然后在onDestroy()方法中調(diào)用：
@Override
protected void onDestroy() {
if( mWebView!=null) {
mWebView.setVisibility(View.GONE);
mWebView.removeAllViews();
mWebView.destroy();
}
super.onDestroy();
}
關(guān)于創(chuàng)建webview時mWebView=new WebView(this);到底是傳入ApplicationContext還是Activity的context：個人建議還是傳activity的context。傳ApplicationContext貌似可以防止webview對activity的引用芬沉，但是在很多情況下會報錯,很多都有說到webview加載的頁面彈出dialog時會出現(xiàn)報錯躺同；所以傳入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中調(diào)用：
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setConfigCallback(WindowManager)getApplicationContext().getSystemService(Context.WINDOW_SERVICE));
}
public void onDestroy() {
setConfigCallback(null);
super.onDestroy();
}
c. 進程
為加載WebView的界面開啟新進程，在該頁面退出之后關(guān)閉這個進程憔维。
這個方法我沒有測試涛救，不知道應(yīng)用和效果如何，有興趣的可以試試业扒。
d.從根源解決（劃重點）
前面的方法都沒有解決我內(nèi)存泄漏的問題检吆，然后我看到了一篇文章是從源碼角度分析了webview內(nèi)存泄漏的原因，最后按作者的方法解決了問題凶赁，后面會貼上原文地址咧栗。這里簡單說一下：
原文里說的webview引起的內(nèi)存泄漏主要是因為org.chromium.android_webview.AwContents 類中注冊了component callbacks逆甜，但是未正常反注冊而導(dǎo)致的虱肄。
org.chromium.android_webview.AwContents 類中有這兩個方法 onAttachedToWindow 和 onDetachedFromWindow；系統(tǒng)會在attach和detach處進行注冊和反注冊component callback交煞；
在onDetachedFromWindow() 方法的第一行中：
if (isDestroyed()) return;
如果 isDestroyed() 返回 true 的話咏窿，那么后續(xù)的邏輯就不能正常走到，所以就不會執(zhí)行unregister的操作素征；我們的activity退出的時候集嵌，都會主動調(diào)用 WebView.destroy() 方法萝挤，這會導(dǎo)致 isDestroyed() 返回 true；destroy()的執(zhí)行時間又在onDetachedFromWindow之前根欧，所以就會導(dǎo)致不能正常進行unregister()怜珍。
然后解決方法就是：
讓onDetachedFromWindow先走，在主動調(diào)用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) {
// 如果先調(diào)用destroy()方法，則會命中if (isDestroyed()) return;這一行代碼嫌拣，需要先onDetachedFromWindow()柔袁，再
// destory()
ViewParent parent = mWebView.getParent();
if (parent != null) {
((ViewGroup) parent).removeView(mWebView);
}
mWebView.stopLoading();
// 退出時調(diào)用此方法，移除綁定的服務(wù)异逐，否則某些特定系統(tǒng)會報錯
mWebView.getSettings().setJavaScriptEnabled(false);
mWebView.clearHistory();
mWebView.clearView();
mWebView.removeAllViews();
mWebView.destroy();
}
super.on Destroy();
}
這個方法親測有效捶索。
5.Handler造成的內(nèi)存泄漏
我在我的項目中使用了handler，此時mHandler會隱式地持有一個外部類對象引用這里就是MainActivity灰瞻，當執(zhí)行postDelayed方法時仇祭，該方法會將你的Handler裝入一個Message弦撩，并把這條Message推到MessageQueue中，MessageQueue是在一個Looper線程中不斷輪詢處理消息，那么當這個Activity退出時消息隊列中還有未處理的消息或者正在處理消息论咏，而消息隊列中的Message持有mHandler實例的引用，mHandler又持有Activity的引用怖辆，所以導(dǎo)致該Activity的內(nèi)存資源無法及時回收浅辙，引發(fā)內(nèi)存泄漏。
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);//模擬內(nèi)存泄露
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;
}
其他原因造成的內(nèi)存泄漏
造成內(nèi)存泄漏的原因有很多捐凭，我們這里只是列舉了其中比較典型的幾種，當然還有好多原因會造成內(nèi)存泄漏凳鬓，比如資源開啟但是未關(guān)閉茁肠、多線程等等等等。但是我們有LeakCanary這個利器哈缩举。
