一、什么是Context
二、Context的创建时机和获取
　　1. Context的创建时机
　　2. Context的获取
三、Application使用相关问题
　　1. 什么时候初始化全局变量
　　2. 自定义Application？
四、Context引起的内存泄露

---

Android应用都是使用Java语言来编写的，本质上也是一个对象，那么Activity可以new吗？一个Android程序和一个Java程序，他们最大的区别在哪里？划分界限又是什么呢？其实简单点分析，Android程序不像Java程序一样，随便创建一个类，写个main()方法就能跑了，Android应用模型是基于Activity、Service、BroadcastReceiver等组件的应用设计模式，组件的运行要有一个完整的Android工程环境，在这个环境下，这些组件并不是像一个普通的Java对象new一下就能创建实例的了，而是要有它们各自的上下文环境Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。

什么是Context

一个Activity是一个Context，一个Service也是一个Context。在程序中，我们把可以把Context理解为当前对象在程序中所处的一个环境，一个与系统交互的过程。用户和操作系统的每一次交互都是一个场景，比如微信聊天，此时的“环境”是指聊天的界面以及相关的数据请求与传输，Context在加载资源、启动Activity、获取系统服务、创建View等操作都要参与。打电话、发短信，这些都是一个有界面的场景，还有一些没有界面的场景，比如后台运行的服务（Service）。一个应用程序可以认为是一个工作环境，用户在这个环境中会切换到不同的场景，这就像一个前台秘书，她可能需要接待客人，可能要打印文件，还可能要接听客户电话，而这些就称之为不同的场景，前台秘书可以称之为一个应用程序。下面我们来看一下Context的继承结构：

Context类，一个纯Abstract类，有ContextImpl和ContextWrapper两个实现类：

• ContextWrapper包装类
  其构造函数中必须包含一个真正的Context引用。ContextWrapper中提供了attachBaseContext()（由系统调用）方法，用于给ContextWrapper对象中指定真正的Context对象，即ContextImpl对象，调用ContextWrapper的方法都会被转向ContextImpl的方法。
• ContextImpl类
  上下文功能的实现类。
• ContextThemeWrapper类
  一个带主题的封装类，其内部包含了与Theme相关的接口，这里所说的主题是指在AndroidManifest.xml中通过android:theme为Application元素或者Activity元素指定的主题。当然，只有Activity才需要主题，Service是不需要主题的，因为Service是没有界面的后台场景，所以Service直接继承于ContextWrapper，Application同理。

总结：Context的两个子类分工明确，其中ContextImpl是Context的具体实现类，ContextWrapper是Context的包装类。Activity，Application，Service虽都继承自ContextWrapper，但它们初始化的过程中都会创建ContextImpl对象，由ContextImpl实现Context中的方法。
　　那么，Context到底可以实现哪些功能呢？这个就实在是太多了，弹出Toast、启动Activity、启动Service、发送广播、操作数据库等等都需要用到Context。由于Context的具体能力是由ContextImpl类去实现的，因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的，但在使用场景上是有一些规则，以下表格中列出了各Context的使用场景：

以上表格中NO上添加了一些数字，其实这些从能力上来说是YES，但是为什么说是NO呢？下面一个一个解释：

• NO^1：启动Activity在这些类中是可以的，但是需要创建一个新的task。不推荐。
  如果我们用Application Context或Service Context去启动一个LaunchMode为standard的Activity的时候会报错，这是因为非Activity类型的Context并没有所谓的任务栈，所以待启动的Activity就找不到栈了。解决这个问题的方法就是为待启动的Activity指定FLAG_ACTIVITY_NEW_TASK标记位，这样启动的时候就为它创建一个新的任务栈，而此时Activity是以singleTask模式启动的。
• NO^2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。不推荐。

所以：

