什么时候用Application的Context,什么时候用Activity的Context

泡在网上的日子 / 文 发表于2015-05-26 18:01 第次阅读 Context,Application

单例模式用application的context

如果我们在Activity A中或者其他地方使用Foo.getInstance()时,我们总是会顺手写一个『this』或者『mContext』(这个变量也是指向this)。 试想一下,当前我们所用的Foo是单例,意味着被初始化后会一直存在与内存中,以方便我们以后调用的时候不会在此次创建Foo对象。但Foo中的 『mContext』变量一直都会持有Activity A中的『Context』,导致Activity A即使执行了onDestroy方法,也不能够将自己销毁。但『applicationContext』就不同了,它一直伴随着我们应用存在(中途也可能 会被销毁,但也会自动reCreate),所以就不用担心Foo中的『mContext』会持有某Activity的引用,让其无法销毁。

 

 

看使用的周期是否在activity周期内,如果超出,必须用application;常见的情景包括:AsyncTask,Thread,第三方库初始化等等。

还有些情景,只能用activity:比如,对话框,各种View,需要startActivity的等。

 

Activity.this 返回当前的Activity实例,如果是UI控件需要使用Activity作为Context对象,但是默认的Toast实际上使用ApplicationContext也可以。

 



     大家注意看到有一些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) 踩 (1)
上一篇:网络请求库Volley详解
Volley是谷歌2013年在I/O大会期间推出的网络库。Volley的开发是因为在Android SDK中缺乏一个用户体验良好的网络加载类。 在Volley发布之前,开发具有客户端与服务端交互程序的唯一工具是标准的java类java.net.HttpURLConnection以及Apache 的org.apache.http
下一篇:Android自定义view 滑动开关 支持左右滑动 适用于listview
转自: http://blog.csdn.net/lengguoxing/article/details/46007121 要做这样一种开关。 当开关在左边时,都是灰色的,向右滑动的时候,滑到一半的时候,改变颜色,变成绿色; 当开关在右边是,都市绿色的,向左滑动的时候,滑动一半的时候,改变颜色,变成