关于Unity的一些基础知识点汇总

1.Prefab实例化后，哪些资源是共用的？哪些资源是拷贝的？
共用资源
脚本组件：实例化后的 Prefab 共享脚本组件的代码。若脚本中无状态数据，多个实例对脚本方法的调用会有相同逻辑。比如一个控制物体移动的脚本，多个实例化的 Prefab 都使用该脚本，它们执行的移动逻辑一样。
材质：默认情况下，实例化 Prefab 的材质是共用的。多个实例对材质属性的修改会相互影响。如改变一个实例材质的颜色，其他实例的材质颜色也会改变。
Shader：材质所使用的 Shader 是共用资源。Shader 定义了渲染逻辑，多个实例化的 Prefab 共享同一 Shader，不会为每个实例单独创建。
Animator Controller：如果 Prefab 包含 Animator Controller 来控制动画状态机，实例化后会共用 Animator Controller 资源，因为它定义的动画状态和转换逻辑是共享的。
粒子系统预设（Particle System Preset）：若预制体包含粒子系统，且粒子系统使用了预设，那么所有实例化对象会共用该预设。粒子系统预设包含了粒子发射速率、生命周期、颜色等一系列设置。修改预设会影响到所有实例化对象的粒子系统表现。比如，调整了粒子系统预设中的发射速率，所有实例化对象的粒子发射速度都会改变
拷贝资源
Transform 组件数据：每个实例化的 Prefab 都有独立的 Transform 组件数据，包括位置、旋转和缩放。对一个实例的 Transform 修改不会影响其他实例。
GameObject 实例：实例化会创建新的 GameObject 实例，每个实例在场景中有独立的存在，可单独进行激活、停用或删除等操作，不影响其他实例。
其他组件数据：除脚本组件外，如 Rigidbody、Collider 等组件的属性数据在实例化时会被拷贝。每个实例的这些组件都有独立的属性值，对一个实例的组件属性修改不会影响其他实例。
渲染器组件的部分设置：虽然材质是共用的，但渲染器组件（如 Mesh Renderer、Skinned Mesh Renderer 等）的某些设置是每个实例化对象独立的。例如，Mesh Renderer 的阴影投射（Cast Shadows）和接收阴影（Receive Shadows）设置，每个实例化对象可以单独开启或关闭，而不影响其他实例。这使得在场景中可以灵活控制每个实例化对象的阴影表现。
自定义脚本中的引用类型变量：如果自定义脚本中有引用类型的变量（如自定义的类或结构体），每个实例化对象会有这些引用类型变量的独立拷贝。例如，假设有一个自定义脚本MyDataScript，其中包含一个自定义类MyData的变量，每个实例化对象的MyDataScript中的MyData变量都是独立的，对一个实例化对象中MyData变量的修改不会影响其他实例化对象。

2.线程与协程的区别 

线程和协程是计算机编程中用于实现并发或并行执行的两种不同机制，它们的区别主要体现在以下几个方面：
概念与定义
线程：是操作系统能够进行运算调度的最小单位，它被包含在进程之中，是进程中的实际运作单位，每个线程都有独立的栈空间和程序计数器等。
协程：是一种用户态的轻量级线程，也称为微线程，它是在一个线程内实现的多个任务的协作式执行，没有线程那样的独立栈空间等资源，是基于线程的一种更细粒度的调度单位。
调度方式
线程：由操作系统内核进行调度，调度算法由操作系统决定，用户一般无法直接干预。
协程：由用户程序自己控制调度时机，在合适的时机主动让出执行权，切换到其他协程执行，具有更高的灵活性。
切换开销
线程：线程切换涉及到内核态和用户态的切换，需要保存和恢复线程的上下文信息，开销相对较大。
协程：协程的切换在用户态完成，不需要陷入内核，切换开销较小，切换速度更快。
资源占用
线程：每个线程都需要独立的栈空间等资源，线程数量过多时，会占用大量的内存等系统资源。
协程：多个协程可以共享同一个线程的资源，只需要很少的额外空间来保存协程的上下文信息，资源占用相对较少。
适用场景
线程：适用于需要真正并行执行的任务，如多核 CPU 上的多任务处理，以及需要与操作系统底层交互等场景。
协程：适用于 I/O 密集型任务，如网络请求、文件读写等，能在单线程内高效处理多个异步操作，避免线程切换开销，提高性能。

3.unity中Time.scale=0，会影响哪些生命周期函数？

