前言
在写 Android 程序的过程中，总是遇到一些很细节的问题，如果不深入的了解以下，可能会导致一些隐藏漏洞。比如在获取上下文的过程中，有时候使用 activity.this 与 getApplicationContext() ，但是一直都是模糊不清楚的，只有到运行出错的时候，才会考虑到换下，然后解决了问题，但是不知道原因 ：( 所以写了这篇，以供参考。。。
Application类
getApplicationContext()是通过以下方法返回一个 Application对象,所以进一步了解这个类。
/** Return the application that owns this activity. */
public final Application getApplication() {
return mApplication;
}
定义
android.app.Application 类代表当前运行的应用程序。应用程序启动时，系统会自动创建对应的 Application 类的实例，并一直伴随应用程序的生命周期，而且始终维持一个实例。对于同一个应用程序，由于系统只会保证存在一个 Application 实例，即在所有组件中获取的是同一个 Application 对象，因此 Application 特别适合保存应用程序中多个组件都需要访问的对象
通过扩展 Application 类，可以完成以下3种任务：
- 对 Android 运行时广播的应用程序及事件做出反应
- 在应用程序组件中传递对象
- 管理和维护多个应用程序组件所需要的资源
生命周期事件
Application 类为应用程序的创建和终止、低可用内存和配置的改变提供了时间处理程序，通过重写以下方法，可以实现上述几种情况的应用程序行为
1. onCreate()
在创建应用程序时调用该方法。通过重写来实例化应用程序单态，也可以创建和实例化任何应用程序状态变量或共享资源
2. onLowMemory()
一般只会在后台进程已经终止但前台应用程序依然缺少内存资源时会被调用，通过重写来清空缓存或者释放不必要的资源
3. onTrimMemory()
作为onLowMemory的一个特定应用程序的替代选择，在 Android 4.0 （API level 13）中引入。当运行时决定当前应用程序是否尝试减少其内存开销。该方法包含一个 level 参数，用于提供请求的上下文
4. onConfigurationChanged()
与 Activity 不同，当配置发生改变时，应用程序对象不会被终止和重启；如果应用程序使用的值依赖于特定的配置，则重写该方法来重新加载这个值，或者在应用程序级别处理配置的改变
两者区别
-
对于
getApplicationContext()，我们可以假定它是一个父类，它属于整个应用程序共有，Activity.this可以假定为其的一个子类，该子类包含了一些特定的引用。所以，一般可以用 getApplicationContext 的地方都可以用特定的 Activity.this 代替。 -
在生命周期上，通过
getApplicationContext()得到的上下文对象们只要当前的应用程序还存在，那么该对象就会一直存在，对于Activity.this上下文来说，只要当前的 activity 执行了 onDestory 方法，这个上下文对象就会一起被系统收回。 -
在应用场景上，如果我们通过一个上下文对象来执行某个动作，且希望一直处于活跃状态，那么应该用 getApplicationContext 来获取上下文，如数据库的操作。此时，如果采用 Activity.this，那么当前 Activity 调用 onDestory 方法时，数据库就会关闭，应用程序会产生错误。
总结
getApplicationContext()返回应用的上下文，生命周期是整个应用，应用摧毁它才摧毁Activity.this的context返回当前 activity 的上下文，属于activity，activity摧毁他就摧毁- 和 UI 操作相关的不建议使用
getApplicationContext()，一般都使用和 activity 相关的 context，其余的操作，看具体情况，根据存在的生命周期的长度作出选择