TG咨询白屏不一定表示界面没有开始绘制：应用可能已显示空壳窗口，但数据、布局或主线程任务仍未完成。排查时，先把“点开应用到可以正常操作”拆成可测量的阶段。应用启动白屏的分阶段性能采样方法，核心是让每个阶段都有起止标记，并在相同条件下重复观察，而不是只凭一次启动的总耗时猜原因。
先统一白屏和启动完成的定义
至少记录三个时间点：用户触发启动、首帧出现、主要内容可操作。首帧只说明系统呈现了一个画面，不代表内容已经加载；交互就绪则应以关键按钮能响应、主要信息已显示为准。将两者分开，才能判断是绘制慢，还是首屏绘制后仍在等待任务。
同时区分冷启动和热启动。冷启动通常需要重新创建进程，热启动可能复用已有进程；两类结果不要混在同一组里比较。记录设备型号、系统版本、应用构建版本、网络状态与缓存状态。启动耗时会随设备负载、动画设置和网络变化，单次结果不能代表稳定表现。
按阶段布置采样点
| 阶段 | 采样内容 | 常见线索 |
|---|---|---|
| 进程创建与运行环境准备 | 启动触发到应用入口执行的时间、进程及线程活动 | 系统调度、动态库加载或初始化较集中 |
| 应用初始化 | 配置读取、数据库打开、依赖组件初始化的起止时间 | 同步读写、重复初始化或主线程等待 |
| 首屏构建与绘制 | 首屏数据准备、布局计算、图片解码及首帧时间 | 主线程长任务、过多视图计算或资源解码 |
| 交互就绪 | 关键内容显示和主要操作可响应的时间 | 首帧已经出现，但请求或任务仍阻塞操作 |
阶段标记应使用同一时钟来源，并放在实际操作的前后；例如把数据库打开前后各记一个点，而不是只在初始化函数入口打总标记。iOS 项目可用 Instruments 的 Time Profiler 配合应用内的 signpost 标记；Android 项目可用 Perfetto 跟踪线程调度、主线程活动与帧事件。采样工具本身也会增加开销，因此不要把开启分析器后的绝对耗时直接当作线上表现。
按顺序执行采样与定位
- 建立基线：关闭无关后台任务，在同一设备和网络条件下分别测冷启动、热启动。每种条件重复多次，例如先做 5 至 10 次观察；若结果波动明显，继续增加样本并检查环境变化。
- 记录阶段边界：为入口执行、关键初始化、首屏数据到达、首帧和交互就绪添加时间标记。白屏结束点尽量通过屏幕录像或界面自动化确认，避免把“窗口出现”误认作“内容可见”。
- 采集线程与等待：对照时间线查看主线程是否长时间执行、等待锁或同步 I/O，并检查后台任务是否在首屏之前被强制串行完成。若主线程忙，沿调用栈找耗时函数；若主线程在等，则追查等待对象和任务发起处。
- 做单变量对照：一次只延后或跳过一个非首屏必需的初始化，再重新采样。若首帧改善而交互时间不变，瓶颈可能在绘制前路径；若首帧正常、可操作时间拖后，重点检查首屏后的网络请求、解码和任务排队。
- 复测并保留证据：在未开启分析器的构建或较接近真实用户的条件下复核改动，并保存阶段耗时、调用栈和设备环境。优化后仍按原条件测量，避免把网络或缓存变化误判为代码收益。
从时间线判断瓶颈类型
主线程持续繁忙
如果首帧前主线程连续执行大量任务，检查同步初始化、复杂布局、图片解码和大对象创建。优先将不影响首屏的信息延后，或把适合后台执行的工作移出主线程；但界面更新仍应遵循平台的线程规则。
首帧后仍然白或内容迟到
如果首帧时间正常，但有效内容出现很晚，应分开测网络等待、数据解析和界面绑定。用受控网络或已有缓存做对照：只有网络条件变化时耗时显著改变，才把请求链路列为重点；离线也慢则继续查本地计算与绘制。
结果波动而非稳定偏慢
波动可能来自后台负载、缓存冷热、网络质量或设备温度。不要只挑最快的一次；比较多次结果的中位数和范围，并保留异常样本。应用启动白屏的分阶段性能采样方法要能复现同一问题，结论才适合指导改动。
常见问题
只看启动总耗时够吗？
不够。总耗时无法说明时间花在初始化、首帧还是首帧后的任务，应同时记录阶段边界。
首帧出现就算启动完成吗？
不算。首帧可能只是空窗口或加载占位；还应测主要内容显示及关键操作可响应的时间。
分析器显示的耗时可以直接用于验收吗？
不宜直接照搬。分析器可能带来额外开销，应结合重复采样，并在接近实际使用的条件下复核。
优化后如何确认白屏确实改善？
用相同设备、构建、缓存和网络条件重复测试，比较首帧与交互就绪的阶段耗时，并检查改善是否稳定。
定位时先问白屏落在哪个阶段，再用线程时间线和单变量对照验证原因。把这些记录持续用于回归，应用启动白屏的分阶段性能采样方法就能从一次性排查变成可复用的性能检查流程。