阅读 895

Android全面解析之Context机制(一) : context认知

文章相关内容已授权『郭霖』公众号发布

前言

很高兴遇见你~ 欢迎阅读我的文章。

在文章Android全面解析之由浅及深Handler消息机制中讨论到,Handler可以:

避免我们自己去手动写 死循环和输入阻塞 来不断获取用户的输入以及避免线程直接结束,而是采用事务驱动型设计,使用Handler消息机制,让AMS可以控制整个程序的运行逻辑。

这是关于android程序在设计上更加重要的一部分,不太了解的读者可以前往阅读了解一下。而当我们知道android程序的程序是通过main方法跑起来的,然后通过handler机制来控制程序的运行,那么四大组件和普通的Java类到底有什么区别?为什么同样是Java类,而ActivityThread、Activity等等这些类就显得那么特殊呢?我们的代码、写的布局是通过什么路径使用系统资源把界面展示在屏幕上的?这一切就涉及到我们今天的主角:Context。

这是context系列文章的开篇,限于篇幅分为三部分:
第一部分:也就是本文,主要讲解什么是context以及关于context家族和相关实现类。
第二部分:主要讲不同Context的创建流程,包括Application、Activity、Service。
第三部分:也是最终篇,讲解剩下两个四大组件的context来源以及从更高的角度理解context。

读者可前往主页选择感兴趣的部分阅读,也可以完整阅读系统化学习context。

什么是Context

回想一下最初学习Android开发的时候,第一用到context是什么时候?如果你跟我一样是通过郭霖的《第一行代码》来入门android,那么一般是Toast。Toast的常规用法是:

Toast.makeText(this, "我是toast", Toast.LENGTH_SHORT).show()
复制代码

当初也不知道什么是Context,只知道他需要一个context类型,把activity对象传进去即可。从此context贯穿在我开发过程的方方面面,但我始终不知道这个context到底有什么用?为什么要这个对象?我们首先来看官方对于Context类的注释:

/**
 * Interface to global information about an application environment.  This is
 * an abstract class whose implementation is provided by
 * the Android system.  It
 * allows access to application-specific resources and classes, as well as
 * up-calls for application-level operations such as launching activities,
 * broadcasting and receiving intents, etc.
 */
public abstract class Context {...}
复制代码

关于应用程序环境的全局信息的接口。 这是一个抽象类,它的实现是由Android系统提供。 它允许访问特定应用的资源和类,以及向上调用应用程序级的操作,如启动活动,广播和接收Intent等

可以看到Context最重要的作用就是获取全局消息、访问系统资源、调用应用程序级的操作。可能对于这些作用没什么印象,想一下,如果没有context,我们如何做到以下操作:

  • 弹出一个toast
  • 启动一个activity
  • 获取程序布局文件、drawable文件等
  • 访问数据库

这些平时看似简单的操作,一旦失去了context将无法执行。这些行为都有一个共同点:需要与系统交汇。四大组件为什么配为组件,而我们的写的就只能叫做一个普通的Java类,正是因为context的这些功能让四大组件有了不一样的能力。简单来说,context是:

应用程序和系统之间的桥梁,应用程序访问系统各种资源的接口。

我们一般使用context最多的是两种情景:直接调用context的方法和调用接口时需要context参数。这些行为都意味着我们需要访问系统相关的资源。

那context是从哪里来的?AMS!AMS是系统级进程,拥有访问系统级操作的权利,应用程序的启动受AMS的调控,在程序启动的过程中,AMS会把一个“凭证”通过跨进程通信给到我们的应用程序,我们的程序会把这个“凭证”封装成context,并提供一系列的接口,这样我们的程序也就可以很方便地访问系统资源了。这样的好处是:

系统可以对应用程序级的操作进行调控,限制各种情景下的权限,同时也可以防止恶意攻击。

如Application类的context和Activity的context权利是不一样的,生命周期也不一样。对于想要操作系统攻击用户的程序也进行了阻止,没有获得允许的Java类没有任何权利,而Activity开放给用户也只有部分有限的权利。而我们开发者获取context的路径,也只有从activity、application等组件获取。

因而,什么是Context?Context是应用程序与系统之间沟通的桥梁,是应用程序访问系统资源的接口,同时也是系统给应用程序的一张“权限凭证”。有了context,一个Java类才可以被称之为组件。

Context家族

上一部分我们了解什么是context以及context的重要性,这一部分就来了解一下context在源码中的子类继承情况。先看一个图:

最顶层是Context抽象类,他定义了一系列与系统交汇的接口。ContextWrapper继承自Context,但是并没有真正实现Context中的接口,而是把接口的实现都托管给ContextImpl,ContextImpl是Context接口的真正实现者,从AMS拿来的“凭证”也是封装到了ContextImpl中,然后赋值给ContextWrapper,这里运用到了一种模式:装饰者模式ApplicationService都继承自ContextWrapper,那么他们也就拥有Context的接口方法且本身即是context,方便开发者的使用。Activity比较特殊,因为它是有界面的,所以他需要一个主题:Theme,ContextThemeWrapper在ContextWrapper的基础上增加与主题相关的操作。

