by hzwusibo? 20190504
前言
LeakCanary舵变、MAT等工具來檢測應(yīng)用程序是否存在內(nèi)存泄漏，MAT是一款強大的內(nèi)存分析工具，功能繁多而復(fù)雜观蓄，而LeakCanary則是由Square開源的一款輕量第三方內(nèi)存泄漏檢測工具混移，當(dāng)它檢測到程序中有內(nèi)存泄漏的產(chǎn)生時，它將以最直觀的方式告訴我們該內(nèi)存泄漏是由誰產(chǎn)生的和該內(nèi)存泄漏導(dǎo)致誰泄漏了而不能回收侮穿，供我們復(fù)查歌径。
為什么會產(chǎn)生內(nèi)存泄漏？
當(dāng)一個對象已經(jīng)不需要再使用了亲茅，本該被回收時回铛，而有另外一個正在使用的對象持有它的引用從而導(dǎo)致它不能被回收，這導(dǎo)致本該被回收的對象不能被回收而停留在堆內(nèi)存中克锣，這就產(chǎn)生了內(nèi)存泄漏茵肃。
內(nèi)存泄漏對程序的影響？
內(nèi)存泄漏是造成應(yīng)用程序OOM的主要原因之一袭祟！我們知道Android系統(tǒng)為每個應(yīng)用程序分配的內(nèi)存有限验残，而當(dāng)一個應(yīng)用中產(chǎn)生的內(nèi)存泄漏比較多時，這就難免會導(dǎo)致應(yīng)用所需要的內(nèi)存超過這個系統(tǒng)分配的內(nèi)存限額巾乳，這就造成了內(nèi)存溢出而導(dǎo)致應(yīng)用Crash您没。
Android中常見的內(nèi)存泄漏匯總
單例造成的內(nèi)存泄漏
由于單例的靜態(tài)特性使得單例的生命周期和應(yīng)用的生命周期一樣長，這就說明了如果一個對象已經(jīng)不需要使用了胆绊，而單例對象還持有該對象的引用氨鹏，那么這個對象將不能被正常回收压状，這就導(dǎo)致了內(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;
? ? }
}
這樣不管傳入什么Context最終將使用Application的Context，而單例的生命周期和應(yīng)用的一樣長种冬，這樣就防止了內(nèi)存泄漏
非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實例造成的內(nèi)存泄漏
有的時候我們可能會在啟動頻繁的Activity中镣丑，為了避免重復(fù)創(chuàng)建相同的數(shù)據(jù)資源，可能會出現(xiàn)這種寫法：
public class MainActivity extends AppCompatActivity {
? ? private static TestResource mResource = null;
? ? @Override
? ? protected void onCreate(Bundle savedInstanceState) {
? ? ? ? super.onCreate(savedInstanceState);
? ? ? ? setContentView(R.layout.activity_main);
? ? ? ? if(mResource == null){
? ? ? ? ? ? mResource = new TestResource();
? ? ? ? }
? ? ? ? //...
? ? }
? ? class TestResource {
? ? //...
? ? }
}
因為非靜態(tài)內(nèi)部類默認會持有外部類的引用碌廓，而又使用了該非靜態(tài)內(nèi)部類創(chuàng)建了一個靜態(tài)的實例传轰，該實例的生命周期和應(yīng)用的一樣長，這就導(dǎo)致了該靜態(tài)實例一直會持有該Activity的引用谷婆，導(dǎo)致Activity的內(nèi)存資源不能正晨埽回收。正確的做法為：
將該內(nèi)部類設(shè)為靜態(tài)內(nèi)部類或?qū)⒃搩?nèi)部類抽取出來封裝成一個單例纪挎，如果需要使用Context期贫，請使用ApplicationContext
非靜態(tài)內(nèi)部類為什么持有外部類的this引用
https://blog.csdn.net/beixiaozhang/article/details/52950669
內(nèi)部類雖然和外部類寫在同一個文件中， 但是編譯完成后异袄， 還是生成各自的class文件通砍，內(nèi)部類通過this訪問外部類的成員。
1 編譯器自動為內(nèi)部類添加一個成員變量， 這個成員變量的類型和外部類的類型相同封孙， 這個成員變量就是指向外部類對象(this)的引用迹冤；
2 編譯器自動為內(nèi)部類的構(gòu)造方法添加一個參數(shù)， 參數(shù)的類型是外部類的類型虎忌， 在構(gòu)造方法內(nèi)部使用這個參數(shù)為內(nèi)部類中添加的成員變量賦值泡徙；
3在調(diào)用內(nèi)部類的構(gòu)造函數(shù)初始化內(nèi)部類對象時，會默認傳入外部類的引用膜蠢。
Handler造成的內(nèi)存泄漏
如下示例：
public class MainActivity extends AppCompatActivity {
private Handler mHandler = new Handler() {
? ? @Override
? ? public void handleMessage(Message msg) {
? ? //...
? ? }
};
? ? @Override
? ? protected void onCreate(Bundle savedInstanceState) {
? ? ? ? super.onCreate(savedInstanceState);
? ? ? ? setContentView(R.layout.activity_main);
? ? ? ? loadData();
? ? }
? ? private void loadData(){
? ? ? ? //...request
? ? ? ? Message message = Message.obtain();
? ? ? ? mHandler.sendMessage(message);
? ? }
}
這種創(chuàng)建Handler的方式會造成內(nèi)存泄漏堪藐，由于mHandler是Handler的非靜態(tài)匿名內(nèi)部類的實例，所以它持有外部類Activity的引用挑围，消息隊列是在一個Looper線程中不斷輪詢處理消息礁竞，那么當(dāng)這個Activity退出時消息隊列中還有未處理的消息或者正在處理消息，而消息隊列中的Message持有mHandler實例的引用杉辙，mHandler又持有Activity的引用模捂，所以導(dǎo)致該Activity的內(nèi)存資源無法及時回收，引發(fā)內(nèi)存泄漏蜘矢，所以另外一種做法為：
public class MainActivity extends AppCompatActivity {
? ? private MyHandler mHandler = new MyHandler(this);
? ? private TextView mTextView ;
? ? private static class MyHandler extends Handler {
? ? ? ? private WeakReference reference;
? ? ? ? public MyHandler(Context context) {
? ? ? ? reference = new WeakReference<>(context);
? ? ? ? }
? ? ? ? @Override
? ? ? ? public void handleMessage(Message msg) {
? ? ? ? ? ? MainActivity activity = (MainActivity) reference.get();
? ? ? ? ? ? if(activity != null){
? ? ? ? ? ? activity.mTextView.setText("");
? ? ? ? ? ? }
? ? ? ? }
? ? }
? ? @Override
? ? protected void onCreate(Bundle savedInstanceState) {
? ? ? ? super.onCreate(savedInstanceState);
? ? ? ? setContentView(R.layout.activity_main);
? ? ? ? mTextView = (TextView)findViewById(R.id.textview);
? ? ? ? loadData();
? ? }
? ? private void loadData() {
? ? ? ? //...request
? ? ? ? Message message = Message.obtain();
? ? ? ? mHandler.sendMessage(message);
? ? }
}
創(chuàng)建一個靜態(tài)Handler內(nèi)部類枫绅，然后對Handler持有的對象使用弱引用，這樣在回收時也可以回收Handler持有的對象硼端，這樣雖然避免了Activity泄漏，不過Looper線程的消息隊列中還是可能會有待處理的消息寓搬，所以我們在Activity的Destroy時或者Stop時應(yīng)該移除消息隊列中的消息珍昨，更準(zhǔn)確的做法如下：
public class MainActivity extends AppCompatActivity {
? ? private MyHandler mHandler = new MyHandler(this);
? ? private TextView mTextView ;
? ? private static class MyHandler extends Handler {
? ? ? ? private WeakReference reference;
? ? ? ? public MyHandler(Context context) {
? ? ? ? reference = new WeakReference<>(context);
? ? ? ? }
? ? ? ? @Override
? ? ? ? public void handleMessage(Message msg) {
? ? ? ? ? ? MainActivity activity = (MainActivity) reference.get();
? ? ? ? ? ? if(activity != null){
? ? ? ? ? ? activity.mTextView.setText("");
? ? ? ? ? ? }
? ? ? ? }
? ? }
? ? @Override
? ? protected void onCreate(Bundle savedInstanceState) {
? ? ? ? super.onCreate(savedInstanceState);
? ? ? ? setContentView(R.layout.activity_main);
? ? ? ? mTextView = (TextView)findViewById(R.id.textview);
? ? ? ? loadData();
? ? }
? ? private void loadData() {
? ? ? ? //...request
? ? ? ? Message message = Message.obtain();
? ? ? ? mHandler.sendMessage(message);
? ? }
? ? @Override
? ? protected void onDestroy() {
? ? ? ? super.onDestroy();
? ? ? ? mHandler.removeCallbacksAndMessages(null);
? ? }
}
使用mHandler.removeCallbacksAndMessages(null);是移除消息隊列中所有消息和所有的Runnable。當(dāng)然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();來移除指定的Runnable和Message句喷。
線程造成的內(nèi)存泄漏
對于線程造成的內(nèi)存泄漏镣典，也是平時比較常見的，異步任務(wù)和Runnable都是一個匿名內(nèi)部類唾琼，因此它們對當(dāng)前Activity都有一個隱式引用兄春。如果Activity在銷毀之前，任務(wù)還未完成锡溯，
那么將導(dǎo)致Activity的內(nèi)存資源無法回收赶舆，造成內(nèi)存泄漏。正確的做法還是使用靜態(tài)內(nèi)部類的方式祭饭，如下：
static class MyAsyncTask extends AsyncTask {
? ? private WeakReference weakReference;
? ? public MyAsyncTask(Context context) {
? ? ? ? weakReference = new WeakReference<>(context);
? ? }
? ? @Override
? ? protected Void doInBackground(Void... params) {
? ? ? ? SystemClock.sleep(10000);
? ? ? ? return null;
? ? }
? ? @Override
? ? protected void onPostExecute(Void aVoid) {
? ? ? ? super.onPostExecute(aVoid);
? ? ? ? MainActivity activity = (MainActivity) weakReference.get();
? ? ? ? if (activity != null) {
? ? ? ? //...
? ? ? ? }
? ? }
}
static class MyRunnable implements Runnable{
? ? @Override
? ? public void run() {
? ? ? ? SystemClock.sleep(10000);
? ? }
}
//——————
new Thread(new MyRunnable()).start();
new MyAsyncTask(this).execute();
這樣就避免了Activity的內(nèi)存資源泄漏芜茵，當(dāng)然在Activity銷毀時候也應(yīng)該取消相應(yīng)的任務(wù)AsyncTask::cancel()，避免任務(wù)在后臺執(zhí)行浪費資源倡蝙。
資源未關(guān)閉造成的內(nèi)存泄漏
對于使用了BraodcastReceiver九串，ContentObserver，F(xiàn)ile，Cursor猪钮，Stream品山，Bitmap等資源的使用，應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷烤低，否則這些資源將不會被回收肘交，造成內(nèi)存泄漏。
一些建議
對于生命周期比Activity長的對象如果需要應(yīng)該使用ApplicationContext
對于需要在靜態(tài)內(nèi)部類中使用非靜態(tài)外部成員變量（如：Context拂玻、View )酸些，可以在靜態(tài)內(nèi)部類中使用弱引用來引用外部類的變量來避免內(nèi)存泄漏
對于不再需要使用的對象，顯示的將其賦值為null檐蚜，比如使用完Bitmap后先調(diào)用recycle()魄懂，再賦為null
保持對對象生命周期的敏感，特別注意單例闯第、靜態(tài)對象市栗、全局性集合等的生命周期
對于生命周期比Activity長的內(nèi)部類對象，并且內(nèi)部類中使用了外部類的成員變量咳短，可以這樣做避免內(nèi)存泄漏：
將內(nèi)部類改為靜態(tài)內(nèi)部類
靜態(tài)內(nèi)部類中使用弱引用來引用外部類的成員變量
在涉及到Context時先考慮ApplicationContext填帽，當(dāng)然它并不是萬能的，對于有些地方則必須使用Activity的Context咙好，對于Application篡腌，Service，Activity三者的Context的應(yīng)用場景如下：
其中：NO1表示Application和Service可以啟動一個Activity勾效，不過需要創(chuàng)建一個新的task任務(wù)隊列嘹悼。而對于Dialog而言，只有在Activity中才能創(chuàng)建
UI相關(guān)的context 用activity
Java GC基本算法
https://blog.csdn.net/heyutao007/article/details/38151581
Android如何避免OOM總結(jié)
https://blog.csdn.net/ljx19900116/article/details/50037627
四個方面著手
1层宫、減小對象的內(nèi)存占用
2杨伙、內(nèi)存對象的重復(fù)利用
3、 避免對象的內(nèi)存泄露
4萌腿、內(nèi)存使用策略優(yōu)化限匣。
為什么WebView會造成的內(nèi)存泄露
Android 5.1 WebView內(nèi)存泄漏問題及解決
https://blog.csdn.net/u013085697/article/details/53259116
檢測內(nèi)存泄露工具，LeakCanary實現(xiàn)原理毁菱。? 有那些內(nèi)存泄露
1米死、RefWatcher.watch()創(chuàng)建了一個KeyedWeakReference用于去觀察對象。
2贮庞、然后哲身，在后臺線程中，它會檢測引用是否被清除了贸伐，并且是否沒有觸發(fā)GC勘天。
3、如果引用仍然沒有被清除，那么它將會把堆棧信息保存在文件系統(tǒng)中的.hprof文件里脯丝。
4商膊、HeapAnalyzerService被開啟在一個獨立的進程中，并且HeapAnalyzer使用了HAHA開源庫解析了指定時刻的堆棾杞快照文件heap dump晕拆。
5、從heap dump中材蹬，HeapAnalyzer根據(jù)一個獨特的引用key找到了KeyedWeakReference实幕，并且定位了泄露的引用。
6堤器、HeapAnalyzer為了確定是否有泄露昆庇，計算了到GC Roots的最短強引用路徑，然后建立了導(dǎo)致泄露的鏈?zhǔn)揭谩?/p>
7闸溃、這個結(jié)果被傳回到app進程中的DisplayLeakService整吆，然后一個泄露通知便展現(xiàn)出來了。
看完這篇 LeakCanary 原理分析辉川，又可以虐面試官了表蝙！
https://mp.weixin.qq.com/s/1jFY_22hoWgCw3CDo2rpOA
