内存泄露之常见问题解决--初级篇

身为一个段子猿,我决定来写写最近的学习心得。

1.简介

在整个Android开发过程中,内存泄露是导致OOM的一个重点因素。大概意思就是:GC无法回收原本应该被回收的对象,这个对象就引发了内存泄露。那有什么危害呢?手机的内存大小是有限的,如果不能释放的话,你就无法创建新的对象,你的新界面等等就无法正常运行,然后程序就OOM了(OutOfMemory)。

2.OOM以及内存泄露

OOM通俗点讲就是,你家里有2个厕所,本来你和你老婆用的话,都是够用的,有一天你不小心造人了,从此家里有了1+1=3个人了。一天的凌晨,你起床,发现肚子不舒服,“我要上厕所!”(请求系统分配空余内存给当前app)。咦,老婆你在里面啊,那我去下一家(系统开始分析你需要的内存以及空余内存,准备分配)。啊,儿子你也蹲着啊(完了,2个厕所都被人占着了,内存不足,boom!boom!你此时肯定是奔溃的,拉屎忍不住了,肯定要异常奔溃了。OOM,app程序异常退出了)。

那么内存泄露呢?比如你买了一堆可擦除的画板(画板=手机,画板空间有限=内存有限),刚开始你拿去画了一会画,慢慢的用了不少画板。此时你还在继续画,发现没有新的画板了,只好找刚才用过的,但是你发现用错了画笔,导致擦不掉!(不正常的使用context等导致内存泄露了,GC回收不了内存。)而且所以找遍了所有的画板,都没有找到空白的地方(分配不了新的空余内存给app),只好结束此次画画的事情(内存泄露导致内存不足,这个app程序OOM)。

3.配置

本篇是初级篇,就不过多描述理论性的东西了,大牛的文章都写过,本人就不再进行描述了。那么我们如何解决内存泄露的问题呢?对于小白的我们肯定想有一款简单易用、快速定位的内存泄露插件,那么我推荐LeakCanary傻瓜式检测工具给大家。

ok,第一步肯定是怎么在项目里引用这个呢?首先,Android studio的项目引用第三方库的方法你得知道。在build.gradle(下方图里的1位置,2位置不是哦)里如下2个引用。什么,为什么有2个?其实有3个呢,原因很简单,你总不会正式发布的包也加内存泄露吧?当然也可以正式发布时,把相关引用全都干掉。

dependencies {
    debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3‘
    releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3‘
}

引用完了,咱们开始做一些初始化操作。在你的Application的实现类写下下面2句。

/**
     * 内存泄露检测
     */
    private RefWatcher refWatcher;
    public static RefWatcher getRefWatcher(Context context) {
        TTApplication application = (TTApplication) context.getApplicationContext();
        return application.refWatcher;
    }
  @Override
    public void onCreate() {
        super.onCreate();
        refWatcher = LeakCanary.install(this);//内存泄露检测
}

然后在你的fragment的基类里加上这一句

  @Override
    public void onDestroy() {
        RefWatcher refWatcher = TTApplication.getRefWatcher(getActivity());
        refWatcher.watch(this);//内存泄露检测
    }

好了,我们的配置全部完成了,是不是so easy?先休息一下看个美腿。







哦,不好意思放错了。

4.常见内存泄露

下面就念咒语“哦玛尼玛尼哄”,”奔跑吧我的app”,”出来吧,万恶的内存泄露”。(看下图)

如果出现内存泄露,上方会有盾牌的通知消息(1位置),点击后可以进入详情界面(2位置)。

上方的图片里我们能找到一些蛛丝马迹,比如这个回调导致内存泄露了。我回忆了下代码,因为本人这个项目是MVP模式,P层持有activity的context以及IView接口。常见的泄露基本都是上下文的持有导致的,所以应对这一点,我采用P层持有弱引用的方式。弱引用,只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中,一旦发现了只具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。此外,刚才的回调接口也需要设置null。这样在activity销毁时onDestroy方法里调用下面的destroy方法即可。重要的一点是,网络请求在界面销毁时最好进行cancel操作,比如volly框架的根据请求tag进行取消,这样也是尽量避免接口回调导致的内存泄露。此外,动画在界面离开时或者销毁时,同时进行暂停或者销毁。

