让人做网站需要准备什么条件,各大网站响应生态建设,织梦做分销网站,公司注册新流程今天被问到了关于Context的一些问题。发现自己关于这部分还是不是很清晰#xff0c;然后发现洋神博客里有一篇讲的很好 很详细。我反正是看懂了#xff0c;我觉得我再写 也不会比这个更清楚了#xff0c;所以转过来。 http://blog.csdn.net/lmj623565791/article/details/40… 今天被问到了关于Context的一些问题。发现自己关于这部分还是不是很清晰然后发现洋神博客里有一篇讲的很好 很详细。我反正是看懂了我觉得我再写 也不会比这个更清楚了所以转过来。 http://blog.csdn.net/lmj623565791/article/details/40481055本文出自【张鸿洋的博客】 1、Context概念 其实一直想写一篇关于Context的文章但是又怕技术不如而误人子弟于是参考了些资料今天准备整理下写出来如有不足请指出参考资料会在醒目地方标明。 Context相信不管是第一天开发Android还是开发Android的各种老鸟对于Context的使用一定不陌生~~你在加载资源、启动一个新的Activity、获取系统服务、获取内部文件夹路径、创建View操作时等都需要Context的参与可见Context的常见性。大家可能会问到底什么是ContextContext字面意思上下文或者叫做场景也就是用户与操作系统操作的一个过程比如你打电话场景包括电话程序对应的界面以及隐藏在背后的数据 但是在程序的角度Context又是什么呢在程序的角度我们可以有比较权威的答案Context是个抽象类我们可以直接通过看其类结构来说明答案 可以看到Activity、Service、Application都是Context的子类 也就是说Android系统的角度来理解Context是一个场景代表与操作系统的交互的一种过程。从程序的角度上来理解Context是个抽象类而Activity、Service、Application等都是该类的一个实现。 在仔细看一下上图Activity、Service、Application都是继承自ContextWrapper而ContextWrapper内部会包含一个base context由这个base context去实现了绝大多数的方法。 先扯这么多有能力了会从别的角度去审视Context加油~ 2、Context与ApplicationContext 看了标题千万不要被误解ApplicationContext并没有这个类其实更应该叫做Activity与Application在作为Context时的区别。嗯的确是这样的大家在需要Context的时候如果是在Activity中大多直接传个this当在匿名内部类的时候因为this不能用需要写XXXActivity.this很多哥们会偷懒直接就来个getApplicationContext。那么大家有没有想过XXXActivity.this和getApplicationContext的区别呢 XXXActivity和getApplicationContext返回的肯定不是一个对象一个是当前Activity的实例一个是项目的Application的实例。既然区别这么明显那么各自的使用场景肯定不同乱使用可能会带来一些问题。 下面开始介绍在使用Context时需要注意的问题。 3、引用的保持 大家在编写一些类时例如工具类可能会编写成单例的方式这些工具类大多需要去访问资源也就说需要Context的参与。 在这样的情况下就需要注意Context的引用问题。 例如以下的写法 package com.mooc.shader.roundimageview; import android.content.Context; public class CustomManager
{ private static CustomManager sInstance; private Context mContext; private CustomManager(Context context) { this.mContext context; } public static synchronized CustomManager getInstance(Context context) { if (sInstance null) { sInstance new CustomManager(context); } return sInstance; } //some methods private void someOtherMethodNeedContext() { }
} 对于上述的单例大家应该都不陌生请别计较getInstance的效率问题内部保持了一个Context的引用 这么写是没有问题的问题在于这个Context哪来的我们不能确定很大的可能性你在某个Activity里面为了方便直接传了个this;这样问题就来了我们的这个类中的sInstance是一个static且强引用的在其内部引用了一个Activity作为Context也就是说我们的这个Activity只要我们的项目活着就没有办法进行内存回收。而我们的Activity的生命周期肯定没这么长所以造成了内存泄漏。 那么我们如何才能避免这样的问题呢 有人会说我们可以软引用嗯软引用假如被回收了你不怕NullPointException么。 把上述代码做下修改 public static synchronized CustomManager getInstance(Context context) { if (sInstance null) { sInstance new CustomManager(context.getApplicationContext()); } return sInstance; } 这样我们就解决了内存泄漏的问题因为我们引用的是一个ApplicationContext它的生命周期和我们的单例对象一致。 这样的话可能有人会说早说嘛那我们以后都这么用不就行了很遗憾的说不行。上面我们已经说过Context和Application Context的区别是很大的也就是说他们的应用场景你也可以认为是能力是不同的并非所有Activity为Context的场景Application Context都能搞定。 下面就开始介绍各种Context的应用场景。 4、Context的应用场景 大家注意看到有一些NO上添加了一些数字其实这些从能力上来说是YES但是为什么说是NO呢下面一个一个解释 数字1启动Activity在这些类中是可以的但是需要创建一个新的task。一般情况不推荐。 数字2在这些类中去layout inflate是合法的但是会使用系统默认的主题样式如果你自定义了某些样式可能不会被使用。 数字3在receiver为null时允许在4.2或以上的版本中用于获取黏性广播的当前值。可以无视 注ContentProvider、BroadcastReceiver之所以在上述表格中是因为在其内部方法中都有一个context用于使用。 好了这里我们看下表格重点看Activity和Application可以看到和UI相关的方法基本都不建议或者不可使用Application并且前三个操作基本不可能在Application中出现。实际上只要把握住一点凡是跟UI相关的都应该使用Activity做为Context来处理其他的一些操作Service,Activity,Application等实例都可以当然了注意Context引用的持有防止内存泄漏。 5、总结 好了到此Context的分析基本完成了希望大家在以后的使用过程中能够稍微考虑下这里使用Activity合适吗会不会造成内存泄漏这里传入Application work吗 转载于:https://www.cnblogs.com/codenoodles/p/6421151.html
