说起来，

App 启动流程：从 Launcher 点击到 Activity 创建

一、主要流程速览 & 使用者痛点快速定位

痛点一：你在点击图标后为什么程序会做这么多“中间人”操作？答案是“统一调度”，下面的表格帮你一眼看清各角色。

S: . Binder IPC: ATMS.startActivity
至于S->S，. parse Intent & check process
S->Z这方面，. socket: fork request
Z->A的观点是，. new process & invoke main
从A->A来看，. prepareMainLooper + attach
至于A->S，. Binder IPC: attachApplication
至于S->A，. scheduleLaunchActivity ★第1步
说到A->H，sendMessage ★第2步
从H-->A来看，handleLaunchActivity → performLaunchActivity ★第3步
-->

注意这方面，整个链路的指挥权始终在 SystemServer，App 只是一名“被动执行者”。说起来，这正是为什么即使你能看到自己的代码。也无法直接 new 一个 Activity 的根源。

二、第一阶段：Launcher 发起启动请求 – 痛点拆解篇

痛点二的观点是，Launcher 为什么不直接跑到 App？因为它没有权限去管理栈和生命周期。只有 SystemServer 能做到。

源码调用链概览

Launcher.startActivitySafely // 桌面进程,响应图标点击
└─ Activity.startActivity
└─ Activity.startActivityForResult
└─ Instrumentation.execStartActivity
└─ ActivityTaskManager.getService.startActivity
└─ ATMS.startActivity // SystemServer 进程

关键源码细节 & 要点

public ActivityResult execStartActivity {
int result = ActivityTaskManager.getService
.startActivity。who.getAttributionTag,intent,intent.resolveTypeIfNeeded),token,target,requestCode,null,options);checkStartActivityResult;// 异常如 ActivityNotFound 在此抛出
}
…public static IActivityTaskManager getService {
return IActivityTaskManagerSingleton.get;}
private static final Singleton
IActivityTaskManagerSingleton = new Singleton{
@Override protected IActivityTaskManager create{
final IBinder b = ServiceManager.getService;return IActivitiyTaskManager.Stub.asInterface;}
}，

• A:  拿到 Binder，真正执行体在 SystemServer 的 .
• B: Binder IPC = 一次跨进程+内核拷贝。Launcher 无法直接创建.
• C: 自 Android 10 起，AMS 的启动逻辑迁移至 ATMS；AMS 保留其他服务.
• D: No more direct UI launching from app side.
.

"三、第二阶段：SystemServer 中 AMS 启动 App 进程 – 痛点解析"

至于痛点三，Zygote 为什么用 socket 而不是 Binder？ 让我们看看底层实现，话说回来，

"ATMS 如何处理启动请求"

ATMS.startActivity
├─ ActivityStarter.execute
│ ├─ parse Intent / target info
│ ├─ check if ProcessRecord exists
│ │ ├─ exists → warm/hot path
│ │ └─ not → startProcessLocked → create new process
│ └─ stack management : create / reuse Task

"fork 过程——为什么用 LocalSocket"

// ProcessList.startProcessLocked
// ...
ZygoteProcess.start;// LocalSocket to Zygote with arguments
// ...
// Inside ZygoteInit.java:
public static void main{
ZygoteServer zys = new ZygoteServer;Runnable caller = zys.runSelectLoop;// wait for socket msg
if caller.run;}
// Received fork request:
int pid = Zygote.forkAndSpecialize;// native fork
if{ /* child */ RuntimeInit.findStaticMain;}

• E: .
• E: .
• E: .

"App 端初始化 —— 从 Main 到 Attach"

public static void main{
Looper.prepareMainLooper;//①
ActivityThread thread = new ActivityThread;
thread.attach;
//②
Looper.loop;//③
}
private void attach{
…mgr.attachApplication;//★反向注册
} 

这一步经常被忽视。话说回来，没有它，AMS 就没法主动回调给 App。

• M1：MAppThread 是 IApplicationThread.Stub‑impl，即 App 的 Binder 服务端。
  • - 没有它，AMS 无法通知 App 启动完成或失败。- 本质上是 “把自己的句柄交给程序”。- 也是 “从客户端到服务器”的逆向绑定。
  • - 对比旧版，只有在第一次 activity 时才会触发 Application.onCreate。其实，- 后续 activity 会复用同一个 Application 实例。
  attachApplicationLocked{ /* confirm process ready */ }