• 凡是跟UI相关的，都应使用Activity做为Context来处理；其他的一些操作，Service,Activity,Application等都可以，当然得注意Context引用的持有，防止内存泄漏。
  比如启动Activity，还有弹出Dialog。出于安全原因的考虑，Android是不允许Activity或Dialog凭空出现的，一个Activity的启动必须要建立在另一个Activity的基础之上，也就是以此形成的返回栈。而Dialog则必须在一个Activity上面弹出（除非是System Alert类型的Dialog），因此在这种场景下，我们只能使用Activity类型的Context，否则将会出错。

了解了Context，那在一个应用程序中，Context的数量又是多少呢？由以上的介绍可以知道：**Context数量 = Activity数量 + Service数量 + 1 **

Context的创建时机和获取

1.Context的创建时机

（1）创建Application对象的时机
　　每个应用程序在第一次启动时，都会首先创建Application对象。在应用程序启动一个Activity(startActivity)的流程中，创建Application的时机是创建handleBindApplication()方法中，该函数位于 ActivityThread.java类中，如下：

//创建Application时同时创建的ContextIml实例
  private final void handleBindApplication(AppBindData data){
      …
      ///创建Application对象
      Application app = data.info.makeApplication(data.restrictedBackupMode, null);
      …
  }
  public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) {
      …
     try {
         java.lang.ClassLoader cl = getClassLoader();
         ContextImpl appContext = new ContextImpl();    //创建一个ContextImpl对象实例
         appContext.init(this, null, mActivityThread);  //初始化该ContextIml实例的相关属性
         ///新建一个Application对象
         app = mActivityThread.mInstrumentation.newApplication(
                 cl, appClass, appContext);
        appContext.setOuterContext(app);  //将该Application实例传递给该ContextImpl实例
     }
     …
 }

（2）创建Activity对象的时机
　　通过startActivity()或startActivityForResult()请求启动一个Activity时，如果系统检测需要新建一个Activity对象时，就会回调handleLaunchActivity()方法，该方法继而调用performLaunchActivity()方法，去创建一个Activity实例，并且回调onCreate()，onStart()方法等， 函数都位于 ActivityThread.java类 ，如下：

//创建一个Activity实例时同时创建ContextIml实例
private final void handleLaunchActivity(ActivityRecord r, Intent customIntent) {
    …
    Activity a = performLaunchActivity(r, customIntent);  //启动一个Activity
}
private final Activity performLaunchActivity(ActivityRecord r, Intent customIntent) {
    …
    Activity activity = null;
    try {
        //创建一个Activity对象实例
        java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
        activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
    }
    if (activity != null) {
        ContextImpl appContext = new ContextImpl();      //创建一个Activity实例
        appContext.init(r.packageInfo, r.token, this);   //初始化该ContextIml实例的相关属性
        appContext.setOuterContext(activity);            //将该Activity信息传递给该ContextImpl实例
        …
    }
    …
}

（3）创建Service对象的时机
　　通过startService或者bindService时，如果系统检测到需要新创建一个Service实例，就会回调handleCreateService()方法，完成相关数据操作。handleCreateService()函数位于 ActivityThread.java类，如下：

//创建一个Service实例时同时创建ContextIml实例
private final void handleCreateService(CreateServiceData data){
    …
    //创建一个Service实例
    Service service = null;
    try {
        java.lang.ClassLoader cl = packageInfo.getClassLoader();
        service = (Service) cl.loadClass(data.info.name).newInstance();
    } catch (Exception e) {
    }
    …
    ContextImpl context = new ContextImpl(); //创建一个ContextImpl对象实例
    context.init(packageInfo, null, this);   //初始化该ContextIml实例的相关属性
    //获得我们之前创建的Application对象信息
    Application app = packageInfo.makeApplication(false, mInstrumentation);
    //将该Service信息传递给该ContextImpl实例
    context.setOuterContext(service);
    …
}

另外，通过对ContextImp的分析可知，其方法的大多数操作都是直接调用其属性mPackageInfo(该属性类型为PackageInfo)的相关方法而来。这说明ContextImp是一种轻量级类，而PackageInfo才是真正重量级的类。而一个App里的所有ContextIml实例，都对应同一个packageInfo对象。

2.Context的获取

（1）通常我们想要获取Context对象，主要有以下四种方法

