性能优化系列-Android(安卓)内存泄漏例子
性能优化系列-Android 内存泄漏例子
内存泄露(Memory Leak)
Java内存泄漏指的是进程中某些对象(垃圾对象)已经没有使用价值了,但是它们却可以直接或间接地引用到gc roots导致无法被GC回收。Dalvik VM具备的GC机制(垃圾回收机制)会在内存占用过多时自动回收,严重时会造成内存溢出OOM。
内存溢出OOM(Out Of Memory)
当应用程序申请的java heap空间超过Dalvik VM HeapGrowthLimit时,溢出。
效果是能让较多进程常驻内存。
注意:OOM并不代表内存不足,只要申请的heap超过Dalvik VM HeapGrowthLimit时,即使内存充足也会溢出。
还有一点概念要搞清楚, 内存泄漏可以导致内存溢出, 但是内存溢出并不是都是由内存泄漏造成的。
接下来我们聊几种常见的内存泄漏的例子 ,以及优化方案。
- 静态变量引起的内存泄漏
- 非静态内部类引起的内存泄漏
- 资源未关闭引起的内存泄漏
- 不要用的监听未移除
一、静态变量引起的内存泄漏
在java中静态变量的生命周期是在类加载时开始,类卸载时结束。也就是说,在android中其生命周期是在进程启动时开始,进程死亡时结束。所以在程序的运行期间,如果进程没有被杀死,静态变量就会一直存在,不会被回收掉。如果静态变量强引用了某个Activity中变量,那么这个Activity就同样也不会被释放,
即便是该Activity执行了onDestroy 注意这里Activity 执行onDestory 和 内存回收不是同一概念 。
这类问题的解决方案为:
1.寻找与该静态变量生命周期差不多的替代对象。
2.若找不到,将强引用方式改成弱引用。
找几段代码看看比较典型的例子如下:
- 单例引起的Context内存泄漏
public class Singleton { private Context context; private static Singleton mInstance; public static Singleton getInstance(Context context) { if (mInstance == null) { synchronized (Singleton.class) { if (mInstance == null) mInstance = new Singleton(context); } } return mInstance; } private Singleton(Context context) { this.context = context; }}
当调用getInstance时,如果传入的context是Activity的context。只要这个单例没有被释放,这个Activity也不会被释放。
解决办法当然是, 让context的引用的生命周期和单例一样长。传入Application的context,因为Application的context的生命周期比Activity长,可以理解为Application的context与单例的生命周期一样长,传入它是最合适的。
关键代码:
//将传入的context转换成Application的context mInstance = new Singleton(context.getApplicationContext());
- 集合引发的内存泄漏
如果把一些对象的引用加入到集合容器(比如ArrayList)中,当我们不再需要该对象时,并没有把它的引用从集合中清理掉,当集合中的内容过于大的时候,并且是static的时候就造成了内存泄漏,所有最好在onDestory清空;
private static List nameList; private static List list; @Override public void onDestroy() { super.onDestroy(); if (nameList != null){ nameList.clear(); nameList = null; } if (list != null){ list.clear(); list = null; } }
二、非静态内部类引起的内存泄漏
内部类的优势之一就是可以访问外部类,不幸的是,导致内存泄漏的原因,就是内部类持有外部类实例的强引用。
在java里,非静态内部类 和 匿名类 都会潜在的引用它们所属的外部类。但是,静态内部类却不会。
如果这个非静态内部类实例做了一些耗时的操作,就会造成外围对象不会被回收,从而导致内存泄漏。
这类问题的解决方案为:
-
1.将内部类变成静态内部类
-
2.如果有强引用Activity中的属性,则将该属性的引用方式改为弱引用。
-
3.在业务允许的情况下,当Activity执行onDestory时,结束这些耗时任务。
- 内部线程造成的内存泄漏
public class LeakAty extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.aty_leak); test(); } public void test() { //匿名内部类会引用其外围实例LeakAty.this,所以会导致内存泄漏 new Thread(new Runnable() { @Override public void run() { while (true) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } } } }).start(); }}
解决方案
将非静态匿名内部类修改为静态匿名内部类
public class LeakAty extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.aty_leak); test(); } //加上static,变成静态匿名内部类 public static void test() { new Thread(new Runnable() { @Override public void run() { while (true) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } } } }).start(); }}
还如, 关键代码:TimerTask 缺失部分自行脑补,
void scheduleTimer() { new Timer().schedule(new TimerTask() { @Override public void run() { while (true) ; } }, Long.MAX_VALUE >> 1);}View ttButton = findViewById(R.id.tt_button);ttButton.setOnClickListener(new View.OnClickListener(){ @Override public void onClick (View v){ scheduleTimer(); nextActivity(); }});
- Handler引起的内存泄漏
public class LeakAty extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.aty_leak); fetchData(); } private Handler mHandler = new Handler() { public void handleMessage(android.os.Message msg) { switch (msg.what) { case 0: // 刷新数据 break; default: break; } }; }; private void fetchData() { //获取数据 mHandler.sendEmptyMessage(0); }}
mHandler 为匿名内部类实例,会引用外围对象LeakAty.this,如果该Handler在Activity退出时依然还有消息需要处理,那么这个Activity就不会被回收。
比如尤其是:
mHandler.postDelayed(sRunnable, 1000 * 60 * 10);
解决方案:
解决方案public class LeakAty extends Activity { private TextView tvResult; private MyHandler handler; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.aty_leak); tvResult = (TextView) findViewById(R.id.tvResult); handler = new MyHandler(this); fetchData(); } //第一步,将Handler改成静态内部类。 private static class MyHandler extends Handler { //第二步,将需要引用Activity的地方,改成弱引用。 private WeakReference atyInstance; public MyHandler(LeakAty aty) { this.atyInstance = new WeakReference(aty); } @Override public void handleMessage(Message msg) { super.handleMessage(msg); LeakAty aty = atyInstance == null ? null : atyInstance.get(); //如果Activity被释放回收了,则不处理这些消息 没毛病, 如果activity都没回收了, 那么消息肯定也就不用处理了, 直接return。 if (aty == null || aty.isFinishing()) { return; } aty.tvResult.setText("fetch data success"); } } private void fetchData() { // 获取数据 handler.sendEmptyMessage(0); } @Override protected void onDestroy() { //第三步,在Activity退出的时候移除回调 super.onDestroy(); handler.removeCallbacksAndMessages(null); }}
这里用弱引用,万一被回收了怎么办?岂不是会空指针。
需要说明:你弱引用里面的Activity都被干掉了,你一个Handler还想继续玩什么? 所以如果为null, 直接return ,没毛病。
最后虽然我们结束了Activity的内存泄漏问题,但是经过Handler发送的延时消息还在MessageQueue中,Looper也在等待处理消息,
所以我们要在Activity销毁的时候处理掉队列中的消息。
小结
虽然静态类与非静态类之间的区别并不大,但是对于Android开发者而言却是必须理解的。
至少我们要清楚,如果一个内部类实例的生命周期比Activity更长,那么我们千万不要使用非静态的内部类。
最好的做法是,使用静态内部类,然后在该类里使用弱引用来指向所在的Activity。
三、资源未关闭引起的内存泄漏
当使用了BraodcastReceiver、Cursor、Bitmap、自定义属性attr等资源时,当不需要使用时,需要及时释放掉,若没有释放,则会引起内存泄漏
四、不要用的监听未移除
- 调用了View.getViewTreeObserver().addOnXXXListener ,而没有调用View.getViewTreeObserver().removeXXXListener
- 传感器的注册与解注册
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(); }});
3.PhoneStateListener电话状态监听
假设我们希望在锁屏界面(LockScreen)中,监听系统中的电话服务以获取一些信息(如信号强度等),则可以在LockScreen中定义一个 PhoneStateListener的对象,同时将它注册到TelephonyManager服务中,而对于TelephonyManager 是系统级Service, 生命周期和系统一致。
对于LockScreen对象,当需要显示锁屏界面的时候就会创建一个LockScreen对象,而当锁屏界面消失的时候LockScreen对象就会被释放掉。 但是如果在释放 LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象,则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失,则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process 进程挂掉。 虽然有些系统程序,它本身好像是可以自动取消注册的(当然不及时),但是我们还是应该在我们的程序中明确的取消注册,程序结束时应该把所有的注册都取消掉。
五、无限循环动画
在Activity中播放属性动画中的一类无限循环动画,没有在ondestory中停止动画,Activity会被动画持有而无法释放。
解决办法 就是及时停止动画,释放资源。
六、其他常见的引起内存泄漏原因
- 构造Adapter时,没有使用缓存的 convertView
- Bitmap在不使用的时候没有使用recycle()释放内存
- 非静态内部类的静态实例容易造成内存泄漏:即一个类中如果你不能够控制它其中内部类的生命周期(譬如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,这样的设计谁都得不到释放
总结
上边主要分析了四种内存泄漏例子和泄漏原因以及解决方案。 由于本人能力有限写得肯定有不对的地方,欢迎批评指正。
参考资料
- 分析内存使用情况
- 内存机制分析
- 性能优化-内存优化和布局优化
- 详解 Android 性能优化【史诗巨著之内存篇
更多相关文章
- Android(安卓)low memory killer 详解
- android的原理,为什么我们不需要手动关闭程序
- Android窗口管理分析(4):Android(安卓)View绘制内存的分配、传递、
- 5. Android(安卓)内存管理
- Android(安卓)高级面试题及答案,android试题及答案 如何对 Androi
- Android内存管理机制
- android内存处理机制
- Android(安卓)中下载文件到sdcard和进度条小结
- Android的内存泄漏和调试