四大组件以及 Application和Context的全面理解

本文首发于微信公众号——世界上有意思的事，搬运转载请注明出处，不然将追究版权责任。我的微信号：a1018998632，交流qq群：859640274

1、概述

阅读须知

• 1.文章中的缩写指代的意思：CI——>ContextImpl、AT——>ActivityThread、LA——>LoadedApk、CR——>ContentResolver、PM——>PackageManager、SP——>SharedPreferences、APT——>ApplicationThread、AMS——>ActivityManagerService、PR——>ProcessRecord、AR——>ActivityRecord、AS——>ActiveServices、SR——>ServicecRecord。
• 2.文章中的变量 mXXX(yyy)，括号中 yyy 表示该变量的类型。
• 3.文章中的方法 xxx(yyy)，括号中 yyy 表示方法须要传入的变量类型。

2、用处

• 1.Context的实现类有不少，可是 CI 是惟一作具体工做的，其余实现都是对 CI 作代理。
• 2.CI 中有一些成员对象，先来看看这些对象的用处：
  • 1.mSharedPrefsPaths、sSharedPrefsCache：这两个对象是用于获取 SharedPreferences 的，在我前一篇博客里面有讲到。全面剖析SharedPreferences。
  • 2.mMainThread(AT)：这个对象是一个 App 进程的主线程，一个 App 的 Framework 层就是从这里启动的。
  • 3.mPackageInfo(LA)：在 AT 初始化 App 的主线程的时候，会将 Apk 加载到内存中，Apk 在内存中就是以这个对象的形式存在的，该对象能够加载 Apk 的资源和 Dex 文件。
  • 4.mUser(UserHandle)：多用户相关。
  • 5.mContentResolver( ApplicationContentResolver)：继承于 CR，主要功能是经过 Uri 来获取文件、数据库、Asset、Res 等数据，还有就是经过 ContentProvider 来获取其余应用和本机数据。
  • 6.mResourcesManager(ResourcesManager)：单例，由于一个 Apk 不一样机型的适配资源，因此用来加载Resource对象，以保证一个 App 中全部的 CI 使用的都是同一份资源。
  • 7.mResources(Resources)：获取 Apk 中 Res 资源的对象。
  • 8.mOuterContext(Context)：用于指向代理本对象的 Context，例如 Activity、Service 等。
  • 9.mTheme(Resources.Theme)：主题
  • 10.mPackageManager(PM)：包管理类，不只能够获取咱们apk包的信息，还能获取本机apk包的信息。
• 3.CI 中有不少 Api，我将这些 Api 归了一下类
  • 1.获取成员对象：即获取上面我列出来的那些对象，这些对象获取到了以后又有更多 Api 暴露出来，在这里 CI 至关于作了一个聚合。最经常使用的就是 getResource() 了。
  • 2.获取成员对象的成员对象：即为了方便，CI 封装了一些经常使用的获取成员对象中的信息的方法。例如getPackageName()，是经过 PM 来获取的。
  • 3.关于 SP 的操做：咱们知道 SP 其实就是 Xml 文件，因此这里的操做有：获取、移动、删除。
  • 4.文件操做：增删移文件、打开文件流、获取 App 私有文件夹地址等等。
  • 5.数据库操做：咱们知道 Sqlite 实际上是一种文件型数据库，因此有：打开、建立、移动、删除、获取数据库文件路径，等操做。
  • 6.壁纸相关操做：这个不是成员变量提供的，WallpaperManager 是系统 Service 一种，因此是SystemService 提供的。
  • 7.启动Activity：包括通常启动 Acitivyt、多用户启动 Activity、启动多个 Activity。
  • 8.广播操做：发送普通广播、发送须要权限的广播、发送有序广播、发送粘连广播、发送有序粘连广播、多用户广播、移除各类广播、注册各类广播、取消注册各类广播。
  • 9.Service 操做：启动、中止、重启、绑定、解绑、获取系统服务以及多用户操做。
  • 10.权限操做：检查本 App 是否有某种权限、检查某 App 是否有某种权限、检查Uri权限、授予权限等等。
  • 11.各类状况下建立 CI，这个比较重要：
    • 1.createSystemContext(AT)：在 SystemService 建立的时候为其建立一个 CI
    • 2.create App Context(AT，LA)：在 App lication/Service建立的时候为其建立一个 CI
    • 3.createActivityContext(ActivityThread mainThread，LA， IBinder， int displayId，Configuration)：在 Activity 建立的时候为其建立一个 CI。

