1. 项目概述为什么FixedUpdate是物理模拟的基石在Unity开发中尤其是涉及到角色移动、车辆驾驶、物体碰撞这类需要稳定物理交互的游戏时新手和老手都可能会遇到一个共同的困惑为什么明明在Update里写好了移动逻辑物体的运动却时快时慢甚至在某些低帧率设备上直接“穿墙而过”这个问题的根源往往在于没有理解Unity物理引擎的运作机制以及FixedUpdate这个核心方法在其中扮演的角色。简单来说FixedUpdate是Unity为物理模拟专门开辟的一条“独立时间线”。它不受游戏画面渲染帧率Update的调用频率波动的影响以固定的时间间隔默认为0.02秒即每秒50次稳定地推进物理世界的计算。想象一下Update是电影的播放速度可能因为设备性能或场景复杂度而忽快忽慢而FixedUpdate则是电影中物理世界的“心跳”无论画面播放是否卡顿这个世界里的重力、碰撞、关节约束都在以恒定的节奏精确地演化。如果你直接在Update里使用transform.position来移动一个带有碰撞体的物体那么物体的移动速度将与帧率直接挂钩帧率低时物体每帧移动的距离大物理引擎可能来不及在两帧之间检测到碰撞导致穿透现象。而将物理相关的操作如对Rigidbody施加力AddForce或修改速度velocity放在FixedUpdate中就能确保物理引擎有足够稳定和可预测的机会来处理这些变化从而得到准确、一致的碰撞和运动效果。对于任何希望构建物理表现扎实、手感稳定的2D或3D项目的开发者无论是制作一款平台跳跃游戏、一个物理解谜玩具还是一个需要精确模拟的仿真应用深入理解并正确应用FixedUpdate都是绕不开的必修课。它不仅关乎功能正确性更直接影响到游戏在不同性能设备上的表现和玩家的核心体验。2. FixedUpdate的核心原理与工作机制拆解要驾驭FixedUpdate不能只停留在“把代码放进去”的层面必须理解它背后的运行逻辑、与Update的协作关系以及Unity物理引擎默认是NVIDIA PhysX是如何被驱动的。2.1 双循环机制Update与FixedUpdate的协奏曲Unity的主游戏循环可以看作是两个并行的循环在协同工作一个是基于帧的Update循环另一个是基于固定时间步长的FixedUpdate循环。Update循环驱动因素与图形渲染同步。每渲染一帧或执行一次游戏逻辑更新就调用一次。时间间隔Time.deltaTime。这个值是不固定的它等于上一帧到当前帧所经历的真实时间。在60 FPS的设备上它大约是0.0167秒在30 FPS的设备上它大约是0.0333秒如果某一帧卡顿了这个值可能会变得很大如0.1秒。主要用途处理玩家输入Input.GetKey、非物理动画、游戏状态管理、摄像机跟随等与渲染帧率强相关或对时间波动不敏感的逻辑。FixedUpdate循环驱动因素由独立的固定时间步长计时器驱动。时间间隔Time.fixedDeltaTime。这是一个常量默认0.02秒50 Hz。你可以在Edit - Project Settings - Time中修改Fixed Timestep的值。主要用途执行所有与物理引擎相关的计算。包括对Rigidbody施加力AddForce、扭矩AddTorque。修改Rigidbody的速度velocity或角速度angularVelocity。查询物理状态但在FixedUpdate中查询能保证与当前物理步骤的状态一致。任何需要以稳定速率执行的、与物理世界交互的逻辑。这两个循环并非严格交替执行。Unity内部维护着一个名为fixedTime的累加器。每一帧Update开始前引擎会将自上一帧以来过去的时间Time.deltaTime累加到fixedTime中。然后只要fixedTime大于或等于预设的fixedDeltaTime引擎就会调用一次FixedUpdate并在fixedTime中减去一个fixedDeltaTime。这个过程会一直重复直到fixedTime小于fixedDeltaTime为止。调用完所有该帧需要的FixedUpdate后才会进行该帧的Update逻辑和后续渲染。2.2 物理引擎的驱动与“追赶”机制FixedUpdate的调用直接关联着物理引擎的模拟步进。每一次FixedUpdate调用后更准确地说是在所有脚本的FixedUpdate方法执行完毕后Unity会调用物理引擎的Physics.Simulate(fixedDeltaTime)将物理世界向前推进一个固定时间步长。这就引出了那个经典的“追赶”Catch-up问题。假设你的游戏目标帧率是60 FPSfixedDeltaTime是0.02秒50 Hz。在理想情况下每渲染一帧约0.0167秒fixedTime累加0.0167小于0.02所以这一帧不会调用FixedUpdate。下一帧再累加0.0167总和0.0334大于0.02于是调用一次FixedUpdate并减去0.02剩余0.0134。如此循环大约每3帧图形更新对应2次物理更新60/501.2近似3:2。但是如果某一帧因为加载资源或复杂计算导致耗时长达0.1秒那么fixedTime会一次性累加0.1。为了“追赶”上真实流逝的时间引擎会在这一帧里连续调用5次FixedUpdate0.1 / 0.02 5。这会导致两个现象性能开销同一帧内执行5倍的物理计算CPU峰值负载剧增可能加剧卡顿。视觉表现由于多次物理模拟的结果会在同一帧的渲染中体现物体可能看起来“瞬移”了一段距离而不是平滑移动。为了避免这种恶性循环Unity提供了Maximum Allowed Timestep最大允许时间步长默认0.333秒。当fixedTime的累积值超过这个阈值时引擎会“丢弃”超出的时间直接重置fixedTime并可能跳过一些物理更新来防止游戏完全卡死但这会导致物理世界的时间与真实时间不同步表现为游戏“丢帧”或“慢动作”。注意理解“追赶”机制是性能优化的关键。在低端移动设备上将Fixed Timestep适当调大例如从0.02调到0.033对应~30 Hz可以降低物理更新的频率减少单帧内需要“追赶”的次数从而避免因物理计算堆积而导致的性能雪崩。2.3 FixedUpdate、物理查询与变换同步另一个需要厘清的关键点是物理查询如Physics.Raycast,OverlapSphere和变换同步的时机。默认情况下在Update中进行的物理查询其依据的物理世界状态是上一次FixedUpdate完成、物理引擎模拟后的状态。如果你在Update里移动了一个Transform非物理方式然后立即进行射线检测射线检测可能“看不到”这次移动因为物理引擎内部的碰撞体位置还没有更新。这涉及到autoSyncTransforms这个设置Edit - Project Settings - Physics。当它启用时默认是关闭的任何对Transform的修改都会立即触发与物理引擎的同步确保后续的物理查询基于最新位置。但这会带来性能损耗。更高效的做法是保持其关闭并在需要精确查询前手动调用Physics.SyncTransforms()。最佳实践对于大多数游戏建议在FixedUpdate中进行物理移动和物理查询以保证逻辑的一致性。如果必须在Update中进行查询并且查询依赖于本帧内对Transform的修改那么需要在查询前手动调用Physics.SyncTransforms()。3. FixedUpdate的正确应用模式与实战技巧理解了原理我们来看看在代码中如何正确地使用FixedUpdate以及有哪些可以提升代码质量和性能的实战模式。3.1 何时用FixedUpdate一个清晰的决策流判断一段逻辑是否应该放在FixedUpdate中可以遵循以下流程操作对象是否是Rigidbody如果是优先考虑FixedUpdate。操作是否直接影响了物理状态例如施加力、设置速度、使用MovePosition/MoveRotation。如果是必须放在FixedUpdate。逻辑是否需要严格按固定时间步长执行例如一个计时器你希望它在任何帧率下都精确地每秒触发一次。FixedUpdate比用Time.deltaTime累加更可靠。逻辑是否严重依赖于物理模拟的结果例如检测角色是否着地如果检测代码在Update中而跳跃起跳代码在FixedUpdate中可能会因为执行顺序问题导致检测不准。将这类依赖物理状态的逻辑也放在FixedUpdate中可以简化问题。反之处理输入、播放动画、更新UI、摄像机平滑跟随基于Transform等则应该放在Update中并使用Time.deltaTime来保证帧率独立。3.2 输入处理与FixedUpdate的延迟问题一个常见的陷阱是在Update中捕获输入如Input.GetKeyDown然后在FixedUpdate中响应如施加跳跃力。由于FixedUpdate的调用频率可能低于Update你可能会错过一个只在某一帧发生的按键事件。解决方案是使用缓存private bool _jumpRequested; void Update() { // 在Update中捕获瞬间输入 if (Input.GetButtonDown(Jump)) { _jumpRequested true; } } void FixedUpdate() { // 在FixedUpdate中处理物理响应 if (_jumpRequested) { _rigidbody.AddForce(Vector3.up * _jumpForce, ForceMode.Impulse); _jumpRequested false; // 重置请求 } // ... 其他固定更新逻辑如持续移动 Vector2 moveInput new Vector2(Input.GetAxis(Horizontal), Input.GetAxis(Vertical)); Vector3 moveDirection new Vector3(moveInput.x, 0, moveInput.y).normalized; _rigidbody.AddForce(moveDirection * _moveSpeed); }对于GetAxis这类连续值输入可以直接在FixedUpdate中使用因为其值在帧间是平滑变化的。3.3 在FixedUpdate中实现稳定移动对于角色控制器或车辆在FixedUpdate中操作Rigidbody是实现稳定移动的关键。通常有两种模式力驱动模式public float moveForce 10f; public float maxSpeed 5f; private Rigidbody _rb; void FixedUpdate() { float horizontal Input.GetAxis(Horizontal); float vertical Input.GetAxis(Vertical); Vector3 force new Vector3(horizontal, 0, vertical) * moveForce; _rb.AddForce(force); // 可选限制最大速度模拟阻力 if (_rb.velocity.magnitude maxSpeed) { _rb.velocity _rb.velocity.normalized * maxSpeed; } }这种方式最物理手感真实有加速过程但需要精细调参。速度直接设置模式public float moveSpeed 5f; private Rigidbody _rb; void FixedUpdate() { float horizontal Input.GetAxis(Horizontal); float vertical Input.GetAxis(Vertical); Vector3 targetVelocity new Vector3(horizontal, 0, vertical) * moveSpeed; // 只改变水平速度保留垂直方向的速度如重力影响 _rb.velocity new Vector3(targetVelocity.x, _rb.velocity.y, targetVelocity.z); }这种方式响应即时易于控制但缺乏惯性感更像“冰面滑动”。可以根据游戏类型选择。实操心得对于平台跳跃游戏跳跃力AddForce(ForceMode.Impulse)必须在FixedUpdate中施加。而在地面移动时混合使用力驱动和速度修正往往能获得更好的手感。例如用AddForce进行加速但当输入方向突然改变或松开按键时可以施加一个反向力或直接干预速度来实现更灵敏的操控。3.4 与Update的通信插值Interpolation与预测由于FixedUpdate的调用与Update/渲染不同步直接使用Rigidbody的位置来更新视觉对象如角色模型、特效位置可能会导致抖动。这就是为什么Rigidbody组件提供了插值Interpolation选项。None不插值。视觉位置直接等于物理引擎最新计算出的位置。在物理更新频率低于渲染频率时会出现卡顿或跳跃。Interpolate插值。基于上一物理帧和当前物理帧的位置在渲染帧之间进行平滑过渡。这是最常用的选项能提供平滑的视觉运动。Extrapolate外推。基于当前物理速度和上一物理帧的位置预测当前渲染帧的位置。在物理计算稳定时很平滑但在物理状态突变如碰撞时可能产生抖动或“过冲”。启用方法在需要进行平滑渲染的Rigidbody组件上将Interpolation设置为Interpolate。工作原理当启用插值后在每一帧Update渲染前Unity会根据该Rigidbody在上一次FixedUpdate和下一次FixedUpdate预测之间的时间比例计算出当前渲染帧应该显示的平滑位置。这完全由引擎在后台处理你无需在代码中做额外工作。注意事项插值会带来轻微的性能开销需要存储多一帧的变换数据并进行计算对于大量存在的刚体如数百个弹珠需权衡使用。对于由玩家直接控制的主角刚体务必开启插值。对于运动轨迹复杂或速度极快的物体如子弹外推模式可能不适用插值模式是更安全的选择。4. 基于FixedUpdate的性能深度优化策略FixedUpdate和物理模拟是性能问题的重灾区。不当的使用会导致CPU峰值飙升、帧时间不稳定。以下是从架构到细节的层层优化策略。4.1 宏观调参时间步长与最大允许步长这是优化物理性能的第一道也是最重要的一道防线。调整Fixed Timestep默认值0.02秒 (50 Hz)。对于PC和主机游戏这通常是个不错的起点。移动端优化考虑提高到0.033秒 (30 Hz) 甚至0.05秒 (20 Hz)。物理模拟频率降低一半计算量也大致减少一半对性能提升显著。对于许多移动游戏来说30Hz的物理更新率在视觉上是可以接受的尤其是当配合运动模糊或插值时。如何调整Edit - Project Settings - Time - Fixed Timestep。测试方法在目标低端设备上运行使用Unity Profiler观察Physics.Processing和Physics.Simulate的时间。如果它们占总帧时间的比例过高例如超过30%且游戏对超高精度物理需求不高尝试增大此值。设置Maximum Allowed Timestep作用限制一帧内用于“追赶”物理模拟的最大时间。防止因单帧卡顿导致后续帧陷入物理计算的死亡螺旋。默认值0.333秒。意味着如果一帧花了0.5秒物理引擎只会用0.333秒的时间来模拟约16.5个固定步长剩下的0.167秒会被丢弃游戏时间会变慢。优化建议对于快节奏动作游戏可以适当调小如0.1秒以牺牲极端卡顿情况下的时间准确性为代价换取更快的恢复速度避免游戏长时间“慢动作”。对于慢节奏游戏可以保持默认或调大。4.2 中观优化减少物理计算负载即使调整了时间步长物理计算本身也可能是瓶颈。我们需要减少物理引擎的工作量。简化碰撞体原则用简单的几何体Box, Sphere, Capsule近似复杂的网格Mesh Collider。方法对于角色使用胶囊体对于车辆使用多个盒子或胶囊体的组合对于复杂静态环境如果不能用简单碰撞体组合再考虑使用Mesh Collider并务必在导入设置或Mesh Collider组件中优化其Cooking Options如禁用Enable Mesh Cleaning、Weld Colocated Vertices以提升烹饪速度。工具使用Physics DebuggerWindow Analysis Physics Debugger可视化查看场景中所有的碰撞体检查是否有不必要的复杂碰撞体。优化物理查询使用非分配Non-Alloc方法Physics.RaycastNonAlloc,Physics.OverlapSphereNonAlloc等。这些方法允许你传入一个预分配的数组作为结果缓冲区避免每次查询都在堆上分配新数组从而减少垃圾回收GC压力。private RaycastHit[] _raycastHits new RaycastHit[10]; // 预分配 void PerformRaycast() { int hitCount Physics.RaycastNonAlloc(transform.position, transform.forward, _raycastHits, 10f); for (int i 0; i hitCount; i) { // 处理 _raycastHits[i] } }批量射线检测如果需要同时进行大量射线检测如AI感知系统不要用循环调用Physics.Raycast。使用RaycastCommand配合C# Job System将计算并行化并卸载到工作线程。优化查询频率不是每一帧都需要进行物理查询。例如AI的感知系统可以每3-5帧更新一次。管理刚体与碰撞体设置合适的刚体类型对于永远不会移动的物体如地形、建筑使用静态碰撞体只有Collider没有Rigidbody。物理引擎会为它们做特殊优化。冻结刚体对于暂时不参与动态模拟的刚体如被击倒后躺在地上的敌人可以将其Rigidbody设置为Sleep状态引擎会自动处理或者直接设置isKinematic true将其从动力学模拟中移除需要时再激活。简化碰撞矩阵在Edit - Project Settings - Physics - Layer Collision Matrix中取消勾选永远不会发生交互的层之间的碰撞。这能显著减少宽相位Broad-phase检测的计算量。4.3 微观优化FixedUpdate内部的代码效率即使物理引擎本身负载不高低效的FixedUpdate脚本代码也会成为瓶颈。减少每帧的GameObject.Find、GetComponent调用这些调用开销较大。在Start或Awake中缓存引用。// 避免在FixedUpdate中这样做 void FixedUpdate() { // 错误示范 GameObject player GameObject.Find(Player); Rigidbody rb player.GetComponentRigidbody(); // ... } // 正确做法 private Rigidbody _playerRb; void Start() { _playerRb GameObject.Find(Player).GetComponentRigidbody(); } void FixedUpdate() { // 使用缓存的 _playerRb }避免在FixedUpdate中进行复杂的数学运算或内存分配例如避免在循环中频繁创建新的Vector3、RaycastHit数组除非使用NonAlloc、或者使用LINQ它会产生GC分配。尽量复用对象和数组。使用合适的ForceModeAddForce有四种模式ForceMode.Force添加一个持续的力质量相关。ForceMode.Impulse添加一个瞬间的冲量质量相关。适用于跳跃、射击。ForceMode.Acceleration添加一个持续的加速度忽略质量。ForceMode.VelocityChange添加一个瞬间的速度变化忽略质量。 根据需求选择。例如想让一个物体无视质量获得一个恒定的加速度用Acceleration更直观且计算稍简。谨慎使用Physics.SyncTransforms如前所述除非必要保持autoSyncTransforms为false。如果需要在Update中基于变换修改进行物理查询手动调用Physics.SyncTransforms()但应将其调用频率降到最低。4.4 架构级优化分帧与异步处理当场景中需要更新大量物理对象时如成千上万的粒子或碎片即使每个对象的计算量很小在同一个FixedUpdate中处理所有对象也会造成CPU尖峰。分帧处理策略 将N个对象分成M批每一帧只更新其中一批。这可以将一个大的CPU峰值平摊到多帧中。public class BatchPhysicsUpdater : MonoBehaviour { public ListRigidbody physicsBodies; private int _currentIndex 0; public int batchSize 10; // 每帧更新多少个 void FixedUpdate() { int endIndex Mathf.Min(_currentIndex batchSize, physicsBodies.Count); for (int i _currentIndex; i endIndex; i) { // 更新 physicsBodies[i] 的物理状态例如施加一个随机的力 // physicsBodies[i].AddForce(Random.insideUnitSphere * 0.1f); } _currentIndex endIndex; if (_currentIndex physicsBodies.Count) { _currentIndex 0; // 循环 } } }这种方法牺牲了一点实时性换来了更平滑的帧时间对于背景或次要的物理效果非常有效。5. 常见问题排查与调试技巧实录即使遵循了最佳实践在复杂项目中依然会遇到各种诡异的物理问题。下面是一些常见问题的排查思路和调试技巧。5.1 问题物体运动抖动或不平滑可能原因及排查未启用刚体插值检查运动物体的Rigidbody组件Interpolation是否设置为Interpolate或Extrapolate。在Update和FixedUpdate中同时修改位置确保对Rigidbody的位置/旋转操作只在FixedUpdate中进行。在Update中操作Transform会与物理引擎的插值计算冲突。Fixed Timestep设置与帧率不匹配如果Fixed Timestep设置得过高如0.1秒而游戏运行在60帧物理更新频率太低会导致视觉上的跳跃感。尝试降低Fixed Timestep或确认渲染帧率是否稳定。性能问题导致FixedUpdate追赶使用Profiler (Window Analysis Profiler) 查看Physics.Processing的时间。如果出现一帧内多次调用FixedUpdate表现为Physics.Simulate的调用柱状图很高说明遇到了追赶问题。需要按照第4.1节的策略优化Fixed Timestep和Maximum Allowed Timestep或者优化物理负载。5.2 问题碰撞检测失败物体穿透可能原因及排查移动方式错误使用transform.Translate或直接设置transform.position来移动带有碰撞体的物体。这是最常见的原因。必须通过Rigidbody来移动物理物体AddForce,velocity,MovePosition。物体速度过快在单个FixedUpdate步长内物体移动的距离超过了其碰撞体的尺寸。物理引擎的连续碰撞检测CCD可能未开启或不足以处理。解决方案为高速运动的刚体如子弹启用Rigidbody上的Collision Detection模式为Continuous或Continuous Dynamic。注意这会增加性能开销。替代方案使用射线检测来模拟高速子弹而不是实际的物理运动。碰撞体层级设置错误检查Layer Collision Matrix确保发生碰撞的两个物体的层是相互勾选的。碰撞体尺寸为0或太小检查碰撞体组件的尺寸确保它不是零或接近零。5.3 问题物理表现不一致不同设备或帧率下行为不同可能原因及排查在Update中使用Time.deltaTime进行物理相关计算这是绝对要避免的。任何影响物理状态的力、速度计算都必须基于Time.fixedDeltaTime并且放在FixedUpdate中。// 错误在Update中使用deltaTime计算力 void Update() { float forceThisFrame someForce * Time.deltaTime; _rb.AddForce(Vector3.forward * forceThisFrame); // 力的大小会随帧率波动 } // 正确在FixedUpdate中使用fixedDeltaTime void FixedUpdate() { float forceThisStep someForce * Time.fixedDeltaTime; // fixedDeltaTime是常量 _rb.AddForce(Vector3.forward * forceThisStep); }使用了ForceMode.Force或ForceMode.Acceleration但计算时未乘Time.fixedDeltaTime这两种模式是“持续的力/加速度”通常需要乘以时间步长来得到该步长内的冲量/速度变化。而Impulse和VelocityChange本身代表瞬间变化不需要再乘。void FixedUpdate() { // 假设想每帧施加一个恒定的力 _rb.AddForce(Vector3.forward * 10f * Time.fixedDeltaTime, ForceMode.Force); // 正确 // _rb.AddForce(Vector3.forward * 10f, ForceMode.Force); // 错误力会过大 }复杂场景下的浮点数精度差异在极端庞大或微小的场景中不同CPU的浮点数计算可能会有细微差异但这种情况较少见。确保物理相关计算使用float类型并检查Rigidbody的Solver Iterations求解器迭代次数是否足够。对于特别复杂或堆叠的刚体可以适当增加此值Project Settings Physics Default Solver Iterations或在单个Rigidbody上设置但会增加计算成本。5.4 调试工具Physics Debugger 与 ProfilerPhysics Debugger(Window Analysis Physics Debugger)可视化碰撞体可以按层、按类型静态/动态/运动学显示碰撞体轮廓颜色编码快速发现碰撞体缺失、重叠或尺寸不合理的问题。查看接触点在播放模式下可以显示实时发生的碰撞接触点和法线对于调试复杂的碰撞交互至关重要。Profiler(Window Analysis Profiler)CPU Usage重点关注Physics.Processing和Physics.Simulate所占用的时间。如果它们占比过高就是性能瓶颈的明确信号。观察FixedUpdate调用频率在Profiler的CPU图表中观察FixedUpdate的调用柱状图。平稳的间隔表示运行良好出现密集的柱状图簇则表示发生了“追赶”需要优化。内存分配在Profiler的CPU模块下查看GC Alloc列。如果在FixedUpdate中看到持续的、大量的内存分配1KB/帧就要检查是否使用了会产生垃圾的物理API如没有使用NonAlloc版本的查询或者在循环中创建了临时对象。5.5 一个综合排查清单表当你遇到物理相关问题时可以按此表顺序排查问题现象优先检查项工具/方法物体抖动、不平滑1. 刚体Interpolation是否开启2. 是否在Update中操作刚体Transform3. Profiler中Physics.Simulate是否出现峰值Physics Debugger, Profiler碰撞穿透、检测不到1. 是否用Transform直接移动刚体2. 物体速度是否过快CCD是否开启3. 碰撞体层级矩阵是否正确4. 碰撞体尺寸是否合理Physics Debugger, 场景视图查看碰撞体不同设备表现不一1. 物理计算是否错误使用了Time.deltaTime2.ForceMode和时间步长乘法是否正确3.Fixed Timestep设置是否合理代码审查在不同帧率下测试游戏卡顿帧时间波动大1. Profiler中Physics.Processing时间是否过高2. 场景中动态刚体数量是否过多3. 是否使用了复杂的Mesh Collider4.Maximum Allowed Timestep是否设置过小Profiler, Stats窗口Draw Calls, Tris, SetPass Calls物理反应“软绵绵”或“过冲”1. 刚体的Mass质量、Drag阻力、Angular Drag角阻力设置是否合理2. 求解器迭代次数(Solver Iterations)是否太低调整刚体参数在Physics Debugger中观察碰撞掌握FixedUpdate的原理、应用与优化是迈向资深Unity开发者的关键一步。它要求开发者不仅会写代码更要理解引擎底层的工作机制并具备跨系统渲染、物理、输入的全局优化视野。从稳定移动的手感到复杂碰撞的精确反馈再到在全平台设备上流畅运行的性能表现都离不开对这条“物理心跳线”的精细把控。在实际项目中我习惯在项目初期就建立物理相关的编码规范比如强制要求所有Rigidbody操作必须在FixedUpdate中并在性能测试阶段将Profiler的Physics模块作为重点监控对象。记住一个稳定的物理帧率往往是游戏整体流畅度的基石。
Unity物理模拟核心：FixedUpdate原理、应用与性能优化全解析
1. 项目概述为什么FixedUpdate是物理模拟的基石在Unity开发中尤其是涉及到角色移动、车辆驾驶、物体碰撞这类需要稳定物理交互的游戏时新手和老手都可能会遇到一个共同的困惑为什么明明在Update里写好了移动逻辑物体的运动却时快时慢甚至在某些低帧率设备上直接“穿墙而过”这个问题的根源往往在于没有理解Unity物理引擎的运作机制以及FixedUpdate这个核心方法在其中扮演的角色。简单来说FixedUpdate是Unity为物理模拟专门开辟的一条“独立时间线”。它不受游戏画面渲染帧率Update的调用频率波动的影响以固定的时间间隔默认为0.02秒即每秒50次稳定地推进物理世界的计算。想象一下Update是电影的播放速度可能因为设备性能或场景复杂度而忽快忽慢而FixedUpdate则是电影中物理世界的“心跳”无论画面播放是否卡顿这个世界里的重力、碰撞、关节约束都在以恒定的节奏精确地演化。如果你直接在Update里使用transform.position来移动一个带有碰撞体的物体那么物体的移动速度将与帧率直接挂钩帧率低时物体每帧移动的距离大物理引擎可能来不及在两帧之间检测到碰撞导致穿透现象。而将物理相关的操作如对Rigidbody施加力AddForce或修改速度velocity放在FixedUpdate中就能确保物理引擎有足够稳定和可预测的机会来处理这些变化从而得到准确、一致的碰撞和运动效果。对于任何希望构建物理表现扎实、手感稳定的2D或3D项目的开发者无论是制作一款平台跳跃游戏、一个物理解谜玩具还是一个需要精确模拟的仿真应用深入理解并正确应用FixedUpdate都是绕不开的必修课。它不仅关乎功能正确性更直接影响到游戏在不同性能设备上的表现和玩家的核心体验。2. FixedUpdate的核心原理与工作机制拆解要驾驭FixedUpdate不能只停留在“把代码放进去”的层面必须理解它背后的运行逻辑、与Update的协作关系以及Unity物理引擎默认是NVIDIA PhysX是如何被驱动的。2.1 双循环机制Update与FixedUpdate的协奏曲Unity的主游戏循环可以看作是两个并行的循环在协同工作一个是基于帧的Update循环另一个是基于固定时间步长的FixedUpdate循环。Update循环驱动因素与图形渲染同步。每渲染一帧或执行一次游戏逻辑更新就调用一次。时间间隔Time.deltaTime。这个值是不固定的它等于上一帧到当前帧所经历的真实时间。在60 FPS的设备上它大约是0.0167秒在30 FPS的设备上它大约是0.0333秒如果某一帧卡顿了这个值可能会变得很大如0.1秒。主要用途处理玩家输入Input.GetKey、非物理动画、游戏状态管理、摄像机跟随等与渲染帧率强相关或对时间波动不敏感的逻辑。FixedUpdate循环驱动因素由独立的固定时间步长计时器驱动。时间间隔Time.fixedDeltaTime。这是一个常量默认0.02秒50 Hz。你可以在Edit - Project Settings - Time中修改Fixed Timestep的值。主要用途执行所有与物理引擎相关的计算。包括对Rigidbody施加力AddForce、扭矩AddTorque。修改Rigidbody的速度velocity或角速度angularVelocity。查询物理状态但在FixedUpdate中查询能保证与当前物理步骤的状态一致。任何需要以稳定速率执行的、与物理世界交互的逻辑。这两个循环并非严格交替执行。Unity内部维护着一个名为fixedTime的累加器。每一帧Update开始前引擎会将自上一帧以来过去的时间Time.deltaTime累加到fixedTime中。然后只要fixedTime大于或等于预设的fixedDeltaTime引擎就会调用一次FixedUpdate并在fixedTime中减去一个fixedDeltaTime。这个过程会一直重复直到fixedTime小于fixedDeltaTime为止。调用完所有该帧需要的FixedUpdate后才会进行该帧的Update逻辑和后续渲染。2.2 物理引擎的驱动与“追赶”机制FixedUpdate的调用直接关联着物理引擎的模拟步进。每一次FixedUpdate调用后更准确地说是在所有脚本的FixedUpdate方法执行完毕后Unity会调用物理引擎的Physics.Simulate(fixedDeltaTime)将物理世界向前推进一个固定时间步长。这就引出了那个经典的“追赶”Catch-up问题。假设你的游戏目标帧率是60 FPSfixedDeltaTime是0.02秒50 Hz。在理想情况下每渲染一帧约0.0167秒fixedTime累加0.0167小于0.02所以这一帧不会调用FixedUpdate。下一帧再累加0.0167总和0.0334大于0.02于是调用一次FixedUpdate并减去0.02剩余0.0134。如此循环大约每3帧图形更新对应2次物理更新60/501.2近似3:2。但是如果某一帧因为加载资源或复杂计算导致耗时长达0.1秒那么fixedTime会一次性累加0.1。为了“追赶”上真实流逝的时间引擎会在这一帧里连续调用5次FixedUpdate0.1 / 0.02 5。这会导致两个现象性能开销同一帧内执行5倍的物理计算CPU峰值负载剧增可能加剧卡顿。视觉表现由于多次物理模拟的结果会在同一帧的渲染中体现物体可能看起来“瞬移”了一段距离而不是平滑移动。为了避免这种恶性循环Unity提供了Maximum Allowed Timestep最大允许时间步长默认0.333秒。当fixedTime的累积值超过这个阈值时引擎会“丢弃”超出的时间直接重置fixedTime并可能跳过一些物理更新来防止游戏完全卡死但这会导致物理世界的时间与真实时间不同步表现为游戏“丢帧”或“慢动作”。注意理解“追赶”机制是性能优化的关键。在低端移动设备上将Fixed Timestep适当调大例如从0.02调到0.033对应~30 Hz可以降低物理更新的频率减少单帧内需要“追赶”的次数从而避免因物理计算堆积而导致的性能雪崩。2.3 FixedUpdate、物理查询与变换同步另一个需要厘清的关键点是物理查询如Physics.Raycast,OverlapSphere和变换同步的时机。默认情况下在Update中进行的物理查询其依据的物理世界状态是上一次FixedUpdate完成、物理引擎模拟后的状态。如果你在Update里移动了一个Transform非物理方式然后立即进行射线检测射线检测可能“看不到”这次移动因为物理引擎内部的碰撞体位置还没有更新。这涉及到autoSyncTransforms这个设置Edit - Project Settings - Physics。当它启用时默认是关闭的任何对Transform的修改都会立即触发与物理引擎的同步确保后续的物理查询基于最新位置。但这会带来性能损耗。更高效的做法是保持其关闭并在需要精确查询前手动调用Physics.SyncTransforms()。最佳实践对于大多数游戏建议在FixedUpdate中进行物理移动和物理查询以保证逻辑的一致性。如果必须在Update中进行查询并且查询依赖于本帧内对Transform的修改那么需要在查询前手动调用Physics.SyncTransforms()。3. FixedUpdate的正确应用模式与实战技巧理解了原理我们来看看在代码中如何正确地使用FixedUpdate以及有哪些可以提升代码质量和性能的实战模式。3.1 何时用FixedUpdate一个清晰的决策流判断一段逻辑是否应该放在FixedUpdate中可以遵循以下流程操作对象是否是Rigidbody如果是优先考虑FixedUpdate。操作是否直接影响了物理状态例如施加力、设置速度、使用MovePosition/MoveRotation。如果是必须放在FixedUpdate。逻辑是否需要严格按固定时间步长执行例如一个计时器你希望它在任何帧率下都精确地每秒触发一次。FixedUpdate比用Time.deltaTime累加更可靠。逻辑是否严重依赖于物理模拟的结果例如检测角色是否着地如果检测代码在Update中而跳跃起跳代码在FixedUpdate中可能会因为执行顺序问题导致检测不准。将这类依赖物理状态的逻辑也放在FixedUpdate中可以简化问题。反之处理输入、播放动画、更新UI、摄像机平滑跟随基于Transform等则应该放在Update中并使用Time.deltaTime来保证帧率独立。3.2 输入处理与FixedUpdate的延迟问题一个常见的陷阱是在Update中捕获输入如Input.GetKeyDown然后在FixedUpdate中响应如施加跳跃力。由于FixedUpdate的调用频率可能低于Update你可能会错过一个只在某一帧发生的按键事件。解决方案是使用缓存private bool _jumpRequested; void Update() { // 在Update中捕获瞬间输入 if (Input.GetButtonDown(Jump)) { _jumpRequested true; } } void FixedUpdate() { // 在FixedUpdate中处理物理响应 if (_jumpRequested) { _rigidbody.AddForce(Vector3.up * _jumpForce, ForceMode.Impulse); _jumpRequested false; // 重置请求 } // ... 其他固定更新逻辑如持续移动 Vector2 moveInput new Vector2(Input.GetAxis(Horizontal), Input.GetAxis(Vertical)); Vector3 moveDirection new Vector3(moveInput.x, 0, moveInput.y).normalized; _rigidbody.AddForce(moveDirection * _moveSpeed); }对于GetAxis这类连续值输入可以直接在FixedUpdate中使用因为其值在帧间是平滑变化的。3.3 在FixedUpdate中实现稳定移动对于角色控制器或车辆在FixedUpdate中操作Rigidbody是实现稳定移动的关键。通常有两种模式力驱动模式public float moveForce 10f; public float maxSpeed 5f; private Rigidbody _rb; void FixedUpdate() { float horizontal Input.GetAxis(Horizontal); float vertical Input.GetAxis(Vertical); Vector3 force new Vector3(horizontal, 0, vertical) * moveForce; _rb.AddForce(force); // 可选限制最大速度模拟阻力 if (_rb.velocity.magnitude maxSpeed) { _rb.velocity _rb.velocity.normalized * maxSpeed; } }这种方式最物理手感真实有加速过程但需要精细调参。速度直接设置模式public float moveSpeed 5f; private Rigidbody _rb; void FixedUpdate() { float horizontal Input.GetAxis(Horizontal); float vertical Input.GetAxis(Vertical); Vector3 targetVelocity new Vector3(horizontal, 0, vertical) * moveSpeed; // 只改变水平速度保留垂直方向的速度如重力影响 _rb.velocity new Vector3(targetVelocity.x, _rb.velocity.y, targetVelocity.z); }这种方式响应即时易于控制但缺乏惯性感更像“冰面滑动”。可以根据游戏类型选择。实操心得对于平台跳跃游戏跳跃力AddForce(ForceMode.Impulse)必须在FixedUpdate中施加。而在地面移动时混合使用力驱动和速度修正往往能获得更好的手感。例如用AddForce进行加速但当输入方向突然改变或松开按键时可以施加一个反向力或直接干预速度来实现更灵敏的操控。3.4 与Update的通信插值Interpolation与预测由于FixedUpdate的调用与Update/渲染不同步直接使用Rigidbody的位置来更新视觉对象如角色模型、特效位置可能会导致抖动。这就是为什么Rigidbody组件提供了插值Interpolation选项。None不插值。视觉位置直接等于物理引擎最新计算出的位置。在物理更新频率低于渲染频率时会出现卡顿或跳跃。Interpolate插值。基于上一物理帧和当前物理帧的位置在渲染帧之间进行平滑过渡。这是最常用的选项能提供平滑的视觉运动。Extrapolate外推。基于当前物理速度和上一物理帧的位置预测当前渲染帧的位置。在物理计算稳定时很平滑但在物理状态突变如碰撞时可能产生抖动或“过冲”。启用方法在需要进行平滑渲染的Rigidbody组件上将Interpolation设置为Interpolate。工作原理当启用插值后在每一帧Update渲染前Unity会根据该Rigidbody在上一次FixedUpdate和下一次FixedUpdate预测之间的时间比例计算出当前渲染帧应该显示的平滑位置。这完全由引擎在后台处理你无需在代码中做额外工作。注意事项插值会带来轻微的性能开销需要存储多一帧的变换数据并进行计算对于大量存在的刚体如数百个弹珠需权衡使用。对于由玩家直接控制的主角刚体务必开启插值。对于运动轨迹复杂或速度极快的物体如子弹外推模式可能不适用插值模式是更安全的选择。4. 基于FixedUpdate的性能深度优化策略FixedUpdate和物理模拟是性能问题的重灾区。不当的使用会导致CPU峰值飙升、帧时间不稳定。以下是从架构到细节的层层优化策略。4.1 宏观调参时间步长与最大允许步长这是优化物理性能的第一道也是最重要的一道防线。调整Fixed Timestep默认值0.02秒 (50 Hz)。对于PC和主机游戏这通常是个不错的起点。移动端优化考虑提高到0.033秒 (30 Hz) 甚至0.05秒 (20 Hz)。物理模拟频率降低一半计算量也大致减少一半对性能提升显著。对于许多移动游戏来说30Hz的物理更新率在视觉上是可以接受的尤其是当配合运动模糊或插值时。如何调整Edit - Project Settings - Time - Fixed Timestep。测试方法在目标低端设备上运行使用Unity Profiler观察Physics.Processing和Physics.Simulate的时间。如果它们占总帧时间的比例过高例如超过30%且游戏对超高精度物理需求不高尝试增大此值。设置Maximum Allowed Timestep作用限制一帧内用于“追赶”物理模拟的最大时间。防止因单帧卡顿导致后续帧陷入物理计算的死亡螺旋。默认值0.333秒。意味着如果一帧花了0.5秒物理引擎只会用0.333秒的时间来模拟约16.5个固定步长剩下的0.167秒会被丢弃游戏时间会变慢。优化建议对于快节奏动作游戏可以适当调小如0.1秒以牺牲极端卡顿情况下的时间准确性为代价换取更快的恢复速度避免游戏长时间“慢动作”。对于慢节奏游戏可以保持默认或调大。4.2 中观优化减少物理计算负载即使调整了时间步长物理计算本身也可能是瓶颈。我们需要减少物理引擎的工作量。简化碰撞体原则用简单的几何体Box, Sphere, Capsule近似复杂的网格Mesh Collider。方法对于角色使用胶囊体对于车辆使用多个盒子或胶囊体的组合对于复杂静态环境如果不能用简单碰撞体组合再考虑使用Mesh Collider并务必在导入设置或Mesh Collider组件中优化其Cooking Options如禁用Enable Mesh Cleaning、Weld Colocated Vertices以提升烹饪速度。工具使用Physics DebuggerWindow Analysis Physics Debugger可视化查看场景中所有的碰撞体检查是否有不必要的复杂碰撞体。优化物理查询使用非分配Non-Alloc方法Physics.RaycastNonAlloc,Physics.OverlapSphereNonAlloc等。这些方法允许你传入一个预分配的数组作为结果缓冲区避免每次查询都在堆上分配新数组从而减少垃圾回收GC压力。private RaycastHit[] _raycastHits new RaycastHit[10]; // 预分配 void PerformRaycast() { int hitCount Physics.RaycastNonAlloc(transform.position, transform.forward, _raycastHits, 10f); for (int i 0; i hitCount; i) { // 处理 _raycastHits[i] } }批量射线检测如果需要同时进行大量射线检测如AI感知系统不要用循环调用Physics.Raycast。使用RaycastCommand配合C# Job System将计算并行化并卸载到工作线程。优化查询频率不是每一帧都需要进行物理查询。例如AI的感知系统可以每3-5帧更新一次。管理刚体与碰撞体设置合适的刚体类型对于永远不会移动的物体如地形、建筑使用静态碰撞体只有Collider没有Rigidbody。物理引擎会为它们做特殊优化。冻结刚体对于暂时不参与动态模拟的刚体如被击倒后躺在地上的敌人可以将其Rigidbody设置为Sleep状态引擎会自动处理或者直接设置isKinematic true将其从动力学模拟中移除需要时再激活。简化碰撞矩阵在Edit - Project Settings - Physics - Layer Collision Matrix中取消勾选永远不会发生交互的层之间的碰撞。这能显著减少宽相位Broad-phase检测的计算量。4.3 微观优化FixedUpdate内部的代码效率即使物理引擎本身负载不高低效的FixedUpdate脚本代码也会成为瓶颈。减少每帧的GameObject.Find、GetComponent调用这些调用开销较大。在Start或Awake中缓存引用。// 避免在FixedUpdate中这样做 void FixedUpdate() { // 错误示范 GameObject player GameObject.Find(Player); Rigidbody rb player.GetComponentRigidbody(); // ... } // 正确做法 private Rigidbody _playerRb; void Start() { _playerRb GameObject.Find(Player).GetComponentRigidbody(); } void FixedUpdate() { // 使用缓存的 _playerRb }避免在FixedUpdate中进行复杂的数学运算或内存分配例如避免在循环中频繁创建新的Vector3、RaycastHit数组除非使用NonAlloc、或者使用LINQ它会产生GC分配。尽量复用对象和数组。使用合适的ForceModeAddForce有四种模式ForceMode.Force添加一个持续的力质量相关。ForceMode.Impulse添加一个瞬间的冲量质量相关。适用于跳跃、射击。ForceMode.Acceleration添加一个持续的加速度忽略质量。ForceMode.VelocityChange添加一个瞬间的速度变化忽略质量。 根据需求选择。例如想让一个物体无视质量获得一个恒定的加速度用Acceleration更直观且计算稍简。谨慎使用Physics.SyncTransforms如前所述除非必要保持autoSyncTransforms为false。如果需要在Update中基于变换修改进行物理查询手动调用Physics.SyncTransforms()但应将其调用频率降到最低。4.4 架构级优化分帧与异步处理当场景中需要更新大量物理对象时如成千上万的粒子或碎片即使每个对象的计算量很小在同一个FixedUpdate中处理所有对象也会造成CPU尖峰。分帧处理策略 将N个对象分成M批每一帧只更新其中一批。这可以将一个大的CPU峰值平摊到多帧中。public class BatchPhysicsUpdater : MonoBehaviour { public ListRigidbody physicsBodies; private int _currentIndex 0; public int batchSize 10; // 每帧更新多少个 void FixedUpdate() { int endIndex Mathf.Min(_currentIndex batchSize, physicsBodies.Count); for (int i _currentIndex; i endIndex; i) { // 更新 physicsBodies[i] 的物理状态例如施加一个随机的力 // physicsBodies[i].AddForce(Random.insideUnitSphere * 0.1f); } _currentIndex endIndex; if (_currentIndex physicsBodies.Count) { _currentIndex 0; // 循环 } } }这种方法牺牲了一点实时性换来了更平滑的帧时间对于背景或次要的物理效果非常有效。5. 常见问题排查与调试技巧实录即使遵循了最佳实践在复杂项目中依然会遇到各种诡异的物理问题。下面是一些常见问题的排查思路和调试技巧。5.1 问题物体运动抖动或不平滑可能原因及排查未启用刚体插值检查运动物体的Rigidbody组件Interpolation是否设置为Interpolate或Extrapolate。在Update和FixedUpdate中同时修改位置确保对Rigidbody的位置/旋转操作只在FixedUpdate中进行。在Update中操作Transform会与物理引擎的插值计算冲突。Fixed Timestep设置与帧率不匹配如果Fixed Timestep设置得过高如0.1秒而游戏运行在60帧物理更新频率太低会导致视觉上的跳跃感。尝试降低Fixed Timestep或确认渲染帧率是否稳定。性能问题导致FixedUpdate追赶使用Profiler (Window Analysis Profiler) 查看Physics.Processing的时间。如果出现一帧内多次调用FixedUpdate表现为Physics.Simulate的调用柱状图很高说明遇到了追赶问题。需要按照第4.1节的策略优化Fixed Timestep和Maximum Allowed Timestep或者优化物理负载。5.2 问题碰撞检测失败物体穿透可能原因及排查移动方式错误使用transform.Translate或直接设置transform.position来移动带有碰撞体的物体。这是最常见的原因。必须通过Rigidbody来移动物理物体AddForce,velocity,MovePosition。物体速度过快在单个FixedUpdate步长内物体移动的距离超过了其碰撞体的尺寸。物理引擎的连续碰撞检测CCD可能未开启或不足以处理。解决方案为高速运动的刚体如子弹启用Rigidbody上的Collision Detection模式为Continuous或Continuous Dynamic。注意这会增加性能开销。替代方案使用射线检测来模拟高速子弹而不是实际的物理运动。碰撞体层级设置错误检查Layer Collision Matrix确保发生碰撞的两个物体的层是相互勾选的。碰撞体尺寸为0或太小检查碰撞体组件的尺寸确保它不是零或接近零。5.3 问题物理表现不一致不同设备或帧率下行为不同可能原因及排查在Update中使用Time.deltaTime进行物理相关计算这是绝对要避免的。任何影响物理状态的力、速度计算都必须基于Time.fixedDeltaTime并且放在FixedUpdate中。// 错误在Update中使用deltaTime计算力 void Update() { float forceThisFrame someForce * Time.deltaTime; _rb.AddForce(Vector3.forward * forceThisFrame); // 力的大小会随帧率波动 } // 正确在FixedUpdate中使用fixedDeltaTime void FixedUpdate() { float forceThisStep someForce * Time.fixedDeltaTime; // fixedDeltaTime是常量 _rb.AddForce(Vector3.forward * forceThisStep); }使用了ForceMode.Force或ForceMode.Acceleration但计算时未乘Time.fixedDeltaTime这两种模式是“持续的力/加速度”通常需要乘以时间步长来得到该步长内的冲量/速度变化。而Impulse和VelocityChange本身代表瞬间变化不需要再乘。void FixedUpdate() { // 假设想每帧施加一个恒定的力 _rb.AddForce(Vector3.forward * 10f * Time.fixedDeltaTime, ForceMode.Force); // 正确 // _rb.AddForce(Vector3.forward * 10f, ForceMode.Force); // 错误力会过大 }复杂场景下的浮点数精度差异在极端庞大或微小的场景中不同CPU的浮点数计算可能会有细微差异但这种情况较少见。确保物理相关计算使用float类型并检查Rigidbody的Solver Iterations求解器迭代次数是否足够。对于特别复杂或堆叠的刚体可以适当增加此值Project Settings Physics Default Solver Iterations或在单个Rigidbody上设置但会增加计算成本。5.4 调试工具Physics Debugger 与 ProfilerPhysics Debugger(Window Analysis Physics Debugger)可视化碰撞体可以按层、按类型静态/动态/运动学显示碰撞体轮廓颜色编码快速发现碰撞体缺失、重叠或尺寸不合理的问题。查看接触点在播放模式下可以显示实时发生的碰撞接触点和法线对于调试复杂的碰撞交互至关重要。Profiler(Window Analysis Profiler)CPU Usage重点关注Physics.Processing和Physics.Simulate所占用的时间。如果它们占比过高就是性能瓶颈的明确信号。观察FixedUpdate调用频率在Profiler的CPU图表中观察FixedUpdate的调用柱状图。平稳的间隔表示运行良好出现密集的柱状图簇则表示发生了“追赶”需要优化。内存分配在Profiler的CPU模块下查看GC Alloc列。如果在FixedUpdate中看到持续的、大量的内存分配1KB/帧就要检查是否使用了会产生垃圾的物理API如没有使用NonAlloc版本的查询或者在循环中创建了临时对象。5.5 一个综合排查清单表当你遇到物理相关问题时可以按此表顺序排查问题现象优先检查项工具/方法物体抖动、不平滑1. 刚体Interpolation是否开启2. 是否在Update中操作刚体Transform3. Profiler中Physics.Simulate是否出现峰值Physics Debugger, Profiler碰撞穿透、检测不到1. 是否用Transform直接移动刚体2. 物体速度是否过快CCD是否开启3. 碰撞体层级矩阵是否正确4. 碰撞体尺寸是否合理Physics Debugger, 场景视图查看碰撞体不同设备表现不一1. 物理计算是否错误使用了Time.deltaTime2.ForceMode和时间步长乘法是否正确3.Fixed Timestep设置是否合理代码审查在不同帧率下测试游戏卡顿帧时间波动大1. Profiler中Physics.Processing时间是否过高2. 场景中动态刚体数量是否过多3. 是否使用了复杂的Mesh Collider4.Maximum Allowed Timestep是否设置过小Profiler, Stats窗口Draw Calls, Tris, SetPass Calls物理反应“软绵绵”或“过冲”1. 刚体的Mass质量、Drag阻力、Angular Drag角阻力设置是否合理2. 求解器迭代次数(Solver Iterations)是否太低调整刚体参数在Physics Debugger中观察碰撞掌握FixedUpdate的原理、应用与优化是迈向资深Unity开发者的关键一步。它要求开发者不仅会写代码更要理解引擎底层的工作机制并具备跨系统渲染、物理、输入的全局优化视野。从稳定移动的手感到复杂碰撞的精确反馈再到在全平台设备上流畅运行的性能表现都离不开对这条“物理心跳线”的精细把控。在实际项目中我习惯在项目初期就建立物理相关的编码规范比如强制要求所有Rigidbody操作必须在FixedUpdate中并在性能测试阶段将Profiler的Physics模块作为重点监控对象。记住一个稳定的物理帧率往往是游戏整体流畅度的基石。