• View.getContext，返回当前View对象的Context对象，通常是当前正在展示的Activity对象
• Activity.getApplicationContext，获取的context来自允许在应用(进程)application中的所有Activity，当你需要用到的Context超出当前Activity的生命周期时使用
• Activity.this 返回当前的Activity实例，如果是UI控件需要使用Activity作为Context对象，但是默认的Toast实际上使用ApplicationContext也可以
• ContextWrapper.getBaseContext()用来获取一个ContextWrapper进行装饰之前的Context，也就是ContextImpl对象，如果想获取另一个可以访问的application里面的Context时可以使用

（2）再来看看getApplication()和getApplicationContext()
　　这两个方法有什么区别呢？看看以下结果：

通过上面的代码，可以看到它们是同一个对象。其实这个结果也很好理解，因为前面已经说过了，Application本身就是一个Context，所以这里获取getApplicationContext()得到的结果就是Application本身的实例。那么问题来了，既然这两个方法得到的结果都是相同的，那么Android为什么要提供两个功能重复的方法呢？实际上这两个方法在作用域上有比较大的区别。
　　getApplication()方法的语义性非常强，一看就知道是用来获取Application实例的，但这个方法只有在Activity和Service中才能调用。如果在一些其它的场景，比如BroadcastReceiver中也想获得Application的实例，这时就需要借助getApplicationContext()方法了。也就是说，getApplicationContext()方法的作用域会更广一些，任何一个Context的实例，只要调用getApplicationContext()方法都可以拿到我们的Application对象。
（3）getActivity()和getContext()

• getActivity()返回Activity，getContext()返回Context；
• 两者是Fragment的方法，但Activity没有，多数情况下两者没有什么区别，但新版Support Library包，Fragment不被Activity持有时，区别见这里；
• 参数是context的，可以使用getActivity() 。因为Activity间接继承了Context，但Context不是Activity；
• this和getContext() 并不是完全相同。在Activity类中可以使用this，因为Activity继承自Context，但是getContext()方法不在Activity类中。

Application使用相关问题

1.什么时候初始化全局变量

在应用程序中常常会持有一个自己的Application，首先让它继承自系统的Application类，然后在自己的Application类中去封装一些通用的操作。虽然Application的用法很简单，但同时也存在着不少Application误用的场景。Application是Context的其中一种类型，那么是否就意味着，只要是Application的实例，就能随时使用Context的各种方法呢？做个实验试：

方式1：
public class MyApplication extends Application {      
    public MyApplication() {  
        String packageName = getPackageName();  
        Log.d("TAG", "package name is " + packageName);  
    }     
}  
  
方式2：
public class MyApplication extends Application {      
    @Override  
    public void onCreate() {  
        super.onCreate();  
        String packageName = getPackageName();  
        Log.d("TAG", "package name is " + packageName);  
    }     
} 

这是一个非常简单的自定义Application，以上我们分别采用了在MyApplication的构造方法和onCreate()方法中两种方式来获取当前应用程序的包名，并打印出来。获取包名使用了getPackageName()方法，这个方法就是由Context提供的。那哪种方式能得到想要的结果呢？得到的结果是否又是一样？
结果表明，方式一应用程序一启动就立刻崩溃了，报的是一个空指针异常：

方式二运行正常：

这两个方法之间到底发生了什么事情呢？我们重新回顾一下ContextWrapper类的源码，ContextWrapper中有一个attachBaseContext()方法，这个方法会将传入的一个Context参数赋值给mBase对象，之后mBase对象就有值了。而我们又知道，所有Context的方法都是调用这个mBase对象的同名方法，那么也就是说如果在mBase对象还没赋值的情况下就去调用Context中的任何一个方法时，就会出现空指针异常，上面的代码就是这种情况。
Application中方法的执行顺序为：Application构造方法—>attachBaseContext()—>onCreate()。
Application中在onCreate()方法里去初始化各种全局变量数据是一种比较推荐的做法，但如果你想把初始化的时间提前到极致，也可以重写attachBaseContext()，如下所示：

