Android开发常见的Activity中内存泄漏及解决办法-低调大师

Android开发常见的Activity中内存泄漏及解决办法

2017-11-09 609

上一篇文章楼主提到由Context引发的内存泄漏，在这一篇文章里，我们来谈谈Android开发中常见的Activity内存泄漏及解决办法。本文将会以“为什么”“怎么解决”的方式来介绍这几种内存泄漏。
在开篇之前，先来了解一下什么是内存泄漏。

什么是内存泄漏？

内存泄漏是当程序不再使用到的内存时，释放内存失败而产生了无用的内存消耗。内存泄漏并不是指物理上的内存消失，这里的内存泄漏是值由程序分配的内存但是由于程序逻辑错误而导致程序失去了对该内存的控制，使得内存浪费。

怎样会导致内存泄漏？

资源对象没关闭造成的内存泄漏，如查询数据库后没有关闭游标cursor
构造Adapter时，没有使用 convertView 重用
Bitmap对象不在使用时调用recycle()释放内存
对象被生命周期长的对象引用，如activity被静态集合引用导致activity不能释放

在接下来的篇幅里，我们重点讲有关Activity常见的内存泄漏。

内存泄漏1：静态Activities（static Activities）

代码如下：
MainActivity.Java

public class MainActivity extends AppCompatActivity { private static MainActivity activity; TextView saButton; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); saButton = (TextView) findViewById(R.id.text); saButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { setStaticActivity(); nextActivity(); } }); } void setStaticActivity() { activity = this; } void nextActivity(){ startActivity(new Intent(this,RegisterActivity.class)); SystemClock.sleep(1000); finish(); } @Override protected void onDestroy() { super.onDestroy(); //使用LeakCanary观察是否有内存泄漏 MyApplication.getRefWatcher().watch(this); } }

LeakCanary检测出的内存泄漏：

为什么？
在上面代码中，我们声明了一个静态的Activity变量并且在TextView的OnClick事件里引用了当前正在运行的Activity实例，所以如果在activity的生命周期结束之前没有清除这个引用，则会引起内存泄漏。因为声明的activity是静态的，会常驻内存，如果该对象不清除，则垃圾回收器无法回收变量。

怎么解决？
最简单的方法是在onDestory方法中将静态变量activity置空，这样垃圾回收器就可以将静态变量回收。

@Override
    protected void onDestroy() {
        super.onDestroy(); activity = null; //使用LeakCanary观察是否有内存泄漏 MyApplication.getRefWatcher().watch(this); }

内存泄漏2：静态View

代码如下：
MainActivity.java

    ...
    private static View view;
    TextView saButton;
    @Override
    protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); saButton = (TextView) findViewById(R.id.text); saButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { setStaticView(); nextActivity(); } }); } void setStaticView() { view = findViewById(R.id.sv_view); } ...

LeakCanary检测到的内存泄漏

为什么？
上面代码看似没有问题，在Activity里声明一个静态变量view，然后初始化，当Activity生命周期结束了内存也释放了，但是LeakCanary却显示出现了内存泄漏，为什么？问题出在这里，View一旦被加载到界面中将会持有一个Context对象的引用，在这个例子中，这个context对象是我们的Activity，声明一个静态变量引用这个View，也就引用了activity，所以当activity生命周期结束了，静态View没有清除掉，还持有activity的引用，因此内存泄漏了。

怎么解决？
在onDestroy方法里将静态变量置空。

@Override
protected void onDestroy() {
    super.onDestroy(); view = null; MyApplication.getRefWatcher().watch(this); }

内存泄漏3：内部类

代码如下：
MainActivity.java

private static Object inner;
void createInnerClass() {
    class InnerClass {
    }
    inner = new InnerClass();
}

View icButton = findViewById(R.id.ic_button);
icButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { createInnerClass(); nextActivity(); } });

使用LeakCanary检测到的内存泄漏：

为什么？
非静态内部类会持有外部类的引用，在上面代码中内部类持有Activity的引用，因此inner会一直持有Activity，如果Activity生命周期结束没有清除这个引用，这样就发生了内存泄漏。

怎么解决？
因为非静态内部类隐式持有外部类的强引用，所以我们将内部类声明成静态的就可以了。

void createInnerClass() {
    static class InnerClass {
    }
    inner = new InnerClass();
}

内存泄漏4：匿名类

void startAsyncTask() {
    new AsyncTask<Void, Void, Void>() {
        @Override protected Void doInBackground(Void... params) { while(true); } }.execute(); } super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); View aicButton = findViewById(R.id.at_button); aicButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { startAsyncTask(); nextActivity(); } });

使用LeakCanary检测到的内存泄漏：

为什么？
上面代码在activity中创建了一个匿名类AsyncTask，匿名类和非静态内部类相同，会持有外部类对象，这里也就是activity，因此如果你在Activity里声明且实例化一个匿名的AsyncTask对象，则可能会发生内存泄漏，如果这个线程在Activity销毁后还一直在后台执行，那这个线程会继续持有这个Activity的引用从而不会被GC回收，直到线程执行完成。

怎么解决？
自定义静态AsyncTask类，并且让AsyncTask的周期和Activity周期保持一致，也就是在Activity生命周期结束时要将AsyncTask cancel掉。

内存泄漏5：Handler

代码如下：
MainActivity.java

...
void createHandler() {
    new Handler() {
        @Override public void handleMessage(Message message) { super.handleMessage(message); } }.postDelayed(new Runnable() { @Override public void run() { while(true); } }, 1000); } ... View hButton = findViewById(R.id.h_button); hButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { createHandler(); nextActivity(); } }); ...

