大型办公套件的运行时折叠

【踩坑实录】大型办公套件的运行时折叠

▍现象
办公套件工程的进程模型怪病：关闭最后一个文档后，应用界面还显示着最后一帧画面（冻结帧），点击无反应但不崩溃——用户看到的是应用坏了，实际是文档引擎已正常退出，壳层拿着一帧僵尸画面。

▍定位过程
上游的运行时模型：单文档接口（SDI）形态下，最后一个文档关闭、内核主函数直接返回——桌面语义里这等于应用退出（系统收走进程）。移植环境里壳进程（ArkTS 层）还活着、还持有渲染表面——内核退了壳不知道，僵尸画面由此而来。工程还发现更深一层：进程内二次调用内核主函数会因全局状态不可重建而挂死——不能简单重启内核了事。

▍对策
两级检测加一条重启通道（工程编号 P64/P65 的两轮修复）：第一级，内核在主函数返回处主动推退出事件，壳层收到后显示引擎已退出的引导层（重新开始的入口）——把僵尸画面变成有反馈的状态页；第二级，僵尸态恢复阶梯（零可见窗持续数秒且无模态时触发）：先尝试按标题寻找隐藏的起始中心复活，找不到再推退出事件——处理更隐蔽的僵尸形态；重启通道的收敛（进程内重启不可行、部分重启接口仅特定形态支持，最终收敛到应用级恢复重启机制）。

▍根因抽象
跨层运行时模型的错位：内核假设自己拥有进程生命周期（退出即结束），壳层假设内核永远活着（持有画面等交互）。双层架构里必须显式约定生命周期的所有权与通知协议。

▍方法论沉淀
双引擎架构的生命周期契约：谁负责退出检测（主动通知加被动检测两级）、退出后壳层呈现什么（有反馈的终态而非黑屏僵尸）、重启怎么走（进程内不行就进程级）。

僵尸态两级检测的完整记录在办公套件工程实录，apps 板块 56 篇欢迎对照。