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這個利器哈。