一道面试题引发的对android中context的研究（二）

在一道面试题引发的对android中context的研究（一）中。

/article/5358130.html

主要解决了怎么将sharedPreference 保存在我们的SD卡上。利用了Java的反射机制修改了SharedPreference的保存位置。也是通过阅读Context 的源码一步一步的找到了突破口， 这也引起了我对Android 中Context 的兴趣。也参考了网上的文章，写出了这篇小笔记， 希望对大家有帮助。

参考文章目录：

https://possiblemobile.com/2013/06/context/

这里贴上翻译文章：

http://blog.csdn.net/race604/article/details/9331807

下面一步一步的来进行分析：

step1 首先我们来看看我们的context的主要目录视图



我们也可以打开自己的IDE进行查看（我使用的是IntelliJ IDEA 快捷键是Ctrl+H 查看目录视图）：







step2 打开我们的源代码,在文章（一）中也提及过Attach 源代码.

也可以自行打开目录，在我的目录中是：\Android_SDK\sources\android-19\android\content\Context.java

这里写出主要的一些方法：

1）Context类：

public abstract class Context {
...
public abstract Object getSystemService(String name);  //获得系统级服务
public abstract void startActivity(Intent intent);     //通过一个Intent启动Activity
public abstract ComponentName startService(Intent service);  //启动Service
//根据文件名得到SharedPreferences对象
public abstract SharedPreferences getSharedPreferences(String name,int mode);
...
}

说明：抽象类，提供了一组通用的API。

2）ContextIml.java类

/**
* Common implementation of Context API, which provides the base
* context object for Activity and other application components.
*/
class ContextImpl extends Context{
//所有Application程序公用一个mPackageInfo对象
/*package*/ ActivityThread.PackageInfo mPackageInfo;

@Override
public Object getSystemService(String name){
...
else if (ACTIVITY_SERVICE.equals(name)) {
return getActivityManager();
}
else if (INPUT_METHOD_SERVICE.equals(name)) {
return InputMethodManager.getInstance(this);
}
}
@Override
public void startActivity(Intent intent) {
...
//开始启动一个Activity
mMainThread.getInstrumentation().execStartActivity(
getOuterContext(), mMainThread.getApplicationThread(), null, null, intent, -1);
}
}

说明：该Context类的实现类为ContextIml，该类实现了Context类的功能。

3）ContextWrapper类：

public class ContextWrapper extends Context {
Context mBase;  //该属性指向一个ContextIml实例，一般在创建Application、Service、Activity时赋值

//创建Application、Service、Activity，会调用该方法给mBase属性赋值
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
}
@Override
public void startActivity(Intent intent) {
mBase.startActivity(intent);  //调用mBase实例方法
}
}

说明： 正如其名称一样，该类只是对Context类的一种包装，该类的构造函数包含了一个真正的Context引用，即ContextIml对象。

4） ContextThemeWrapper类：

public class ContextThemeWrapper extends ContextWrapper {
//该属性指向一个ContextIml实例，一般在创建Application、Service、Activity时赋值

private Context mBase;
//mBase赋值方式同样有一下两种
public ContextThemeWrapper(Context base, int themeres) {
super(base);
mBase = base;
mThemeResource = themeres;
}

@Override
protected void attachBaseContext(Context newBase) {
super.attachBaseContext(newBase);
mBase = newBase;
}
}

说明：该类内部包含了主题(Theme)相关的接口，即android:theme属性指定的。只有Activity需要主题，Service不需要主题，

所以Service直接继承于ContextWrapper类。更多信息大家可以自行参考源代码进行理解。

step3分析了一下，也就是知道应用程序创建Context实例的情况有如下几种情况：

1）、创建Application 对象时， 而且整个App共一个Application对象

2）、创建Service对象时

3）、创建Activity对象时

因此应用程序App共有的Context数目公式为：

总Context实例个数 = Service个数 + Activity个数 + 1（Application对应的Context实例）

step4 具体使用：

public class MyActivity extends Activity {
public void method() {
mContext = this; // since Activity extends Context
mContext = getApplicationContext();
mContext = getBaseContext();
}
}

this 是Activity 的实例，扩展了Context，其生命周期是Activity 创建到销毁。getApplicationContext()返回应用的上下文，生命周期是整个应用，应用摧毁它才摧毁。Activity.this的context 返回当前activity的上下文，属于activity ，activity摧毁他就摧毁

getBaseContext() 返回由构造函数指定或setBaseContext()设置的上下文，SDK文档很少，不推荐使用

搞清楚了生命周期就会在使用过程中犯错误，比如有一个全局的数据操作类用到了context，这个时候就要getApplicationContext 而不是用ACtivity，这就保证了数据库的操作与activity无关（不会一直引用Activity的资源，防止内存泄漏）

应用场景：

比如一个activity的onCreate：

protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this); //??context?view c
ontrol
label.setText("Leaks are bad");
setContentView(label);
}

把activity context传递给view，意味着view拥有一个指向activity的引用，进而引用activity占有的资源：view hierachy, resource等。这样如果context发生内存泄露的话，就会泄露很多内存。这里泄露的意思是gc没有办法回收activity的内存。

Leaking an entire activity是很容易的一件事。当屏幕旋转的时候，系统会销毁当前的activity，保存状态信息，再创建一个新的activity。

比如我们写了一个应用程序，它需要加载一个很大的图片，我们不希望每次旋转屏幕的时候都销毁这个图片重新加载。

实现这个要求的简单想法就是定义一个静态的Drawable，这样Activity类创建销毁它始终保存在内存中。

实现示例：

public class myactivity extends Activity {
private static Drawable sBackground;
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
P 2 / 3
Android Context 详解
sBackground = getDrawable(R.drawable
.large_bitmap);
}
label.setBackgroundDrawable(sBackground);//dra
wable attached to a view
setContentView(label);
}
}

这段程序看起来很简单，但是却问题很大。当屏幕旋转的时候会有leak（即gc没法销毁activity）。我们刚才说过，屏幕旋转的时候系统会销毁当前的activity。但是当drawable和view关联后，drawable保存了view的reference，即sBackground保存了label的引用，而label保存了activity的引用。既然drawable不能销毁，它所引用和间接引用的都不能销毁，这样系统就没有办法销毁当前的activity，于是造成了内存泄露。gc对这种类型的内存泄露是无能为力的。避免这种内存泄露的方法是避免activity中的任何对象的生命周期长过activity，避免由于对象对activity的引用导致activity不能正常被销毁。我们可以使用application
context。applicationcontext伴随application的一生，与activity的生命周期无关。application context可以通过Context.getApplicationContext()或者Activity.getApplicationContext()方法获取。

定制一个自己的Application：首先创建一个MyApplication类继承自Application

public class MyApplication extends Application
{
private static Context context;
public void onCreate()
{
context=getApplicationContext();
}
public static Context getContext()
{
return context;
}
}

注意：当程序启动的时候应该初始化MyApplication类，而不是默认的Application类。在AndroidMainifest.xml文件的标签下进行指定就可以了。

android:name="com.example.hl.MyApplication"

这样就已经实现了一种全局获取Context的机制，之后想在项目中使用Application的Context时，只需调用一下MyApplication.getContext()就可以了。

step 5 需要注意的地方：
避免context相关的内存泄露，记住以下几点：

1）、 不要让生命周期长的对象引用activity context，即保证引用activity的对象要与activity本身生命周期是一样的

2）、 对于生命周期长的对象，可以使用application context

3）、 避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化