Fragment里面Context为null的解决办法

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

Fragment里面Context为null的解决办法

猜你喜欢