外观
点图标到页面显示，AMS、ATMS、WMS 怎样配合？
标准回答
以目标进程尚未运行、需要新建页面的典型启动为例：Launcher 根据入口发起启动请求，经过应用框架进入系统的 Activity 启动链路。系统解析目标组件并做相应检查，ATMS 决定任务归属和页面启动安排。包管理提供组件等信息，不会负责画出页面。
如果目标进程还不存在，AMS 的进程管理链路请求 Zygote 创建进程。应用进入 ActivityThread 运行入口，与系统建立联系，完成应用绑定、必要的 Provider 和 Application 等初始化；系统再协调目标 Activity 的生命周期事务，由应用主线程创建页面并执行回调。
页面准备过程中，setContentView 创建并组织内容 View 树。窗口接入由 WindowManager、ViewRootImpl 与 WMS 等协作：系统管理窗口位置、尺寸、可见性等，应用安排 View 的测量、布局与绘制。典型硬件加速路径还会经过 RenderThread 和 GPU 生成窗口图像，再由 SurfaceFlinger 与硬件合成链路处理最终展示。
这是一条便于理解的职责主线，并非所有设备严格串行执行的固定函数清单。已有进程或页面可复用时会跳过部分步骤，启动窗口和转场也可能提前出现。startActivity 返回、onResume 执行、第一帧内容上屏和页面完全可交互，是不同时间点。
关键机制
- 先决定启动谁与放在哪里，再准备目标进程并执行页面生命周期。
- 页面内容在应用侧创建和绘制，窗口状态由系统协调，图像经合成后展示。
- 区分冷启动、已有进程与实例复用；每种路径需要观察的阶段不同。
通俗例子
点图标后立即出现启动背景，但真正列表晚了 500ms：系统已经给出了启动反馈，不代表业务首帧完成。需要继续看 Application、页面创建、数据绑定和实际呈现时间。
追问与回答
只打开同一个应用的第二个页面，也要经过系统吗？
一般仍会经过 Activity 启动管理，因为任务栈、生命周期、窗口和权限等都需要系统协调。已有进程时可以跳过进程创建和首次应用初始化，但不能把 startActivity 理解成直接 new 一个 Activity。Fragment 或单个页面内部切换 View 则是另一类界面组织方式。
怎样找到启动慢究竟慢在 AMS 还是应用？
我会把提交启动请求、系统处理、进程创建与绑定、Application 初始化、Activity 回调、绘制及上屏放到同一条时间线上。系统处理长就追服务端线程与锁，应用阶段长就查主线程任务和依赖，绘制后仍迟迟不显示就看后续渲染合成。必须用分段证据归因，不能靠日志标签里出现 AMS 就认定它是根因。
易混淆点
startActivity 不会等整个新页面绘制完成才返回。onResume 也不能证明最终像素已上屏，启动窗口更不能当成业务内容已经可用。
参考资料
内容来源
- Android 技术札记 · 原条目
framework-launch