外观
路线 A｜Cocos 引擎、渲染与性能
A4｜Engine Practice：完成一次引擎级实践
适用基础： A1～A3 目标： 用一个真实问题贯穿复现、源码定位、实现修改、数据验证和回归交付。
一、实践任务与知识目标
以下题目不是简单的操作清单，而是用来训练同一套工程推理：
- 场景切换后旧对象和资源不释放。
- UI 打开首帧卡顿并伴随 DrawCall 峰值。
- Native 能力回调在页面退出后偶发崩溃。
- 移动端粒子效果 GPU 时间过高。
二、统一交付流程
text
问题定义
→ 最小复现
→ 版本/设备锁定
→ 数据基线
→ 调用链和对象图
→ 源码验证
→ 单变量修改
→ 正确性与性能回归
→ 风险和回滚说明三、案例一：场景切换内存峰值的推理
问题模型
场景切换同时涉及运行时对象销毁、常驻节点、事件监听、资源缓存、对象池和平台 allocator。稳定值不回落不等于泄漏，必须先区分“对象仍活着”和“分配器暂未归还”。
假设树
text
稳定值不回落
├── 常驻节点持有页面引用
├── 全局 EventTarget 未取消
├── schedule/Tween 闭包持有对象
├── Asset cache/Bundle 仍有引用
└── 平台 allocator 延迟归还但对象已释放推理顺序
先看生命周期和引用图，再看资源缓存和平台分配；连续多轮往返只用于确认趋势，不能替代根因分析。
四、案例二：UI 首帧卡顿的知识拆解
首帧不是一个函数，而是脚本创建、布局遍历、字体缓存、纹理上传、RenderData 重建、透明绘制和 GPU 提交的串联。优化时要先找最长阶段，再判断它的上游输入和下游代价；例如减少节点数可能降低 CPU，却因合批破坏增加 GPU。
五、案例三：Native 崩溃的生命周期推理
Native 崩溃需要同时考虑参数转换、绑定对象、回调保存、工作线程、主线程和页面 session。核心判断不是“崩在哪个 C++ 函数”，而是回调返回时它所依赖的对象和线程上下文是否仍有效。
六、工程约束
不得修改 library/、temp/、local/、build/、native/ 生成目录，不手改 .meta UUID，不直接编辑 .scene/.prefab。所有编辑器资源变更必须由 Creator AssetDB 产生。
七、最终验收
交付物包括：
text
README：问题、环境、复现步骤
trace：日志和调用链
before-after：指标对比
patch：代码或编辑器操作说明
regression：功能、设备、性能回归
risk：版本边界、已知限制、回滚方法八、答辩题与答案
1. 为什么不能只提交修改后的代码？
没有基线和复现步骤，无法证明修改解决了原问题，也无法判断是否把成本转移到其他维度。
2. 源码与日志矛盾怎么办？
先检查版本、构建产物、平台和日志插入点，再区分教学模型、公开语义与实际实现；不能强行选择自己喜欢的结论。
3. 什么结果才算完成？
问题可复现、根因有证据、修改可解释、指标按定义改善、功能没有回归，并明确剩余风险。
九、路线 A 总结
A1 建立源码追踪能力，A2 进入 GPU，A3 建立系统性能证据链，A4 把能力转成真实工程交付。完成路线 A 后，可以继续路线 B；两者共享 Stage07 的 C++ 基础，但不共享线程、协议和生产运维的具体语义。