Fragment里面有list列表,快速切换Fragment,getActivity为null。getActivity是Fragment所依附的Activity,当Fragment的生命周期结束的时候,getActivity是返回null的。
so,Fragment中不推荐使用getActivity,必须判断是否为null和捕获空指针异常
解决办法:
Fragment中获取上下文Context一般使用全局Application
public class MyApp extends LitePalApplication {
/**
* 自定义的application中,临时存储application拥有的上下文Context。
* 在程序中,通过单利访问application的时候获取该上下文Context。
*/
private static MyApp instance;
@Override
public void onCreate() {
super.onCreate();
instance = this;
}
public static MyApp getInstance() {
return instance;
}
}
//填充数据
mAdapter = new RecyclerViewAdapter_jy_db_list(MyApp.getInstance(), mListAll);
mRecyclerView.setAdapter(mAdapter);
注意:Dialog的Context不能使用全局Application
参考:为什么Dialog不能用Application的Context
附录:Application,Activity,Service,ContentProvider等中的Context 适用范围
大家注意看到有一些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引用的持有,防止内存泄漏。能使用Application的context的时候尽量使用Application的,减少内存开支。
在Application的Context中还有getApplication和getApplicationContext
getApplication返回结果为Application,且不同的Activity和Service返回的Application均为同一个全局对象,在ActivityThread内部有一个列表专门用于维护所有应用的application