本文依据 corpus 仓库中的四段录屏整理，内容覆盖桌面入口、前一个 Activity 的暂停、目标进程判定，以及新 Activity 的创建与显示。 上一篇《Android-Framework（十五）-进程的 fork 创建过程》已经分析 startSpecificActivityLocked 到 Zygote fork、ActivityThread.main 、attachApplic

一、从 Zygote 到系统服务 Zygote 完成预加载后，Android 还不能立即运行应用。管理 Activity、窗口、电源和软件包的服务需要先启动，而这些服务中的许多都运行在同一个进程中：systemserver。 理解这段启动流程，要分清三个层次： 进程创建：Zygote 通过 fork 创建 systemserver，为子进程设置运行身份。 运行环境初始化：子进程加载入口类、

一、Zygote 要回答的三个问题 在 Android 设备上执行 adb shell ps -A -o USER,PID,PPID,NAME grep -E 'zygote systemserver'，你会看到 zygote 通常只有一个实例，PPID 是 1；而任何一个第三方应用进程的 PPID 都是这个 zygote。再看进程名，zygote 和 systemserver 都不是用户空间

素材来源：AgentWorkFlow「02-开机启动 Init 进程」 一、从 1 号进程说起：init 要回答的三个问题 Android 启动后执行 adb shell ps，能看到 init 的 PID 是 1；杀掉一个由 init 管理、允许重启的 native service，新 PID 很快又会出现。这两个现象指向三个问题：init.rc 明明只是文本，怎样变成内存中的配置？配置里的命令

本文整理自享学团队直播课《Android 插件化(二)：Activity加载》。 上一讲解决的是"插件的类能被加载进来"，这一讲解决的是"插件的 Activity 能真正被启动"。前者靠类加载器，后者靠 Hook——在 Android 启动 Activity 的链路中间安插一个钩子，把"要启动哪个 Activity"这个信息偷偷换一遍，让一个已注册的占坑 Activity 去骗过 AMS 的校验，

本文内容整理自享学团队直播课《App 启动流程源码分析（五）》 一、从启动屏动画到 Application 有一个很容易复现的现象：给 Application.onCreate 的头尾各打一个 Trace.beginSection / endSection，测出来只有 30ms；但用 adb shell am start -W 量整体，接入几个三方 SDK 前后 TotalTime 涨了一百多毫秒

本文内容整理自享学团队直播课《App 启动流程源码分析（四）》 一、App启动性能标准设定 点击桌面图标，屏幕立刻被一整块纯白（或纯黑）铺满，几百毫秒后才切成 App 的真实界面。可以通过在冷启动过程中执行 adb shell dumpsys window windows grep -i starting进行流程观测，通过上述命令能看到一个类型为 TYPEAPPLICATIONSTARTING

本文内容整理自享学团队直播课《App 启动流程源码分析（三）》 一、从 WMS 方向看启动，问题落在哪里 冷启动的耗时账单最后要落到"首帧什么时候上屏"，这条线的终点在 WMS 一侧。但往回追一步就会撞上一个不太好回答的地方：进程创建完成、ApplicationThread 回连 AMS 之后，AMS 在同一段加锁逻辑里干了两件事——把 Application 的信息发过去，以及把 Activit