Update
Update函数会停止调用，因为Update的调用频率取决于Time.deltaTime，而Time.scale = 0时，Time.deltaTime也变为 0，这意味着游戏逻辑的每一帧更新都不再推进，物体的运动、状态更新等依赖Update的操作都会暂停。
FixedUpdate
FixedUpdate通常用于物理相关的更新，虽然它的调用频率不受Time.scale直接影响，固定为每秒调用 50 次，但当Time.scale = 0时，物理系统会停止更新，刚体的运动、碰撞检测等物理相关操作都会暂停，因为物理系统的时间推进也依赖于Time.deltaTime，此时物理的Time.deltaTime也会变为 0。
LateUpdate
LateUpdate同样依赖Time.deltaTime来确定调用时机，Time.scale = 0时，LateUpdate也不会被调用，常用于跟随或插值等操作的LateUpdate中的逻辑也会停止执行。
OnAnimatorMove
对于使用了 Animator 组件的物体，OnAnimatorMove函数用于在动画驱动的移动后进行一些额外的处理，Time.scale = 0时，动画停止播放，Animator 的状态不再更新，OnAnimatorMove也不会被调用。
Time.scale = 0不会影响Awake、Start和OnEnable等函数，这些函数在脚本实例化、对象激活等特定时刻调用，与Time.scale无关。

4.Fixupdate中逻辑执行的时间过长会怎么样？

物理模拟不准确：由于FixedUpdate常用于物理更新，执行时间过长可能导致物理模拟的时间步长不准确，使刚体运动、碰撞等物理效果出现异常，如物体运动不流畅、碰撞检测不准确等。
帧率下降：FixedUpdate执行时间长会占用更多 CPU 时间，可能影响主线程的其他操作，导致游戏整体帧率下降，画面出现卡顿。
同步问题：对于网络多人游戏，可能会导致客户端与服务器之间的物理状态同步出现问题，影响游戏的公平性和稳定性。
物理模拟堆积：Unity 的物理系统以固定的时间间隔进行更新，若FixedUpdate执行时间过长，超过了设定的固定时间步长，物理系统无法按时完成更新，新的物理更新又不断到来，就会导致物理模拟指令在队列中堆积。而物理引擎是按照顺序处理这些指令的，堆积的指令越多，后续处理时就会积累更多的误差，使得物理行为与预期产生较大偏差。
动画与物理不同步：动画系统通常依赖于Update或LateUpdate等函数按照帧率进行更新，而物理系统依赖FixedUpdate。当FixedUpdate执行时间过长，会导致物理系统的更新频率与动画系统的更新频率不一致。例如，动画在正常帧率下播放到角色迈出一步的动作，但由于物理更新延迟，角色的刚体位置没有及时跟上动画的进度，就出现了动作与移动脱节的现象。
影响协程和异步操作：协程和异步操作本质上是在主线程中通过特定的机制来实现暂停和恢复执行的。FixedUpdate执行时间过长会阻塞主线程，导致协程无法及时执行到yield return语句，也就无法按照预期暂停或恢复。例如，一个协程中使用yield return new WaitForSeconds(1)来暂停 1 秒，由于FixedUpdate阻塞了主线程，这个等待时间可能会远远超过 1 秒，从而使协程中的逻辑执行顺序和时间出现混乱。
输入响应延迟：玩家输入的检测和处理通常在每一帧的Update等函数中进行，FixedUpdate执行时间过长占用了主线程大量时间，会导致Update函数不能及时被调用，从而使输入检测和处理被延迟。玩家按下按键后，游戏需要等待FixedUpdate执行完才能处理输入事件，这就造成了操作与反馈之间的明显延迟。

5.一个未激活的Prefab实例化到场景中时，会执行的生命周期函数有？

在Unity2021.3.18中测试，实例化后一个都没有，在激活之后Awake，OnEnable，Start会依次执行。

6. 随机数生成之后，随机数序列是否是固定的？

这取决于随机数生成器的类型。
如果使用的是伪随机数生成器（如常见的编程语言中默认提供的），在给定相同的种子（初始值）时，生成的随机数序列是固定的。
但如果使用的是真随机数生成器（基于物理随机现象，如硬件噪声），每次生成的随机数序列都是不可预测且不固定的。

7.在C#和Unity中随机数是怎样的？

C# 中情况：
System.Random类：如果使用 System.Random 类，默认情况下每次运行程序生成的随机数序列可能不同，因为它通常使用系统时间等不断变化的值作为种子。但如果手动指定相同的种子来初始化 System.Random 对象，那么后续生成的随机数序列就是固定的固定的。
System.Security.Cryptography.RandomNumberGenerator类：该类生成的随机序列是不可预测且不固定的。它依赖于操作系统提供的加密安全随机数生成机制，通常基于物理噪声源（如硬件设备的热噪声等）。

Unity 中情况：
UnityEngine.Random类：UnityEngine.Random使用的 Xorshift128 + 算法也是伪随机数算法。默认情况下，它基于内部维护的状态生成随机数序列，每次运行游戏时初始状态不同，生成的随机序列也就不同。但如果手动重置其内部状态，例如使用Random.InitState(int seed)方法设置种子，那么生成的随机序列会变得固定。