为什么？
当Android Application启动以后，framework会首先帮助我们完成UI线程的消息循环，也就是在UI线程中，Loop、MessageQueue、Message等等这些实例已经由framework帮我们实现了。所有的Application主要事件，比如Activity的生命周期方法、Button的点击事件都包含在这个Message里面，这些Message都会加入到MessageQueue中去，所以，UI线程的消息循环贯穿于整个Application生命周期，所以当你在UI线程中生成Handler的实例，就会持有Loop以及MessageQueue的引用。并且在Java中非静态内部类和匿名内持有外部类的引用，而静态内部类则不会持有外部类的引用。

怎么解决？
可以由上面的结论看出，产生泄漏的根源在于匿名类持有Activity的引用，因此可以自定义Handler和Runnable类并声明成静态的内部类，来解除和Activity的引用。

内存泄漏6：Thread

代码如下：
MainActivity.java

void spawnThread() {
    new Thread() {
        @Override public void run() { while(true); } }.start(); } View tButton = findViewById(R.id.t_button); tButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { spawnThread(); nextActivity(); } });

为什么？
同AsyncTask一样，这里就不过多赘述。

怎么解决？
那我们自定义Thread并声明成static这样可以吗？其实这样的做法并不推荐，因为Thread位于GC根部，DVM会和所有的活动线程保持hard references关系，所以运行中的Thread绝不会被GC无端回收了，所以正确的解决办法是在自定义静态内部类的基础上给线程加上取消机制，因此我们可以在Activity的onDestroy方法中将thread关闭掉。

内存泄漏7：Timer Tasks

代码如下：
MainActivity.java

void scheduleTimer() {
    new Timer().schedule(new TimerTask() {
        @Override
        public void run() { while(true); } },1000); } View ttButton = findViewById(R.id.tt_button); ttButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { scheduleTimer(); nextActivity(); } });

为什么？
这里内存泄漏在于Timer和TimerTask没有进行Cancel，从而导致Timer和TimerTask一直引用外部类Activity。

怎么解决？
在适当的时机进行Cancel。

内存泄漏8：Sensor Manager

代码如下：
MainActivity.java

void registerListener() {
       SensorManager sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
       Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
       sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_FASTEST);
}

View smButton = findViewById(R.id.sm_button);
smButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) { registerListener(); nextActivity(); } });

为什么？
通过Context调用getSystemService获取系统服务，这些服务运行在他们自己的进程执行一系列后台工作或者提供和硬件交互的接口，如果Context对象需要在一个Service内部事件发生时随时收到通知，则需要把自己作为一个监听器注册进去，这样服务就会持有一个Activity，如果开发者忘记了在Activity被销毁前注销这个监听器，这样就导致内存泄漏。

怎么解决？
在onDestroy方法里注销监听器。

总结

在开发中，内存泄漏最坏的情况是app耗尽内存导致崩溃，但是往往真实情况不是这样的，相反它只会耗尽大量内存但不至于闪退，可分配的内存少了，GC便会更多的工作释放内存，GC是非常耗时的操作，因此会使得页面卡顿。我们在开发中一定要注意当在Activity里实例化一个对象时看看是否有潜在的内存泄漏，一定要经常对内存泄漏进行检测。

题外

在本篇中，楼主用LeakCanary来对内存泄漏进行检测。LeakCanary是非常好用的第三方库用来进行内存泄漏检测，感兴趣的朋友可以去查阅LeakCanary使用方法，使用它来监测App中的内存泄漏。

本文转自一点点征服博客园博客，原文链接：http://www.cnblogs.com/ldq2016/p/6636317.html，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/567588

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Android开发之旅: Intents和Intent Filters（实例部分）

引言上篇我们介绍了Intents和Intent Filters的理论部分，主要是介绍了：activities、services、broadcastreceivers三种组件的Intent机制两种Intent（显式和隐式）及它们如何去匹配目的组件、Intent对象包含哪些信息、Intent Filters的action & category & data。 Intent的重要性，我不再着重介绍了，但我还是要说：Intent能够使应用程序突破沙盒与外界交流，者这使得Android的世界变得丰富多彩！本篇将用实例来介绍，如何应用Intent，而且继续用SMS方面的例子来阐述。本文的主要内容如下：例子（需求）描述 STEP1、添加用于显示通讯录的布局文件 STEP2、添加Button的点击事件 STEP3、添加通讯录活动 STEP4、解析通讯录返回的数据 STEP5、在清单文件AndroidManifest.xml中注册通讯录活动和读取Contact数据库的权限总结例子（需求）描述用手机发过SMS的人都知道：用户可以先编辑短信，然后再去通讯录中选择相应的人并发生给他...

2017-11-10

520

在设备上保存用户数据应用程序在保存数据到程序的Bundle，这在模拟器上是可以的，但是在真机上就不行了。这是因为设备和模拟器的不同的权限导致的。模拟器拥有完全的读写权限，设备就没有了。 iPhone Application Programming Guide 中包含了相关的描述。程序的目录下有一个偏好设置的目录<Application_Home>/Library/Preferences 但是你不能直接创建文件，应该使用NSUserDefaults或者CFPreferences来设置。同时你可以保存应用程序数据到<Application_Home>/Documents 目录下。这两个地方存储的数据在车功能需升级的时候后可以保留。本文转自 arthurchen 51CTO博客，原文链接：http://blog.51cto.com/arthurchen/801311，如需转载请自行联系原作者

2017-11-10

693

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。