Appearance
监控上报链路搭建
打通 Unity → Android 原生 → 飞书的完整监控上报链路，建立可量化的线上质量数据体系。
背景
小鹏一张图的线上质量数据（crash、卡顿、性能）需要从车机上采集 → 上报 → 后台 → 飞书通知 → 开发可查阅。从 0 到 1 搭建完整链路。
链路架构
Unity 端埋点 → Android 原生接收 → 平台上报 → 飞书通知Unity 端
- SaveException：crash/异常自动捕获
- 性能采样：每 5 分钟采样 FPS/CPU/GPU/内存
- 关键事件：SD/LD/SR 切换、手势锁定、网络超时
Android 原生端
- 接收 Unity 埋点数据
- 限次限流（SaveException 防重入）
- 批量打包上报（减少网络开销）
上报平台
- 接入公司内部数据平台
- 结构化存储 + 聚合查询
飞书通知
- crash 实时推送 → 特定飞书群
- 每日性能摘要 → 日报机器人
- 异常趋势图表（周报）
监控指标
| 指标 | 采集方式 | 告警阈值 |
|---|---|---|
| Crash 率 | Unity Exception Handler | > 0.1%/日 |
| 帧率 | 每 5 分钟采样 | < 30fps |
| GPU 占用 | Android GPU Inspector | > 80% |
| 内存 | Unity Profiler API | > 500MB |
| 卡顿 | 主线程超时检测 | > 200ms |
成果
- 620 版本监控上报失效缺陷闭环（合入 6.2.0/6.2.2）
- 线上问题从"用户反馈才知道"变成"crash 后 5 分钟飞书通知"
公开版深化
案例定位
监控上报链路搭建不是孤立笔记，而是稳定性与工程化能力下的一个可复用案例。它服务于“小鹏一张图 / SR 渲染引擎”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
打通 Unity → Android 原生 → 飞书的完整监控上报链路，建立可量化的线上质量数据体系。
这篇文章已经覆盖 背景、链路架构、监控指标、成果。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- Crash 率 Unity Exception Handler 0.1%/日
- 帧率 每 5 分钟采样 < 30fps
- GPU 占用 Android GPU Inspector 80%
- 内存 Unity Profiler API 500MB
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。
公开版深化
案例定位
监控上报链路搭建不是孤立笔记，而是稳定性与工程化能力下的一个可复用案例。它服务于“小鹏一张图 / SR 渲染引擎”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
打通 Unity → Android 原生 → 飞书的完整监控上报链路，建立可量化的线上质量数据体系。
这篇文章已经覆盖 背景、链路架构、监控指标、成果。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- Crash 率 Unity Exception Handler 0.1%/日
- 帧率 每 5 分钟采样 < 30fps
- GPU 占用 Android GPU Inspector 80%
- 内存 Unity Profiler API 500MB
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。
公开版深化
案例定位
监控上报链路搭建不是孤立笔记，而是稳定性与工程化能力下的一个可复用案例。它服务于“小鹏一张图 / SR 渲染引擎”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
打通 Unity → Android 原生 → 飞书的完整监控上报链路，建立可量化的线上质量数据体系。
这篇文章已经覆盖 背景、链路架构、监控指标、成果。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- Crash 率 Unity Exception Handler 0.1%/日
- 帧率 每 5 分钟采样 < 30fps
- GPU 占用 Android GPU Inspector 80%
- 内存 Unity Profiler API 500MB
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。