这样的设计有这样的优点:

  • Activity等可以更加方便地使用context,可以把自身当成context来使用,遇到需要context的接口直接把自身传进去即可。
  • 运用装饰者模式,向外屏蔽ContextImpl的内部逻辑,同时当需要更改ContextImpl的逻辑实现,ContextWrapper的逻辑几乎不需要更改。
  • 更方便地扩展不同情景下的逻辑。如service和activity,情景不同,需要的接口方法也不同,但是与系统交互的接口是相同的,使用装饰者模式可以拓展出很多的功能,同时只需要把ContextImpl对象赋值进去即可。

context的分类

前面讲到Context的家族体系时,了解到他的最终实现类有:Application、Activity、Service,ContextImpl被前三者持有,是Context接口的真正实现。那么这里讨论一下这三者有什么不同,和使用时需要注意的问题。

Application

Application是全局Context,整个应用程序只有一个,他可以访问到应用程序的包信息等资源信息。获取Application的方法一般有两个:

context.getApplicationContext()
activity.getApplication()
复制代码

通过context和activity都可以获取到Application,那这两个方法有什么区别?没有区别。我们可以打印来看一下:

override fun onCreate(savedInstanceState: Bundle?) {
    ...
    Log.d("一只修仙的猿", "application:$application")
    Log.d("一只修仙的猿", "applicationContext:$applicationContext")
}
复制代码

可以看到确实是同个对象。但为什么要提供两个一样作用的方法?getApplication()方法更加直观,但是只能在activity中调用。getApplicationContext()适用范围更广,任意一个context对象皆可以调用此方法。

Application类的Context的特点是生命周期长,在整个应用程序运行的期间他都会存在。同时我们可以自定义Application,并在里面做一些全局的初始化操作,或者写一个静态的context供给全局获取,不需要在方法中传入context。如:

class MyApplication : Application(){
    // 全局context
    companion object{
        lateinit var context: Context
    }
    override fun onCreate() {
        super.onCreate()
        // 做全局初始化操作
        RetrofitManager.init(this)
        context = this
    }
}
复制代码

这样我们就可以在应用启动的时候对一些组件进行初始化,同时可以通过MyApplication.context来获取Application对象。

但是!!!请不要把Application当成工具类使用。由于Application获取的便利性,有开发者会在Application中编写一些工具方法,全局获取使用,这样是不行的。自定义Application的目的是在程序启动的时候做全局初始化工作,而不能拿来取代工具类,这严重违背谷歌设计Application的原则,也违背Java代码规范的单一职责原则。

四大组件

Activity继承自ContextThemeWrapper,是一个拥有主题的context对象。Activity常用于与UI有关的操作,如添加window等。常规使用可以直接用activity.this

Service继承自ContextWrapper,也可以和Activity一样直接使用service.this来使用context。和activity不同的是,Service没有界面,所以也不需要主题。

ContentProvider使用的是Application的context,Broadcast使用的是activity的context,这两点在后面会进行源码分析。

BaseContext

嗯?baseContext是什么?把这个拿出来单独讲,细心的读者可能会发现activity中有一个方法:getBaseContext。这个是ContextWrapper中的mBase对象,也就是ContextImpl,也是context接口的真正逻辑实现。

context的使用问题

使用context最重要的问题之一是注意内存泄露。不同的context的生命周期不同,Application是在应用存在的期间会一直存在,而Activity是会随着界面的销毁而销毁,如果当我们的代码长时间持有了activity的context,如静态引用或者单例类,那么会导致activity无法被释放。如下面的代码:

object MyClass {
    lateinit var mContext : Context
    fun showToast(context : Context){
        mContext = context
    }
}
复制代码

单例类在应用持续的时间都会一直存在,这样context也就会被一直被持有,activity无法被回收,导致内存泄露。

那,我们就都换成Application不就可以了,如下:

object MyClass {
    lateinit var mContext : Context
    fun showToast(context : Context){
        mContext = context.applicationContext
    }
}
复制代码

答案是:不可以。什么时候可以使用Application?不涉及UI以及启动Activity操作Activity的context是拥有主题属性的,如果使用Application来操作UI,那么会丢失自定义的主题,采用系统默认的主题。同时,有些UI操作只有Activity可以执行,如弹出dialog,这涉及到window的token问题,我在这篇文章token验证进行了详细的解答,有兴趣的读者可以去阅读一下。这也是官方对于context不同权限的设计,没有界面的context,就不应该有操作界面的权利。使用Application启动的Activity必须指定task以及标记为singleTask,因为Application是没有任务栈的,需要重新开一个新的任务栈。因此,我们需要根据不同context的不同职责来执行不同的任务

总结

文章讲解了什么是context、context家族、已经不同的context实现类。 通过本文可以了解什么是context以及与context相关的类。

那么接下来就要开始深入讲源码相关内容了。很多读者一听到源码就下意识地表示拒绝。其实源码没有想象中那么枯燥无味,甚至可以说还是挺有趣的。阅读完源码会对context有更加深刻的理解。

全文到此,原创不易,觉得有帮助可以点赞收藏评论转发。 笔者才疏学浅,有任何想法欢迎评论区交流指正。 如需转载请评论区或私信交流。

另外欢迎光临笔者的个人博客:传送门

文章分类
Android
文章标签