Appearance
Unity 云日志系统
搭建 Unity 云日志系统，将线上问题排查周期从 5 天缩短至 1 天，减少日常维护冗余沟通成本。
背景
B 站虚拟直播项目在线上出现问题时，排查流程极度低效：
- 用户反馈"面捕不动了" → 运营转产品 → 产品转开发
- 开发远程登录用户机器？不可能
- 只能让用户复现 + 截图 + 描述 → 猜问题 → 尝试修复 → 发包 → 让用户再试
问题排查周期：5 天。
方案
架构
Unity 客户端 → 结构化日志 → HTTPS 上报 → 云端存储 → 开发查询日志内容
| 类别 | 记录内容 | 频率 |
|---|---|---|
| 面捕引擎 | Mediapipe 输出帧率、丢帧数、BS 值范围 | 每 60 帧 1 次 |
| 驱动框架 | 当前模型类型、BlendShape 更新耗时 | 切换时 |
| 下载框架 | MLive 下载状态、失败重试次数 | 事件驱动 |
| 性能 | FPS、CPU、内存 | 每 5 分钟 |
| 异常 | Exception 堆栈 + 上下文快照 | 触发时 |
查询体验
- 按用户 ID + 时间范围查询
- 关键字过滤（"Mediapipe"、"MLive"、"Exception"）
- 异常日志红色高亮
效果
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 排查周期 | 5 天 | 1 天 |
| 沟通成本 | 多次转达 | 开发直接看日志 |
| 问题复现 | 依赖用户描述 | 日志分析 |
| 误判率 | 高（信息不全） | 低（结构化数据） |
教训
- 不要等用户描述问题——结构化日志比用户描述可靠 100 倍
- 采样的艺术——全量日志会压垮服务器，关键事件 + 低频快照才是最佳平衡
公开版深化
案例定位
Unity 云日志系统不是孤立笔记，而是稳定性与工程化能力下的一个可复用案例。它服务于“性能治理与稳定性优化”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
搭建 Unity 云日志系统，将线上问题排查周期从 5 天缩短至 1 天，减少日常维护冗余沟通成本。
这篇文章已经覆盖 背景、方案、效果、教训。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- 面捕引擎 Mediapipe 输出帧率、丢帧数、BS 值范围 每 60 帧 1 次
- 不要等用户描述问题——结构化日志比用户描述可靠 100 倍
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。
公开版深化
案例定位
Unity 云日志系统不是孤立笔记，而是稳定性与工程化能力下的一个可复用案例。它服务于“性能治理与稳定性优化”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
搭建 Unity 云日志系统，将线上问题排查周期从 5 天缩短至 1 天，减少日常维护冗余沟通成本。
这篇文章已经覆盖 背景、方案、效果、教训。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- 面捕引擎 Mediapipe 输出帧率、丢帧数、BS 值范围 每 60 帧 1 次
- 不要等用户描述问题——结构化日志比用户描述可靠 100 倍
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。
公开版深化
案例定位
Unity 云日志系统不是孤立笔记，而是稳定性与工程化能力下的一个可复用案例。它服务于“性能治理与稳定性优化”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
搭建 Unity 云日志系统，将线上问题排查周期从 5 天缩短至 1 天，减少日常维护冗余沟通成本。
这篇文章已经覆盖 背景、方案、效果、教训。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- 面捕引擎 Mediapipe 输出帧率、丢帧数、BS 值范围 每 60 帧 1 次
- 不要等用户描述问题——结构化日志比用户描述可靠 100 倍
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。