private WeakReference<ShoppingCartActivity> mBaseActivity;
  private IShoppingCartView mIShoppingCartView;
    public ShoppingCartPresenter(ShoppingCartActivity context, IShoppingCartView
            iShoppingCartView) {
        mBaseActivity = new WeakReference<>(context);
        mIShoppingCartView = iShoppingCartView;
    }
     @Override
    public void destroy() {
        mIShoppingCartView = null;
    }

还有一种常见的就是handler的使用。通常我们直接new一个就完事了,Android studio会显示大大的黄色警告区域。此时就需要利用静态内部类以及弱引用解决了。平常需要context的地方就可以用 mActivity.get()代替了。

static class CommentHandler extends Handler {
        WeakReference<HomeActivity> mActivity;

        CommentHandler(HomeActivity activity) {
            mActivity = new WeakReference<>(activity);
        }

        public void handleMessage(Message msg) {
            super.handleMessage(msg);

        }
    }

在App不可避免的是webview加载网页了,然后这个也是一个可怕的开始。webview界面内存泄露解决,不要xml设置webview,而是以代码创建view对象的方式进行初始化,并且界面销毁时调用 destroy等方法 。

    WebView  mWebView  =new WebView (this);

  @Override
    protected void onDestroy() {
        if (mWebView != null) {
            mWebView.getSettings().setBuiltInZoomControls(true);
            mWebView.setVisibility(View.GONE);// 把destroy()延后
            mWebView.removeAllViews();
            mWebView.destroy();
        }
        super.onDestroy();
    }

此外,Toast最好用ApplicationContext,如果用activity的context,吐司还没结束的时候退出当前界面,这是内存也会泄露。

至于context与bitmap之间的点滴,我用了fresco图片加载框架,还算好。而且这方面资料也不少,我暂时也不准备描述了。

好了,LeakCanary的简单使用就到这里了。下次再来深度分析内存泄露的点点滴滴。

时间: 2024-04-19 17:01:36

内存泄露之常见问题解决--初级篇的相关文章

JAVA内存溢出与内存泄露

虽然jvm可以通过GC自动回收无用的内存,但是代码不好的话仍然存在内存溢出的风险. 最近在网上搜集了一些资料,现整理如下: —————————————————————————————————————————— 一.为什么要了解内存泄露和内存溢出? 1.内存泄露一般是代码设计存在缺陷导致的,通过了解内存泄露的场景,可以避免不必要的内存溢出和提高自己的代码编写水平: 2.通过了解内存溢出的几种常见情况,可以在出现内存溢出的时候快速的定位问题的位置,缩短解决故障的时间. 二.基本概念 理解这两个概念非

java内存溢出和内存泄露

虽然jvm可以通过GC自动回收无用的内存,但是代码不好的话仍然存在内存溢出的风险. 最近在网上搜集了一些资料,现整理如下: —————————————————————————————————————————— 一.为什么要了解内存泄露和内存溢出? 1.内存泄露一般是代码设计存在缺陷导致的,通过了解内存泄露的场景,可以避免不必要的内存溢出和提高自己的代码编写水平: 2.通过了解内存溢出的几种常见情况,可以在出现内存溢出的时候快速的定位问题的位置,缩短解决故障的时间. 二.基本概念 理解这两个概念非

[Android Memory] App调试内存泄露之Context篇(下)