public class MyApplication extends Application {      
    @Override  
    protected void attachBaseContext(Context base) {  
        // 在这里调用Context的方法会崩溃  
        super.attachBaseContext(base);  
        // 在这里可以正常调用Context的方法  
    }       
} 

2.自定义Application？

其实Android官方并不太推荐我们使用自定义的Application，基本上只有需要做一些全局初始化的时候可能才需要用到自定义Application。多数项目只是把自定义Application当成了一个通用工具类，而这个功能并不需要借助Application来实现，使用单例可能是一种更加标准的方式。不过自定义Application也并没有什么副作用，它和单例模式二选一都可以实现同样的功能，但把自定义Application和单例模式混合到一起使用，就会出各种问题了。如下：

public class MyApplication extends Application {  
      
    private static MyApplication app;  
      
    public static MyApplication getInstance() {  
        if (app == null) {  
            app = new MyApplication();  
        }  
        return app;  
    }       
} 

就像单例模式一样，这里提供了一个getInstance()方法，用于获取MyApplication的实例，有了这个实例之后，就可以调用MyApplication中的各种工具方法了，然而事实却非想的那么美好。因为我们知道Application是属于系统组件，系统组件的实例是要由系统来去创建的，如果这里我们自己去new一个MyApplication的实例，它就只是一个普通的Java对象而已，而不具备任何Context的能力，如果想通过该对象来进行Context操作，就会发生空指针错误。那么如果真的想要提供一个获取MyApplication实例的方法，比较标准的写法又是什么样的呢？其实这里我们只需谨记一点，Application全局只有一个，它本身就已经是单例了，无需再用单例模式去为它做多重实例保护了，代码如下所示：

public class MyApplication extends Application {      
    private static MyApplication app;  
      
    public static MyApplication getInstance() {  
        return app;  
    }  
      
    @Override  
    public void onCreate() {  
        super.onCreate();  
        app = this;  
    }      
}  

getInstance()方法可以照常提供，但是里面不要做任何逻辑判断，直接返回app对象就可以了，而app对象又是什么呢？在onCreate()方法中我们将app对象赋值成this，this就是当前Application的实例，那么app也就是当前Application的实例了。

Context引起的内存泄露

context发生内存泄露的话，就会泄露很多内存。这里泄露的意思是gc没有办法回收activity的内存，在传递Context时会增加对象指针的引用计数，所以基于智能指针技术的GC无法释放相应的内存。
　　当屏幕旋转的时候，系统会销毁当前的activity，保存状态信息，再创建一个新的。比如我们写了一个应用程序，它需要加载一个很大的图片，我们不希望每次旋转屏幕的时候都销毁这个图片，重新加载。实现这个要求的简单想法就是定义一个静态的Drawable，这样Activity 类创建销毁它始终保存在内存中。实现类似：

public class myActivity extends Activity {
    private static Drawable sDrawable;
    protected void onCreate(Bundle state) {
    super.onCreate(state);
 
    TextView textView = new TextView(this);
    textView.setText("Leaks are bad");
    if (sDrawable == null) {
    sDrawable = getDrawable(R.drawable.large_bitmap);
    }
    textView.setBackgroundDrawable(sDrawable);//drawable attached to a view
    setContentView(label);
  }
}

这段程序看起来很简单，但是却问题很大。当屏幕旋转的时候会有内存泄漏（即gc没法销毁Activity）。屏幕旋转的时系统会销毁当前的activity，但是当drawable和view关联后，drawable保存了view的 reference，即sDrawable保存了textView的引用，而textView保存了Activity的引用。既然Drawable不能销毁，它所引用和间接引用的都不能销毁，这样系统就没有办法销毁当前的Activity，于是造成了内存泄露，gc对这种类型的内存泄露是无能为力的。为了防止内存泄露，我们应该注意以下几点：

• 不要让生命周期长的对象引用Activity Context，即保证引用activity的对象要与activity本身生命周期是一样的
• 对于生命周期长的对象，可以使用Application Context
• 避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化