/**
* Make a standard toast that just contains a text view.
*
* @param context The context to use. Usually your {@link android.app.Application}
* or {@link android.app.Activity} object.
* @param text The text to show. Can be formatted text.
* @param duration How long to display the message. Either {@link #LENGTH_SHORT} or
* {@link #LENGTH_LONG}
*
*/
public static Toast makeText(Context context, CharSequence text, @Duration int duration)
Application和Activity,Service一样是Android框 架的一个系统组件，当android程序启动时系统会创建一个application对象，用来存储系统的一些信息。通常我们是不需要指定一个 Application的，这时系统会自动帮我们创建。打开每一个应用程序的manifest文件,可以看到activity都是包含在 application标签之中，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
<application android:label="ViewPagerIndicator Sample" android:icon="@drawable/icon"> <activity android:name=".ListSamples" android:label="ViewPager Indicator"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity>................... |
android系统会为每个程序运行时创建一个Application类的对象且仅创建一个，所以Application是单例 (singleton)模式的一个类.且application对象的生命周期是整个程序中最长的，它的生命周期就等于这个程序的生命周期。因为它是全局 的单例的，所以在不同的Activity,Service中获得的对象都是同一个对象。因此在安卓中我们可以避免使用静态变量来存储长久保存的值，而用 Application。
为了更好的利用Application的这一特性，比如我们需要Application来保存一些静态值，需要自定义继承于Application的类， 然后在这个类中定义一个变量来保存。在默认情况下应用系统会自动生成Application 对象，但是如果我们自定义了Application，那就需要告知系统，实例化的时候，是实例化我们自定义的，而非默认的。比如我们自定义了一个 AppContext类：
|
1
2
3
4
5
6
7
8
|
public class AppContext extends Application { public static final int NETTYPE_WIFI = 0x01; public static final int NETTYPE_CMWAP = 0x02; public static final int NETTYPE_CMNET = 0x03; public static final int PAGE_SIZE = 20;//默认分页大小 private static final int CACHE_TIME = 10*60000;//缓存失效时间 |
为了让系统实例化的时候找到，我们必须在manifest中修改application标签属性：
|
1
2
3
4
5
|
<application android:name=".AppContext" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" > |
关键的是这句：android:name=".AppContext"
通常Application全局对象是通过Context或者Activity的getApplicationContext()方法获得的比如我们在应用程序中想要获得我们刚刚定义的AppContext对象，就需要在activity中这样做：
appContext = (AppContext)this.getApplicationContext();
如果有Context对象，还可以：appContext = (AppContext)mContext.getApplicationContext();
但是很多时候我们的代码可能在activity之外，且没有context对象的引用，但是又需要获得AppContext对象，原始的做法可能是想办法将activity或者context传递到需要调用的地方，但是这样代码耦合度太高，可读性差。我们有更优雅的做法。
我们谈到Application对象是全局的，单例的，既然是单例应该有一个类方法能让我们获得这个单例对象才是，但Application本身没有，我们只能在自定义的时候想办法。
Application是系统的一个组件，也就有自己的生命周期函数，让人感到意外的是他的生命周期函数中居然也有onCreate(),onCreate是被自动调用的，我们可以利用这点来获得这个Application对象。
在AppContext中加入如下几行代码：
|
1
2
3
4
5
6
7
8
9
10
|
private static AppContext instance;public static AppContext getInstance() { return instance;} @Overridepublic void onCreate() { // TODO Auto-generated method stub super.onCreate(); instance = this;} |
这样我们就能在app工程的任何地方通过AppContext.getInstance()来获得Application全局对象。比如我定义了一个工具类，在工具内中我们需要使用
Context的getExternalFilesDir()方法。但是这个工具类没有直接的办法获取到context，于是我们可以：
|
1
|
return AppContext.getInstance().getExternalFilesDir(null); |
1、Context概念
其实一直想写一篇关于Context的文章，但是又怕技术不如而误人子弟，于是参考了些资料，今天准备整理下写出来，如有不足，请指出，参考资料会在醒目地方标明。
Context，相信不管是第一天开发Android， 还是开发Android的各种老鸟，对于Context的使用一定不陌生~~你在加载资源、启动一个新的Activity、获取系统服务、获取内部文件 （夹）路径、创建View操作时等都需要Context的参与，可见Context的常见性。大家可能会问到底什么是Context，Context字面 意思上下文，或者叫做场景，也就是用户与操作系统操作的一个过程，比如你打电话，场景包括电话程序对应的界面，以及隐藏在背后的数据；
但是在程序的角度Context又是什么呢？在程序的角度，我们可以有比较权威的答案，Context是个抽象类，我们可以直接通过看其类结构来说明答案：
可以看到Activity、Service、Application都是Context的子类；
也就是说，Android系统的角度来理解：Context是一个场景，代表与操作系统的交互的一种过程。从程序的角度上来理解：Context是个抽象类，而Activity、Service、Application等都是该类的一个实现。
在仔细看一下上图：Activity、Service、Application都是继承自ContextWrapper，而ContextWrapper内部会包含一个base context，由这个base context去实现了绝大多数的方法。
先扯这么多，有能力了会从别的角度去审视Context，加油~
2、Context与ApplicationContext
看 了标题，千万不要被误解，ApplicationContext并没有这个类，其实更应该叫做：Activity与Application在作为 Context时的区别。嗯，的确是这样的，大家在需要Context的时候，如果是在Activity中，大多直接传个this，当在匿名内部类的时 候，因为this不能用，需要写XXXActivity.this，很多哥们会偷懒，直接就来个getApplicationContext。那么大家有 没有想过，XXXActivity.this和getApplicationContext的区别呢？
XXXActivity和getApplicationContext返回的肯定不是一个对象，一个是当前Activity的实例，一个是项目的Application的实例。既然区别这么明显，那么各自的使用场景肯定不同，乱使用可能会带来一些问题。
下面开始介绍在使用Context时，需要注意的问题。
3、引用的保持
大家在编写一些类时，例如工具类，可能会编写成单例的方式，这些工具类大多需要去访问资源，也就说需要Context的参与。
在这样的情况下，就需要注意Context的引用问题。
例如以下的写法：
- package com.mooc.shader.roundimageview;
- import android.content.Context;
- public class CustomManager
- {
- private static CustomManager sInstance;
- private Context mContext;
- private CustomManager(Context context)
- {
- this.mContext = context;
- }
- public static synchronized CustomManager getInstance(Context context)
- {
- if (sInstance == null)
- {
- sInstance = new CustomManager(context);
- }
- return sInstance;
- }
- //some methods
- private void someOtherMethodNeedContext()
- {
- }
- }
对于上述的单例，大家应该都不陌生（请别计较getInstance的效率问题），内部保持了一个Context的引用；
这 么写是没有问题的，问题在于，这个Context哪来的我们不能确定，很大的可能性，你在某个Activity里面为了方便，直接传了个this;这样问 题就来了，我们的这个类中的sInstance是一个static且强引用的，在其内部引用了一个Activity作为Context，也就是说，我们的 这个Activity只要我们的项目活着，就没有办法进行内存回收。而我们的Activity的生命周期肯定没这么长，所以造成了内存泄漏。
那么，我们如何才能避免这样的问题呢？
有人会说，我们可以软引用，嗯，软引用，假如被回收了，你不怕NullPointException么。
把上述代码做下修改：
- public static synchronized CustomManager getInstance(Context context)
- {
- if (sInstance == null)
- {
- sInstance = new CustomManager(context.getApplicationContext());
- }
- return sInstance;
- }
这样，我们就解决了内存泄漏的问题，因为我们引用的是一个ApplicationContext，它的生命周期和我们的单例对象一致。
这 样的话，可能有人会说，早说嘛，那我们以后都这么用不就行了，很遗憾的说，不行。上面我们已经说过，Context和Application Context的区别是很大的，也就是说，他们的应用场景（你也可以认为是能力）是不同的，并非所有Activity为Context的场 景，Application Context都能搞定。
下面就开始介绍各种Context的应用场景。
4、Context的应用场景
大家注意看到有一些NO上添加了一些数字，其实这些从能力上来说是YES，但是为什么说是NO呢？下面一个一个解释：
数字1：启动Activity在这些类中是可以的，但是需要创建一个新的task。一般情况不推荐。
数字2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。
数字3：在receiver为null时允许，在4.2或以上的版本中，用于获取黏性广播的当前值。（可以无视）
注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因为在其内部方法中都有一个context用于使用。
好 了，这里我们看下表格，重点看Activity和Application，可以看到，和UI相关的方法基本都不建议或者不可使用Application， 并且，前三个操作基本不可能在Application中出现。实际上，只要把握住一点，凡是跟UI相关的，都应该使用Activity做为Context 来处理；其他的一些操作，Service,Activity,Application等实例都可以，当然了，注意Context引用的持有，防止内存泄 漏。