在Android编程中,Context类到底是什么?它用于什么?
我在开发者网站上读过这篇文章,但我无法清楚地理解它。
在Android编程中,Context类到底是什么?它用于什么?
我在开发者网站上读过这篇文章,但我无法清楚地理解它。
当前回答
了解android环境的简单示例:
每个老板都有一个助手来照顾,来完成所有不那么重要和耗时的任务。如果需要一份文件或一杯咖啡,一名助手就在路上。一些老板几乎不知道办公室里发生了什么,所以他们也会询问助手。他们自己做一些工作,但在大多数其他事情上,他们需要助手的帮助。
在这种情况下,
Boss–是Android应用程序
助手–是一个上下文
文件/咖啡杯–是资源
当我们需要获取有关应用程序的不同部分(如活动、应用程序等)的信息时,我们通常会调用上下文。
涉及上下文的某些操作(需要助手的操作):
加载公共资源创建动态视图显示Toast消息启动活动等。
获取上下文的不同方式:
getContext()
getBaseContext()
getApplicationContext()
this
其他回答
Context是android.content类的实例。Context提供到执行应用程序的android系统的连接。例如,您可以通过上下文检查当前设备显示的大小。
它还允许访问项目的资源。它是有关应用程序环境的全局信息的接口。
Context类还提供对Android服务的访问,例如报警管理器以触发基于时间的事件。
活动和服务扩展了Context类。因此,它们可以直接用于访问上下文。
上下文的定义
上下文表示环境数据它提供了对数据库等内容的访问
更简单的术语(示例1)
假设Person-X是一家初创软件公司的首席执行官。公司有一位首席架构师,这位首席架构师在公司内完成所有涉及数据库、UI等的工作等现在,首席执行官雇佣了一名新的开发人员。是建筑师告诉新聘人员的责任基于新人的技能数据库或UI等工作。
更简单的术语(示例2)
这就像访问应用程序资源的android活动。这与你去酒店时想吃早餐、午餐类似&在合适的时间吃饭,对吧?在逗留期间,你还喜欢其他很多东西。你是怎么得到这些东西的?你让客房服务人员为你带来这些东西。这里,客房服务人员是上下文,因为您是单一活动和酒店将成为您的应用程序,最后是早餐、午餐&晚餐必须是资源。
涉及上下文的内容包括:
正在加载资源。启动新活动。创建视图。获取系统服务。
上下文是Activity、Service、Application等的基类
描述这一点的另一种方式是:将上下文视为电视的远程&电视中的频道是资源、服务、使用意图等--这里,远程充当访问前台所有不同资源的访问权限。
因此,Remote可以访问资源、服务、使用意图等渠道。。。。同样地访问远程的人自然可以访问所有的东西,如资源、服务、使用意图等
获取上下文的不同方法
getApplicationContext()获取上下文()getBaseContext()或者这个(在活动课上)
例子:
TextView tv = new TextView(this);
关键字this指的是当前活动的上下文。
简单地说:
顾名思义,它是应用程序/对象当前状态的上下文。它让新创建的对象了解发生了什么。通常,您调用它来获取有关程序的另一部分(活动和包/应用程序)的信息。
您可以通过调用getApplicationContext()、getContext()和getBaseContext()或this(当在从context扩展的类中时,例如Application、Activity、Service和IntentService类)来获取上下文。
上下文的典型用法:
创建新对象:创建新视图、适配器和侦听器:TextView tv=新建TextView(getContext());ListAdapter适配器=新的SimpleCursorAdapter(getApplicationContext(),…);访问标准公共资源:服务,如LAYOUT_INFLATER_SERVICE、SharedPreferences:context.getSystemService(LAYOUT_INFLATER_SERVICE)getApplicationContext().getSharedPreferences(*name*,*mode*);隐式访问组件:关于内容提供商、广播、意图getApplicationContext().getContentResolver().query(uri,…);
如果您想将Context与Android中其他熟悉的类连接,请记住以下结构:
Context<ContextWrapper<应用程序Context<ContextWrapper<ContextThemeWrapper<活动Context<ContextWrapper<ContextThemeWrapper<活动<列表活动Context<ContextWrapper<ServiceContext<ContextWrapper<Service<IntentService
所以,所有这些类都是以自己的方式存在的上下文。如果愿意,可以将Service和ListActivity转换为Context。但如果仔细观察,一些类也会继承主题。在活动或片段中,您希望将主题化应用于视图,但不关心它,例如Service类。
我在这里解释上下文的差异。
如果您查看的评论https://stackoverflow.com/a/16301475/1772898,你会看到ulf edholm的评论
嗯,对我来说,这一切听起来就像我们老前辈过去所说的全局变量,当对象定向进入场景时,这是非常令人反感的
他是对的。上下文是全局变量的替代。
为了简单起见,我们可以说:全局变量≈上下文
上下文相对于全局变量的好处是,全局变量使得不可能在同一进程中创建同一系统的两个独立实例,而上下文允许系统的多个实例在单个进程中共存,每个实例都有自己的上下文。
请查看John Ousterhout的《软件设计哲学》,7.5传递变量。
全局变量使得无法创建两个独立变量同一进程中同一系统的实例,因为访问全局变量将发生冲突。...我最常用的解决方案是引入上下文对象,如图7.2(d).上下文存储应用程序的所有全局状态(否则将是传递变量或全局变量变量)。大多数应用程序的全局变量中都有多个变量状态,表示配置选项、共享子系统和性能计数器。每个有一个上下文对象系统的实例。上下文允许系统在单个进程中共存,每个进程都有自己的上下文。
稍后在评论部分,您将看到比约恩的另一条评论
如果你只是grep一个代码库,你会看到数百个不同的getContext,getBaseContext,getBlaBlaContext。
他也是对的。
为了减少必须了解上下文的方法的数量,在许多主要对象中都引用了对上下文的引用。这就是为什么会看到getContext、getBaseContext、getBlaBlaContext。。在这么多地方。
参考资料:John Ousterhout的《软件设计哲学》,7.5传递变量。
不幸的是,许多地方可能需要上下文,因此它可能会成为传递变量。为了减少必须知道的方法的数量,对上下文的引用可以保存在系统的大多数主要对象中。在以下示例中图7.2(d),包含m3的类存储对上下文作为其对象中的实例变量。当新对象create方法从其对象,并将其传递给新对象的构造函数。用这个方法,上下文在任何地方都可用,但它只显示为构造函数中的显式参数。