Android内存泄露在项目中出现情况较为频繁,如果严重的话可能会导致应用内存占用情况严重。
导致内存泄露的原因非常多,本文介绍下比较常见的context的引用导致的内存泄露!
Android界面比较多,基本都需要引用到context,平时用时不注意,在当前Activity直接传this,长期的结果就会出现较多释放不掉的类,导致内存泄露。
有时候虽然传入的是context对象,但组件需要的是Activity,如dialog。而有时候需要的只是简单的context就ok,我们也经常直接Activity.this传入。以下
为内存泄露的几种情况:
1) 传入的Context为Activity.this
private static TestService service;
public static DataSourceService getInstance(Context context)
{
synchronized (lock)
{
if (service == null)
{
service = new TestService(context);
}
return service;
}
}
2)在AsyncTask里面传入Activity,然后传入 new progressDialog(Context context),当Activity finish()之后AsyncTask showDidlog时就会出现内存泄露问题,
导致finish失败;
3)在Acitivity里面传入Acitivity.this 给dialog,在finish之后没有dismiss Dialog,这样也会导致Activity释放不了
那我们怎么选择传入怎样的context呢?怎么解决这个问题呢?
我们经常使用到两种context:
A)Activity.this 周期为当前Acitivity生命周期;
B)getApplicationContext() 周期为整个应用生命周期;
第一种情况是因为传入的Activity被static的类所引用,不管里面有没有界面显示,传入的Activity都释放不了,解决的办法就是传入getApplicationContext() ,类似
的如果不需要Activity来显示界面或者做只有Activity才能做的事情,那只需要传入getApplicationContext() 就能满足要求。
第二种情况是由于dialog是异步线程里面显示的,但它的界面显示却依赖于传入的Activity,所以Activity在调用finish时不会完全结束,无法释放,解决办法是通过在
Activity里面初始化AsyncTask时传入接口,然后使用回调的方式调用Activity里面的界面显示方法,当然,调用的时候需要判断组件是否被被设为null或者是否初始化。
第三种情况,就是在当前界面传入Activity.this给Dialog,在finish时没有调用dialog的dismiss(),这样也会导致Activity释放不了。所以在finish()里面要做一些
致空的操作。
以上在平时都是比较细节用法,可能对整个程序不会照成太大影响,但一个好的产品来源于对于细节的极致要求,细节决定成败!