Android-Context

时间  2019-11-12
标签 android context 栏目 Android 繁體版
原文   原文链接

http://blog.csdn.net/guolin_blog/article/details/47028975android

 

Context类型

咱们知道，Android应用都是使用Java语言来编写的，那么你们能够思考一下，一个Android程序和一个Java程序，他们最大的区别在哪里？划分界限又是什么呢？其实简单点分析，Android程序不像Java程序同样，随便建立一个类，写个main()方法就能跑了，而是要有一个完整的Android工程环境，在这个环境下，咱们有像Activity、Service、BroadcastReceiver等系统组件，而这些组件并非像一个普通的Java对象new一下就能建立实例的了，而是要有它们各自的上下文环境，也就是咱们这里讨论的Context。能够这样讲，Context是维持Android程序中各组件可以正常工做的一个核心功能类。数据库

下面咱们来看一下Context的继承结构：安全

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

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

那么Context到底能够实现哪些功能呢？这个就实在是太多了，弹出Toast、启动Activity、启动Service、发送广播、操做数据库等等等等都须要用到Context。因为Context的具体能力是由ContextImpl类去实现的，所以在绝大多数场景下，Activity、Service和Application这三种类型的Context都是能够通用的。不过有几种场景比较特殊，好比启动Activity，还有弹出Dialog。出于安全缘由的考虑，Android是不容许Activity或Dialog凭空出现的，一个Activity的启动必需要创建在另外一个Activity的基础之上，也就是以此造成的返回栈。而Dialog则必须在一个Activity上面弹出（除非是System Alert类型的Dialog），所以在这种场景下，咱们只能使用Activity类型的Context，不然将会出错。ide

 

Context数量

那么一个应用程序中到底有多少个Context呢？其实根据上面的Context类型咱们就已经能够得出答案了。Context一共有Application、Activity和Service三种类型，所以一个应用程序中Context数量的计算公式就能够这样写：工具

Context数量 = Activity数量 + Service数量 + 1 oop

上面的1表明着Application的数量，由于一个应用程序中能够有多个Activity和多个Service，可是只能有一个Application。性能

Application Context的设计

基本上每个应用程序都会有一个本身的Application，并让它继承自系统的Application类，而后在本身的Application类中去封装一些通用的操做。其实这并非Google所推荐的一种作法，由于这样咱们只是把Application当成了一个通用工具类来使用的，而实际上使用一个简单的单例类也能够实现一样的功能。可是根据个人观察，有太多的项目都是这样使用Application的。固然这种作法也并无什么反作用，只是说明仍是有很多人对于Application理解的还有些欠缺优化

 

首先新建一个MyApplication并让它继承自Application，而后在AndroidManifest.xml文件中对MyApplication进行指定，以下所示：

<application  
    android:name=".MyApplication"  
    android:allowBackup="true"  
    android:icon="@drawable/ic_launcher"  
    android:label="@string/app_name"  
    android:theme="@style/AppTheme" >  
    ......  
</application>

指定完成后，当咱们的程序启动时Android系统就会建立一个MyApplication的实例，若是这里不指定的话就会默认建立一个Application的实例。

 

前面提到过，如今不少的Application都是被看成通用工具类来使用的，那么既然做为一个通用工具类，咱们要怎样才能获取到它的实例呢？以下所示：

public class MainActivity extends Activity {  
      
    @Override  
    protected void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.layout.activity_main);  
        MyApplication myApp = (MyApplication) getApplication();  
        Log.d("TAG", "getApplication is " + myApp);  
    }  
      
}

那么除了getApplication()方法，其实还有一个getApplicationContext()方法，能够获取到Application的实例。这两个方法获得的是同一个对象。其实这个结果也很好理解，由于前面已经说过了，Application自己就是一个Context，因此这里获取getApplicationContext()获得的结果就是MyApplication自己的实例。

那么有的朋友可能就会问了，既然这两个方法获得的结果都是相同的，那么Android为何要提供两个功能重复的方法呢？实际上这两个方法在做用域上有比较大的区别。getApplication()方法的语义性很是强，一看就知道是用来获取Application实例的，可是这个方法只有在Activity和Service中才能调用的到。那么也许在绝大多数状况下咱们都是在Activity或者Service中使用Application的，可是若是在一些其它的场景，好比BroadcastReceiver中也想得到Application的实例，这时就能够借助getApplicationContext()方法了，以下所示：

public class MyReceiver extends BroadcastReceiver {  
  
    @Override  
    public void onReceive(Context context, Intent intent) {  
        MyApplication myApp = (MyApplication) context.getApplicationContext();  
        Log.d("TAG", "myApp is " + myApp);  
    }  
  
}

也就是说，getApplicationContext()方法的做用域会更广一些，任何一个Context的实例，只要调用getApplicationContext()方法均可以拿到咱们的Application对象。

那么更加细心的朋友会发现，除了这两个方法以外，其实还有一个getBaseContext()方法，这个baseContext又是什么东西呢？

此次获得的是不一样的对象了，getBaseContext()方法获得的是一个ContextImpl对象。