转载地址:http://www.cnblogs.com/qianxudetianxia/p/3655475.html 5. AsyncTask对象 我N年前去盛大面过一次试,当时面试官极力推荐我使用AsyncTask等系统自带类去做事情,当然无可厚非. 但是AsyncTask确实需要额外注意一下.它的泄露原理和前面Handler,Thread泄露的原理差不多,它的生命周期和Activity不一定一致. 解决方案是:在activity退出的时候,终止AsyncTask中的后台任务. 但是,问题是如

raywenderlich写的关于内存管理,第二篇,关于如何检查内存泄露

原文链接地址:http://www.raywenderlich.com/2696/how-to-debug-memory-leaks-with-xcode-and-instruments-tutorial 著作权声明:本文由http://www.cnblogs.com/andyque翻译,欢迎转载分享.请尊重作者劳动,转载时保留该声明和作者博客链接,谢谢! 教程截图: 作为一名无证程序员,无论你多么精通Objective-C的内存管理,随着时间的推移,你也不可避免的犯内存相关的错误.但通常因为代

android中的内存泄露查找与常见的内存泄露案例分析

常见的内存泄露查找方法请参见:http://hukai.me/android-performance-patterns/ 这篇文章是google发布的android性能优化典范示例,对于渲染.内存GC与电量消耗都做了好的示范. 这里我总结了下,android中常见的内存泄露 1.类中调用registerReceiver后未调用unregisterReceiver(). 在调用registerReceiver后,若未调用unregisterReceiver,其所占的内存是相当大的. 这种情况常见于

JS高程中的垃圾回收机制与常见内存泄露的解决方法

起因是因为想了解闭包的内存泄露机制,然后想起<js高级程序设计>中有关于垃圾回收机制的解析,之前没有很懂,过一年回头再看就懂了,写篇博客与大家分享一下. #内存的生命周期: 分配你所需要的内存: 由于字符串.对象等没有固定的大小,js程序在每次创建字符串.对象的时候,程序都会分配内存来存储那个实体. 使用分配到的内存做点什么. 不需要时将其释放回归: 在不需要字符串.对象的时候,需要释放其所占用的内存,否则将会消耗完系统中所有可用的内存,造成系统崩溃,这就是垃圾回收机制所存在的意义. 所谓的内

[Android Memory] App调试内存泄露之Context篇(上)

转载自:http://www.cnblogs.com/qianxudetianxia/p/3645106.html Context作为最基本的上下文,承载着Activity,Service等最基本组件.当有对象引用到Activity,并不能被回收释放,必将造成大范围的对象无法被回收释放,进而造成内存泄漏. 下面针对一些常用场景逐一分析. 1. CallBack对象的引用 先看一段代码: @Override protectedvoid onCreate(Bundle state){ super.o

内存泄露从入门到精通三部曲之常见原因与用户实践

腾讯Bugly特约作者: 姚潮生 常见原因 1.集合类 集合类如果仅仅有添加元素的方法,而没有相应的删除机制,导致内存被占用.如果这个集合类是全局性的变量 (比如类中的静态属性,全局性的 map 等即有静态引用或 final 一直指向它),那么没有相应的删除机制,很可能导致集合所占用的内存只增不减. 2.单例模式 不正确使用单例模式是引起内存泄露的一个常见问题,单例对象在被初始化后将在 JVM 的整个生命周期中存在(以静态变量的方式),如果单例对象持有外部对象的引用,那么这个外部对象将不能被 J

内存泄露从入门到精通三部曲之排查方法篇

内存泄露从入门到精通三部曲之排查方法篇 最原始的内存泄露测试 重复多次操作关键的可疑的路径,从内存监控工具中观察内存曲线,是否存在不断上升的趋势且不会在程序返回时明显回落.这种方式可以发现最基本,也是最明显的内存泄露问题,对用户价值最大,操作难度小,性价比极高. MAT内存分析工具 2.1 MAT分析heap的总内存占用大小来初步判断是否存在泄露 在Devices 中,点击要监控的程序. 点击Devices视图界面中最上方一排图标中的“Update Heap” 点击Heap视图 点击Heap视图