android context解析

1.context 概念

      Context，在加载资源、启动一个新的Activity、获取系统服务、获取内部文件（夹）路径、创建View操作时等都需要Context的参与。

     1、它描述的是一个应用程序环境的信息，即上下文。
     2、该类是一个抽象(abstract class)类，Android提供了该抽象类的具体实现类(后面我们会讲到是ContextIml类)。
     3、通过它我们可以获取应用程序的资源和类，也包括一些应用级别操作，例如：启动一个Activity，发送广播，接受Intent
    信息等

     context相关类的继承关系如下：

     

       可以看到Activity、Service、Application都是Context的子类.
      也就是说，Android系统的角度来理解：Context是一个场景，代表与操作系统的交互的一种过程。从程序的角度上来理解：Context是个抽象类，而Activity、Service、Application等都是该类的一个实现。在仔细看一下上图：Activity、Service、Application都是继承自ContextWrapper，而ContextWrapper内部会包含一个base context，由这个base context去实现了绝大多数的方法。

2.两种类型的context

 2.1 Activity context

      通常我们在各种类和方法间传递的是activity context。很多方法需要通过 Context才能识别调用者的实例，比如说Toast的第一个参数就是Context，一般在Activity中我们直接用this代替，代表调用者的 实例为Activity，而在一个匿名内部类，或者一个button的onClick(View view)等方法时，我们用this时就会报错，所以我们可能使用ActivityName.this来解决，主要原因是因为实现Context的类主要有Android特有的几个模型，Activity、Service以及BroadcastReceiver。

      代码示例：

protected void onCreate(Bundle state) {super.onCreate(state);TextView label = new TextView(this);//传递context给view controllabel.setText("Leaks are bad");setContentView(label);}

把activity context传递给view，意味着view拥有一个指向activity的引用，进而引用activity占有的资源:view hierachy, resource等。

2.2 activity context引用保持与内存泄露

        在编写一些类时，例如工具类，可能会编写成单例的方式，这些工具类大多需要去访问资源，也就说需要Context的参与。
在这样的情况下，就需要注意Context的引用问题。

         代码示例：

        

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()      {                }  } 

        问题在于，这个Context哪来的我们不能确定，很大的可能性，在某个Activity里面为了方便，直接传了个this;这样问题就来了，我们的这个类中的sInstance是一个static且强引用的，在其内部引用了一个Activity作为Context，也就是说，我们的这个Activity只要我们的项目活着，就没有办法进行内存回收。而我们的Activity的生命周期肯定没这么长，所以造成了内存泄漏。如果使用软引用，假如被回收了，可能会产生NullPointException
        gc对这种类型的内存泄露是无能为力的。避免这种内存泄露的方法是避免activity中的任何对象的生命周期长过activity，避免由于对象对 activity的引用导致activity不能正常被销毁。

        为了防止内存泄露，我们应该注意以下几点：
        1.不要让生命周期长的对象引用activity context，即保证引用activity的对象要与activity本身生命周期是一样的。
        2.对于生命周期长的对象，可以使用application context。
        3.避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化。
2.3  Application Context

      我们可以使用application context。application context伴随application的一生，与activity的生命周期无关。application context可以通过Context.getApplicationContext或者Activity.getApplication方法获取。

      对于上例中的代码，为了避免内存泄露问题，可以作如下修改：

      

public static synchronized CustomManager getInstance(Context context)      {          if (sInstance == null)          {              sInstance = new CustomManager(context.getApplicationContext());          }          return sInstance;      } 

这样，我们就解决了内存泄漏的问题，因为我们引用的是一个ApplicationContext，它的生命周期和我们的单例对象一致。

但是，Activity Context和Application Context的区别是很大的，也就是说，他们的应用场景（你也可以认为是能力）是不同的，并非所有Activity为Context的场景，Application Context都能搞定。

2.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引用的持有，防止内存泄漏。

3.创建context的时机

应用程序创建Context实例的情况有如下几种情况：
1，创建Application 对象时， 而且整个App共一个Application对象
2、创建Service对象时
3、创建Activity对象时
因此应用程序App共有的Context数目公式为：
总Context实例个数 = Service个数 + Activity个数 + 1（Application对应的Context实例）

4.context的get方法

1.public abstract Context getApplicationContext ()
Return the context of the single, global Application object of the current process.

2.public abstract ApplicationInfo getApplicationInfo ()
Return the full application info for this context's package.

3.public abstract ContentResolver getContentResolver ()
Return a ContentResolver instance for your application's package.

4.public abstract PackageManager getPackageManager ()
Return PackageManager instance to find global package information.

5.public abstract String getPackageName ()
Return the name of this application's package.

6.public abstract Resources getResources ()
Return a Resources instance for your application's package.

7.public abstract SharedPreferences getSharedPreferences (String name, int mode)
Retrieve and hold the contents of the preferences file 'name', returning a SharedPreferences through which you can retrieve and modify its values. Only one instance of the SharedPreferences object is returned to any callers for the same name, meaning they will see each other's edits as soon as they are made.

8.public final String getString (int resId)
Return a localized string from the application's package's default string table.

9.public abstract Object getSystemService (String name)
Return the handle to a system-level service by name. The class of the returned object varies by the requested name. Currently available names are: