Appearance
内存泄漏系统性排查
使用 Google DevTools 和 Deep Profiler 建立内存泄漏排查方法论，从小鹏 3D crash 到 B 站 WebGL 换装内存泄漏。
排查方法论
Step 1: 确认泄漏
- Chrome DevTools Memory Tab → 录制 Heap Snapshot
- 反复执行可疑操作 10 次 → 再录制一次
- 对比两次 Snapshot：哪些对象数量持续增长？Step 2: 定位根因
- 对可疑对象点 "Retainers" 查看引用链
- 找到"谁在持有这个对象"
- 区分：真正的泄漏 vs 缓存 vs 延迟释放Step 3: 修复验证
- 修复后重新做 Step 1 的对比
- 确认对象数量不再增长
- 实车/真机验证（实验室环境和真机环境的内存行为可能不同）案例 1：B 站 WebGL 换装内存泄漏
现象：连续切换换装配件（衣服、翅膀、头发），内存持续增长，最终崩溃。
排查：
- 录制 Heap Snapshot → WebGLTexture 对象数量持续增长
- Retainers 指向 Three.js 的 WebGLMotionVector 类
- 根因：换装时旧 Mesh 被移除，但其关联的 WebGL 纹理资源未调用
gl.deleteTexture()
修复：修改 Three.js 底层 WebGLMotionVector 源码，在 Mesh dispose 时级联释放纹理。
案例 2：小鹏 3D Crash
现象：600 版本线上 crash 8844 例。
排查：
- 分类为三类根因：
- Unity 自杀（含 fd 泄露）
- 渲染 SRP 崩溃
- XStringBuilder 字符串溢出
- 开发无限抓 trace 工具定位具体崩溃点
- 实车拉日志验证内存（结论：600 版无泄漏，crash 多为第三方百度问题）
案例 3：P0 SR 黑屏/卡顿/自杀
现象：610 版本批量 SR 黑屏、卡顿、进程自杀。
根因：内存爆炸/泄露 → 渲染线程卡死 20 秒 → 触发 Unity 自杀逻辑。
修复：
- 定位内存爆炸来源（大纹理贴图未及时释放）
- 加内存预警机制
- 渲染线程卡死检测 + 降级渲染
公开版深化
案例定位
内存泄漏系统性排查不是孤立笔记，而是性能优化能力下的一个可复用案例。它服务于“小鹏一张图 / SR 渲染引擎”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
使用 Google DevTools 和 Deep Profiler 建立内存泄漏排查方法论，从小鹏 3D crash 到 B 站 WebGL 换装内存泄漏。
这篇文章已经覆盖 排查方法论、案例 1：B 站 WebGL 换装内存泄漏、案例 2：小鹏 3D Crash、案例 3：P0 SR 黑屏/卡顿/自杀。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- 案例 3：P0 SR 黑屏/卡顿/自杀
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。
公开版深化
案例定位
内存泄漏系统性排查不是孤立笔记，而是性能优化能力下的一个可复用案例。它服务于“小鹏一张图 / SR 渲染引擎”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
使用 Google DevTools 和 Deep Profiler 建立内存泄漏排查方法论，从小鹏 3D crash 到 B 站 WebGL 换装内存泄漏。
这篇文章已经覆盖 排查方法论、案例 1：B 站 WebGL 换装内存泄漏、案例 2：小鹏 3D Crash、案例 3：P0 SR 黑屏/卡顿/自杀。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- 案例 3：P0 SR 黑屏/卡顿/自杀
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。
公开版深化
案例定位
内存泄漏系统性排查不是孤立笔记，而是性能优化能力下的一个可复用案例。它服务于“小鹏一张图 / SR 渲染引擎”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
使用 Google DevTools 和 Deep Profiler 建立内存泄漏排查方法论，从小鹏 3D crash 到 B 站 WebGL 换装内存泄漏。
这篇文章已经覆盖 排查方法论、案例 1：B 站 WebGL 换装内存泄漏、案例 2：小鹏 3D Crash、案例 3：P0 SR 黑屏/卡顿/自杀。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- 案例 3：P0 SR 黑屏/卡顿/自杀
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。