Android上 ,Context可以用于很多操作,但是大部份时候是用来加载和使用资源。这就是为何所有的widgets在他们的构造函数中接受1个Context参数。在1般的android利用中,你通常有两种Context:分别是Activity和Application。通常的,当我们的类和方法需要使用到context时,我们传递的是Activity这个context。
这个例子展现了1个最简单的Context
泄漏的情况,你可以在Home screen 的源码中看到我们是如何解决这个问题的( 查找unbindDrawables() 方法) ,这就是当activity 被烧毁的时候将drawables 的回调设为null 。有趣的是,你可能创造出1系列context泄漏的情况有很多,这非常糟。他们会是你很快内存溢出。
有两种简单的方法来避免context 相干的内存泄漏。最显著地1个是避免context 逃出他自己的范围以外。上面的例子就展现了使用静态援用的情况,而内部类和他们对外部类的的隐式援用也是一样危险的。第2种方法是使用Application context 。这个context 的生存周期和你的利用的生存周期1样长,而不是取决于activity 的生存周期。如果你想保持1个长时间生存的对象,并且这个对象需要1个context ,记得使用application 对象。你可以通过调用Context.getApplicationContext()
or Activity.getApplication() 来取得。
总而言之,想要避免context 相干的内存泄漏 ,记住以下几点:
1、不要对activity 的context 长时间援用( 1个activity 的援用的生存周期应当和activity 的生命周期相同)
2、试着使用关于application的 context 来替换和activity相干的context
3、如果1个acitivity 的非静态内部类的生命周期不受控制,那末避免使用它;使用1个静态的内部类并且对 其中的activity 使用1个弱援用。解决这个问题的方法是使用1个静态的内部类,并且对它的外部类有1 WeakReference,就像在ViewRoot中内部类W所做的就是这么个例子。
4、垃圾回收器不能处理内存泄漏的保障