开机动画长跑半小时

【踩坑实录】开机动画长跑半小时

▍现象
虚拟机工程首次引导客户机系统：开机动画（bootanimation）阶段画面几乎静止，一跑三十多分钟。期间没有报错、没有崩溃，就是慢得离谱。用户视角这是死机，团队视角这是误判陷阱。

▍定位过程
第一轮误判：系统初始化挂死（界面不动加日志稀疏，直觉结论）。第二轮纠偏：同机同固件同参数下对比观察，模拟器进程 CPU 持续高位（百分之一百二十一）——在跑，没死。第三轮定性：开机动画阶段是客户机全系统首次编译的高峰（这个阶段的系统服务与应用全在首编），翻译执行的吞吐跟不上编译密度，动画帧的生产速度以分钟计。工程记录原文：开机动画长跑三十六分钟暴露单核编译瓶颈。

▍根因
首启与二次启动的负载结构性不同：首启要做全量即时编译（有效编译时间以小时计——该工程首启总账约六点六小时，有效编译约四小时），开机动画恰好叠在编译峰上；二次启动后代码缓存热了，同阶段只要四分多钟。看起来像 bug 的现象，本质是首启冷编译的真实成本。

▍对策
三层：翻译层加速（MTTCG 多线程——上篇实录的对策，首编时间大幅压缩）；快照通道（把一次完整引导的结果存档，后续启动直接恢复快照跳过编译——该工程的极速启动通道，冷启二十分钟级降到秒级恢复）；预期管理（首启提示与进度说明，让用户知道这是首次的一次性成本）。

▍方法论沉淀
慢与死要用活性证据分清；结构性的慢（首编成本）不靠修补靠通道绕开（快照）；一次性成本要向用户说透。

首启六小时到桌面可用的全过程在虚拟机工程实录，apps 板块 56 篇欢迎对照。