Android开发中的Application类

我们在平时的开发中，有时候可能会需要一些全局数据，来让应用中的所有Activity和View都能访问到，大家在遇到这种情况时，可能首先会想到自己定义一个类，然后创建很多静态成员。
但是这种方法不符合Android的框架架构，不过andorid已经为我们提供了这种情况的解决方案：在Android中，有一个名为Application的类，我们可以在Activity中使用getApplication()，方法来获得，它是代表我们的应用程序的类，使用它可以获得当前应用的主题，资源文件中的内容等，这个类更灵活的一个特性就是可以被我们继承，来添加我们自己的全局属性。让整个App的Activity和View都能访问到。

1.概念：
android系统会为每个程序运行时创建一个Application类的对象且仅创建一个，所以Application可以说是单例 (singleton)模式的一个类.且application对象的生命周期是整个程序中最长的，它的生命周期就等于这个程序的生命周期。因为它是全局的单例的，所以在不同的Activity,Service中获得的对象都是同一个对象。所以通过Application来进行一些数据传递，数据共享,数据缓存等操作。

2.作用：
(1).Application是一个基类，这个基类的作用是获取整个App的状态，我们需要自己定义一个类来继承这个基类。
(2).定义一些全局的和一些上下文都要用到的变量和方法。

 3.优点：
(1).继承的方式：
生命周期随着应用程序的销毁而销毁。
(2).静态类或静态方法：
程序退出后该类或者变量不能立刻被GC回收。
当你再次进入后会发现该静态类保存的信息状态是之前的。有可能会导致程序不是你想要的初始化状态。
(3) .App的进程被创建时， 这个类就会被实例化，onCreate()方法就会被执行 ，给所有全局变量赋初期值。这样， 所有的Activity就共同拥有这个类里面的变量了。

 4.getContext()、getApplication()、getApplicationContext()、getActivity()的区别：
(1).getContext():获取到当前对象的上下文。
(2).getApplication():获得Application的对象
(3).getApplicationContext():获得应用程序的上下文。有且仅有一个相同的对象。生命周期随着应用程序的摧毁而销毁。就像是社会，所有的都发生在这个社会上，仅且只有一个社会。每个Activity都有自己的上下文，而整个应用只有一个上下文
(4)getActivity():获得Fragment依附的Activity对象。

1. Context类型

Android是用Java语言来编写和，然而Android却需要一个完整的Android工程环境，在这个环境下，我们熟悉的Activity、Service、ContentPrivoder等系统组件才能有自己各自的上下文环境，也就是Context。Context是维持Android应用的核心功能类，是整个Android系统交互的核心。

context继承图

Context的继承结构从图中可以看到，直系子类有两个，一个是ContextWrapper，一个是ContextImpl。那么从名字上就可以看出，ContextWrapper是上下文功能的封装类，而ContextImpl则是上下文功能的实现类。而ContextWrapper又有三个直接的子类，ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，而它有一个直接子类就是Activity。

在这里我们至少看到了几个所比较熟悉的面孔，Activity、Service、还有Application。由此，其实我们就已经可以得出结论了，Context一共有三种类型，分别是Application、Activity和Service。这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。

2. Application类在项目开发中的使用

首先在项目目录下一个Java类继承Application类，实现是onCreate()方法。这个类可以做APP的全局初始化工作，比如图片加载框架的全局配置信息设置。

public class AndroidApplication extends Application {

    private static AndroidApplication instance;

    @Override
    public void onCreate() {
        super.onCreate();
        instance = this;
    }

    public static AndroidApplication getInstance(){
        return instance;
    }
}

然后千万不要忘了在Android项目的Manifest文件中指定Application的实现类，不然系统会创建一个默认的Application类。

<application
        android:name=".AndroidApplication"
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>

                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>

3. Application类或Context类的误用情况

1. 不能用Application缓存数据！！！

因为Application进入background后会因为内存不足被系统干掉，再次进入app后系统就会重新创建一个Application类，而导致缓存在Application类里的数据全部初始化而丢失。

2. 错误的获取全局Context对象的方式

public class AnddroidApplication extends Application {  

    private static AnddroidApplication app;  

    public static AnddroidApplication getInstance() {
        if (app == null) {  
            app = new AnddroidApplication();  
        }  
        return app;  
    }  

}

上面这种方式如果是单纯的Java工程可能没有问题，但是在Android里这样说大错特错的。因为Application是系统组件，系统组件实例是要由系统去创建的，如果我们这里直接创建一个，不过是简单的Java对象而已，不具备任何Context能力，也无法进行任何Context操作。标准的写法就本文的第一段示意代码那样。