---
title: "Unity 6 性能测量、垃圾回收与 Camera.main 官方资料摘录"
author: "Perrin Yong"
author_profile: https://www.pystone.net/profile/
published_by: "Perrin Yong"
canonical: https://www.pystone.net/notes/unity6-performance-gc-camera-main-reference/
type: note
content_role: unspecified
visibility: public
id_stability: rename-stable
source_path: "99-资料来源、摘录与归档/01-外部文章与转载摘录/Unity 6 性能测量、垃圾回收与 Camera.main 官方资料摘录.md"
content_hash: 5c5221d1fa5428ad74bd5b686694c8f427ed6a6a24ae0f700fb16df2a351e53a
knowledge_version: 224c990773de.5fa8af6e39fa
site_commit: 224c990773de166d23a886306577dd90379529ce
notes_commit: 5fa8af6e39fa3891d1b9b4832bfa6c4e0ecaaf0a
---
# Unity 6 性能测量、垃圾回收与 Camera.main 官方资料摘录

> **source · 官方资料摘录**
> 核对版本为 Unity 6.0（6000.0），核对日期为 2026-07-23。API 和平台行为可能继续变化；综合应用见[性能优化的本质是控制成本发生的频率、时机与范围](https://www.pystone.net/notes/performance-optimization-cost-frequency-scope/)。

## 在目标平台采集真实数据

Unity 的[目标平台性能采集文档](https://docs.unity3d.com/6000.0/Documentation/Manual/profiling-target-device.html)要求在目标发布平台的 Development Build 上连接 Profiler，可通过局域网、线缆或 IP 连接。它支持一个基础边界：编辑器或开发机上的热点只是诊断线索，发布设备、构建后端与真实场景才决定可外推的性能结论。

文档说明了连接步骤，但没有保证 Development Build 与最终 Release 完全等价；Deep Profiling 本身也可能带来额外开销。因此应先用低侵入采样定位，再用接近发布配置的复测确认。

## 垃圾回收器与临时分配

Unity 6 的[垃圾回收概览](https://docs.unity3d.com/6000.0/Documentation/Manual/performance-garbage-collector.html)说明：托管堆没有足够连续空间满足分配时会触发回收；逐帧临时对象会按频率持续累积待处理工作。文档以每帧 1 KB、60 FPS 为例说明小分配如何在一分钟内累积到 3.6 MB，但这个数字只是算术示例，不是所有项目的性能阈值。

可保留的机制是：分配大小、发生频率、对象存活期和堆状态共同决定回收压力；“0 B/帧”是实时路径的优化方向，不是脱离场景的强制验收线。

## 增量、非增量与手动 GC

[垃圾回收模式文档](https://docs.unity3d.com/6000.0/Documentation/Manual/performance-incremental-garbage-collection.html)说明：

- 增量 GC 默认启用，把标记工作分散到多帧，主要降低单次尖峰，并不会让总回收工作凭空消失；
- 引用变化过多会增加 write barrier 与重复扫描成本，极端时增量标记可能无法完成并退回完整回收；
- 非增量模式暂停主线程处理整个托管堆，实时应用可能出现明显 GC spike；
- 手动禁用 GC 会阻止回收并让堆持续增长，只适合可严格控制分配的短关键区间。

因此，“始终开启增量 GC”与“彻底禁用 GC”都不是普适答案。应观察帧时间分布、引用变化、堆增长和目标平台行为后选择。

## `Camera.main` 的当前实现边界

Unity 6 的[`Camera.main` API](https://docs.unity3d.com/6000.0/Documentation/ScriptReference/Camera-main.html)返回第一个启用且带 `MainCamera` 标签的相机；没有符合条件的组件时返回 `null`。当前实现会缓存带该标签的 GameObject，单次访问仍有与 `GetComponent` 相近的小 CPU 开销，性能敏感处可以自行缓存结果。

这限制了历史经验中“每次调用都全场景搜索”的说法。当前仍不能据文档断言缓存永远值得做：调用频率、场景切换、相机启停和缓存失效风险都需要进入测量。

## 资料共同支持的诊断顺序

1. 在目标平台和代表性场景采样；
2. 先确认成本是否位于用户可见关键路径及高分位帧；
3. 对 GC 同时检查分配频率、生命周期、堆增长和回收模式；
4. 对单个 API 先核对当前版本实现，再决定是否缓存或替换；
5. 改动后在相同设备与工作负载复测，不沿用旧版本经验数字。