3、四大组件以及 App lication初始化与Context的关系

在了解 Binder 的时候有以下要注意的点

1.Activity初始化

• 1.CI.startActivity()：将调用交给 Instrumentation (负责监控 Activity 和 AMS 的交互，全部 Activity 的本地进程到远端进程的调用转换都是其来执行)，

• 2.Instrumentation.execStartActivity()：传入一个 APT 而后经过 Binder 机制将调用过程转移到(后称AMS)所AMS 在的系统服务进程，本地主线程则继续运行，不过本地主线程后续也没别的操做了。接下来就是本地的MessageQueue 等待 AMS 服务运行完毕，发送消息将 Activity 的启动从新交给本地主线程。

• 3.AMS.startActivity()：从这里开始会调用会按顺序在 ActivityStarter、ActivityStackSupervisor、ActivityStack 这三个类之间进行调用，主要会进行下面这些操做，不按顺序：

  • 1.对 Intent 的内容进行解析，获取目标 Activity 的信息。
  • 2.根据传入的 APT 获取被调用 App 的信息封装成 PR。
  • 3.将一、2和其余信息结合，将源 Activity 和目标 Activity 封装成两个 AR
  • 4.解析 Activity 的启动模式 和当前的 Activity 栈状态，判断是否须要建立栈和 Activity 。(注意这里的AR 有着 App 中的 Activity 的所有信息，能够将其当作系统服务里面的 Activity 的化身)
  • 5.获取到 Activity 和 Activity 栈以后，接下来要判断是否要将当前 Activity 执行 onPause() 以及让使用Binder 执行目标 Activity 的 onCreate() 和 onResume(注意这里 onStart() 会在 Binder 远程调用onCreate() 的时候直接执行)，这里 AMS 进程会使用 APT 调用 App 进程的 Activity 执行相应的生命周期。
  • 6.在 AMS 中前置准备一切就绪以后，会经过 APT 使用 Handler 的形式调用到 App 进程的 AT 中。
  • 7.最终到了ActivityStackSupervisor.realStartActivityLocked()中会使用 APT 将调用交给 App 进程——>AT.scheduleLaunchActivity()——>AT.handleLaunchActivity()

• 4.AT.handleLaunchActivity()：将有如下操做

  • 1.AT.performLaunchActivity：这个方法有如下操做
    • 1.建立对象LA(一个 App 只加载一次)
    • 2.建立对象 Activity
    • 3.建立对象 App lication(一个 App ，只建立一次)
    • 4.**建立对象 CI **：CI.createActivityContext()
    • 5.Application、CI都 attach 到 Activity 对象：Activity.attach()
    • 6.执行 onCreate()：Instrumentation.callActivityOnCreate()——>Activity.performCreate()——>Activity.onCreate()
    • 7.执行onStart()：AT.performLaunchActivity——>Activity.performStart()——>Instrumentation.callActivityOnStart()——>Activity.onStart()
  • 2.AT.handleResumeActivity()
    • 1.AT.performResumeActivity()——>Activity.performResume()——>Instrumentation.callActivityOnResume()——>Activity.onResume()
    • 2.Activity.makeVisible()——>WindowManager.addView()：开始进行View的绘制流程。
  • 3.从上面咱们能够总结一下：在 AMS 将调用交给 App 进程以后，三个生命周期都是在 App 进程被回调的，而且在 onResume() 以后View才进行绘制

2.Service初始化

