內(nèi)存泄漏定義
有些對(duì)象只有有限的生命周期。當(dāng)它們的任務(wù)完成之后，它們將被垃圾回收。如果在對(duì)象的生命周期本該結(jié)束的時(shí)候，這個(gè)對(duì)象還被一系列的引用，這就會(huì)導(dǎo)致內(nèi)存泄漏。隨著泄漏的累積，app將消耗完內(nèi)存。
內(nèi)存泄漏造成的影響
它是造成應(yīng)用程序OOM的主要原因之一。由于android系統(tǒng)為每個(gè)應(yīng)用程序分配的內(nèi)存有限，當(dāng)一個(gè)應(yīng)用中產(chǎn)生的內(nèi)存泄漏比較多時(shí)，就難免會(huì)導(dǎo)致應(yīng)用所需要的內(nèi)存超過這個(gè)系統(tǒng)分配的內(nèi)存限額，這就造成了內(nèi)存溢出而導(dǎo)致應(yīng)用Crash。
LeakCanary工具
leakCanary是Square開源框架，是一個(gè)Android和Java的內(nèi)存泄露檢測庫，如果檢測到某個(gè) activity 有內(nèi)存泄露，LeakCanary 就是自動(dòng)地顯示一個(gè)通知，所以可以把它理解為傻瓜式的內(nèi)存泄露檢測工具。通過它可以大幅度減少開發(fā)中遇到的oom問題，大大提高APP的質(zhì)量。
LeakCanary捕獲常見內(nèi)存泄漏以及解決辦法
1.）錯(cuò)誤使用單例造成的內(nèi)存泄漏
在平時(shí)開發(fā)中單例設(shè)計(jì)模式是我們經(jīng)常使用的一種設(shè)計(jì)模式，而在開發(fā)中單例經(jīng)常需要持有Context對(duì)象，如果持有的Context對(duì)象生命周期與單例生命周期更短時(shí)，或?qū)е翪ontext無法被釋放回收，則有可能造成內(nèi)存泄漏，錯(cuò)誤寫法如下：
public class LoginManager {
private static LoginManager mInstance;
private Context mContext;
private LoginManager(Context context) {
this.mContext = context;
}
public static LoginManager getInstance(Context context) {
if (mInstance == null) {
synchronized (LoginManager.class) {
if (mInstance == null) {
mInstance = new LoginManager(context);
}
}
}
return mInstance;
}
public void dealData() {
}
}
若我們?cè)谝粋€(gè)Activity中調(diào)用的，然后關(guān)閉該Activity則會(huì)出現(xiàn)內(nèi)存泄漏。
LoginManager.getInstance(this).dealData();
LeakCanary檢測結(jié)果如下：
解決 辦法要保證Context和AppLication的生命周期一樣，修改后代碼如下：
public class LoginManager {
private static LoginManager mInstance;
private Context mContext;
private LoginManager(Context context) {
//生命周期
this.mContext = context.getApplicationContext();
}
public static LoginManager getInstance(Context context) {
if (mInstance == null) {
synchronized (LoginManager.class) {
if (mInstance == null) {
mInstance = new LoginManager(context);
}
}
}
return mInstance;
}
public void dealData() {
}
}
2.）Handler造成的內(nèi)存泄漏
Handler的使用頻率還是蠻高的，它是工作線程與UI線程之間通訊的橋梁，只是現(xiàn)在大量開源框架對(duì)其進(jìn)行了封裝，我們這里模擬一種常見使用方式來模擬內(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_main);
mTextView = (TextView) findViewById(R.id.text);//模擬內(nèi)存泄露
mHandler.postDelayed(new Runnable() {
@Override
public void run() {
mTextView.setText("lcj");
}
}, 3 * 60 * 1000);
finish();
}
@Override
protected void onDestroy() {
super.onDestroy();
LApplication.getRefWatcher().watch(this);
}
}
上述代碼通過內(nèi)部類的方式創(chuàng)建mHandler對(duì)象,此時(shí)mHandler會(huì)隱式地持有一個(gè)外部類對(duì)象引用這里就是MainActivity，當(dāng)執(zhí)行postDelayed方法時(shí)，該方法會(huì)將你的Handler裝入一個(gè)Message，并把這條Message推到MessageQueue中，MessageQueue是在一個(gè)Looper線程中不斷輪詢處理消息，那么當(dāng)這個(gè)Activity退出時(shí)消息隊(duì)列中還有未處理的消息或者正在處理消息，而消息隊(duì)列中的Message持有mHandler實(shí)例的引用，mHandler又持有Activity的引用，所以導(dǎo)致該Activity的內(nèi)存資源無法及時(shí)回收，引發(fā)內(nèi)存泄漏。
LeakCanary檢測結(jié)果如下：
要想避免Handler引起內(nèi)存泄漏問題，需要我們?cè)贏ctivity關(guān)閉退出的時(shí)候的移除消息隊(duì)列中所有消息和所有的Runnable。上述代碼只需在onDestroy()函數(shù)中調(diào)用mHandler.removeCallbacksAndMessages(null);就行了。
public class MainActivity1 extends AppCompatActivity {
private Handler mHandler = new Handler();
private TextView mTextView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTextView = (TextView) findViewById(R.id.text);
//模擬內(nèi)存泄露
mHandler.postDelayed(new Runnable() {
@Override
public void run() {
mTextView.setText("lcj"); //主線程更新ui
}
}, 3 * 60 * 1000);
finish();
}
@Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
mHandler=null;
LApplication.getRefWatcher().watch(this);
}
}
handler基本使用 https://blog.csdn.net/ly502541243/article/details/52062179/
//handler內(nèi)存泄露的解決方案
方法一：通過程序邏輯來進(jìn)行保護(hù)。
1.在關(guān)閉Activity的時(shí)候停掉你的后臺(tái)線程。線程停掉了，就相當(dāng)于切斷了Handler和外部連接的線，Activity自然會(huì)在合適的時(shí)候被回收。
2.如果你的Handler是被delay的Message持有了引用，那么使用相應(yīng)的Handler的removeCallbacks()方法，把消息對(duì)象從消息隊(duì)列移除就行了。
方法二：將Handler聲明為靜態(tài)類。
PS:在Java 中，非靜態(tài)的內(nèi)部類和匿名內(nèi)部類都會(huì)隱式地持有其外部類的引用，靜態(tài)的內(nèi)部類不會(huì)持有外部類的引用。
靜態(tài)類不持有外部類的對(duì)象，所以你的Activity可以隨意被回收。由于Handler不再持有外部類對(duì)象的引用，導(dǎo)致程序不允許你在Handler中操作Activity中的對(duì)象了。所以你需要在Handler中增加一個(gè)對(duì)Activity的弱引用（WeakReference）。
static class MyHandler extends Handler
{
WeakReference<Activity> mWeakReference;
public MyHandler(Activity activity)
{
mWeakReference=new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg)
{
final Activity activity=mWeakReference.get();
if(activity!=null)
{
if (msg.what == 1)
{
noteBookAdapter.notifyDataSetChanged();
}
}
}
}
說明:
WeakReference弱引用，與強(qiáng)引用（即我們常說的引用）相對(duì)，它的特點(diǎn)是，GC在回收時(shí)會(huì)忽略掉弱引用，即就算有弱引用指向某對(duì)象，但只要該對(duì)象沒有被強(qiáng)引用指向（實(shí)際上多數(shù)時(shí)候還要求沒有軟引用，但此處軟引用的概念可以忽略），該對(duì)象就會(huì)在被GC檢查到時(shí)回收掉。對(duì)于上面的代碼，用戶在關(guān)閉Activity之后，就算后臺(tái)線程還沒結(jié)束，但由于僅有一條來自Handler的弱引用指向Activity，所以GC仍然會(huì)在檢查的時(shí)候把Activity回收掉。這樣，內(nèi)存泄露的問題就不會(huì)出現(xiàn)了。
2.)Activity 內(nèi)部類接口回調(diào)監(jiān)聽
在編碼中常常會(huì)定義各種接口回調(diào)，類似有點(diǎn)擊時(shí)間監(jiān)聽OnClickListener，這些回調(diào)監(jiān)聽有時(shí)候就定義在Activity內(nèi)部，或者直接用Activity對(duì)象去實(shí)現(xiàn)這個(gè)接口，到時(shí)候設(shè)置監(jiān)聽的時(shí)候直接調(diào)用setListener(innerListener)或者setListener(this)，innerListener是Activity內(nèi)部定義的，this就是Activity對(duì)象，那么問題來了，回調(diào)監(jiān)聽并不一定馬上返回，只有在觸發(fā)條件滿足的時(shí)候才會(huì)回調(diào)，這個(gè)時(shí)間是無法確定的，因此在Activity退出的時(shí)候應(yīng)該顯示的把回調(diào)監(jiān)聽都移除掉setListener(null)，既釋放了回調(diào)監(jiān)聽對(duì)象占用的內(nèi)存，也避免回調(diào)監(jiān)聽繼續(xù)持有activity引用；對(duì)與內(nèi)部類還有一種解決方式，和內(nèi)部Handler相似，定義成static內(nèi)部類，然后把Activity對(duì)象的弱引用傳遞進(jìn)去，這樣也就萬無一失
3.)線程造成的內(nèi)存泄漏
最早時(shí)期的時(shí)候處理耗時(shí)操作多數(shù)都是采用Thread+Handler的方式，后來逐步被AsyncTask取代，直到現(xiàn)在采用RxJava的方式來處理異步。這里以AsyncTask為例，可能大部分人都會(huì)這樣處理一個(gè)耗時(shí)操作然后通知UI更新結(jié)果：
public class MainActivity extends AppCompatActivity {
private AsyncTask<Void, Void, Integer> asyncTask;
private TextView mTextView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTextView = (TextView) findViewById(R.id.text);
testAsyncTask();
finish();
}
private void testAsyncTask() {
asyncTask = new AsyncTask<Void, Void, Integer>() {
@Override
protected Integer doInBackground(Void... params) {
int i = 0;
//模擬耗時(shí)操作
while (!isCancelled()) {
i++;
if (i > 1000000000) {
break;
}
Log.e("LeakCanary", "asyncTask---->" + i);
}
return i;
}
@Override
protected void onPostExecute(Integer integer) {
super.onPostExecute(integer);
mTextView.setText(String.valueOf(integer));
}
};
asyncTask.execute();
}
@Override
protected void onDestroy() {
super.onDestroy();
LApplication.getRefWatcher().watch(this);
}
}
對(duì)于上面的例子來說，在處理一個(gè)比較耗時(shí)的操作時(shí)，可能還沒處理結(jié)束MainActivity就執(zhí)行了退出操作，但是此時(shí)AsyncTask依然持有對(duì)MainActivity的引用就會(huì)導(dǎo)致MainActivity無法釋放回收引發(fā)內(nèi)存泄漏。
LeakCanary檢測結(jié)果：
如何解決這種內(nèi)存泄漏呢？在使用AsyncTask時(shí)，在Activity銷毀時(shí)候也應(yīng)該取消相應(yīng)的任務(wù)AsyncTask.cancel()方法，避免任務(wù)在后臺(tái)執(zhí)行浪費(fèi)資源，進(jìn)而避免內(nèi)存泄漏的發(fā)生。
public class MainActivity3 extends AppCompatActivity {
private AsyncTask<Void, Void, Integer> asyncTask;
private TextView mTextView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTextView = (TextView) findViewById(R.id.text);
testAsyncTask();
finish();
}
private void testAsyncTask() {
asyncTask = new AsyncTask<Void, Void, Integer>() {
@Override
protected Integer doInBackground(Void... params) {
int i = 0;
//模擬耗時(shí)操作
while (!isCancelled()) {
i++;
if (i > 1000000000) {
break;
}
Log.e("LeakCanary", "asyncTask---->" + i);
}
return i;
}
@Override
protected void onPostExecute(Integer integer) {
super.onPostExecute(integer);
mTextView.setText(String.valueOf(integer));
}
};
asyncTask.execute();
}
private void destroyAsyncTask() {
if (asyncTask != null && !asyncTask.isCancelled()) {
asyncTask.cancel(true);
}
asyncTask = null;
}
@Override
protected void onDestroy() {
super.onDestroy();
destroyAsyncTask();
LApplication.getRefWatcher().watch(this);
}
}
如果內(nèi)部線程的生命周期比Activity的生命周期要長，那么內(nèi)部線程任然默認(rèn)持有Activity的引用，導(dǎo)致Activity對(duì)象無法被回收，但是當(dāng)這個(gè)線程執(zhí)行完了之后，Activity對(duì)象就能被成功的回收了，這會(huì)造成一個(gè)崩潰風(fēng)險(xiǎn)，可能在線程里面有調(diào)用到一些Activity的內(nèi)部對(duì)象，但是在Activity退出后這些對(duì)象有可能有些已經(jīng)被回收了，就變成null了，這時(shí)候要是不進(jìn)行null的判斷就會(huì)報(bào)空指針異常，如果這個(gè)線程是一直跑的，那就會(huì)造成Activity對(duì)象一直不會(huì)被回收了，因此，在activity退出后一定要做相關(guān)的清理操作，中斷線程，取消網(wǎng)絡(luò)請(qǐng)求等等
4.）非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實(shí)例造成的內(nèi)存泄漏
%注意:靜態(tài)變量的生命周期和應(yīng)用程序一致%
我們先來看看非靜態(tài)內(nèi)部類（non static inner class）和 靜態(tài)內(nèi)部類（static inner class）之間的區(qū)別。
可以看到非靜態(tài)內(nèi)部類自動(dòng)獲得外部類的強(qiáng)引用，而且它的生命周期甚至比外部類更長，這便埋下了內(nèi)存泄露的隱患。如果一個(gè) Activity 的非靜態(tài)內(nèi)部類的生命周期比 Activity 更長，那么 Activity 的內(nèi)存便無法被回收，也就是發(fā)生了內(nèi)存泄露，而且還有可能發(fā)生難以預(yù)防的空指針問題。
有時(shí)我們需要一個(gè)可以隨著屏幕旋轉(zhuǎn)的Activity，比如視頻播放Activity，這時(shí)我們?yōu)榱朔乐苟啻握{(diào)用onCreate方法導(dǎo)致某些參數(shù)重新初始化，我們一般會(huì)選擇創(chuàng)建一個(gè)內(nèi)部類和一個(gè)靜態(tài)實(shí)例來保存這些參數(shù)，比如以下實(shí)現(xiàn)：
public class MainActivity extends AppCompatActivity {
private static Config mConfig;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//模擬內(nèi)存泄露
if (mConfig == null) {
mConfig = new Config();
mConfig.setSize(18);
mConfig.setTitle("老九門");
}
finish();
}
@Override
protected void onDestroy() {
super.onDestroy();
LApplication.getRefWatcher().watch(this);
}
class Config {
private int size;
private String title;
public int getSize() {
return size;
}
public void setSize(int size) {
this.size = size;
}
public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
}
}
上述代碼看著沒有任何問題，其實(shí)內(nèi)部類都會(huì)持有一個(gè)外部類引用，這里這個(gè)外部類就是MainActivity，然而內(nèi)部類實(shí)例又是static靜態(tài)變量其生命周期與Application生命周期一樣，所以在MainActivity關(guān)閉的時(shí)候，內(nèi)部類靜態(tài)實(shí)例依然持有對(duì)MainActivity的引用，導(dǎo)致MainActivity無法被回收釋放，引發(fā)內(nèi)存泄漏。LeakCanary檢測內(nèi)存泄漏結(jié)果如下：
對(duì)于這種泄漏的解決辦法就是將內(nèi)部類改成靜態(tài)內(nèi)部類，不再持有對(duì)MainActivity的引用即可，修改后的代碼如下：
public class MainActivity extends AppCompatActivity {
private static Config mConfig;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//模擬內(nèi)存泄露
if (mConfig == null) {
mConfig = new Config();
mConfig.setSize(18);
mConfig.setTitle("老九門");
}
finish();
}
@Override
protected void onDestroy() {
super.onDestroy();
LApplication.getRefWatcher().watch(this);
}
static class Config {
private int size;
private String title;
public int getSize() {
return size;
}
public void setSize(int size) {
this.size = size;
}
public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
}
}
5.）由WebView引起的內(nèi)存泄漏
在目前的開發(fā)中多多少少會(huì)用到Hybrid開發(fā)方式，這樣我們就會(huì)用WebView去承載Html網(wǎng)頁，就如下面這種方式：
java代碼：
public class MainActivity5 extends AppCompatActivity {
private WebView mWebView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_web);
mWebView = (WebView) findViewById(R.id.web);
mWebView.loadUrl("http://www.cnblogs.com/whoislcj/p/5720202.html");
}
@Override
protected void onDestroy() {
super.onDestroy();
LApplication.getRefWatcher().watch(this);
}
}
WebView解析網(wǎng)頁時(shí)會(huì)申請(qǐng)Native堆內(nèi)存用于保存頁面元素，當(dāng)頁面較復(fù)雜時(shí)會(huì)有很大的內(nèi)存占用。如果頁面包含圖片，內(nèi)存占用會(huì)更嚴(yán)重。并且打開新頁面時(shí)，為了能快速回退，之前頁面占用的內(nèi)存也不會(huì)釋放。有時(shí)瀏覽十幾個(gè)網(wǎng)頁，都會(huì)占用幾百兆的內(nèi)存。這樣加載網(wǎng)頁較多時(shí)，會(huì)導(dǎo)致系統(tǒng)不堪重負(fù)，最終強(qiáng)制關(guān)閉應(yīng)用，也就是出現(xiàn)應(yīng)用閃退或重啟。及時(shí)Activity關(guān)閉時(shí)在onDestroy中調(diào)用如下代碼也是沒有任何作用。
private void destroyWebView() {
if (mWebView != null) {
mLinearLayout.removeView(mWebView);
mWebView.pauseTimers();
mWebView.removeAllViews();
mWebView.destroy();
mWebView = null;
}
}
先看下LeakCanary檢測到的結(jié)果如下：
該如何解決呢？這個(gè)查了不少資料，其中一種就是使用getApplicationgContext作為參數(shù)構(gòu)建WebView，然后動(dòng)態(tài)添加到一個(gè)ViewGroup中，最后退出的時(shí)候調(diào)用webView的銷毀的函數(shù)，雖然也達(dá)到了防止內(nèi)存溢出的效果，但是在有些網(wǎng)頁彈出時(shí)候需要記住密碼的對(duì)話框的時(shí)候，會(huì)出現(xiàn)Unable to add window -- token null is not for an application 的錯(cuò)誤，所以這里采用的解決辦法是通過把使用了WebView的Activity(或者Service)放在單獨(dú)的進(jìn)程里。然后在檢測到應(yīng)用占用內(nèi)存過大有可能被系統(tǒng)干掉或者它所在的Activity(或者Service)結(jié)束后，調(diào)用android.os.Process.killProcess(android.os.Process.myPid());，主動(dòng)Kill掉進(jìn)程。由于系統(tǒng)的內(nèi)存分配是以進(jìn)程為準(zhǔn)的，進(jìn)程關(guān)閉后，系統(tǒng)會(huì)自動(dòng)回收所有內(nèi)存。
修改后的代碼如下：
public class MainActivity5 extends AppCompatActivity {
private WebView mWebView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_web);
mWebView = (WebView) findViewById(R.id.web);
mWebView.loadUrl("http://www.cnblogs.com/whoislcj/p/5720202.html");
}
@Override
protected void onDestroy() {
destroyWebView();
android.os.Process.killProcess(android.os.Process.myPid());
super.onDestroy();
LApplication.getRefWatcher().watch(this);
}
private void destroyWebView() {
if (mWebView != null) {
mWebView.pauseTimers();
mWebView.removeAllViews();
mWebView.destroy();
mWebView = null;
}
}
}
6.）資源未關(guān)閉造成的內(nèi)存泄漏
對(duì)于使用了BraodcastReceiver，ContentObserver，F(xiàn)ile，Cursor，Stream，Bitmap等資源的使用，應(yīng)該在Activity銷毀時(shí)及時(shí)關(guān)閉或者注銷，否則這些資源將不會(huì)被回收，造成內(nèi)存泄漏。例如獲取媒體庫圖片地址代碼在查詢結(jié)束的時(shí)候一定要調(diào)用
Cursor 的關(guān)閉方法防止造成內(nèi)存泄漏。
String columns[] = new String[]{
MediaStore.Images.Media.DATA, MediaStore.Images.Media._ID, MediaStore.Images.Media.TITLE, MediaStore.Images.Media.DISPLAY_NAME
};
Cursor cursor = this.getContentResolver().query(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, columns, null, null, null);
if (cursor != null) {
int photoIndex = cursor.getColumnIndexOrThrow(MediaStore.Images.Media.DATA);
//顯示每張圖片的地址，但是首先要判斷一下，Cursor是否有值
while (cursor.moveToNext()) {
String photoPath = cursor.getString(photoIndex); //這里獲取到的就是圖片存儲(chǔ)的位置信息
Log.e("LeakCanary", "photoPath---->" + photoPath);
}
cursor.close();
}
7.）集合類
集合類添加元素后，仍引用著集合元素對(duì)象，導(dǎo)致該集合中的元素對(duì)象無法被回收，從而導(dǎo)致內(nèi)存泄露，舉個(gè)例子：
static List<Object> objectList = new ArrayList<>();
for (int i = 0; i < 10; i++) {
Object obj = new Object();
objectList.add(obj);
obj = null;
}
在這個(gè)例子中，循環(huán)多次將 new 出來的對(duì)象放入一個(gè)靜態(tài)的集合中，因?yàn)殪o態(tài)變量的生命周期和應(yīng)用程序一致，而且他們所引用的對(duì)象 Object 也不能釋放，這樣便造成了內(nèi)存泄露。
解決方法:
在集合元素使用之后從集合中刪除，等所有元素都使用完之后，將集合置空。
objectList.clear();
objectList = null;
