--- title: "性能优化的本质是控制成本发生的频率、时机与范围" author: "Perrin Yong" author_profile: https://www.pystone.net/profile/ published_by: "Perrin Yong" canonical: https://www.pystone.net/notes/performance-optimization-cost-frequency-scope/ type: note content_role: synthesis source_type: "synthesis" visibility: public id_stability: rename-stable source_path: "10-计算机、信息技术与工程/05-游戏图形与运行时/游戏性能优化/性能优化的本质是控制成本发生的频率、时机与范围.md" content_hash: 5e5b06e4f39110f42decc725a4532205e854c4a525ccfd5492040f797ea4cbac knowledge_version: 224c990773de.5fa8af6e39fa site_commit: 224c990773de166d23a886306577dd90379529ce notes_commit: 5fa8af6e39fa3891d1b9b4832bfa6c4e0ecaaf0a --- # 性能优化的本质是控制成本发生的频率、时机与范围 > **abstract · 知识演化层** > 本文基于公开库中的 Unity、C#、运行时与工程质量材料维护当前综合。历史阈值和具体 API 技巧保留在来源页；实际项目使用前必须按引擎版本、设备和场景重新验证。 ## 当前综合判断 性能优化不是把一张“昂贵 API 黑名单”逐项套进代码，也不是让 CPU、内存、GC、GPU 和加载指标分别越低越好。它首先是一个资源与体验约束问题：在代表性设备和真实场景中，让必要工作在可接受的频率、时机和影响范围内发生，同时不以不可维护的复杂度或明显体验损失换取局部数字。 一个跨模块更稳定、但不混淆量纲的成本模型是： ```text 平均工作负载 ≈ 单次成本 c × 发生频率 f × 影响范围 n 在途或常驻规模 L = 到达率 λ × 平均停留时间 W 用户可见风险 = F(工作负载、关键路径位置、时间聚集、资源余量、扇出与相关性) ``` 循环中的小分配、每帧的跨边界调用和父节点变化引起的大量子节点更新主要改变 `c × f × n`；长期存活对象和未完成任务通过 `λ × W` 扩大常驻或在途集合；场景切换中的集中加载、关键帧同步与大规模扇出则决定这些局部成本何时成为用户可见峰值。三层互相作用，但不能当成一个无量纲乘积。 ## 分散材料之间的关系 ### CPU 与内存并不是两条独立优化线 [CPU 耗时优化](https://www.pystone.net/notes/unity-csharp-cpu-performance-optimization/)强调减少重复调用、只在状态变化时执行、缓存结果和控制高频引擎 API；[内存与 GC 优化](https://www.pystone.net/notes/unity-csharp-memory-gc-optimization/)则说明频繁堆分配最终会转化为 GC 扫描、停顿与堆扩张成本。 两者共同支持：分配问题既是空间问题，也是未来某个时刻的 CPU 调度问题；缓存可以减少计算和分配，却会延长对象生命周期、增加常驻内存与失效管理。因而“缓存一切”和“零分配”都不是无条件目标。 ### 局部 API 的代价取决于调用拓扑 单次 `Find`、`Update`、跨托管/引擎边界调用或字符串操作未必足以形成用户可见问题；当它们进入每帧循环、作用于大量对象、触发层级传播或隐含分配时，成本才会放大。对象池、事件驱动、隔帧调用、LOD 和 Culling 的共同作用不是“换一个更快 API”，而是减少工作发生次数、缩小工作集合或把工作移出关键帧。 ### 模块优化经常是跨资源交换 [Unity 性能优化知识体系](https://www.pystone.net/notes/unity-performance-optimization-knowledge-map/)展示了 CPU、内存、GPU、加载、UI、动画和物理之间的耦合： - 烘焙动画可以减少实时蒙皮计算，却增加内存和加载成本； - 拆分动态与静态 UI 可以缩小重建范围，却增加结构管理； - 共享或控制材质实例可能改善内存与合批，但会限制独立视觉状态； - LOD、裁剪和粒子降级用表现精度换取更小的工作集合； - 对象池减少创建和回收，却引入容量、重置和生命周期错误风险。 因此，优化结论必须同时说明收益指标、被转移的成本和适用边界。 ## 一条证据驱动的优化闭环 ### 1. 从用户症状和预算开始 先明确问题是持续低帧率、偶发卡顿、加载峰值、内存增长、耗电发热还是低端设备崩溃，并指定设备、场景、画质、数据规模和可接受阈值。没有场景的“性能差”无法决定优化对象。 ### 2. 捕获代表性证据 用 Profiler、采样、帧时间分布、分配记录和资源快照定位主要成本。平均值可能隐藏尖峰；编辑器数据可能不代表真机；单次截图也可能把后果误当成原因。先建立可重复基线，再讨论改法。 ### 3. 沿成本机制提出解释 至少区分：工作本身是否不必要、执行频率是否过高、影响集合是否过大、是否跨越昂贵边界、对象是否活得过久、成本是否集中在关键帧，以及当前瓶颈究竟在 CPU、GPU、内存带宽、I/O 还是同步等待。 ### 4. 选择最小完整改动 优先改变高乘数项：把轮询改为变化驱动，缩小遍历范围，合并跨边界操作，复用已验证的昂贵结果，分散非关键工作，或按设备与距离降低工作精度。微观语法替换只有在热点证据支持时才进入。 ### 5. 比较前后与副作用 在同一场景、设备和构建配置下比较帧时间分位数、峰值、内存、加载时间与体验。检查优化是否制造状态错误、缓存陈旧、对象池泄漏、画质退化或维护复杂度。结果只支持被测范围，不能从单个设备外推全部平台。 ### 6. 保存版本和失效条件 具体技巧需要记录 Unity、运行时、后端和平台版本。来源材料中关于早期 `foreach` 装箱、`Camera.main` 搜索、Mono GC、旧移动设备内存线以及 Unity 4/5 物理与 UI 实现的结论具有明显时代背景；它们适合解释历史机制或产生测试假设，不应直接成为当前硬规则。 ## 后续应用：用 Unity 6 官方机制核验旧规则 2026-07-22，在本页形成后，针对“旧 Unity 性能技巧还能否直接使用”这一问题查阅 Unity 6.0 官方文档，得到三类关系： - **支持**：Unity 仍明确说明每帧临时分配会按频率累积并增加 GC 工作，加载期间大量临时对象也会推动托管堆扩张。这支持把单次成本、发生频率、影响范围和停留时间分别测量，而不是只支持某一条语法禁令。 - **限制与替代**：Unity 6 默认使用增量 GC，把工作分散到多帧以缩短单次中断，但不会让垃圾收集的总工作更快；引用变化过多时还可能回退为完整非增量收集，并引入 write barrier 开销。因此，“GC 必然表现为一次长时间 stop-the-world 峰值”只适用于非增量模式或回退情形，应被“先确认 GC 模式与实际帧分布”替代。 - **校准**：Unity 6 的 `Camera.main` 已缓存带 `MainCamera` 标签的对象，访问仍有接近 `GetComponent` 的小量 CPU 开销。旧资料若把它描述成每次全场景搜索，机制已经过期；只有热点证据表明访问频率构成成本时，才需要进一步缓存。 Unity 还提供在目标平台的 Development Build 上采集更现实指标的路径。这使“编辑器里看起来更快”只能作为迭代线索，不能完成验证闭环。此次核验没有真实性能故障、目标设备和前后基线，所以它能修订机制边界，不能证明任何项目已经获得性能收益。 ### 本次官方来源 - [Unity 6 性能测量、垃圾回收与 Camera.main 官方资料摘录](https://www.pystone.net/notes/unity6-performance-gc-camera-main-reference/) ## 规律候选：用户可见性能由成本拓扑与资源余量共同决定 ### 机制与关键变量 当前候选不是“所有性能都等于一个乘法公式”，而是：**局部操作只有经过发生频率、影响范围、停留时间、关键路径和系统余量构成的成本拓扑，才会转化为整体资源压力与用户体验；优化若没有改变实际瓶颈上的这些变量，就不应预期稳定的整体收益。** - `c`：一次工作在 CPU、GPU、内存带宽、I/O、网络、功耗等资源上的成本向量，不能只看一个标量； - `f`：工作被触发的频率，包括每帧轮询、请求到达率和状态变化率； - `n`：一次触发波及的对象、组件、像素、依赖或下游请求范围； - `W`：对象、任务或数据在系统中停留的时间，决定在途、排队或常驻规模； - `q`：工作是否位于用户等待的关键路径，以及是否集中在同一帧或阶段； - `h`：瓶颈资源的余量；余量充足时局部成本可能不可见，接近饱和时排队与争用会非线性放大； - `v`：耗时方差、扇出规模和组件相关性，决定局部尾部是否传播为整体尾部。 因果链是：`c × f × n` 消耗资源容量，`λ × W` 积累在途或常驻状态；当这些压力接近瓶颈容量，或落在关键路径、集中窗口与大扇出结构中，局部延迟和波动才更可能变成卡顿、加载峰值、尾延迟、发热或崩溃。缓存、池化、批处理、异步化和降级之所以不能被简单判定为“优化”，正是因为它们经常只降低一组变量，同时提高另一组变量或把成本转移到别的资源。 ### 三个独立理论约束 1. [Little（1961），A Proof for the Queuing Formula: L = λW](https://www.pystone.net/notes/in-flight-load-local-speedup-tail-latency-literature/)在有限均值、严格平稳等条件下证明平均在途数量等于到达率乘以平均停留时间。这支持把生命周期从“总成本乘数”中拆出，单独检查对象驻留、排队和未完成工作；它不证明降低 `W` 必然改善所有体验，也不提供因果方向。 2. [Amdahl（1967），Validity of the Single Processor Approach](https://www.pystone.net/notes/in-flight-load-local-speedup-tail-latency-literature/)说明整体加速受未改善部分约束。迁移到本页时，它限制了“热点局部基准变快即整体变快”的推断：只有被改部分在实际工作中的占比和瓶颈位置足够大，局部收益才可能成为整体收益。 3. [Dean 与 Barroso（2013），The Tail at Scale](https://www.pystone.net/notes/in-flight-load-local-speedup-tail-latency-literature/)显示，系统规模或利用率上升时，单个组件中偶发的高延迟可能主导大规模服务的整体尾延迟。这支持把扇出、关键路径和耗时分布加入模型；具体放大幅度仍取决于相关性、超时、冗余和调度策略，不能直接把独立概率公式套到所有系统。 三项来源分别约束驻留、可改善比例和尾部传播，连同 Unity 的资源机制形成中等强度的机制支持。它们没有共同证明一个跨所有资源的精确性能方程，因此本候选目前只主张变量方向与诊断顺序，不主张统一数值预测。 ### 反例、竞争解释与失效边界 - **非瓶颈反例**：某个 API 单次耗时和调用频率都明显下降，但实际瓶颈在 GPU、I/O、同步或未修改部分，用户指标可以几乎不变；这符合 Amdahl 约束，反驳“局部更快自动等于整体更快”。 - **成本转移反例**：批处理降低单项开销，却增加等待时间和峰值；缓存、对象池降低计算或分配频率，却延长 `W`、增加常驻内存和陈旧状态风险；异步化移出关键帧，却可能增加端到端延迟、并发量与取消复杂度。 - **可预测性反例**：对象少、负载低且预算宽松时，固定频率轮询可能比变化驱动更简单、更稳定，新增状态机制的错误与维护成本大于节省的资源。 - **竞争解释：饱和与排队才是根因**。这个解释指出接近容量时延迟会非线性恶化，简单乘积无法预测幅度。本候选接受这一限制，并把资源余量 `h` 作为从工作量到体验的必要中介。 - **竞争解释：体验问题来自内容或正确性而非性能**。降低画质、精度或一致性可以换取绿色指标，却不是同一产品目标下的改进；因此质量约束必须与性能预算共同进入验收。 - GPU 填充、带宽、热降频、共享资源争用和强相关尾延迟未必能自然分解成独立事件。若真实事件中 `c、f、n、W、q、h、v` 仍不能缩小根因或区分方案，本候选应被限制到离散工作与可观测瓶颈，而不能继续扩张解释范围。 - 该候选目前只在游戏运行时、排队系统、并行计算和分布式服务之间获得机制互证。项目管理、组织负荷或个人注意力虽然也有“到达—停留—积压”的表面映射，但对象、容量、反馈和时间尺度尚未逐项核验，暂不称为跨社会领域的同构规律。 ### 事前预测与决策原则 以下预测在下一次有代表性设备、场景和前后基线的公开性能事件出现前记录： 1. 若改动只降低非瓶颈、低占比路径的单次成本，局部微基准会改善，但端到端或帧时间 `p95` 不会获得同量级改善；若整体收益反而很大，应回查隐藏的调用范围、同步或资源转移，而不是事后宣称公式正确。 2. 若保持总工作近似不变，只把工作从关键帧分散到其他帧，关键帧 `p95` 应改善，但总 CPU 时间、功耗或端到端完成时间至少一项不会同步等比例下降；若全部下降，说明改动同时减少了工作量、频率、范围或争用。 3. 若对象池或缓存主要降低创建与分配频率，分配率和 GC 压力应下降，但常驻内存、对象停留时间或失效管理成本不会自动下降；若两者都改善，应寻找容量收缩、生命周期缩短或重复数据减少等第二机制。 4. 在单组件耗时分布近似不变时，扩大必须共同完成的对象或依赖范围会提高整体尾部暴露概率；若没有提高，需要检查组件相关性、并行掩蔽、超时、冗余或剩余余量，而不能只用平均值否定范围效应。 ### 形成后工程校准：公开仓库 staged-snapshot 关键路径 本页预测形成后，公开知识库的一次真实维护暴露了可重复的提交延迟：当工作树存在不应进入本次提交的并行改动时，pre-commit 会把 Git index 精确物化到临时 linked worktree，再运行完整 validator。对同一份公开暂存快照分阶段测量，顺序 `checkout-index` 的一次剖析为 1714.1 ms，完整 validator 为 930.0 ms，worktree 移除为 257.8 ms，整条路径为 3149.0 ms；索引物化是当时最大的单段关键路径。 [Git 并行检出配置官方资料](https://www.pystone.net/notes/git-sparse-checkout-config-reference/)说明，`checkout.workers` 默认为 1，小于 1 时使用可用逻辑核心，`checkout.thresholdForParallelism` 控制值得启动并行处理的最小文件数。保持 index、临时 worktree、审批记录、validator 范围和失败语义不变，只让物化命令使用 `checkout.workers=0` 与阈值 100 后，同一次剖析中的 checkout 降为 401.9 ms，validator 保持 942.1 ms，整条路径降为 1858.9 ms。随后无剖析重复运行得到顺序 3167.5/3183.4 ms、并行 1860.8/1869.4 ms，方向与幅度稳定；按两次无剖析均值，端到端约下降 41%。 这个结果支持“先定位真实关键路径，再改变高占比变量”的窄预测，并展示 Amdahl 约束的瓶颈转移：索引物化约下降 77%，总时间没有等比例下降，优化后未改变的 validator 成为最大部分。它也改变了下一步决策——当前不为剩余成本引入持久缓存、增量 validator 或新的状态目录，因为这些方案会扩大正确性与维护边界；先保留全量检查，等待 validator 自身出现可重复且可分解的真实瓶颈。 证据边界同样明确：这是 Windows 上公开仓库提交工作流的少量配对测量，不是 Unity 目标设备、用户帧时间或长期耗时分布；文件缓存、CPU 核数、存储介质和仓库规模都会改变具体数值。它校准的是关键路径与未改善比例机制，不支持把 41% 外推为其他仓库或运行时的预期收益，也没有检验尾延迟、排队和资源转移三项预测。 ### 后续底座校准：指标、采样时窗与历史阈值不能互相替代 2026-08-01 对三篇历史底座的纠错，把“代表性证据”进一步拆成了测量坐标。[Android PSS 内存的含义与分析方法](https://www.pystone.net/notes/android-pss-memory-analysis/)明确 PSS 是私有页全计、共享页按比例分摊的一次系统采样，不等于进程独占内存，也不能从一次升高直接推出泄漏；[Unity Profiler](https://www.pystone.net/notes/unity-profiler/)则区分 Unity 内部分类、系统 PSS/RSS/footprint、Used 与 Reserved，避免把不同观察器的数值直接相减或合并。[Unity 性能优化知识体系](https://www.pystone.net/notes/unity-performance-optimization-knowledge-map/)保留旧分类框架，但把 3 ms、150 MB、200 MB 等数字降级为特定年代、设备与项目的历史预算，并补入目标设备多轮采样流程。 这些修订支持本页的成本拓扑，却也增加一个前置条件：进入 `c、f、n、W、q、h、v` 之前，必须先声明“哪个观察器、哪个对象、哪个生命周期窗口、哪个环境、哪种统计量”。同名“内存”可以指托管对象、Unity allocator、进程物理压力或共享页面分摊；同一个数字只有在测量对象和时窗一致时才适合比较。固定阈值也不是事实常量，而是帧率目标、设备档位、系统终止策略和其他资源预算共同决定的局部决策线。 这反驳了“数字越精确越可迁移”的隐含假设。历史阈值可以产生待验证假设，却不能跳过当前基线；一次 PSS 高点可以触发进一步采样，却不能替代多轮趋势、对象快照和释放验证。未来若多轮操作后 PSS 单调抬升，而对象或映射证据能定位到同一未释放集合，泄漏解释会增强；若 PSS 波动但回到稳定区间，或增长来自可解释缓存、预热和 allocator 保留，则“高于旧阈值”不应成为泄漏结论。 本次仍是底座纠错，不是目标设备性能事件。它提高了概念与测量口径的一致性，却没有产生任何帧时间、内存峰值或崩溃率改善，因此不增加规律效果证据。当前决策是把历史数字保留为有语境的来源线索，实际优化只接受同设备、同场景、同构建、同观察器和对齐时窗的前后证据。 决策时先记录用户症状和目标分位数，再标出实际瓶颈上的 `c、f、n、W、q、h、v` 及被转移成本。优先改变高杠杆变量或关键路径，而不是按 API 名称排序；同时比较帧时间或端到端分位数、资源向量、内存峰值、功耗、正确性与维护复杂度。这个原则与[软件质量反馈系统](https://www.pystone.net/notes/software-quality-as-feedback-system/)共同构成闭环：性能模型提出可区分预测，代表性测量负责支持、限制、反驳或替代它。 ## 比技巧更稳定的检查问题 1. 用户可见的问题是什么，发生在哪个场景和设备？ 2. 实际瓶颈上的 `c、f、n、W` 分别是多少？ 3. 工作是否位于关键路径，时间如何聚集，资源余量和尾部范围怎样？ 4. 当前看到的是根因、放大器，还是后果？ 5. 这项修改把成本转移到了哪个资源、阶段或质量目标？ 6. 是否有更高杠杆的结构变化，而不是只改热点中的一行语法？ 7. 前后证据是否可比较，结论是否写清版本、场景与失效边界？ 这套问题与[软件质量反馈系统](https://www.pystone.net/notes/software-quality-as-feedback-system/)相互支持：性能测试生产证据，但指标阈值、体验取舍和维护成本仍需要工程与产品判断；一次绿色基准不能证明所有运行环境都已经优化。 ## 边界与开放问题 - 本页建立的是推理框架，不替代平台官方文档、当前 Profiler 结果或硬件实测。 - 来源页包含多个旧 Unity/Mono 版本的经验数字和实现细节；本次只核验了 GC、目标平台采样和 `Camera.main`，其余 API、设备阈值与平台差异仍不能直接沿用。 - PSS、RSS/footprint、Unity Used/Reserved 和对象快照观察不同边界；如果没有声明对象、时窗、环境和统计量，跨工具数字不能直接组合成泄漏或优化收益。 - “只在变化时工作”可能增加状态同步复杂度；在对象少、逻辑简单的场景中，轮询反而可能更可靠且成本可忽略。 - 更少分配并不自动意味着更低总内存；缓存和池化的容量、峰值与回收策略必须共同验证。 - 后续真实性能问题应先调用本页，记录它是否帮助缩小根因、避免无效微优化，或在哪类 GPU、I/O、热功耗问题上仍显得过于 CPU/托管运行时中心。 ## 演化记录 - **2026-07-22**：把 CPU 调用、托管分配、GC、加载、UI、动画、物理与渲染材料连接为“单次成本 × 频率 × 影响范围 × 生命周期”模型；将版本相关技巧和旧设备阈值降级为待复测假设，形成从用户症状到前后对照和副作用审阅的优化闭环。 - **2026-07-22（后续核验）**：用 Unity 6 官方文档调用本页。保留“高频临时分配会放大 GC 成本”和“目标平台采样”的判断；把 GC 单次长暂停限制到非增量或回退情形，并以当前 `Camera.main` 缓存机制替代旧的全场景搜索描述。由于没有项目基线，本次只证明框架能引导版本校准，不宣称实际优化收益。 - **2026-07-23**：把原先混合工作量、驻留和体验的四项乘积修订为三层模型；以 Little 定律、Amdahl 约束和 Tail at Scale 分别核验停留时间、局部改善比例与尾部传播，形成第二个公开规律候选。新增四项事前预测、成本转移反例和竞争解释；尚无真实性能事件结果，因此不计为预测支持。 - **2026-07-23（形成后工程校准）**：公开 staged-snapshot 路径先测得索引物化 1714.1 ms、validator 930.0 ms；只启用 Git 并行 checkout 后，物化降为 401.9 ms，重复端到端均值由约 3175 ms 降为约 1865 ms。结果窄支持关键路径诊断和 Amdahl 瓶颈转移，保留单机、少量样本和非目标设备边界；当前不以缓存或增量检查换取更多复杂度。 - **2026-08-01（测量坐标校准）**：PSS、Unity Profiler 与历史性能体系的纠错把内存指标拆回各自观察器、对象、生命周期和环境，并将固定毫秒/内存数字降级为历史项目预算。它支持代表性测量优先于技巧清单，也限制了跨工具相加、单点泄漏判断和旧阈值外推；本次没有真实性能前后结果，不增加效果证据。