建筑局网站,wordpress主题 汉化,wordpress图片链接更换域名,网站建设对接视频在手机桌面应用中点击某一个 icon 之后#xff0c;最终是通过 startActivity 去打开某一个 Activity 页面。我们知道#xff0c;Android 中的一个 APP 就相当于一个进程。所以#xff0c;startActivity 操作中还需要判断#xff0c;目标 Activity 的进程是否已经创建。如果…在手机桌面应用中点击某一个 icon 之后最终是通过 startActivity 去打开某一个 Activity 页面。我们知道Android 中的一个 APP 就相当于一个进程。所以startActivity 操作中还需要判断目标 Activity 的进程是否已经创建。如果没有则在显示 Activity 之前还需要将进程 Process 提前创建出来。
假设是从 Activity A 跳转到另一个 APP 中的 Activity B。过程如下图所示 整个 startActivity 的流程分为 3 大部分也涉及 3 个进程之间的交互 ActivityA -- ActivityManagerService简称 AMS ActivityManagerService -- ApplicationThrad ApplicationThread -- Activity 1. ActivityA 到 AMS 阶段
这一过程并不复杂用如下这张图表示具体过程 接下来查看源码看看做了哪些操作 Activity 的 startActivity()最终调用了 startActivityForResult() 方法。传入的 -1 表示不需要获取 startActivity 的结果。
Activity 的 startActivityForResult()具体代码如下所示。调用 Instrumentation 的 execStartActivity方法剩下的交给 Instrumentation 类去处理。 Instrumentation 类主要用来监控应用程序与系统交互。蓝线部分的 MainThread 是 ActivityThread 类型。ActivityThread 可用理解为1个进程这里即表示 ActivityA 所在的进程。通过 MainThread 获取一个 ApplicationThread 引用这个引用就是实现进程间通信的。具体来说就是 AMS 所在的系统进程通知应用进程进行了一系列操作。
Instrumentation 类的 execStartActivity。在 instrumentation 中会通过 ActivityManager.getService获取 AMS 的实例。然后调用其 startActivity 方法。实际上这里就是通过 AIDL 来调用 AMS 的 startActivity 方法。 至此startActivity 的工作重心成功的从进程 A 转移到了系统进程 AMS中。
2. ActivityManagerService 到 ApplicationThread 阶段
下面来探索在 AMS 中是如何一步一步执行到 B 进程的。
上面在讲 Instrumentation 时我们提到了一个 ApplicationThread 类来负责进程间通信的。这里 AMS 最终其实就是调用了 B 进程的一个 ApplicationThread 引用从而间接地通知 B 进程进行相应操作。
相比较 startActivity 到 AMSAMS 到 ApplicationThread 的流程看起来复杂了很多。实际上这里面就干了两件事情
a)综合处理 launchMode 和 Intent 中的 Flag 标志位并根据处理结果生成一个目标 Activity B 的对象ActivityRecord
b)判断是否需要为目标 Activity B 创建一个新的进程ProcessRecord、新的任务栈TaskRecord
AMS 的 startActivity 从上图中的代码可以看出经过多个方法的调用最终通过 obtainStarter() 方法获取了 ActivityStarter 类型的对象然后调用其 execute() 方法。在 execute() 方法中会再次调用其内部的 startActivityMayWait 方法。
ActivityStarter 的 startActivityMayWait
ActivityStarter 类专门负责一个 Activity 的启动操作主要作用包括解析 Intent、创建 ActivityRecord、如果有可能还要创建 TaskRecord。
startActivityMayWait 的部分实现代码如下 从上面代码可以看出获取目标 Activity 信息的操作由 mSupervisor 来实现它是 ActivityStackSupervisor 类型。主要是负责 Activity 所处栈的管理类。在上面代码的 resolveIntent 中实际上是调用系统 PackageManagerService 来获取最佳 Activity。有时候我们通过隐式 Intent 启动 Activity 时系统中可能存在多个 Activity 可以处理 Intent。此时会弹出一个选择框让用户选择具体需要打开哪一个 Activity 界面就是此处的逻辑处理结果。
在 startActivityMayWait 方法中调用了一个重载的 startActivity 方法最终会调用 ActivityStarter 中的 startActivityUnchecked 方法来获取启动 Activity 的结果。
ActivityStarter 的 startActivityUnchecked 图中 1 处计算启动 Activity 的 Flag 值图中2处处理 Task 和 Activity 的进栈操作图中3处启动栈中顶部的 Activity。 computeLaunchingTaskFlags 方法 这个方法的主要作用是计算启动 Activity 的 Flag不同的 Flag 决定了启动 Activity 最终会被放置到哪一个 Task 集合中。
图中1处 mInTask 是 TaskRecord 类型此处为 null代表 Activity 要加入的栈不存在。因此需要判断是否需要新建 Task图中2处的 mSourceRecord 是 ActivityRecord 类型它是用来描述初始 Activity比如ActivityA 启动了 ActivityBActivityA 就是初始 Activity。当我们使用 Context 或者 Application 启动 Activity 时此时 mSourceRecord 为 null图中3处表示初始 Activity如果是在 LAUNCH_SINGLE_INSTANCE 栈中的 Activity需要添加 FLAG_ACTIVITY_NEW_TASK 的标识。因为 LAUNCH_SINGLE_INSTANCE 栈只能允许保存一个 Activity图中4处表示如果 LaunchMode 设置了 LAUNCH_SINGLE_TASK 或 LAUNCH_SINGLE_INSTANCE则也要创建一个新栈。 startActivityLocked 方法 方法中会调用 insertTaskAtTop() 方法尝试将 Task 和 Activity 入栈。如果 Activity 是以 NEW_TASK 的模式启动或者 Task 堆栈中不存在该 TaskId则 task 会重新入栈并且放在栈的顶部。注意Task 先入栈之后才是 Activity 入栈它们是包含关系。
上面一下子引出了好几个概念StackTaskActivity。其实它们都是在 AMS 内部维护的数据结构它们之间的关系如下图 resumeFocusedStackTopActivityLocked 方法 经过一些列调用最终代码又回到了 ActivitSupervisor 中
ActivityStackSupervisor 的 startSpecificActivityLocked 方法 图中1处根据进程名称和 Application 的 UID来判断目标进程是否已经创建。如果没有则代表进程未创建图中2处调用 AMS 创建 Activity 所在进程。
不管是目标进程已经存在还是新建目标进程最终都会调用图中红线部分的 realStartActivityLocked 方法来执行启动 Activity 的操作。
ActivityStackSupervisor 的 realStartActivityLocked 方法 这个方法在 Android 27 和 28两个版本的区别很大。从 android-28 开始 Activity 的启动交给了事务Transaction来完成。图中1处创建了 Activity 启动事务并传入 app.thread 参数它是 applicationThread 类型。在上文 startActivity 阶段applicationThread 是为例实现进程间通信的是 ActivityThread 的一个内部类图中2处执行 Activity 的启动事务由 ClientLifecycleManager 来完成。具体代码如下 可以看出实际上是调用了启动事务的 ClientTransaction 的 schedule() 方法。而这个 transaction 实际上是在创建 ClientTransaction 时传入的 app.thread 对象也就是 applicationThrad。 这里传入的 app.thread 会赋值给 ClientTransaction 的成员变量 mClientClientTransaction 会调用 mClient.scheduleTransaction(this) 来执行事务。这个 app.thread 是 ActivityThread 的内部类 ApplicationThread所以事务最终是调用 app.thread 的 scheduleTransaction 执行。 到这里位置startActivity 的操作就成功的从 AMS 转移到了另一个进程B 中的 ApplicationThread 中。剩下的就是 AMS 通过进程间通信机制通知 ApplicationThread 执行 ActivityB 的生命周期方法。 3. ApplicationThread 到 Activity 阶段
上面我们分析到AMS 将启动 Activity 的任务作为一个事务 ClientTransaction 去完成。在 ClientLifecycleManager 中会调用 ClientTransaction 的 schedule() 方法。如下代码所示 mClient 是一个 IApplicationThread 接口类型具体实现是 ActivityThread 的内部类 ApplicationThread。因此后续执行 Activity 生命周期的过程都是由 ApplicationThread 指导完成的。 上面代码中的 scheduleTransaction() 方法仍然是调用了 ActivityThread 的 scheduleTransaction() 方法但实际上这个方法是在 ActivityThread 的父类 ClientTransactionHandler 中实现。 调用 sendMessage() 方法向 Hanlder 中发送了一个 EXECUTE_TRANSACTION 消息并且 Message 中的 obj 就是启动 Activity 的事务对象。而这个 Handler 的具体实现是 ActivityThread 中的 mH 对象。具体代码如下 最终调用了事务的 execute() 方法如下代码所示 在 executeCallback 方法中会遍历事务中的 callback 并执行 execute 方法。这些 callbacks 是何时被添加的呢
前面在创建 ClientTransaction 时通过 addCallback() 方法传入了callback 参数。从下面代码可以看出其实是一个 LaunchActivityItem 对象 LaunchActivityItem 的 execute() 方法 这里就已经到了与 Activity 生命周期相关的方法。上面代码中的 client 是 ClientTransactionHandler 类型实际实现类是 ActivityThread因此最终方法又回到了 ActivityThread。
ActivityThread 的 handleLaunchActivity
这是一个比较重要的方法Activity 的生命周期方法就是在这个方法中有序执行。 图中1处初始化 Activity 的 WindowManager每一个 Activity 都会对应一个窗口图中2处调用 performLaunchActivity 创建并显示 Activity图中3处通过反射创建目标 Activity 对象图中4处调用 attach 方法建立 activity 与 context 之间的联系。创建 phoneWindow 对象并与 Activity 进行关联操作图中5处通过 instrumentation 最终调用 Activity 的 onCreate 方法。
至此目标 Activity 已经成功创建并执行生命周期方法。 总结
本次详细介绍了 Activity 的启动在源码中的实现流程
这一过程主要涉及 3 个进程间的通信过程 进程 A 通过 Binder 调用 AMS 的 startActivity 方法 AMS 通过一系列的计算构造目标 Intent然后在 ActivityStack 与 ActivityStackSupervisor 中处理 Task 和 Activity 的入栈操作 AMS 通过 Binder 机制调用目标进程中 ApplicationThread 的方法来创建并执行 Activity 生命周期方法ApplicationThread 是 ActivityThread 的一个内部类最终都调用到了 ActivityThread 中的相应方法。
