android context理解,安卓中的context
1.语境的概念。其实一直想写一篇关于语境的文章，但是怕技术不如别人，所以参考了一些资料。今天我就来整理一下，写出来。如有不足之处，请指出，参考资料会在显眼的地方标明。
Context，相信无论是第一天开发Android，还是各种开发Android的老鸟，都一定熟悉Context的使用~ ~加载资源、开始一个新的活动、获取系统服务、获取内部文件(文件夹)路径、创建视图操作等都需要Context的参与。可见语境是共通的。你可能会问到底是什么语境。Context字面意思是上下文，或者叫场景，也就是用户用操作系统操作的过程。比如你打电话，场景包括电话程序对应的界面和背后隐藏的数据；
但是从程序的角度来看，语境是什么呢？从节目的角度，可以有一个比较权威的回答。Context是一个抽象类，我们可以通过看它的类结构来直接解释答案：
你可以看到，活动、服务、应用都是上下文的子类；
也就是说，从Android系统的角度来看，上下文是一个场景，代表了一个与操作系统交互的过程。从程序的角度理解，上下文是一个抽象类，活动、服务、应用等。都是这个类的实现。
仔细看看上图：Activity、Service、Application都继承自ContextWrapper，ContextWrapper包含了一个基础上下文，实现了大部分方法。
先说这么多吧。如果有能力，我们会从其他角度看语境。加油~
2.语境和应用语境看标题，不要误解。ApplicationContext没有这个类，但是应该叫：Activity和Application作为上下文的区别。嗯，那倒是真的。当你需要上下文时，如果是在活动中，大多数人会直接发送这个。在匿名内部类的时候，因为这个不能用，所以需要写XXXActivity .这个很多哥们会偷懒，所以就来getApplicationContext。那么你有没有想过XXXActivity.this和getApplicationContext的区别呢？
XXX和getApplicationContext返回的肯定不是一个对象，而是当前XXXActivity的一个实例，是项目的应用的一个实例。既然区别这么明显，那么各自的使用场景肯定是不一样的，乱用可能会带来一些问题。
先说使用上下文时需要注意的问题。
3.保留证明资料。当你写一些类的时候，比如工具类，你可以把它们写成单例。这些工具类大多需要访问资源，也就是说你需要上下文的参与。
在这种情况下，我们需要注意语境的指称。
例如，下面的措辞：
对于上面的单个案例，大家应该都不陌生(请不要在意getInstance的效率)，内部保存了一个上下文引用；
1.包com . mooc . shader . round imageview；
2.
3.导入Android . content . context；
4.
5.公共类CustomManager
6.{
7.私有静态CustomManager sInstance
8.私有ContextmContext
9.
10.私有CustomManager(上下文上下文)
11.{
12.this.mContext=context
13.}
14.
15.公共静态同步CustomManager getInstance(上下文Context)
16.{
17.if(sin instance==null)
18.{
19.新的CustomManager(上下文)；
20.}
21.return sInstance
22.}
23.
24.//一些方法
25.private void someothermethodneecontext()
26.{
27.
28.}
29.}
这样写没有问题。问题是我们无法确定这个语境是从哪里来的。有很大的可能是你为了方便，直接在一个活动里发了个this这就是问题所在。我们类中的sInstance是一个静态的、强引用的实例，它将一个活动作为上下文来引用。也就是说，只要我们的项目还活着，我们的活动就没有办法回收它的内存。而且我们活动的生命周期肯定没那么长，所以造成内存泄露。
那么，怎样才能避免这样的问题呢？
有些人会说，我们可以软报价，嗯，软报价。如果是回收的，就不怕NullPointException了。
对上述代码进行以下更改：
1.公共静态同步CustomManager getInstance(上下文Context)
2.{
3.if(sin instance==null)
4.{
5.new custom manager(context . getapplicationcontext())；
6.}
7.return sInstance
8.}
这样我们就解决了内存泄漏的问题，因为我们引用了一个ApplicationContext，它的生命周期和我们的singleton对象是一致的。
在这种情况下，有些人可能会说：“我早告诉你了。”那以后只能这样用了。不幸的是，我们不能。上面我们已经说过了，Context和Application Context的区别是很大的，也就是说，它们的应用场景(你也可以把它们想成能力)是不一样的，并不是所有以Activity为Context的场景都可以用Application Context来处理。
下面开始介绍各种上下文的应用场景。
4.语境的应用场景
请注意，一些数字被添加到一些没有。其实这些从能力上来说都是可以的，但为什么都是不可以的呢？
以下逐一解释：
第一：在这些类中开始活动是可能的，但是需要创建一个新的任务。一般不推荐。
第二：在这些类中使用layout inflate是合法的，但是会使用系统的默认主题风格。如果自定义了一些样式，可能就用不上了。
数字3:当接收者为空时允许。在4.2或以上版本中，用于获取粘性广播的当前值。(可以忽略)
注意：ContentProvider和BroadcastReceiver在上表中，因为它们的内部方法中有上下文可供使用。
好了，我们来看这里的表格，重点是活跃度和应用。可以看出，UI相关的方法基本不推荐或者不能使用Application，前三种操作基本不可能出现在Application中。其实只要把握好一点，一切与UI相关的事情都要以活动为上下文来处理；其他操作，如服务、活动、应用等。可以做到。当然要注意上下文引用的持有，防止内存泄露。
5.总结完毕。至此，语境的分析基本完成。希望你以后能稍微考虑一下。这里用Activity合适吗？会不会造成内存泄露？申请工作在这里通过吗？
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。