关闭

Android 内存泄露与优化,以及MAT工具

标签: android内存mat
1421人阅读 评论(2) 收藏 举报
分类:

一.介绍
Android机器中,内存使用问题一直是个十分重要,引人注目的问题,当我们代码编写不当,或者逻辑没处理好,就会导致机器运行缓慢,有时候甚至死机。对于程序员来说,这很致命,所以要去理解内存的使用,去避免内存的泄露,不断优化内存,而当出现内存泄露导致的问题,我们能够分析log,并且会用工具MAT。

二.什么场景会导致内存泄露
内存泄露其实就是占用内存的对象使用后没有被回收。在这种现象下,当java程序运行一段时间,占用的内存越来越大,导致该进程的内存占用达到Android为进程分配的内存使用上限,程序就死了。

  1. ListView、GridView等在使用适配器时,没有使用ConvertView缓存
  2. Bitmap使用后没有释放
  3. Context泄露,Context的引用超过了本身的生命周期。比如一个长时间在跑的异步任务或者长时间的对象,拥有着Activity(Context类型)的引用,这时Activity被销毁了,但是内存依然存在,Context无法被回收。所以这种情况下,应使用getApplicationContext比较好
  4. 数据库游标或者文件流缓存等使用后未关闭
  5. 线程使用不当。在线程中的run函数处理着耗时的工作,当设备横竖屏切换,重新创建Activity,由于run函数未处理完,导致引用的Activity也不会被销毁。再说AsyncTask,由于运行机制ThreadPoolExcutor,生命周期更加不可控,更容易出现问题了(具体解决方法,可看下面讲解)。

三.内存优化注意点

1.图片优化
在Android中显示Bitmap图片,会造成一定的内存消耗,甚至会导致OOM异常爆发,所以对于图片的显示,要做一定的处理。

  • 大图片显示要进行压缩才能加载。一张图片,不要认为表面的小而不以为然,比如一张150kb的图片,当读到内存时,若该图片像素为2048*1024,使用属性为ARGB_8888(默认),也就是一个像素4byte,那么总内存就是4*2048*1024byte,8M多。可见,大图片压缩加载的必要性。具体压缩详细方法可见 Android高效加载大图,防止OOM,以及多图解决方案
  • 多图显示时要活用内存缓存技术。在一个ListView(或GridView)中,不断加载图片,不可能一直把图片都到内存中,因为内存是有上限值的,也要为其他操作分配内存。所以当在可见区域里,要将移除屏幕的部分内存进行回收处理。可若移除的部分在下个操作中又要马上使用,这时若被移除回收,性能效率马上就下去了,所以可以使用LRUCache缓存技术。具体可见以上那篇博文。
  • ListView中的快速滑动加载图片,在不影响使用体验的情况下,应判断滑动状态进行加载操作。在快速滑动时,由于滑动过程中加载的资源是不会被使用的,反而影响了用户所要查看资源的加载,所以在快速滑动(SCROLL_STATE_TOUCH_SCROLL)列表时,就不再去获取加载资源了,在静止(SCROLL_STATE_IDLE)以及触摸屏幕(SCROLL_STATE_TOUCH_SCROLL)时才去加载,我们需要注册一个滚动监听器OnScrollListener 。

2.线程、异步任务优化
因为线程、异步任务等生命周期的不可控性,成为了内存泄露的另一个源头。平常中,因为对它的频繁使用,所以,我们应慎重对待它。

  • 在Activity结束时,应及时销毁所创建的线程。不然,当线程持有该所在Activity的引用时,实际上以为退出去的Activity,其实由于线程未完成,所引用的老Activity是不会被销毁的,就出现了内存泄露,所以可使用Thread.interrupt()中断线程,虽然并不是真正意义上的中断!具体详细可见 Thread的中断机制(interrupt)
  • AsyncTask异步任务的生命周期不可控性。一定得注意一件事,因为平常喜欢在Activity中创建AsyncTask作为内部类,完成一些耗时且Ui交互的操作,十分方便,但是其实这个是具有很大风险的,因为很容易出现内存泄露。异步任务内部是以ThreadPoolExcutor作为实现机制的,这样出来的线程对象生命周期是不确定的!!网上有人给出两个解决方案:1.将线程的内部类改为静态内部类(没试过,不知道效果) 2.在线程内部采用弱引用保存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  
       }  
}  

可能内存优化方面,还有很多方面需要补足,还需努力。

四.内存分析
不管是对内存使用情况的分析,还是排查内存泄露,我都推荐
去好好看看以下大神的文章,相信看过后,会有很大的收获,我就是如此=。=

在此记录,以备日后再读。

3
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:46605次
    • 积分:947
    • 等级:
    • 排名:千里之外
    • 原创:25篇
    • 转载:3篇
    • 译文:1篇
    • 评论:47条
    最新评论