• 1.CI.startService()——>CI.startServiceCommon()：在这里传入一个 APT，相似 Activity 启动时的第二步，将调用过程转移到 AMS 中，本地主线程继续运行，等待 APT 从 AMS 进程将调用转移到本地主线程中。
• 2.AMS.startService()：到了 AMS 进程以后，Service 的启动就会全权交给 AS(这是 AMS 用来管理 Service 的成员变量)
• 3.AS.startServiceLocked()：这里作了如下操做
  • 1.根据传入的 APT 获取被调用 App 的信息封装成 PR
  • 2.解析 Intent 等参数获取到 Service 的信息，封装成 SR(这个类能够看作是 Service 在系统服务的化身，记录了 Service 的一切信息)
  • 3.再进过一系列调用：AS.startServiceInnerLocked()——>AS.bringUpServiceLocked()——>AS.realStartServiceLocked() 到这里才是真正在 App 进程启动 Service 的流程。
• 4.AS.realStartServiceLocked()：这里会有如下操做：
  • 1.SR.APT.scheduleCreateService()：这里会将调用转到 App 进程，可是当前的进程还会继续执行，这里就到了 App 线程的APT，这个方法里有如下操做
    • 1.经过 Handler 转到 AT.handleCreateService()
    • 2.建立对象 LA(一个 App 只加载一次)
    • 3.建立对象 Service
    • 4.建立对象 CI
    • 5.建立对象 Application(一个 App 只建立一次)
    • 6.Application、CI分别 attach 到 Service 对象
    • 7.执行 Service.onCreate() 回调
    • 8.此时 Service 已经启动了
  • 2.AS.sendServiceArgsLocked()——>SR. App.APT.scheduleServiceArgs()：这里就转到了 App 进程的 APT 中，这里会有如下操做：
    • 1.APT.scheduleServiceArgs()
    • 2.AT.handleServiceArgs()
    • 3.Service.onStartCommand()
    • 4.此时咱们须要在 Service 中进行的操做将会执行。

3.ContentProvider初始化

• 1.AT.main()——>AT.attach()——>AMS.attach App lication()：传入一个 APT，调用转到了 AMS 进程
• 2.AMS.attachApplicationLocked()：获取到 ApplicationInfo 和 ProviderInfo 列表以后经过 APT 将调用转回 App 进程。
• 3.APT.bindApplication()——>AT.handleBindApplication()——>AT.installContentProviders()：到这里以后将会循环初始化 ContentProvider。
• 4.AT.installProvider()：这个方法里面有如下操做
  • 1.建立对象LA：CI.createPackageContext()中
  • 2.建立对象CI：CI.createPackageContext()中
  • 3.建立对象ContentProvider：ClassLoader建立
  • 4.CI attach到ContentProvider对象：ContentProvider.attachInfo()中
  • 5.执行onCreate回调：ContentProvider.attachInfo()中

4.BroadCastReceiver静态初始化

由于动态广播的注册时进程已建立， 基本对象已建立完成，只须要回调BroadcastReceiver 的 onReceive() 方法便可，因此这里不分析

• 1.当收到广播时会调用AT.handleReceiver()

• 2.建立对象LA(一个 App 只加载一次)

• 3.建立对象BroadcastReceiver

• 4.建立对象 Application

• 5.从建立的 Application中获取 CI

• 6.执行 onReceive() 回调

• 5.Application初始化：由上面四个组件的初始化咱们能够知道，当 App 还没启动的时候唤醒任意组件都会建立一个 Application，而这里分析的是正常状况启动一个 App 的时候建立 Application的流程。

  • 1.这里的流程其实就是包含了ContentProvider 初始化的流程，因此前面都差很少
  • 2.最后到了AT.handleBindApplication()中，这里有如下操做：
    • 1.建立对象 LA
    • 2.建立对象 CI
    • 3.建立对象 Instrumentation
    • 4.建立对象 Application;
    • 5.安装 providers
    • 6.执行 Create 回调

4、四大组件以及 App lication绑定Context的方法

由上一节咱们能够知道，四大组件以及 App lication在初始化的时候都会进行Context的绑定或者建立，这节就来说讲各个组件是如何对context进程赋值的。

