通过这篇文章你将学习到： Context 与 Activity 有什么关系？ Context对于Activity有什么作用？ 不同类型的Context的应用场景是什么？...不同类型的Context的应用场景是什么？...返回的是同一个Applicatoin对象，但作用域不同： getApplicatoin()的作用域：Activity、Service，但不能在BroadcastReceiver里使用； getApplicationContext...4.3 getApplicationContext()、getBaseContext()和Activity.this的区别是什么？...getApplicationContext()：返回的是Application类型的Context Activity.this：返回的是当前Activity的Context getBaseContext
：四大组件里 Activity 和 Service 都是 Context , 应用的 Context 数就是 Activity 、Service、Application 的个数之和，顺便说一下 Application...：好像都差不多，平常开发的时候用哪个 Context 效果都一样，主要不同就是 Application 的生命周期和应用一样，所以在初始化一些第三方库的时候如果要传 Context 要用 Application...我们调用 ContextWrapper 的 getBaseContext 方法就能拿到 ContextImpl 的实例 再说它们的不同点，它们有各自不同的生命周期；在功能上，只有 Activity 显示界面...面试官：四大组件就剩 BroadcastReceiver ，说说它方法里的 Context 是哪来的 ️：广播接收器，分动态注册和静态注册。...当然，这也是为什么不用的时候要 unregisterReceiver 取消注册，不然这个 Context 就泄漏了哦。
四大组件和 Context Application 和 Context 为什么 Application 的 Context 不可以创建 Dialog ？ 未完待遇......对于 Activity 和 Service 来说，它们都需要系统上下文运行环境，但它们又是不同的。...同时，Activity、Service、Application 这些具体组件本身又扩展出了不同的生命周期功能。 所以，装饰器模式通过组合和扩展装饰类，来给不同的具体对象提供了不同的功能扩展。...四大组件和 Context Activity 和 Context 先说 Activity，Activity 的启动过程极其复杂，我们就直接从 ActivityThread 的 performLaunchActivity...为什么 Application 的 Context 不可以创建 Dialog ？
目录 什么是 Context？ 四大组件和 Context Application 和 Context 为什么 Application 的 Context 不可以创建 Dialog ？...对于 Activity 和 Service 来说，它们都需要系统上下文运行环境，但它们又是不同的。...同时，Activity、Service、Application 这些具体组件本身又扩展出了不同的生命周期功能。 所以，装饰器模式通过组合和扩展装饰类，来给不同的具体对象提供了不同的功能扩展。...四大组件和 Context Activity 和 Context 先说 Activity，Activity 的启动过程极其复杂，我们就直接从 ActivityThread 的 performLaunchActivity...为什么 Application 的 Context 不可以创建 Dialog ？
, 它允许访问特定于应用程序的资源和类，以及用于应用程序级操作的上调，activity，广播和intent等。...首先，肯定有人问为什么context是在ActivityThread中实例化的，这边不具体深入启动流程。...有兴趣的可以自己去看。 Activity中ContextImpl的实例化 通过startActivity我们会启动一个新的Activity。...); ..... } 可以看出步骤流程和Activity的类似，只是实现细节略有不同而已。...getApplication和getApplicationContext的区别 很多人分不清getApplication和getApplicationContext，这其中包括我，于是就去翻了翻源码：
： Context 数量 = Activity 数量 + Service 数量 + 1 另外，我们可以看到 Application 和 Service 都是直接继承 ContextWrapper 的而...Activity 在这里说明一下为什么 Service 和 Application 都是继承的 ContextWrapper 类而 Activity 却是继承 ContextThemeWrapper 那是因为...attachBaseContext(context); 接下来我们来分析一下 Activity 在哪里和这个扯上关系的。...到此为止，关于 Application 、Service 和 Activity 关于Context 的源码基本就差不多了。接下来我们来解决一些实际的内容。...这就涉及到作用域的问题了，我们可以发现使用 getApplication 的方法的作用范围是 Activity 和 Service ，但是我们在其他地方却不能使用这个方法，这种情况下我们就可以使用 getApplicationContext
到这里我们即将开启我们的源码之旅。 可能我们最大的疑惑就是glide为什么就用了简单的一句代码就可以实现图片的加载。...通过上图我们会发现不论传入Activity、FragmentActivity、Fragment最终都会调用图中红框中的方法，而这两个方法最终流程都是一致的就是那就是会向当前的Activity当中添加一个隐藏的...于是Glide就使用了添加隐藏Fragment的这种小技巧，因为Fragment的生命周期和Activity是同步的，如果Activity被销毁了，Fragment是可以监听到的，这样Glide就可以捕获这个事件并停止图片加载了...不仅如此，你监控了所有的activity怎么和Glide想要监控的Activity关联到一块去，虽然可以实现，但是这个办法真心不实用，既然Glide给了我们这么完美的解决方案我们就要学以致用，以后尽力用到自己的工程中去...GlideAPP()和with()方法到这里就结束了，以上为个人见解，有不同理解的小伙伴可以扫码左侧二维码，参与讨论哦！！！欢迎你来技术交流，无bb，不朋友！！
实现思路： 后台提供接口，返回服务端版本号serviceVersion以及APK下载地址 前端对接接口，用拿到的serviceVersion和APK配置的localVersion比较，如果serviceVersion...* @param context */ public void openFile(File f, Context context) { Log.i(LOGTAG...); // 设置进度条风格，风格为长形 m_pDialog.setProgressStyle(ProgressDialog.STYLE_HORIZONTAL);..., Toast.LENGTH_SHORT).show(); } } /** * 根据类型下载不同的文件 *...vsPreference.getData(Constant.VERSION_URL,""); } createThread(downUrl); } /** * 根据不同的包安装
一个应用程序可以认为是一个工作环境，用户在这个环境中会切换到不同的场景，这就像一个前台秘书，她可能需要接待客人，可能要打印文件，还可能要接听客户电话，而这些就称之为不同的场景，前台秘书可以称之为一个应用程序...2：Activity.getApplicationContext,获取当前Activity所在的(应用)进程的Context对象，通常我们使用Context对象时，要优先考虑这个全局的进程Context...getApplication()和getApplicationContext() 上面说到获取当前Application对象用getApplicationContext，不知道你有没有联想到getApplication...那么问题来了，既然这两个方法得到的结果都是相同的，那么Android为什么要提供两个功能重复的方法呢？实际上这两个方法在作用域上有比较大的区别。...3：尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有。
我是在activity调用destroy后开启服务，广播接收器代码如下： /** * 监听activity的结束 */ private BroadcastReceiver mFinishReceiver...= new BroadcastReceiver() { @Override public void onReceive(Context context, Intent...的生命周期，所以在activity的onDestroy方法中去发送广播，通知广播接收器程序已经finish了，可以开启服务，所实现的效果就是当程序结束后，所开启的服务会一直运行在后台进行监听，并通过通知栏发送消息...= new NotificationCompat.Builder(getApplicationContext()); 第三步，获取到builder对象后， 就可以对通知栏进行一个界面和通知形式的一些设置了...在builder设置好后就可以发送通知请求 了： //发送通知请求 manager.notify(1,mBuilder.build()); 一个完整的发送通知栏的代码如下，当然下拉时的显示风格也可以自定义
网上有很多朋友在这里传入this.getApplicationContext（），这是不对的。 AlertDialog对象是依赖于一个View的，而View是和一个Activity对应的。...于是，这里涉及到一个生命周期的问题，this.getApplicationContext（）取的是这个应用程序的Context，Activity.this取的是这个Activity的Context，这两者的生命周期是不同的...而AlertDialog应该是属于一个Activity的，在Activity销毁的时候它也就销毁了，不会再存在；但是，如果传 入this.getApplicationContext（），就表示它的生命周期是整个应用程序...下面具体解释它的内涵 其实Activity.this就是context的一个具体,Activity.this是你当前所在的activity的上下文,this.getApplicationContext(...(this);你是要在当前的activity里面创建对话框,如果传递的是this.getApplicationContext(),这是整个应用的上下文,代码怎么会知道你想在哪个具体的activity里面创建对话框呢
Context如何实现以上功能的？ 为何不同的Context访问资源都得到的是同一套资源？ 为何不同场景下要使用不同的Context？ 一个APP中有多少个Context？...比如，你在家里打”农药“就是一个场景；你在宾馆和妹子一起用手机看"小"电影也是一个场景；你在公司用电脑调试你的app也是一个场景。那么Context 就可以抽象的理解为一个场景，每个场景有不同的内容。...综上所述，我们可以看出在设备其他因素不变的情况下我们通过不同的Context实例得到的Resources是同一套资源。 关于Resources我后续会专门开个文章去详细讲解。...Timer和TimerTask没有进行Cancel，从而导致Timer和TimerTask会一直持有外部Activity的引用，所以要在适当的时机cancel。...调用的getSystemService获取系统服务，这些服务运行在他们自己的进程执行一系列后台工作或者提供和硬件交互的家口，如果Context对象需要在一个Service内部事件发生时随时受到通知，则需要把自己作为一个监听器注册进去
不同 Activity Context、Service Context、Application Context、Base Context 有什么区别？...为什么不推荐使用 Base Context？...不推荐使用 Base Context，是担心用户修改了 Base Context 而导致错误的发生 对于 Activity 而言，除了担心用户的修改之外，Base Context 和 Activity...，Base Context 和 Activity 本身对于 Reource 以及 Theme 的相关行为是不同的（如果应用了 Configuration 的话），使用 Base Context 可能会出现无法预期的现象...，和 Activity 使用的 Resource 不同 getApplicationContext 返回的就是 Application 对象本身，一般情况下它对应的是应用本身的 Application
Android App的页面是有生命周期的，Glide比较好的一个功能就是具有生命周期管理功能，能够根据页面和APP的生命周期来管理图片的加载和停止，也开放接口供用户在内存紧张时手动进行内存管理。...getApplicationContext,也就是不进行生命周期管理： 在getRequestManagerFragment中先查看当前Activity中有没有FRAGMENT_TAG这个标签对应的Fragment...get(@NonNull Activity activity) { if (Util.isOnBackgroundThread()) { return get(activity.getApplicationContext...再贴一次RequestManagerRetriever中获取Fragment的代码，前面留了一个疑问，为什么这里会需要一个pendingRequestManagerFragments对Fragment进行缓存...那么主线程中的执行顺序和消息队列中的执行顺序关系是什么？
一个应用程序可以认为是一个工作环境，用户在这个环境中会切换到不同的场景，这就像一个前台秘书，她可能需要接待客人，可能要打印文件，还可能要接听客户电话，而这些就称之为不同的场景，前台秘书可以称之为一个应用程序...2：Activity.getApplicationContext,获取当前Activity所在的(应用)进程的Context对象，通常我们使用Context对象时，要优先考虑这个全局的进程Context...getApplication()和getApplicationContext() 上面说到获取当前Application对象用getApplicationContext，不知道你有没有联想到getApplication...相信这个问题会难倒不少开发者。 ?...那么问题来了，既然这两个方法得到的结果都是相同的，那么Android为什么要提供两个功能重复的方法呢？实际上这两个方法在作用域上有比较大的区别。
Context 理解 Context的作用 首先来谈一谈Context 什么是Context以及作用 它是应用环境的全局接口，一个抽象类，它的实现是由Android系统提供，是一个系统资源类，启动Activity...Context，调用都委托给他 不同组件Context的区别 Context在不同组件也有区别，下面一一列出不同，这里的Activity与Service中Context的作用是相同的，就不再列出Service...中Context的作用 Activity的Context作用：跟随activity一起启动，内部调用performLaunchActivity，newActivity，classLoad加载，newInstance...Activity里的this和getBaseContext的区别 this返回的是activity对象自己 getBaseContext返回的是ContextWrapper的mBase getApplication...与getApplicationContext的区别 getApplicationContext是Context的抽象函数 getApplication是activity与service特有的，广播不能调用获取
由此，其实我们就已经可以得出结论了，Context一共有三种类型，分别是Application、Activity和Service。...这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。 那么Context到底可以实现哪些功能呢？...由于Context的具体能力是由ContextImpl类去实现的，因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。...Context一共有Application、Activity和Service三种类型，因此一个应用程序中Context数量的计算公式就可以这样写： Context数量 = Activity数量 + Service...(); Log.d("TAG", "myApp is " + myApp); } } 也就是说，getApplicationContext()方法的作用域会更广一些，任何一个Context的实例
由此，其实我们就已经可以得出结论了，Context一共有三种类型，分别是Application、Activity和Service。...这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。 那么Context到底可以实现哪些功能呢？...由于Context的具体能力是由ContextImpl类去实现的，因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。...Context一共有Application、Activity和Service三种类型，因此一个应用程序中Context数量的计算公式就可以这样写： Context数量 = Activity数量 + Service...()方法的作用域会更广一些，任何一个Context的实例，只要调用getApplicationContext()方法都可以拿到我们的Application对象。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
云直播
对象存储
实时音视频
