一.介绍
Android机器中,内存使用问题一直是个十分重要,引人注目的问题,当我们代码编写不当,或者逻辑没处理好,就会导致机器运行缓慢,有时候甚至死机。
对于程序员来说,这很致命,所以要去理解内存的使用,去避免内存的泄露,不断优化内存,而当出现内存泄露导致的问题,我们能够分析log,并且会用工具MAT。
二.什么场景会导致内存泄露
内存泄露其实就是占用内存的对象使用后没有被回收。在这种现象下,当java程序运行一段时间,占用的内存越来越大,导致该进程的内存占用达到Android为进程分配的内存使用上限,程序就死了。
- ListView、GridView等在使用适配器时,没有使用ConvertView缓存
- Bitmap使用后没有释放
- Context泄露。Context的引用超过了本身的生命周期。比如一个长时间在跑的异步任务或者长时间的对象,拥有着Activity(Context类型)的引用,这时Activity被销毁了,但是内存依然存在,Context无法被回收。所以这种情况下, 可以使用getApplicationContext比较好,或者弱引用Context
- 数据库游标或者文件流缓存等使用后未关闭
- 线程使用不当。在线程中的run函数处理着耗时的工作,当设备横竖屏切换,重新创建Activity,由于run函数未处理完,导致引用的Activity也不会被销毁。再说AsyncTask,由于运行机制ThreadPoolExcutor,生命周期更加不可控,更容易出现问题了(具体解决方法,可看下面讲解)。
- Rxjava订阅与反订阅
- BraodcastReceiver等在生命周期结束后一定要记得unregidter
三.内存优化注意点
1.图片优化
在Android中显示Bitmap图片,会造成一定的内存消耗,甚至会导致OOM异常爆发,所以对于图片的显示,要做一定的处理。
- 大图片显示要进行压缩才能加载。一张图片,不要认为表面的小而不以为然,比如一张150kb的图片,当读到内存时,若该图片像素为20481024,使用属性为ARGB_8888(默认),也就是一个像素4byte,那么总内存就是42048*1024byte,8M多。可见,大图片压缩加载的必要性。具体压缩详细方法可见 Android高效加载大图,防止OOM,以及多图解决方案
- 多图显示时要活用内存缓存技术。在一个ListView(或GridView)中,不断加载图片,不可能一直把图片都到内存中,因为内存是有上限值的,也要为其他操作分配内存。所以当在可见区域里,要将移除屏幕的部分内存进行回收处理。可若移除的部分在下个操作中又要马上使用,这时若被移除回收,性能效率马上就下去了,所以可以使用LRUCache缓存技术。具体可见以上那篇博文。
- ListView中的快速滑动加载图片,在不影响使用体验的情况下,应判断滑动状态进行加载操作。在快速滑动时,由于滑动过程中加载的资源是不会被使用的,反而影响了用户所要查看资源的加载,所以在快速滑动(SCROLL_STATE_TOUCH_SCROLL)列表时,就不再去获取加载资源了,在静止(SCROLL_STATE_IDLE)以及触摸屏幕(SCROLL_STATE_TOUCH_SCROLL)时才去加载,我们需要注册一个滚动监听器OnScrollListener 。
- 由于图片占用内存的缘故,所以一些内置资源的图片可以经过tinyPng处理,再放到app里加载。通常的压缩率可以达到50%以上,意思是150kb的图片处理后至少能减少到75kb以下,而且不失真。降低了内存的占用,同时达到APK瘦身的效果。TinyPng入口地址
2.线程、异步任务优化
因为线程、异步任务等生命周期的不可控性,成为了内存泄露的另一个源头。平常中,因为对它的频繁使用,所以,我们应慎重对待它。
- 在Activity结束时,应及时销毁所创建的线程。不然,当线程持有该所在Activity的引用时,实际上以为退出去的Activity,其实由于线程未完成,所引用的老Activity是不会被销毁的,就出现了内存泄露,所以可使用Thread.interrupt()中断线程,虽然并不是真正意义上的中断!具体详细可见 Thread的中断机制(interrupt),这个机制到底做了些什么呢?原来Thread.interrupt()方法不会中断一个正在运行的线程。这一方法实际上完成的是,设置线程的中断标示位,在线程受到阻塞的地方(如调用sleep、wait、join等地方)抛出一个异常InterruptedException,并且中断状态也将被清除,这样线程就得以退出阻塞的状态。
- AsyncTask异步任务的生命周期不可控性。一定得注意一件事,因为以前很喜欢在Activity中创建AsyncTask作为内部类,完成一些耗时且Ui交互的操作,十分方便,但是其实这个是具有很大风险的,因为很容易出现内存泄露。异步任务内部是以ThreadPoolExcutor作为实现机制的,这样出来的线程对象生命周期是不确定的!!
解决方案:在线程内部采用弱引用保存Context引用。即如下代码所示:
public abstract class WeakAsyncTask < Params,Progress,Result,WeakTarget >
extends AsyncTask < Params,Progress,Result > {
protected WeakReference < WeakTarget > mTarget;
public WeakAsyncTask(WeakTarget target) {
mTarget = new WeakReference < WeakTarget > (target);
}
/** {@inheritDoc} */
@Override protected final void onPreExecute() {
final WeakTarget target = mTarget.get();
if (target != null) {
this.onPreExecute(target);
}
}
/** {@inheritDoc} */
@Override protected final Result doInBackground(Params...params) {
final WeakTarget target = mTarget.get();
if (target != null) {
return this.doInBackground(target, params);
} else {
return null;
}
}
/** {@inheritDoc} */
@Override protected final void onPostExecute(Result result) {
final WeakTarget target = mTarget.get();
if (target != null) {
this.onPostExecute(target, result);
}
}
protected void onPreExecute(WeakTarget target) {
// No default action
}
protected abstract Result doInBackground(WeakTarget target, Params...params);
protected void onPostExecute(WeakTarget target, Result result) {
// No default action
}
}
所以内存优化方面,还有很多方面需要补足,还需努力。
四.内存分析
不管是对内存使用情况的分析,还是排查内存泄露与溢出,我都推荐去好好看看以下大神的文章,相信看过后,会有很大的收获,我就是如此=。=
android 中如何分析内存泄露
Android最佳性能实践(二)——分析内存的使用情况
小小的总结与推荐阅读,希望可以帮助到大家~
Ps:以前博客迁移到简书,如果你觉得文章还可以,麻烦底下点个“喜欢”!