这个ContextImpl是否是感受有点似曾相识？回去看一下Context的继承结构图吧，ContextImpl正是上下文功能的实现类。也就是说像Application、Activity这样的类其实并不会去具体实现Context的功能，而仅仅是作了一层接口封装而已，Context的具体功能都是由ContextImpl类去完成的。那么这样的设计究竟是怎么实现的呢？咱们仍是来看一下源码吧。由于Application、Activity、Service都是直接或间接继承自ContextWrapper的，咱们就直接看ContextWrapper的源码，以下所示：

/** 
 * Proxying implementation of Context that simply delegates all of its calls to 
 * another Context.  Can be subclassed to modify behavior without changing 
 * the original Context. 
 */  
public class ContextWrapper extends Context {  
    Context mBase;  
      
    /** 
     * Set the base context for this ContextWrapper.  All calls will then be 
     * delegated to the base context.  Throws 
     * IllegalStateException if a base context has already been set. 
     *  
     * @param base The new base context for this wrapper. 
     */  
    protected void attachBaseContext(Context base) {  
        if (mBase != null) {  
            throw new IllegalStateException("Base context already set");  
        }  
        mBase = base;  
    }  
  
    /** 
     * @return the base context as set by the constructor or setBaseContext 
     */  
    public Context getBaseContext() {  
        return mBase;  
    }  
  
    @Override  
    public AssetManager getAssets() {  
        return mBase.getAssets();  
    }  
  
    @Override  
    public Resources getResources() {  
        return mBase.getResources();  
    }  
  
    @Override  
    public ContentResolver getContentResolver() {  
        return mBase.getContentResolver();  
    }  
  
    @Override  
    public Looper getMainLooper() {  
        return mBase.getMainLooper();  
    }  
      
    @Override  
    public Context getApplicationContext() {  
        return mBase.getApplicationContext();  
    }  
  
    @Override  
    public String getPackageName() {  
        return mBase.getPackageName();  
    }  
  
    @Override  
    public void startActivity(Intent intent) {  
        mBase.startActivity(intent);  
    }  
      
    @Override  
    public void sendBroadcast(Intent intent) {  
        mBase.sendBroadcast(intent);  
    }  
  
    @Override  
    public Intent registerReceiver(  
        BroadcastReceiver receiver, IntentFilter filter) {  
        return mBase.registerReceiver(receiver, filter);  
    }  
  
    @Override  
    public void unregisterReceiver(BroadcastReceiver receiver) {  
        mBase.unregisterReceiver(receiver);  
    }  
  
    @Override  
    public ComponentName startService(Intent service) {  
        return mBase.startService(service);  
    }  
  
    @Override  
    public boolean stopService(Intent name) {  
        return mBase.stopService(name);  
    }  
  
    @Override  
    public boolean bindService(Intent service, ServiceConnection conn,  
            int flags) {  
        return mBase.bindService(service, conn, flags);  
    }  
  
    @Override  
    public void unbindService(ServiceConnection conn) {  
        mBase.unbindService(conn);  
    }  
  
    @Override  
    public Object getSystemService(String name) {  
        return mBase.getSystemService(name);  
    }  
  
    ......  
}

因为ContextWrapper中的方法仍是很是多的，我就进行了一些筛选，只贴出来了部分方法。那么上面的这些方法相信你们都是很是熟悉的，getResources()、getPackageName()、getSystemService()等等都是咱们常常要用到的方法。那么全部这些方法的实现又是什么样的呢？其实全部ContextWrapper中方法的实现都很是统一，就是调用了mBase对象中对应当前方法名的方法。

 

那么这个mBase对象又是什么呢？咱们来看第16行的attachBaseContext()方法，这个方法中传入了一个base参数，并把这个参数赋值给了mBase对象。而attachBaseContext()方法实际上是由系统来调用的，它会把ContextImpl对象做为参数传递到attachBaseContext()方法当中，从而赋值给mBase对象，以后ContextWrapper中的全部方法其实都是经过这种委托的机制交由ContextImpl去具体实现的，因此说ContextImpl是上下文功能的实现类是很是准确的。

那么另外再看一下咱们刚刚打印的getBaseContext()方法，在第26行。这个方法只有一行代码，就是返回了mBase对象而已，而mBase对象其实就是ContextImpl对象，所以刚才的打印结果也获得了印证。

使用Application的问题

虽然说Application的用法确实很是简单，可是咱们平时的开发工做当中也着实存在着很多Application误用的场景，那么今天就来看一看有哪些比较容易犯错的地方是咱们应该注意的。

Application是Context的其中一种类型，那么是否就意味着，只要是Application的实例，就能随时使用Context的各类方法呢？咱们来作个实验试一下就知道了：

 

public class MyApplication extends Application {  
      
    public MyApplication() {  
        String packageName = getPackageName();  
        Log.d("TAG", "package name is " + packageName);  
    }  
      
}

应用程序一启动就马上崩溃了，报的是一个空指针异常。看起来好像挺简单的一段代码，怎么就会成空指针了呢？可是若是你尝试把代码改为下面的写法，就会发现一切正常了：

public class MyApplication extends Application {  
      
