Unity 运行时 GPU / CPU / 内存监控

Unity 打包后的应用里，CPU 和内存还能想办法读，GPU 使用率是真没有现成接口。这套方案在运行时把三项指标都采上来，给性能定位和稳定性治理供数据。

技术问题

虚拟人 PC 端应用出现卡顿、掉帧时，第一反应是看资源占用：是 CPU 算不动了，内存涨了，还是 GPU 打满了。但 Unity 编辑器里的 Profiler 只能在开发环境用，打包发布后的应用是一个黑盒——线上用户机器上发生了什么，没有数据就全靠猜。

要在线上环境做性能定位，必须在打包后的应用程序里持续、实时地采集 GPU、CPU 和内存使用率。

现有方案不足

• 引擎不暴露运行时指标：Unity 引擎本身不提供打包后应用读取系统资源使用率的功能，Profiler 能力随编辑器一起被留在开发环境。
• GPU 采集是空白：当时市面上没有针对 Unity 引擎运行时实时获取 GPU 使用率的功能，CPU 和内存尚有系统层路径，GPU 这一项是缺失的。
• 外部工具不解题：让用户或测试单独开系统监控工具，数据和应用行为对不上时间轴，无法支撑定位。

核心思路

在应用内部建一条采集链路，按数据源分头突破，统一上报：

flowchart TD
    A["Unity 打包应用运行时"] --> B["CPU 使用率采集<br>系统层接口"]
    A --> C["内存使用率采集<br>系统层接口"]
    A --> D["GPU 使用率采集<br>平台能力补齐"]
    B --> E["运行时聚合与展示"]
    C --> E
    D --> E
    E --> F["性能定位<br>稳定性治理数据"]

• CPU / 内存：走操作系统层面的接口读取进程与整机使用率，封装进应用运行时。
• GPU：这是方案的核心差异点。引擎不给，就从平台层补齐采集能力，把实时 GPU 使用率变成应用内可读的指标。
• 统一聚合：三项指标在同一时间轴上聚合，卡顿现场可以直接对照「哪一项先打满」，把定位从猜变成看。

采集本身必须轻量——监控工具自己吃掉几个点的 CPU，就成了被观测系统的一部分，这是设计时就要守住的约束。

应用场景

• PC 端虚拟人应用的线上性能定位：卡顿现场直接读取三项使用率判断瓶颈方向。
• 稳定性治理：长期的资源占用趋势作为劣化预警和回归验证的数据来源。
• 测试与发布环节：中低端机型上验证资源开销是否达标。

关联案例

• GPU 80% 卡顿量化方法论：拿到 GPU 使用率之后如何用它量化卡顿，本页是数据来源那一端。
• 监控闭环管线：运行时采集的指标如何进入统一的监控与告警链路。