以下分别通过Context认知角度，继承关系，对象创建等方面android中Context做了深入的解释，一起学习下。
思考 一般情况下，我们在设计一个插件化框架的时候，要解决的无非是下面几个问题: 四大组件的动态注册 组件相关的类的加载 资源的动态加载 实际上从目前的主流插件化框架来看，都是满足了以上的特点，当然因为Activity是大家最常用到的，因此一些插件化框架便只考虑了对Activity的支持，比如Small框架,从原理上来看，基本都差不多，Hook了系统相关的API来接管自己的加载逻辑，特别是Hook 了AMS(ActivityManagerService)以及ClassLoader这2个，因为这2个控制着四大
Android中bindService是一个异步的过程，什么意思呢？使用bindService无非是想获得一个Binder服务的Proxy，但这个代理获取到的时机并非由bindService发起端控制，而是由Service端来控制，也就是说bindService之后，APP端并不会立刻获得Proxy，而是要等待Service通知APP端，具体流程可简化如下： APP端先通过bindService去AMS登记，说明自己需要绑定这样一个服务，并留下派送地址 APP回来，继续做其他事情，可以看做是非阻塞的 AMS
既然资源的加载是通过 Resource 类，如果想要获取另一个 apk 中的资源文件，那么自己实例化一个 Resource 进行加载可以吗？
上文中写到，写到从AMS->ZygoteServer->ActivityThread。继续承接上文。
为了让大家在后面更好的理解插件化的内容，我们本篇文章围绕Context(基于Android API 24)进行讲解，主要内容如下：
ActivityThread作为主应用程序的主线程管理类，我们都从main方法开始分析。main方法主要功能是创建ActivityThread且关联，创建Looper死循环不让程序退出。
ContentProvider 启动会伴随进程的启动，在ActivityManagerService中，启动进程是由startProcessLocked方法来完成的，内部通过Process的start方法来完成一个新的进程启动。 ActivityThread的main方法
在学习Android的路上，大家肯定会遇到异步消息处理，Android提供给我们一个类来处理相关的问题，那就是Handler。相信大家大多都用过Handler了，下面我们就来看看Handler最简单的用法：
Activity的启动通常从startActivity开始。 但是startActivity最终都会调用startActivityForResult
res里的每一个资源都会在R.java里生成一个对应的Integer类型的id，APP启动时会先把R.java注册到当前的上下文环境，我们在代码里以R文件的方式使用资源时正是通过使用这些id访问res资源，然而插件的R.java并没有注册到当前的上下文环境，所以插件的res资源也就无法通过id使用了。
在Activity调用startService方法实质调用的是ContextWrapper中的startService方法。
插件化的基石 -- apk动态加载 随着我街业务的蓬勃发展，产品和运营随时上新功能新活动的需求越来越强烈，经常可以听到“有个功能我想周x上，行不行”。行么？当然是不行啦，上新功能得发新版本啊，到时候费时费力打乱开发节奏不说，覆盖率也是个问题。苏格拉底曾经说过：“现在移动端的主要矛盾是产品日益增长的功能需求与平台落后的发布流程之间的矛盾”。 当然，作为一个靠谱的程序猿，我们就是为了满足产品的需求而存在的(正义脸)。于是在一个阳光明媚的早晨，吃完公司的免费早餐后，我和小强、叶开，决定做一个完善的Andro
Activity启动过程可以分为两种：一种是根activity的启动过程，另一种是普通activity启动过程。
Activity是Android中一个很重要的概念，堪称四大组件之首，关于Activity有很多内容，比如生命周期和启动Flags，这二者想要说清楚，恐怕又要写两篇长文，更何况分析它们的源码呢。不过本文的侧重点不是它们，我要介绍的是一个Activity典型的启动过程，本文会从源码的角度对其进行分析。我们知道，当startActivity被调用的时候，可以启动一个Activity，但是你知道这个Activity是如何被启动的吗？每个Activity也是一个对象，你知道这个对象是啥时候被创建的吗（也就是说它的构造方法是什么时候被调用的）？为什么onCreate是Activity的执行入口？所有的这一切都被系统封装好了，对我们来说是透明的，我们使用的时候仅仅是传递一个intent然后startActivity就可以达到目的了，不过，阅读了本文以后，你将会了解它的背后到底做了哪些事情。在分析之前，我先介绍几个类：
启动性能 ContentProvider 的生命周期默认在 Application onCreate() 之前，而且都是在主线程创建的。我们自定义的 ContentProvider 类的构造函数、静态代码块、onCreate 函数都尽量不要做耗时的操作，会拖慢启动速度。
到这里AssetManager创建完毕。然后设置相关的路径 AssetManager assets = new AssetManager(); // resDir can be null if the 'android' package is creating a new Resources object. // This is fine, since each AssetManager automatically loads the 'android' package // already. if (resDir != null) { if (assets.addAssetPath(resDir) == 0) { return null; } } if (splitResDirs != null) { for (String splitResDir : splitResDirs) { if (assets.addAssetPath(splitResDir) == 0) { return null; } } } if (overlayDirs != null) { for (String idmapPath : overlayDirs) { assets.addOverlayPath(idmapPath); } } if (libDirs != null) { for (String libDir : libDirs) { if (libDir.endsWith(".apk")) { // Avoid opening files we know do not have resources, // like code-only .jar files. if (assets.addAssetPath(libDir) == 0) { Log.w(TAG, "Asset path '" + libDir + "' does not exist or contains no resources."); } } } } 接着就创建Resource对象 r = new Resources(assets, dm, config, compatInfo); 这里看到AssetManager保存到了Resources对象中。接着进入到Resources的构造方法中 public Resources(AssetManager assets, DisplayMetrics metrics, Configuration config, CompatibilityInfo compatInfo) { mAssets = assets; mMetrics.setToDefaults(); if (compatInfo != null) { mCompatibilityInfo = compatInfo; } updateConfiguration(config, metrics); assets.ensureStringBlocks(); } 最后进入到updateConfiguration(Configuration config, DisplayMetrics metrics, CompatibilityInfo compat) mAssets.setConfiguration(mConfiguration.mcc, mConfiguration.mnc, locale, mConfiguration.orientation, mConfiguration.touchscreen, mConfiguration.densityDpi, mConfiguration.keyboard, keyboardHidden, mConfiguration.navigation, width, height, mConfiguration.smallestScreenWidthDp, mConfiguration.screenWidthDp, mConfiguration.screenHeightDp, mConfiguration.screenLayout, mConfiguration.uiMode, Build.VERSION.RESOURCES
前言 在几个月前我写了Android深入四大组件（一）应用程序启动过程这篇文章，它是基于Android 7.0的，当我开始阅读Android 8.0源码时发现应用程序（根Activity）启动过程照Android 7.0有了一些变化，因此又写下了本篇文章，本篇文章照此前的文章不仅流程发生变化，而且增加了一些分析，算是升级版本。由于篇幅较长，Android8.0 根Activity启动过程仍旧分为前篇和后篇来进行讲解。 1. ActivityThread启动Activity的过程 通过前篇的介绍，我们知道目前
dex 解密时 , 需要将 代理 Application 替换为 真实 Application ; 替换 Application 首先要理解系统如何注册应用的 Application 的 ;
场景:在 APP M 中启动 APP N 中一个服务,即目标服务和 APP M 不在同一个进程
在 Service 中调用 getApplication() 方法 , 获取 Application , 返回的是 Service 中的 private Application mApplication 成员 , 该成员在 Service 的 attach 方法中进行设置 ;
上文 Activity生命周期管理 中我们地完成了『启动没有在AndroidManifest.xml中显式声明的Activity』的任务；通过Hook AMS和拦截ActivityThread中H类对于组件调度我们成功地绕过了AndroidMAnifest.xml的限制。
在 BroadcastReceiver 中的 onReceive 方法中的 Context context 参数 , 打印出来是 android.app.ReceiverRestrictedContext 类型的 , 调用该对象的 getApplicationContext() 方法 , 获取的 Application , 就是用户自定义的 Application ;
Context，中文直译为“上下文”. 主要有三个作用： 1、它描述的是一个应用程序环境的信息，即上下文。 2、该类是一个抽象(abstract class)类，Android提供了该抽象类的具体实现类。 3、通过它我们可以获取应用程序的资源和类，也包括一些应用级别操作，例如：启动一个Activity，发送广播，接受Intentx信心等。
【Android 插件化】插件化简介 ( 组件化与插件化 ) 【Android 插件化】插件化原理 ( JVM 内存数据 | 类加载流程 ) 【Android 插件化】插件化原理 ( 类加载器 )
最近做的项目需要支持几十种语言，很多小语种在不认识的人看来跟乱码一样，翻译一般是由翻译公司翻译的，翻译完成后再导入到项目里面，这就容易存在一些问题。
在 Activity 中调用 getApplication() 方法 , 获取 Application 的过程分析 ;
这是一个abstract方法，具体实现在ContextImpl（Context的具体实现,位置E:\adt\sdk\sources\android-23\android\app）的startService中
在 Activity生命周期管理 以及 广播的管理 中我们详细探讨了Android系统中的Activity、BroadcastReceiver组件的工作原理以及它们的插件化方案，相信读者已经对Android Framework和插件化技术有了一定的了解；本文将探讨Android四大组件之一——Service组件的插件化方式。
创建 自定义 ContentProvider , 并在其 onCreate 方法中打印上下文信息 :
Android应用程序的载体是APK文件，它是一个组件和资源的容器。APK文件和我们常见可执行文件的区别是：每个可执行文件在一个单独的进程中，但是APK文件可能运行在一个单独的进程也可能和其他APK文件运行在同一个进程中。Android的设计理念是弱化进程的存在，取而代之以组件的概念。
好的，上面又又又又提到了两个关键函数：ApplicationThread.scheduleCreateService、requestServiceBingingsLocked。
Context 是一个抽象类。既然是抽象类，那么它就代表了一类具体对象的通用特征。先来看一下 Context 的类图：
Android插件化架构，目前第三方的框架比较多，早几年自己用的是DL框架，这个框架的源码比较简单主要用的是静态代理。如果我们自己要去写一个插件化架构框架那要解决的问题会分为几个方面，类的加载，资源和布局的加载，广播的管理方式，Activity的加载和生命周期管理，Service的插件化，ContentProvider的插件化等等等等，反正加载一个没有运行的app到主程序，需要解决的问题基本就这么多，如果能够一一解决那么就可以实现插件化了。 内涵段子项目部分我们实现几个，然后介绍一个360开源框架DroidPlugin原理一致，后面我们再一一实现，那么这一期实现什么呢？我们需要启动插件APP那么就需要启动里面的Activity,这些Activity事先是不会在主工程的AndroidManifest.xml中配置，启动一个没有注册的Activity肯定会报错，我们是否可以想个办法去绕过系统的检测，让没有在AndroidManifest.xml中配置的Activity照样可以启动呢？ 看源码的时候我们其实时常强调一定要带着思想，要解决这么个问题我们肯定需要清楚的知道系统启动Activity的具体流程，当然可以直接去了解为什么报错，这里我们还是把启动流程全部走一遍，也方便以后开发中再遇到什么问题。
Android中UI线程会自动给我们建立一个looper,但是looper中的loop方法是个死循环.为什么我们在UI线程中写的代码为何都能顺利执行?为什么没有引起ANR呢? Looper的部分源
本篇介绍下android中bindService相关的内容，包括bindService的简单功能，并提供一个demo进行操作演示，最后从源码角度分析下这块流程，希望通过阅读源码可以对该流程可以掌握的清楚一些。
Android中Context用法详解学习 本文我们一起来探讨一下关于Android中Context的作用以及Context的详细用法，这对我们学习Android的资源访问有很大的帮助，文章中也贴出
“爸爸爸爸，你说我玩的这个小天才电话手表怎么这么厉害，随便点一下这个小图片，这个应用就冒出来了，就可以听儿歌了。好神奇啊。”
该文章是一个系列文章，是本人在Android开发的漫漫长途上的一点感想和记录，我会尽量按照先易后难的顺序进行编写该系列。该系列引用了《Android开发艺术探索》以及《深入理解Android 卷Ⅰ，Ⅱ，Ⅲ》中的相关知识，另外也借鉴了其他的优质博客，在此向各位大神表示感谢，膜拜！！！另外，本系列文章知识可能需要有一定Android开发基础和项目经验的同学才能更好理解，也就是说该系列文章面向的是Android中高级开发工程师。
在前一篇博客滴滴插件化框架VirtualAPK原理解析（一）之插件Activity管理 中VirtualAPK是如何对Activity进行管理的，本篇博客，我们继续来学习这个框架，这次我们学习的是如何去管理Service。
launcher就是android桌面应用程序。也是操作系统启动有第一个app。同时作为其他app的入口。我们找到其源码 android-6.0.0_r1\packages\apps\Launcher2 我们先看Manifest文件 找到app的入口Activity
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
