在 Unity 中更新和固定更新的区别是什么？

From the forum:

Update runs once per frame. FixedUpdate can run once, zero, or several times per frame, depending on how many physics frames per second are set in the time settings, and how fast/slow the framerate is.

Also refer to the answer given by duck in the same forum for a detailed explanation of the difference between the two.

It's for this reason that FixedUpdate should be used when applying forces, torques, or other physics-related functions - because you know it will be executed exactly in sync with the physics engine itself.

Whereas Update() can vary out of step with the physics engine, either faster or slower, depending on how much of a load the graphics are putting on the rendering engine at any given time, which - if used for physics - would give correspondingly variant physical effects!

FixedUpdate is used for being in-step with the physics engine, so anything that needs to be applied to a rigidbody should happen in FixedUpdate. Update, on the other hand, works independantly of the physics engine. This can be benificial if a user's framerate were to drop but you need a certain calculation to keep executing, like if you were updating a chat or voip client, you would want regular old update.

Unity has a nice video about Update vs. FixedUpdate here: Unity - Update vs. FixedUpdate

The site is a great resource for beginner game programmers.

Adding to the other answers, Update is in time with the frame rate, not the physics calculation rate. This means that usually when something changes visuals, you want to have it done in Update, not FixedUpdate. This ensures it's always in time for the very moment at which the frame is rendered. I've encountered a number of cases where I had movement that didn't look smooth because I had it calculated in FixedUpdate.

The only potential cost to having something done in Update that should be done in FixedUpdate is that your physics fidelity could drop, especially if you're hitting low frame rates (but in general that's a separate problem that should be fixed, so it's usually not a good reason to put something in FixedUpdate instead of Update).

If you're looking to control the order in which different scripts do their Updates, FixedUpdate is the wrong tree to bark up; you should be looking at something like EarlyUpdate instead.

I noticed most of the answers here explained clearly what FixedUpdate was good for and and when to use it. However, I didn't see any clear examples for when regular Update should be used; Following is from the official Unity tutorial:

Update()

• Called every frame
• Used for regular updates such as :
  • Moving non-physics objects
  • Simple timers
  • Receiving input (aka keypress etc)
• Update interval call times will vary, ie non-uniformly spaced

FixedUpdate()

• Called every physics step
• FixedUpdate() intervals are consistent, ie uniformly spaced
• Used for regular updates such as adjusting physic (eg. RigidBody) objects

Update(): contains that code which has to be executed with visual rendering

FixedUpdate(): contains that code which has to be in sync with physics interaction

source : https://youtu.be/noXtT_zN-84?t=3057

I found this answer by OncaLupe to be the best explanation:

For others that may not know the difference: Update runs at the same frequency as the game's framerate. If you're getting 100 FPS, then Update() runs 100 times per second. FixedUpdate() runs at a constant 50 FPS to match the physics engine.

There's nothing inherently wrong with only using FixedUpdate, and it is where physics calculations and changes should go since it matches the physics engine. However if you're doing things like manually moving non physics objects around and your game runs at a higher framerate, you may notice the movement stutters since there's frames where nothing moves. Using Update makes sure the movement happens every visual frame.

Also, if you need to use inputs that only trigger when a button is pressed down and not when being held (jumps, single fire weapons, etc), you will likely miss them in FixedUpdate. Things like GetButtonDown/GetButtonUp are only set for one frame of the game when the user presses the button, and go back to false the next frame.

In the end though, it all depends on your game and how you set it up or program it. If only using FixedUpdate works for you, then you're free to stick with it. Just realize that there are some limitations like missing one frame triggers and possible movement stuttering with non-physics movements.

Update is called once per frame for every script that it uses it. Almost anything that needs to be changed or adjusted regularly happens in update. The movement of non-physics objects, simple timers and detection of input are set here. Update is not called on regular timeline. If one frame takes longer to process than next, then the time between the update calls will be different.

FixedUpdate has a few differences:

• It is called on a regular timeline and will have the same time between calls

• FixedUpdate() has the advantage of running in fixed time steps and is helpful for time-dependent but frame rate-independent tasks.

• Right after FixedUpdaet is called, any necessary physics calculations are made. such as, anything that affects the rigidbody, meaning that a physics object, should be executed in FixedUpdate.

• When scripting physics in the FixedUpdate loop, it is good practice to use forces for movement. Any physics or Rigidbody-related code always goes inside the FixedUpdate method, rather than Update or the other MonoBehavior methods

• Checking for inputs in FixedUpdate can sometimes lead to input loss or even double inputs because it doesn't run once per frame. That is why we should be checking for inputs in Update and then applying force or setting the velocity in FixedUpdate.