java为什么使用context java 上下文context 怎么理解
大家好，今天来为大家分享java为什么使用context的一些知识点，和java 上下文context 怎么理解的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！
Android中,Context,什么是Context
Context对象是如此常见和传递使用，它可能会很容易产生并不是你预期的情形。加载资源、启动一个新的Activity、获取系统服务、获取内部文件路径以及创建view（其实还远不止这些）统统都需要Context对象来完成。我(原文作者)想做的只是给大家提供一些Context是如何工作的见解，以及让大家在应用中更有效的使用Context的技巧。
Context的类型
并不是所有的context实例都是等价的。根据Android应用的组件不同，你访问的context推向有些细微的差别。
Application－是一个运行在你的应用进程中的单例。在Activity或者Service中，它可以通过getApplication()函数获得，或者人和继承于context的对象中，通过getApplicationContext()方法获得。不管你是通过何种方法在哪里获得的，在一个进程内，你总是获得到同一个实例。
Activity/Service－继承于ContextWrapper，它实现了与context同样API，但是代理这些方法调用到内部隐藏的Context实例，即我们所知道的基础context。任何时候当系统创建一个新的Activity或者Service实例的时候，它也创建一个新的ContextImpl实例来做所有的繁重的工作。每一个Activity和Service以及其对应的基础context，对每个实例来说都是唯一的。
BroadcastReciver－它本身不是context，也没有context在它里面，但是每当一个新的广播到达的时候，框架都传递一个context对象到onReceive()。这个context是一个ReceiverRestrictedContext实例，它有两个主要函数被禁掉：registerReceiver()和bindService()。这两个函数在BroadcastReceiver.onReceive()不允许调用。每次Receiver处理一个广播，传递进来的context都是一个新的实例。
ContentProvider－它本身也不是一个Context，但是它可以通过getContext()函数给你一个Context对象。如果ContentProvider是在调用者的的本地（例如，在同一个应用进程），getContext()将返回的是Application单例。然而，如果调用这和ContentProvider在不同的进程的时候，它将返回一个新创建的实例代表这个Provider所运行的包。
保存引用
第一个我们需要解决问题是，在一个对象或者类内部保存一个context引用，而它生命周期却超过其保存引用的对象的生命周期。例如，创建一个自定义的单例，它需要一个context来加载资源或者获取ContentProvider，从而保存一个指向当前Activiy或者Service的引用在单例中。
糟糕的单例
[java] view plain copy
public class CustomManager{
private static CustomManager sInstance;
public static CustomManager getInstance(Context context){
if(sInstance== null){
sInstance= new CustomManager(context);
}
return sInstance;
}
private Context mContext;
private CustomManager(Context context){
mContext= context;
}
}
这里的问题在于，我们不知道这个context是从哪里来的，并且如果保存一个最终指向的是Activity或者Servece的引用是并不安全的。这是一个问题，是因为一个单例在类的内部维持一个唯一的静态引用，这意味着我们的对象，以及所有其他它所引用的对象，将永远不能被垃圾回收。假如这个Context是一个Activity，我们将保存与这个Activity相关的所有的view以及其他大的对象，从而造成内存泄漏。
为了解决这个问题，我们修改单例永远只是保存Application context：
改善的单例：
[java] view plain copy
public class CustomManager{
private static CustomManager sInstance;
public static CustomManager getInstance(Context context){
if(sInstance== null){
//Always pass in the Application Context
sInstance= new CustomManager(context.getApplicationContext());
}
return sInstance;
}
private Context mContext;
private CustomManager(Context context){
mContext= context;
}
}
现在这个例子中，我们的Context来自哪里都没有关系，因为我们这里保存引用是安全的。Application Context本身就是一个单例，所以我们再创建另外一个static引用，不会造成任何内存泄漏。另外一个很好的例子是，在后台线程或者一个等待的Handler中保存Context的引用，也可以使用这样的方法。
为什么我们不能总是引用Application context呢？正如前面说的，引用Application context永远不用担心内存泄漏的问题。问题的答案，就像我在开始的介绍中说的，是因为不同context并不是等价的。
Context的能力
Conext能做的通用操作决定于这个context最初来源于哪里。下表所列的是，在应用中常见的会收到context对象的，以及对应的每种情况，它可以用于哪些地方：
Application
Activity
Service
ContentProvider
BroadcastReceiver
Show a Dialog NO YES NO NO NO
Start an Activity NO1 YES NO1 NO1 NO1
Layout Inflation NO2 YES NO2 NO2 NO2
Start a Service YES YES YES YES YES
Bind to a Service YES YES YES YES NO
Send a Broadcast YES YES YES YES YES
Register BroadcastReceiver YES YES YES YES NO3
Load Resource Values YES YES YES YES YES
注：NO1表示Application context的确可以开始一个Activity，但是它需要创建一个新的task。这可能会满足一些特定的需求，但是在你的应用中会创建一个不标准的回退栈（back stack），这通常是不推荐的或者不是是好的实践。
NO2表示这是非法的，但是这个填充（inflation）的确可以完成，但是是使用所运行的系统默认的主题（theme），而不是你app定义的主题。
NO3在Android4.2以上，如果Receiver是null的话（这是用来获取一个sticky broadcast的当前值的），这是允许的。
用户界面UI
从前面的表格中可以看到，application context有很多功能并不是合适去做，而这些功能都与UI相关。实际上，只有Activity能够处理所有与UI相关的任务。其他类别的context实例功能都差不多。
幸运的是，在应用中这三种操作基本上都不需要在Activity范围之外进行，这很可能是android框架故意这么设计的。尝试显示一个使用Aplication context创建的Dialog，或者使用Application context开始一个Activity，系统会抛出一个异常，让你的application崩溃，非常强的告诉你某些地方出了问题。
一个并不明显的问题是填充布局（inflating layout）。如果你已经读过了我（原文作者）的上一篇文章Layout inflation，你就已经知道它可能是一个非常神秘过程，伴随一些隐藏的行为。使用正确的context关系到其中的一个行为。当你使用Application context来inflate一个布局的时候，框架并不会报错，并返回一个使用系统默认的主题创建一个完美的view给你，而没有考虑你的applicaiton自定义的theme和style。这是因为Acitivity是唯一的绑定了在manifast文件种定义主题的Context。其他的Context实例将会使用系统默认的主题来inflater你的view。导致显示的结果并不是你所希望的。
规则的路口
可能有些读者已经得出两个规则互相矛盾的结论。可能有些情况下，在某些Application的设计中，我们可能既必须长期保存一个的引用，并且为了完成与UI相关的工作又必须保存一个Activity。如果出现这种情况，我将会强烈建议你重新考虑你的设计，它将是一个很好的“反框架”教材。
经验法则
绝大多数情况下，使用在你的所工作的组建内部能够直接获取的Context。只要这个引用没有超过这个组建的生命周期，你可以安全的保存这个引用。一旦你要保存一个context的引用，它超过了你的Activity或者Service的生命周期范围，甚至是暂时的，你就需要转换你的引用为Application context。
java,android里的context都是什么意思啊该如何处理
Context在Java中的出现是如此频繁，但其中文翻译“上下文”又是如此诡异拗口，因此导致很多人不是很了解Context的具体含义是指什么，所以很有必要来深究一下这词的含义。先来举几个JAVA中用到Context的例子（1）JNDI的一个类javax.naming.InitialContext，它读取JNDI的一些配置信息，并内含对象和其在JNDI中的注册名称的映射信息。请看下面的代码
InitialContext ic=new InitialContext();
RMIAdaptor server=(RMIAdaptor)ic.lookup("jmx/invoker/RMIAdaptor");
这是一段JBoss中获取MBean的远程调用类的代码。在这里面通过InitialContext中JNDI注册的名称“jmx/invoker/RMIAdaptor”来获得RMIAdaptor
对象。这和JAVA集合中的MAP有点象，有一个String的key，key对映着它的对象。（2）再来看看下面Spring中最常见的几句代码。ApplicationContext是内含configuration.xml配置文件的信息，使得可以通过getBean用名称得到相应的注册对象。
ApplicationContext ctx= new FileSystemXmlApplicationContext("configuration.xml");
Object obj= ctx.getBean("Object_Name");
从上面的代码，我很能体会到Context所代表的意义：公用信息、环境、容器....。所以我觉得Context翻译成上下文并不直观，按照语言使用的环境，翻译成“环境”、“容器”可能更好。把Context翻译成“上下文”只是不直观罢了，不过也没大错。我们来看看中文的“上下文”是什么意思。我们常说听话传话不能“断章取义”，而要联系它的“上下文”来看。比如，小丽对王老五说“我爱你”，光看这句还以为在说情话呢。但一看上下文－－“虽然我爱你，但你太穷了，我们还是分手吧”，味道就完全变了。从这里来看“上下文”也有“环境”的意思，就是语言的环境。
上下文其实是一个抽象的概念。我们常见的上下文有Servlet中的pageContext，访问JNDI时候用的Context。写过这些代码的人可能比较容易理解，其实他们真正的作用就是承上启下。比如说pageContext他的上层是WEB容器，下层是你写的那个Servlet类，pageContext作为中间的通道让Servlet和Web容器进行交互。再比如访问JNDI的Context，他的上层是JNDI服务器（可能是远程的），下层是你的应用程序，他的作用也是建立一个通道让你能访问JNDI服务器，同时也让JNDI服务器接受你的请求，同样起到交互作用。
java 上下文context 怎么理解
一、context可以理解成一个聚宝盆,在当前环境下你能拿到的参数都可以从context出发去拿,而不仅仅是放URL的.从里面可以拿到request,session,response.......,可以说只要你拿到了context就可以访问任何你有权限访问的东西
二、context就是“容器”，放的就是应用程序的所有资源，要用时候就访问它，所以context里面的东西，在同一个应用程序里面是全局的。
三、是一个包含各种context的设置的对象
例如：pageContext就包含了该页面的各种设置。可以通过他得到该页面所在服务器路径等等。
Context用于在 Request操作中指定上下文对象的对象，上下文字符串在与请求调用一起被发送之前，必须在该指定的上下文对象中进行解析。Context对象包含 NamedValue对象形式的属性列表。这些属性表示关于客户端、环境或请求情形的信息，它们通常是一些可能不方便作为参数传递的属性。
END，本文到此结束，如果可以帮助到大家，还望关注本站哦！