• 1.Activity：
  • 1.AT.performLaunchActivity()
  • 2.AT.createBaseContextForActivity(ActivityClientRecord ， Activity)
  • 3.CI.createActivityContext(ActivityThread ， LoadedApk ， IBinder ， int displayId ， Configuration)
  • 4.CI()：被赋值了 ActivityThread、LoadedApk、IBinder activityToken、Configuration
• 2.Service/ App lication：
  • 1.AT.handleCreateService()
  • 2.CI.create App Context(ActivityThread ， LoadedApk)
  • 3.new CI()：被赋值了 ActivityThread、LoadedApk
• 3.BroadCastReceiver：在AT.handleReceiver()中直接获取 App lication的Context，其自身并不建立Context
• 4.ContentProvider：
  • 1.AT.installProvider()
  • 2.Context.createPackageContext()——>CI.createPackageContext()——>CI.createPackageContextAsUser()：这里是经过一个 App lication的Context建立的Context，因此能够看作是 App lication的Context的一个复制。

5、总结

1.组件初始化会建立的对象

• 1.LoadedApk：全部组件在初始化的时候，若是LA没被初始化都会初始化一遍
• 2.Context：
  • 1.只有Activity的CI有上一个Activity的Token
  • 2.Receiver的Context是继承于ContextWr App er 的 ReceiverRestrictedContext，不可绑定Service。
• 3. App lication：
  • 1.Receiver使用的Context是ReceiverRestrictedContext包装的 App lication的Context，因此其能够经过Context获取到 App lication
  • 2.ContentProvider通常是在 App 初始化的时候在初始化 App lication的过程当中加载的，此时 App lication会被加载。可是若是是多个 App 共享进程，第二个 App 由ContentProvider调起，那么 App lication不会被初始化。

2.Context使用场景

说明： (图中第一列表明不一样的 Context， √表明容许在该 Context 执行相应的操做; ×表明不容许; -表明分状况讨论)

• 1.当 Context 为 Receiver的状况下：
  • 1.不容许执行 bindService() 操做， 因为限制性上下文(ReceiverRestrictedContext)所决定的，会直接抛出异常.
  • 2.registerReceiver 是否容许取决于 receiver;
  • 3.当 receiver == null 用于获取 sticky 广播， 容许使用。不然不容许使用registerReceiver。
• 2.纵向来看 startActivity 操做
  • 1.当为 ActivityContext 则可直接使用;
  • 2.当为其余 Context， 要启动的 Activity 不属于任何 Activity 栈，因此必须带上 FLAG_ACTIVITY_NEW_TASK flags 才能使用

3.getApplication() 和 getApplicationContext()

绝大多数状况下， getApplication() 和 getApplicationContext() 这两个方法彻底一致， 返回值也相同; 那么二者到底有什么区别呢? 真正理解这个问题的人很是少. 接下来完全地回答下这个问题：

• 1.getApplicationContext() 这个的存在是 Android 历史缘由. 咱们都知道 getApplication() 只存在于 Activity 和Service 对象，那么对于 BroadcastReceiver 和 ContentProvider 却没法获取 Application， 这时就须要一个能在 Context 上下文直接使用的方法， 那即是 getApplicationContext().
• 2.对于 Activity/Service 来讲， getApplication() 和 getApplicationContext() 的返回值彻底相同，除非厂商修改过接口。
• 3.BroadcastReceiver 在 onReceive 的过程，能使用 getBaseContext().getApplicationContext 获取所在 App lication，而没法使用 getApplication;
• 4.ContentProvider 能使用 getContext().getApplicationContext() 获取所在 Application. 绝大多数状况下没有问题，可是有可能会出现空指针的问题。状况以下：当同一个进程有多个 Apk 的状况下， 对于第二个 Apk 是由Provider 方式拉起的， 前面介绍过 Provider 建立过程并不会初始化所在 Application， 此时执 getContext().get ApplicationContext() 返回的结果即是 NULL，因此对于这种状况要作好判空。

参考文章

• 1.Context全面理解

不贩卖焦虑，也不标题党。分享一些这个世界上有意思的事情。题材包括且不限于：科幻、科学、科技、互联网、程序员、计算机编程。下面是个人微信公众号：世界上有意思的事，干货多多等你来看。