Я збирався написати це як коментар, але в кінцевому підсумку це було досить довго, тому я перетворив це на відповідь.
Поточні відповіді здебільшого вірні, але кілька згаданих речей є оманливими / неправильними.
В цілому, більшість завдань , пов'язаних з грою-ігри будуть йти Update
.
Наприклад, ви не хочете проводити опитування для введення даних FixedUpdate
(не через продуктивність, а тому, що дзвінки просто не працюватимуть правильно). AI падає в одному човні.
Постійно оновлювана фізика - це єдине завдання, пов'язане з геймплеєм, для якого FixedUpdate
слід використовувати. Безперервні / раз у раз заклики до речей, як-от Physics.Raycast
або навіть Rigidbody.AddForce
належать до них Update
. Моя згадка про Rigidbody.AddForce
це, здавалося б, суперечить тому, що може мати на увазі документація, але ключовим є безперервний та неперервний.
Однією з величезних причин, чому належить лише безперервна фізика, FixedUpdate
є фактичний характер FixedUpdate
. В інших відповідях згадується, як FixedUpdate викликається у фіксованому interval, but that's slightly misleading. In reality, a script is passed a time in Time.deltaTime
/ Time.fixedDeltaTime
*, що не відповідає безпосередньо фактичному часу між викликами, а навпаки, імітованому часу між викликами.
(* Time.deltaTime
і Time.fixedDeltaTime
є тим самим значенням при FixedUpdate
виклику в [Unity здатний визначити, чи відбувся поточний виклик Time.deltaTime
під час FixedUpdate
і повертається Time.fixedDeltaTime
])
Звичайно, той самий спосіб Update
не може бути викликаний постійно через різну продуктивність, а також не може FixedUpdate
. Ключова відмінність полягає в тому, що кожен кадр, якщо FixedUpdate
його не викликають достатньо часто, щоб перерахувати правильний інтервал між дзвінками, він називається багаторазово (або не називається середній занадто високий). Це те, на що посилаються документи в Order Execution, говорячи про те, що FixedUpdate можна викликати кілька разів кадром:
... FixedUpdate: FixedUpdate часто називають частіше, ніж Оновити. Його можна назвати кілька разів на кадр, якщо частота кадрів низька і взагалі не може бути викликана між кадрами, якщо частота кадрів висока ...
Це не впливає на фізику через характер решти наказу про виконання та двигун, але майже все, що ви введете, FixedUpdate
буде зачеплене, і це спричинить проблеми.
Наприклад, якщо помістити обробку AI всередину FixedUpdate
, немає причин вважати, що AI не буде пропускати оновлення для декількох кадрів поспіль. Крім того, кожен раз, коли `FixedUpdate відстає, ваш AI буде оновлюватися кілька разів в одному кадрі, перш ніж оброблятися такі речі, як фізика та введення / переміщення гравця, що, як мінімум, є витратою на обробку, але також має велику ймовірність спричинити важкість відслідковувати помилки та хаотичну поведінку.
Якщо вам потрібно щось робити через фіксований інтервал, використовуйте інші методи Unity, такі як Coroutines
і InvokeRepeating
.
І невелика примітка про те, Time.deltaTime
і коли його використовувати:
Найпростіший спосіб описати ефект Time.deltaTime - це зміна числа від одиниці на кадр до одиниці в секунду . Наприклад, якщо у вас є сценарій з чимось на зразок transform.Translate(Vector3.up * 5)
оновлення, ви по суті рухаєте перетворення зі швидкістю 5 метрів на кадр . Це означає, що якщо частота кадрів низька, рух відбувається повільніше, а якщо частота кадрів висока, рух відбувається швидше.
Якщо взяти той самий код і змінити його transform.Translate(Vector3.up * 5 * Time.deltaTime)
, об’єкт переміщується зі швидкістю 5 метрів в секунду . Це означає, що незалежно від частоти кадрів, об'єкт рухатиметься на 5 метрів щосекунди (але чим повільніше частота кадрів, тим швидше буде з’являтися перемичка руху об'єкта, оскільки він все одно рухає однакову кількість кожні X секунд)
Взагалі, ви хочете, щоб ваш рух був за секунду. Таким чином, незалежно від того, з якою швидкістю рухається комп'ютер, ваша фізика / рух буде вести себе так само, і у вас не буде дивних помилок, що спливають на повільних пристроях.
І в цьому немає сенсу використовувати FixedUpdate
. Через те, що я згадував вище, ви отримуватимете однакове значення кожного виклику (значення фіксованого часу оновлення), і воно нічого не призведе до ваших значень. Рух / фізика, визначена в FixedUpdate
, вже буде в одиницях в секунду, тому вам це не потрібно.