Android中常见的内存泄漏分析及应对方法

最新推荐文章于 2021-06-11 14:20:01 发布

MyName_kk

最新推荐文章于 2021-06-11 14:20:01 发布

阅读量505

点赞数 1

分类专栏： android 文章标签： android 内存泄露 singleton

本文链接：https://blog.csdn.net/myname_kk/article/details/76258373

版权

android 专栏收录该内容

14 篇文章 0 订阅

订阅专栏

1.单例模式（Singleton）

为了完美解决我们在程序中反复创建同一对象的问题，我们选用了单例模式，单例在我们的程序中随处可见，但是由于单例模式的静态特性，使得它的生命周期和我们的应用一样长，一不小心让单例无限制的持有Activity的强引用就会导致内存泄漏。例如：

public class SingleTon{
    private Context context;
    private static SingleTon singleTon;

    public static final SingleTon getInstance(Context context){
        this.context = context;
        return SingleHolder.INSTANCE;
    }

    private static class SingleHolder{
        private static final SingleTon INSTANCE = new SingleTon();
    }
}

解决办法：

这个错误很普遍，这个是一个很正常的单利模式，但是由于传入了一个Context，而这个Context的生命周期就的长短就尤为重要了。如果我们传入的是某个Activity的Context，而当这个Activity推出的时候，由于该Context的强引用被单例持有，那么这个Activity就等同于拥有了整个程序的生命周期。这种情况下，当Activity退出的时候内存并没有被回收，这就造成了内存泄漏。

正确的做法就是应该把传入的Context改为同应用生命周期一样长的Application中的Context。

  public static final SingleTon getInstance(Context context){
        this.context = context.getApplicationContext;
        return SingleHolder.INSTANCE;
    }

当然我们可以直接重写Application，提供getContext方法,不必在依靠传入的参数：

public class BaseApplication extends Application{
    private static BaseApplication baseApplication;

    @Override
    public void onCreate(){
        super.onCreate();
        baseApplication = this;
    }

    public static Context getContext{
        baseApplication.getApplicationContext();
    }
}

2 .Handler引起的内存泄漏

Handler引起的内存泄漏在我们开发中最为常见的。我们知道Handler、Message、MessageQueue都是相互关联在一起的，万一Handler发送的Message尚未被处理，那么该Message以及发送它的Handler对象都会被线程MessageQueue一直持有。

由于Handler属于TLS（Thread Local Storage）变量，生命周期和Activity是不一致的，因此这种实现方式很难保证跟Activity的生命周期一直，所以很容易无法释放内存。比如：

 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); 
         // 延迟5min发送一个消息
         handler.postDelayed(new Runnable() {
             @Override
             public void run() {
                 // write something
             }
         },1000*60*5);

         this.finish();
     }
 }

我们在例子中生命了一个延时5分钟执行的Message，当该Activity退出的时候，延时任务（Message）还在主线成的MessageQueue中等待，此时的Message持有Handler的强引用，并且由于Handler是HandlerBadActivity的非静态内部类，所以Handler会持有HandlerBadActivity的强引用，此时HandlerBadActivity退出时无法进行内存回收，造成内存泄漏。
解决办法：

将Handler生命为静态内部类，这样它就不会持有外部来的引用了。这样以来Handler的的生命周期就与Activity无关了。不过倘若用到Context等外部类的非static对象，还是应该通过使用Application中与应用同生命周期的Context比较合适。比如：

    public class HandlerGoodActivity extends AppCompatActivity {
    private static final class MyHandler extends Handler {
        private Context mActivity;

        public MyHandler(HandlerGoodActivity activity) {
            //使用生命周期与应用同长的getApplicationContext
            this.mActivity = activity.getApplicationContext();
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            if (mActivity != 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);
    }

虽然我们结局了Activity的内存泄漏问题，但是经过Handler发送的延时消息还在MessageQueue中，Looper也在等待处理消息，所以我们要在Activity销毁的时候处理掉队列中的消息。

   @Override
    protected void onDestroy() {
        super.onDestroy();
        //传入null，就表示移除所有Message和Runnable
        myHandler.removeCallbacksAndMessages(null);
    }

3 .匿名内部类在异步线程中的使用

它们方便却暗藏杀机。Android开发经常会继承实现 Activity 或者 Fragment 或者 View。如果你使用了匿名类，而又被异步线程所引用，那得小心，如果没有任何措施同样会导致内存泄漏的：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_inner_bad);

        Runnable runnable1 = new MyRunnable();
        Runnable runnable2 = new Runnable() {
            @Override
            public void run() {

            }
        };
    }

    private static class MyRunnable implements Runnable{

        @Override
        public void run() {

        }
    }

}