    @Override  
    public void onCreate() {  
        super.onCreate();  
        String packageName = getPackageName();  
        Log.d("TAG", "package name is " + packageName);  
    }  
      
}

在构造方法中调用Context的方法就会崩溃，在onCreate()方法中调用Context的方法就一切正常，那么这两个方法之间到底发生了什么事情呢？咱们从新回顾一下ContextWrapper类的源码，ContextWrapper中有一个attachBaseContext()方法，这个方法会将传入的一个Context参数赋值给mBase对象，以后mBase对象就有值了。而咱们又知道，全部Context的方法都是调用这个mBase对象的同名方法，那么也就是说若是在mBase对象还没赋值的状况下就去调用Context中的任何一个方法时，就会出现空指针异常，上面的代码就是这种状况。Application中方法的执行顺序以下图所示：

Application中在onCreate()方法里去初始化各类全局的变量数据是一种比较推荐的作法，可是若是你想把初始化的时间点提早到极致，也能够去重写attachBaseContext()方法，以下所示：

public class MyApplication extends Application {  
      
    @Override  
    protected void attachBaseContext(Context base) {  
        // 在这里调用Context的方法会崩溃  
        super.attachBaseContext(base);  
        // 在这里能够正常调用Context的方法  
    }  
      
}

 

如下原文：http://mp.weixin.qq.com/s?__biz=MzA4NTQwNDcyMA==&mid=2650661511&idx=1&sn=1b7390e2c971e50a0db4d07c7b9ebb6f&scene=4#wechat_redirect

 

context使用表：

 

Context相关的内存泄漏问题

在讨论内存泄漏以前，先简单的说说Android中内存的回收

 

Dalivik虚拟机扮演了常规的垃圾回收角色，为了GC可以从App中及时回收内存，咱们须要时时刻刻在适当的时机来释放引用对象，Dalvik的GC会自动把离开活动线程的对象进行回收。

 

什么是Android内存泄漏：

 

虽然Android是一个自动管理内存的开发环境，可是垃圾回收器只会移除那些已经失去引用的、不可达的对象，在十几万、几十万行代码中，因为你的失误使得一个本应该被销毁的对象仍然被错误的持有，那么该对象就永远不会被释放掉，这些已经没有任何价值的对象，仍然占据汇集在你的堆内存中，GC就会被频繁触发，多说几句，若是手机不错，一次GC的时间70毫秒，不会对应用的性能产生什么影响，可是若是一个手机的性能不是那么出色，一次GC时间120毫秒，出现大量的GC操做，我相信用户就能感受到了吧。这些无用的引用堆积在堆内存中，越积越多最终致使Crash，有关一些性能优化推荐给你们一个我总结的博客。

 

「Android性能优化总结」

 

有些跑题了，咱们赶忙来看看什么状况下Context会引起内存泄漏

 

  • 错误的单例模式

咱们来分析一下这个非线程安全的单例模式，假设你在Activity A去getInstance得到instance对象，顺手传了一个this，好了，如今一个常驻内存的Singleton保存了你传入Activity A的对象，而且一直持有Activity A的引用，这样即便你Activity被销毁掉，可是由于它的引用还存在于一个Singleton中，是不可能被GC掉的，这样就致使了内存泄漏。

 

  • View持有Activity的引用

再来分析一下，有一个静态的Drawable对象，当我给ImageView设置这个Drawable时，ImageView像上面那个例子同样，保存了这个mDrawable的引用（你们能够点开源码705行去看，不少UI组件都是统一的操做，一直持有传入的对象），然而ImageView传入了this，也就是ImageView一样持有一个MainActivity的mContext。由于被static修饰的mDrawable是常驻内存的，MainActivity是它的间接引用，因此当MainActivity被销毁时，也不能被GC掉，因此也形成了内存泄漏。

 

使用Context的正确姿式

通俗一点说，Context形成的内存泄漏，几乎都是当Context销毁的时候，却还被各类不合理、无故地引用着。那么哪一个Context对象是不会被销毁的呢？对了，Application的Context对象能够理解为随着进程存在的，因此当Application的Context能搞定的状况下，而且生命周期长的对象，优先使用Application的Context

调用一行代码：

 

LaucherApplication.getContext();

 

回头看看上面那张表格，显然Application的Context不是万能的，涉及UI加载操做时，彷佛咱们只能使用Activity的Context，因此你当你使用Activity的Context时，你要对持有Activity的对象心中有数，保证它能随着生命周期的销毁而被回收，慎用static关键字，不要由于方便访问就各类static乱入。

 

多说一点，上表中Layout Inflation中只能使用Activity的Context，而各类View在建立时，须要传入的Context参数也是Activity的，你们懂了吧，当解析XML文件的时候，传入的参数也就统一了，相信你们必定能想明白这点。

 

写在最后：

 

给你们推荐一个内存检测的自动化工具，LeakCanary，可是当你曾经写出的代码不规范不负责，已经达到十几万行，几十万行的时候，再去抽丝剥茧试图解开已经打上层层死结的引用关联，是很是难的。因此平时仍是要注意下细节哈~

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程