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

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

http://blog.csdn.net/u014315849/article/details/50392049

主要解决了怎么将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 ContextmContext = 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 controllabel.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 / 3Android Context 详解sBackground = getDrawable(R.drawable.large_bitmap);}label.setBackgroundDrawable(sBackground);//drawable attached to a viewsetContentView(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）、避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化

更多相关文章

随机推荐