runnable1 和 runnable2的区别就是，runnable2使用了匿名内部类，我们看看引用时的引用内存

可以看到，runnable1是没有什么特别的。但runnable2多出了一个MainActivity的引用，若是这个引用再传入到一个异步线程，此线程在和Activity生命周期不一致的时候，也就造成了Activity的泄露。

4 .善用static成员变量

从前面的介绍我们知道，static修饰的变量位于内存的静态存储区，此变量与App的生命周期一致
这必然会导致一系列问题，如果你的app进程设计上是长驻内存的，那即使app切到后台，这部分内存也不会被释放。按照现在手机app内存管理机制，占内存较大的后台进程将优先回收，因为如果此app做过进程互保保活，那会造成app在后台频繁重启。当手机安装了你参与开发的app以后一夜时间手机被消耗空了电量、流量，你的app不得不被用户卸载或者静默。

这里修复的方法是：
不要在类初始时初始化静态成员。可以考虑lazy初始化（延迟加载）。架构设计上要思考是否真的有必要这样做，尽量避免。如果架构需要这么设计，那么此对象的生命周期你有责任管理起来。

5 .避免使用

在我们的日常代码中，这样的情况似乎很常见，及直接写一个class就这么光秃秃的情况

　　　
这样就在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。正确的做法为：

将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，请按照上面推荐的使用Application 的 Context。当然，Application 的 context 不是万能的，所以也不能随便乱用，对于有些地方则必须使用 Activity 的 Context，对于Application，Service，Activity三者的Context的应用场景如下：

其中： NO1表示 Application 和 Service 可以启动一个 Activity，不过需要创建一个新的 task 任务队列。而对于 Dialog 而言，只有在 Activity 中才能创建

6.集合引发的内存泄漏

我们通常会把一些对象的引用加入到集合容器（比如ArrayList）中，当我们不再需要该对象时，并没有把它的引用从集合中清理掉，当集合中的内容过于大的时候，并且是static的时候就造成了内存泄漏，所有我们最好在onDestory情况并让其不可达

private List<String> nameList;
    private List<Fragment> list;

    @Override
    public void onDestroy() {
        super.onDestroy();
        if (nameList != null){
            nameList.clear();
            nameList = null;
        }
        if (list != null){
            list.clear();
            list = null;
        }
    }

7.webView引发的内存泄漏

WebView解析网页时会申请Native堆内存用于保存页面元素，当页面较复杂时会有很大的内存占用。如果页面包含图片，内存占用会更严重。并且打开新页面时，为了能快速回退，之前页面占用的内存也不会释放。有时浏览十几个网页，都会占用几百兆的内存。这样加载网页较多时，会导致系统不堪重负，最终强制关闭应用，也就是出现应用闪退或重启。

由于占用的都是Native堆内存，所以实际占用的内存大小不会显示在常用的DDMS Heap工具中（这里看到的只是Java虚拟机分配的内存，一般即使Native堆内存已经占用了几百兆，这里显示的还只是几兆或十几兆）。只有使用adb shell中的一些命令比如dumpsys meminfo 包名，或者在程序中使用Debug.getNativeHeapSize()才能看到。

据说由于WebView的一个BUG，即使它所在的Activity(或者Service)结束也就是onDestroy()之后，或者直接调用WebView.destroy()之后，它所占用这些内存也不会被释放。

解决这个问题最直接的方法是：把使用了WebView的Activity(或者Service)放在单独的进程里。然后在检测到应用占用内存过大有可能被系统干掉或者它所在的Activity(或者Service)结束后，调用System.exit(0)，主动Kill掉进程。由于系统的内存分配是以进程为准的，进程关闭后，系统会自动回收所有内存。

8.其他常见的引起内存泄漏原因

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

总结：

一.Android内存优化主要是针对堆（Heap）而言的，当堆中对象的作用域结束的时候，这部分内存也不会立刻被回收，而是等待系统GC进行回收。
二.Java中造成内存泄漏的根本原因是：堆内存中长生命周期的对象持有短生命周期对象的强/软引用，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收。