Android Context 干货

2022-02-09 20:32:56

image.png

一、源码角度解析Context

从系统的角度来理解：Context是一个场景，代表与操作系统的交互的一种过程。
Context是一个抽象类；
Activity、Service、Application是它的子类；

image.png

二、Context 应用场景

image.png

数字1：启动Activity在这些类中是可以的，但是需要创建一个新的task。一般情况不推荐。
数字2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。
数字3：在receiver为null时允许，在4.2或以上的版本中，用于获取黏性广播的当前值。（可以无视）
注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因为在其内部方法中都有一个context用于使用。

默认的Toast实际上使用ApplicationContext也可以，因为总有时候在异步线程中做了一些土司操作，这种情况下在Activity关闭时候，很容易造成context为空的情况，所以所有的土司都采用ApplicationContext。

四、Fragment 中 Context 的获取

在Fragment的生命周期中，在生命周期处于onAttach()和onDetach()之间的时候getActivity()方法才不会返回null。因此我们可以在fragment初始化的时候建立Context引用。在fragment销毁的时候销毁引用。代码如下：

private Context mContext;

Override
public void onAttach(Context context) {
    super.onAttach(context);
    mContext = context;//mContext 是成员变量，上下文引用
}

Override
public void onDetach() {
    super.onDetach();
    mContext = null;
}

注意：Activity 中有的onAttach有两个方法

void onAttach(Activity activity);
void onAttach(Context context);

五、Context 引发的内存泄露解决

不要让生命周期长于Activity的对象持有到Activity的引用
尽量使用Application的Context而不是Activity的Context。
尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用（具体可以查看细话Java：”失效”的private修饰符了解）。如果使用静态内部类，将外部实例引用作为弱引用持有。

解决的方法就是不持有Activity的引用，而是持有Application的Context引用。获取方式查看ContextHolder方式。下面会介绍。

单例模式用application的context。
如果我们在Activity A中或者其他地方使用Foo.getInstance()时，我们总是会顺手写一个『this』或者『mContext』（这个变量也是指向this）。试想一下，当前我们所用的Foo是单例，意味着被初始化后会一直存在与内存中，以方便我们以后调用的时候不会在此次创建Foo对象。但Foo中的『mContext』变量一直都会持有Activity A中的『Context』，导致Activity A即使执行了onDestroy方法，也不能够将自己销毁。但『applicationContext』就不同了，它一直伴随着我们应用存在（中途也可能会被销毁，但也会自动reCreate），所以就不用担心Foo中的『mContext』会持有某Activity的引用，让其无法销毁。

实际上，只要把握住一点，凡是跟UI相关的，都应该使用 Activity做为Context来处理(吐司除外)；其他的一些操作，Service,Activity,Application等实例都可以，当然了，注意 Context引用的持有，防止内存泄漏。

六、获取Context的四种方式方式

View.getContext,返回当前View对象的Context对象，通常是当前正在展示的Activity对象。
Activity.getApplicationContext,获取当前Activity所在的(应用)进程的Context对象，通常我们使用Context对象时，要优先考虑这个全局的进程Context。
ContextWrapper.getBaseContext():用来获取一个ContextWrapper进行装饰之前的Context，可以使用这个方法，这个方法在实际开发中使用并不多，也不建议使用。
Activity.this 返回当前的Activity实例，如果是UI控件需要使用Activity作为Context对象，但是默认的Toast实际上使用ApplicationContext也可以。

七、第三方库通用的获取Context方式

首先我们构造一个存储Context的类ContextHolder，在Application初始化时将Application传入ContextHolder，这个方法在很多第三方库都能见到类似的处理。

public class ContextHolder {
    static Context ApplicationContext;
    public static void initial(Context context) {
        ApplicationContext = context;
    }
    public static Context getContext() {
        return ApplicationContext;
    }
}

public class App extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        ContextHolder.initial(this);
    }
}

这样我们就能在任意位置调用ContextHolder.getContext()来获取应用Context。

那么有没有可能不需要任何初始化操作就能完成这个需求呢？笔者做了一些尝试。
由于实际上获取应用Context也就是获取当前应用实例，经笔者研究下面2种方法都可以通过反射直接获取当前应用。

try {    
    Application application = (Application) Class.forName("android.app.ActivityThread").getMethod("currentApplication").invoke(null, (Object[]) null);    
} catch (Exception e) {    
    e.printStackTrace();
}

try {    
    Application application = (Application) Class.forName("android.app.AppGlobals").getMethod("getInitialApplication").invoke(null, (Object[]) null);    
} catch (Exception e) {    
    e.printStackTrace();
}

经测试，即使应用处于后台仍能正确获取到调用此方法的Application。

参考：
http://blog.csdn.net/lmj623565791/article/details/40481055
http://www.jianshu.com/p/9d75e328f1de
http://www.jianshu.com/p/808b9d92d6cd
http://blog.nimbledroid.com/2016/05/23/memory-leaks-zh.html

码农公寓

一、源码角度解析Context

二、Context 应用场景

四、Fragment 中 Context 的获取

五、Context 引发的内存泄露解决

六、获取Context的四种方式方式

七、第三方库通用的获取Context方式

相关文章