Context相关内存泄露问题
2016-11-27 本文已影响0人
模块米次访问法撒旦法地方
- 单例模式
在单例模式下如果需要获取Context相关对象,由于会长期持有该对象,会导致相关对象无法被回收,从而引起内存泄露问题,所以经量通过该Context获取ApplicationContext对象使用,由于ApplicationContext会存在整个app生命周期中,所以长期持有不会导致内存泄露。
-
匿名内部类使用问题
通常在Activity中会创建Handler对象,执行某些方法,而当Activity被finish时,未被处理的方法会被保存10分钟左右,从而导致Activity无法被销毁。所以应该创建一个静态内部类,通过WeakReference获取相关引用,避免内存泄露。
还可以在onDestroy中调用handler的removeCallbacksAndMessages(null),删除所有与该Handler对象相关的Runnable和Message
-
开发中需要注意的点以免内存泄漏
- 不要让生命周期长于Activity的对象持有到Activity的引用
- 尽量使用Application的Context而不是Activity的Context
- 尽量不要在Activity中使用非静态内部类,因为非静态内部类会隐式持有外部类实例的引用(具体可以查看细话Java:”失效”的private修饰符了解)。如果使用静态内部类,将外部实例引用作为弱引用持有。
- 垃圾回收不能解决内存泄露,了解Android中垃圾回收机制
-
获取context的方法,以及使用上context和applicationContext的区别
- View.getContext,返回当前View对象的Context对象,通常是当前正在展示的Activity对象。
- Activity.getApplicationContext,获取当前Activity所在的(应用)进程的Context对象,通常我们使用Context对象时,要优先考虑这个全局的进程Context。
- ContextWrapper.getBaseContext():用来获取一个ContextWrapper进行装饰之前的Context,可以使用这个方法,这个方法在实际开发中使用并不多,也不建议使用。
- Activity.this 返回当前的Activity实例,如果是UI控件需要使用Activity作为Context对象,但是默认的Toast实际上使用ApplicationContext也可以。
大家注意看到有一些NO上添加了一些数字,其实这些从能力上来说是YES,但是为什么说是NO呢?下面一个一个解释:
数字1:启动Activity在这些类中是可以的,但是需要创建一个新的task。一般情况不推荐。
数字2:在这些类中去layout inflate是合法的,但是会使用系统默认的主题样式,如果你自定义了某些样式可能不会被使用。
数字3:在receiver为null时允许,在4.2或以上的版本中,用于获取黏性广播的当前值。(可以无视)
ContentProvider、BroadcastReceiver之所以在上述表格中,是因为在其内部方法中都有一个context用于使用。
好了,这里我们看下表格,重点看Activity和Application,可以看到,和UI相关的方法基本都不建议或者不可使用 Application,并且,前三个操作基本不可能在Application中出现。实际上,只要把握住一点,凡是跟UI相关的,都应该使用 Activity做为Context来处理;其他的一些操作,Service,Activity,Application等实例都可以,当然了,注意 Context引用的持有,防止内存泄漏。