app什么情况下容易内存泄漏?

好文章

转自:https://www.cnblogs.com/liushilin/p/5900089.html

1.常见问题汇总

(1) Singleton

(1-1)问题描述:
比如, 在初始化Singleton时持有了一个Activity的引用. 如果我们传入的是Activity的Context，当这个Context所对应的Activity退出的时候，由于该Context的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前Activity退出时它的内存并不会回收，这造成的内存泄漏就可想而知了。
package com.example.nanchen.anrsolutiondemo.singleton;


import android.content.Context;


/**
 * @author nanchen
 * @fileName ANRSolutionDemo
 * @packageName com.example.nanchen.anrsolutiondemo.singleton
 * @date 2016/09/23  11:27
 */
public class SingletonBad {
    private static SingletonBad singletonBad;
    private Context context;


    private SingletonBad(Context context){
        this.context = context;
    }


    public static SingletonBad getInstance(Context context){
        if (singletonBad == null){
            singletonBad = new SingletonBad(context);
        }
        return singletonBad;
    }
}


(1-2)解决办法
把传入的Context换为和应用的生命周期一样长的Application的Context;

(2) Handler

(2-1)问题描述
Handler、Message和MessageQueue都是相互关联在一起的，万一Handler发送的Message尚未被处理，则该Message及发送它的Handler对象将会被线程MessageQueue一直持有。
       由于Handler属于TLS（Thread Local Storage）变量，生命周期和Activity是不一致的。因此这种实现方式一般很难保证跟View或者Activity的生命周期一致，故很容易导致无法正确释放。比如：
package com.example.nanchen.anrsolutiondemo.handler;


import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.support.v7.app.AppCompatActivity;


import com.example.nanchen.anrsolutiondemo.R;


public class HandlerBadActivity extends AppCompatActivity {


    private final Handler handler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    };


    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler_bad);


        // 延迟10s发送一个消息
        handler.postDelayed(new Runnable() {
            @Override
            public void run() {
                // write something
            }
        },1000*60*5);


        this.finish();
    }
}
在例子中，我们申明了一个延迟5分钟执行的消息Message。当该Activity被finish的时候，延迟任务的Message还存在于主线程中，它持有该Activity的Handler引用，所以此时Finish掉的Activity就不会回收了，所以造成了内存泄漏（因handler为非静态内部类，它会持有外部类的引用，在这里就是当前的Activity）。
(2-2)解决办法
这个解决也是可以通过把其声明为static的，则其存活期就跟activity的生命周期无关了。不过倘若用到Context等外部类的非static对象，还是应该通过弱引用传入
package com.example.nanchen.anrsolutiondemo.handler;


import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.support.v7.app.AppCompatActivity;


import com.example.nanchen.anrsolutiondemo.R;


import java.lang.ref.WeakReference;


public class HandlerGoodActivity extends AppCompatActivity {


    private static final class MyHandler extends Handler{
        private final WeakReference<HandlerGoodActivity> mActivity;


        public MyHandler(HandlerGoodActivity activity){
            this.mActivity = new WeakReference<HandlerGoodActivity>(activity);//使用弱引用
        }


        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            HandlerGoodActivity activity = mActivity.get();
            if (activity != null){
                // write something
            }
        }
    }


    private final MyHandler myHandler = new MyHandler(this);


    // 匿名内部类在static的时候绝对不会持有外部类的引用
    private static final Runnable RUNNABLE = new Runnable() {
        @Override
        public void run() {


        }
    };


    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler_good);


        myHandler.postDelayed(RUNNABLE,1000*60*5);
    }
}


综述：推荐使用静态内部类+弱引用WeakReference这种方式，但要注意每次使用前判空。
说到若引用，这里再提下java的几种引用类型：Strong reference,SoftReference,WeakReference和PhatomReference
 
在android开发中，为了防止内存溢出，在处理一些占用内存大并且生命周期较长的对象的时候，可以尽量地使用软引用和弱引用技术。
比如，保存Bitmap的软引用到HashMap。
 
 1 package com.example.nanchen.anrsolutiondemo.photo;
 2 
 3 import android.graphics.Bitmap;
 4 import android.graphics.BitmapFactory;
 5 
 6 import java.lang.ref.SoftReference;
 7 import java.util.HashMap;
 8 
 9 /**
10  * @author nanchen
11  * @fileName ANRSolutionDemo
12  * @packageName com.example.nanchen.anrsolutiondemo.photo
13  * @date 2016/09/23  11:58
14  */
15 public class CacheBySoftRef {
16 
17     // 首先定义一个HashMap,保存软应用对象
18     private HashMap<String,SoftReference<Bitmap>> imageCache =  new HashMap<>();
19     // 再来定义一个方法，保存Bitmap的软引用到HashMap
20     public void addBitmapToCache(String path){
21         // 强引用的Bitmap对象
22         Bitmap bitmap = BitmapFactory.decodeFile(path);
23         // 软引用的Bitmap对象
24         SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
25         // 添加该对象到Map使其缓存
26         imageCache.put(path,softBitmap);
27     }
28 
29     // 获取的时候，可以通过SoftReference的get()的方法得到Bitmap对象
30     public Bitmap getBitmapByPath(String path){
31         // 从缓存中取软引用的Bitmap对象
32         SoftReference<Bitmap> softBitmap = imageCache.get(path);
33         // 判断是否存在软引用
34         if (softBitmap == null){
35             return null;
36         }
37         // 通过软引用取出Bitmap对象，如果由于内存不足Bitmap被回收，则取得空；
38         // 如果未被回收，则可重复使用，提高速度
39         Bitmap bitmap = softBitmap.get();
40         return bitmap;
41     }
42 }
 
