Android Context 干货

Android Context 干货
image.png

一、源码角度解析Context

从系统的角度来理解:Context是一个场景,代表与操作系统的交互的一种过程。
Context是一个抽象类;
ActivityServiceApplication是它的子类;

Android Context 干货
image.png


二、Context 应用场景

Android 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

上一篇:淘宝群发思路


下一篇:如何建构知识体系?