使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。
如果只是想避免OutOfMemory异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。
另外可以根据对象是否经常使用来判断选择软引用还是弱引用。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。
ok，继续回到主题。前面所说的，创建一个静态Handler内部类，然后对 Handler 持有的对象使用弱引用，这样在回收时也可以回收 Handler 持有的对象，但是这样做虽然避免了 Activity 泄漏，不过 Looper 线程的消息队列中还是可能会有待处理的消息，所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。例如:removeCallbacks
 

(3) 匿名内部类/非静态内部类，它们方便却暗藏杀机

(3-1)问题描述. 非静态匿名内部类持有Activity的引用. 当该内部Runnable内部类在异步线程调用, 且Activity结束, 那么Activity不能正常释放
android开发经常会继承实现Activity或者Fragment或者View。如果你使用了匿名类，而又被异步线程所引用，那得小心，如果没有任何措施同样会导致内存泄漏的
 
 1 package com.example.nanchen.anrsolutiondemo.innerClass;
 2 
 3 import android.os.Bundle;
 4 import android.support.v7.app.AppCompatActivity;
 5 
 6 import com.example.nanchen.anrsolutiondemo.R;
 7 
 8 public class MainActivity extends AppCompatActivity {
 9 
10     private static TestInnerBad testInnerBad = null;
11 
12     class TestInnerBad{
13 
14     }
15 
16     @Override
17     protected void onCreate(Bundle savedInstanceState) {
18         super.onCreate(savedInstanceState);
19         setContentView(R.layout.activity_inner_bad);
20 
21         if (testInnerBad == null){
22             testInnerBad = new TestInnerBad();
23         }
24 
25         Runnable runnable1 = new MyRunnable();
26         Runnable runnable2 = new Runnable() {
27             @Override
28             public void run() {
29 
30             }
31         };
32     }
33 
34     private static class MyRunnable implements Runnable{
35 
36         @Override
37         public void run() {
38 
39         }
40     }
41 
42 }
 
runnable1 和 runnable2的区别就是，runnable2使用了匿名内部类，我们看看引用时的引用内存
 
可以看到，runnable1是没有什么特别的。但runnable2多出了一个MainActivity的引用，若是这个引用再传入到一个异步线程，此线程在和Activity生命周期不一致的时候，也就造成了Activity的泄露。


(3-2)解决办法
远离非静态内部类和匿名类，多用private static class。


(3 -3)问题描述. 类的静态内部引用了类的非静态内部类, 因为这个非静态内部类持有了当前Activity的引用, 且他自己被静态成员持有着, 那么当该Activity结束的时候, 就不会被释放资源
在我们的日常代码中，这样的情况似乎很常见，及直接写一个class就这么光秃秃的情况。
       
　　　
这样就在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。
(3-4)解决办法


将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，请按照上面推荐的使用Application 的 Context。当然，Application 的 context 不是万能的，所以也不能随便乱用，对于有些地方则必须使用 Activity 的 Context，对于Application，Service，Activity三者的Context的应用场景如下：
 
其中： NO1表示 Application 和 Service 可以启动一个 Activity，不过需要创建一个新的 task 任务队列。而对于 Dialog 而言，只有在 Activity 中才能创建

(4) 不用的静态集合类, 要清理掉

　我们通常会把一些对象的引用加入到集合容器（比如ArrayList）中，当我们不再需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
　　所以在退出程序之前，将集合里面的东西clear，然后置为null，再退出程序，如下：
 
 1 private List<String> nameList;
 2     private List<Fragment> list;
 3 
 4     @Override
 5     public void onDestroy() {
 6         super.onDestroy();
 7         if (nameList != null){
 8             nameList.clear();
 9             nameList = null;
10         }
11         if (list != null){
12             list.clear();
13             list = null;
14         }
15   }
 

2总结

 构造Adapter时，没有使用缓存的 convertView
 Bitmap对象不在使用时调用recycle()释放内存
 Context使用不当造成内存泄露：不要对一个Activity Context保持长生命周期的引用。尽量在一切可以使用应用ApplicationContext代替Context的地方进行替换。
 非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。
 警惕线程未终止造成的内存泄露；譬如在Activity中关联了一个生命周期超过Activity的Thread，在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了Activity生命周期，我们必须手动在Activity的销毁方法中中调运thread.getLooper().quit();才不会泄露。
 对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
 创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。
 不要在执行频率很高的方法或者循环中创建对象（比如onmeasure），可以使用HashTable等创建一组对象容器从容器中取那些对象，而不用每次new与释放。
 避免代码设计模式的错误造成内存泄露；譬如循环引用，A持有B，B持有C，C持有A，这样的设计谁都得不到释放。