1.Prefab實(shí)例化后，哪些資源是共用的？哪些資源是拷貝的？
共用資源
腳本組件：實(shí)例化后的 Prefab 共享腳本組件的代碼。若腳本中無狀態(tài)數(shù)據(jù)，多個(gè)實(shí)例對(duì)腳本方法的調(diào)用會(huì)有相同邏輯。比如一個(gè)控制物體移動(dòng)的腳本，多個(gè)實(shí)例化的 Prefab 都使用該腳本，它們執(zhí)行的移動(dòng)邏輯一樣。
材質(zhì)：默認(rèn)情況下，實(shí)例化 Prefab 的材質(zhì)是共用的。多個(gè)實(shí)例對(duì)材質(zhì)屬性的修改會(huì)相互影響。如改變一個(gè)實(shí)例材質(zhì)的顏色，其他實(shí)例的材質(zhì)顏色也會(huì)改變。
Shader：材質(zhì)所使用的 Shader 是共用資源。Shader 定義了渲染邏輯，多個(gè)實(shí)例化的 Prefab 共享同一 Shader，不會(huì)為每個(gè)實(shí)例單獨(dú)創(chuàng)建。
Animator Controller：如果 Prefab 包含 Animator Controller 來控制動(dòng)畫狀態(tài)機(jī)，實(shí)例化后會(huì)共用 Animator Controller 資源，因?yàn)樗x的動(dòng)畫狀態(tài)和轉(zhuǎn)換邏輯是共享的。
粒子系統(tǒng)預(yù)設(shè)（Particle System Preset）：若預(yù)制體包含粒子系統(tǒng)，且粒子系統(tǒng)使用了預(yù)設(shè)，那么所有實(shí)例化對(duì)象會(huì)共用該預(yù)設(shè)。粒子系統(tǒng)預(yù)設(shè)包含了粒子發(fā)射速率、生命周期、顏色等一系列設(shè)置。修改預(yù)設(shè)會(huì)影響到所有實(shí)例化對(duì)象的粒子系統(tǒng)表現(xiàn)。比如，調(diào)整了粒子系統(tǒng)預(yù)設(shè)中的發(fā)射速率，所有實(shí)例化對(duì)象的粒子發(fā)射速度都會(huì)改變
拷貝資源
Transform 組件數(shù)據(jù)：每個(gè)實(shí)例化的 Prefab 都有獨(dú)立的 Transform 組件數(shù)據(jù)，包括位置、旋轉(zhuǎn)和縮放。對(duì)一個(gè)實(shí)例的 Transform 修改不會(huì)影響其他實(shí)例。
GameObject 實(shí)例：實(shí)例化會(huì)創(chuàng)建新的 GameObject 實(shí)例，每個(gè)實(shí)例在場景中有獨(dú)立的存在，可單獨(dú)進(jìn)行激活、停用或刪除等操作，不影響其他實(shí)例。
其他組件數(shù)據(jù)：除腳本組件外，如 Rigidbody、Collider 等組件的屬性數(shù)據(jù)在實(shí)例化時(shí)會(huì)被拷貝。每個(gè)實(shí)例的這些組件都有獨(dú)立的屬性值，對(duì)一個(gè)實(shí)例的組件屬性修改不會(huì)影響其他實(shí)例。
渲染器組件的部分設(shè)置：雖然材質(zhì)是共用的，但渲染器組件（如 Mesh Renderer、Skinned Mesh Renderer 等）的某些設(shè)置是每個(gè)實(shí)例化對(duì)象獨(dú)立的。例如，Mesh Renderer 的陰影投射（Cast Shadows）和接收陰影（Receive Shadows）設(shè)置，每個(gè)實(shí)例化對(duì)象可以單獨(dú)開啟或關(guān)閉，而不影響其他實(shí)例。這使得在場景中可以靈活控制每個(gè)實(shí)例化對(duì)象的陰影表現(xiàn)。
自定義腳本中的引用類型變量：如果自定義腳本中有引用類型的變量（如自定義的類或結(jié)構(gòu)體），每個(gè)實(shí)例化對(duì)象會(huì)有這些引用類型變量的獨(dú)立拷貝。例如，假設(shè)有一個(gè)自定義腳本MyDataScript，其中包含一個(gè)自定義類MyData的變量，每個(gè)實(shí)例化對(duì)象的MyDataScript中的MyData變量都是獨(dú)立的，對(duì)一個(gè)實(shí)例化對(duì)象中MyData變量的修改不會(huì)影響其他實(shí)例化對(duì)象。

2.線程與協(xié)程的區(qū)別?

線程和協(xié)程是計(jì)算機(jī)編程中用于實(shí)現(xiàn)并發(fā)或并行執(zhí)行的兩種不同機(jī)制，它們的區(qū)別主要體現(xiàn)在以下幾個(gè)方面：
概念與定義
線程：是操作系統(tǒng)能夠進(jìn)行運(yùn)算調(diào)度的最小單位，它被包含在進(jìn)程之中，是進(jìn)程中的實(shí)際運(yùn)作單位，每個(gè)線程都有獨(dú)立的?？臻g和程序計(jì)數(shù)器等。
協(xié)程：是一種用戶態(tài)的輕量級(jí)線程，也稱為微線程，它是在一個(gè)線程內(nèi)實(shí)現(xiàn)的多個(gè)任務(wù)的協(xié)作式執(zhí)行，沒有線程那樣的獨(dú)立?？臻g等資源，是基于線程的一種更細(xì)粒度的調(diào)度單位。
調(diào)度方式
線程：由操作系統(tǒng)內(nèi)核進(jìn)行調(diào)度，調(diào)度算法由操作系統(tǒng)決定，用戶一般無法直接干預(yù)。
協(xié)程：由用戶程序自己控制調(diào)度時(shí)機(jī)，在合適的時(shí)機(jī)主動(dòng)讓出執(zhí)行權(quán)，切換到其他協(xié)程執(zhí)行，具有更高的靈活性。
切換開銷
線程：線程切換涉及到內(nèi)核態(tài)和用戶態(tài)的切換，需要保存和恢復(fù)線程的上下文信息，開銷相對(duì)較大。
協(xié)程：協(xié)程的切換在用戶態(tài)完成，不需要陷入內(nèi)核，切換開銷較小，切換速度更快。
資源占用
線程：每個(gè)線程都需要獨(dú)立的?？臻g等資源，線程數(shù)量過多時(shí)，會(huì)占用大量的內(nèi)存等系統(tǒng)資源。
協(xié)程：多個(gè)協(xié)程可以共享同一個(gè)線程的資源，只需要很少的額外空間來保存協(xié)程的上下文信息，資源占用相對(duì)較少。
適用場景
線程：適用于需要真正并行執(zhí)行的任務(wù)，如多核 CPU 上的多任務(wù)處理，以及需要與操作系統(tǒng)底層交互等場景。
協(xié)程：適用于 I/O 密集型任務(wù)，如網(wǎng)絡(luò)請(qǐng)求、文件讀寫等，能在單線程內(nèi)高效處理多個(gè)異步操作，避免線程切換開銷，提高性能。

3.unity中Time.scale=0，會(huì)影響哪些生命周期函數(shù)？

Update
Update函數(shù)會(huì)停止調(diào)用，因?yàn)閁pdate的調(diào)用頻率取決于Time.deltaTime，而Time.scale = 0時(shí)，Time.deltaTime也變?yōu)?0，這意味著游戲邏輯的每一幀更新都不再推進(jìn)，物體的運(yùn)動(dòng)、狀態(tài)更新等依賴Update的操作都會(huì)暫停。
FixedUpdate
FixedUpdate通常用于物理相關(guān)的更新，雖然它的調(diào)用頻率不受Time.scale直接影響，固定為每秒調(diào)用 50 次，但當(dāng)Time.scale = 0時(shí)，物理系統(tǒng)會(huì)停止更新，剛體的運(yùn)動(dòng)、碰撞檢測(cè)等物理相關(guān)操作都會(huì)暫停，因?yàn)槲锢硐到y(tǒng)的時(shí)間推進(jìn)也依賴于Time.deltaTime，此時(shí)物理的Time.deltaTime也會(huì)變?yōu)?0。
LateUpdate
LateUpdate同樣依賴Time.deltaTime來確定調(diào)用時(shí)機(jī)，Time.scale = 0時(shí)，LateUpdate也不會(huì)被調(diào)用，常用于跟隨或插值等操作的LateUpdate中的邏輯也會(huì)停止執(zhí)行。
OnAnimatorMove
對(duì)于使用了 Animator 組件的物體，OnAnimatorMove函數(shù)用于在動(dòng)畫驅(qū)動(dòng)的移動(dòng)后進(jìn)行一些額外的處理，Time.scale = 0時(shí)，動(dòng)畫停止播放，Animator 的狀態(tài)不再更新，OnAnimatorMove也不會(huì)被調(diào)用。
Time.scale = 0不會(huì)影響Awake、Start和OnEnable等函數(shù)，這些函數(shù)在腳本實(shí)例化、對(duì)象激活等特定時(shí)刻調(diào)用，與Time.scale無關(guān)。

4.Fixupdate中邏輯執(zhí)行的時(shí)間過長會(huì)怎么樣？

物理模擬不準(zhǔn)確：由于FixedUpdate常用于物理更新，執(zhí)行時(shí)間過長可能導(dǎo)致物理模擬的時(shí)間步長不準(zhǔn)確，使剛體運(yùn)動(dòng)、碰撞等物理效果出現(xiàn)異常，如物體運(yùn)動(dòng)不流暢、碰撞檢測(cè)不準(zhǔn)確等。
幀率下降：FixedUpdate執(zhí)行時(shí)間長會(huì)占用更多 CPU 時(shí)間，可能影響主線程的其他操作，導(dǎo)致游戲整體幀率下降，畫面出現(xiàn)卡頓。
同步問題：對(duì)于網(wǎng)絡(luò)多人游戲，可能會(huì)導(dǎo)致客戶端與服務(wù)器之間的物理狀態(tài)同步出現(xiàn)問題，影響游戲的公平性和穩(wěn)定性。
物理模擬堆積：Unity 的物理系統(tǒng)以固定的時(shí)間間隔進(jìn)行更新，若FixedUpdate執(zhí)行時(shí)間過長，超過了設(shè)定的固定時(shí)間步長，物理系統(tǒng)無法按時(shí)完成更新，新的物理更新又不斷到來，就會(huì)導(dǎo)致物理模擬指令在隊(duì)列中堆積。而物理引擎是按照順序處理這些指令的，堆積的指令越多，后續(xù)處理時(shí)就會(huì)積累更多的誤差，使得物理行為與預(yù)期產(chǎn)生較大偏差。
動(dòng)畫與物理不同步：動(dòng)畫系統(tǒng)通常依賴于Update或LateUpdate等函數(shù)按照幀率進(jìn)行更新，而物理系統(tǒng)依賴FixedUpdate。當(dāng)FixedUpdate執(zhí)行時(shí)間過長，會(huì)導(dǎo)致物理系統(tǒng)的更新頻率與動(dòng)畫系統(tǒng)的更新頻率不一致。例如，動(dòng)畫在正常幀率下播放到角色邁出一步的動(dòng)作，但由于物理更新延遲，角色的剛體位置沒有及時(shí)跟上動(dòng)畫的進(jìn)度，就出現(xiàn)了動(dòng)作與移動(dòng)脫節(jié)的現(xiàn)象。
影響協(xié)程和異步操作：協(xié)程和異步操作本質(zhì)上是在主線程中通過特定的機(jī)制來實(shí)現(xiàn)暫停和恢復(fù)執(zhí)行的。FixedUpdate執(zhí)行時(shí)間過長會(huì)阻塞主線程，導(dǎo)致協(xié)程無法及時(shí)執(zhí)行到y(tǒng)ield return語句，也就無法按照預(yù)期暫?；蚧謴?fù)。例如，一個(gè)協(xié)程中使用yield return new WaitForSeconds(1)來暫停 1 秒，由于FixedUpdate阻塞了主線程，這個(gè)等待時(shí)間可能會(huì)遠(yuǎn)遠(yuǎn)超過 1 秒，從而使協(xié)程中的邏輯執(zhí)行順序和時(shí)間出現(xiàn)混亂。
輸入響應(yīng)延遲：玩家輸入的檢測(cè)和處理通常在每一幀的Update等函數(shù)中進(jìn)行，FixedUpdate執(zhí)行時(shí)間過長占用了主線程大量時(shí)間，會(huì)導(dǎo)致Update函數(shù)不能及時(shí)被調(diào)用，從而使輸入檢測(cè)和處理被延遲。玩家按下按鍵后，游戲需要等待FixedUpdate執(zhí)行完才能處理輸入事件，這就造成了操作與反饋之間的明顯延遲。

5.一個(gè)未激活的Prefab實(shí)例化到場景中時(shí)，會(huì)執(zhí)行的生命周期函數(shù)有？

在Unity2021.3.18中測(cè)試，實(shí)例化后一個(gè)都沒有，在激活之后Awake，OnEnable，Start會(huì)依次執(zhí)行。

6.?隨機(jī)數(shù)生成之后，隨機(jī)數(shù)序列是否是固定的？

這取決于隨機(jī)數(shù)生成器的類型。
如果使用的是偽隨機(jī)數(shù)生成器（如常見的編程語言中默認(rèn)提供的），在給定相同的種子（初始值）時(shí)，生成的隨機(jī)數(shù)序列是固定的。
但如果使用的是真隨機(jī)數(shù)生成器（基于物理隨機(jī)現(xiàn)象，如硬件噪聲），每次生成的隨機(jī)數(shù)序列都是不可預(yù)測(cè)且不固定的。

7.在C#和Unity中隨機(jī)數(shù)是怎樣的？

C# 中情況：
System.Random類：如果使用 System.Random 類，默認(rèn)情況下每次運(yùn)行程序生成的隨機(jī)數(shù)序列可能不同，因?yàn)樗ǔＪ褂孟到y(tǒng)時(shí)間等不斷變化的值作為種子。但如果手動(dòng)指定相同的種子來初始化 System.Random 對(duì)象，那么后續(xù)生成的隨機(jī)數(shù)序列就是固定的固定的。
System.Security.Cryptography.RandomNumberGenerator類：該類生成的隨機(jī)序列是不可預(yù)測(cè)且不固定的。它依賴于操作系統(tǒng)提供的加密安全隨機(jī)數(shù)生成機(jī)制，通?；谖锢碓肼曉?#xff08;如硬件設(shè)備的熱噪聲等）。

Unity 中情況：
UnityEngine.Random類：UnityEngine.Random使用的 Xorshift128 + 算法也是偽隨機(jī)數(shù)算法。默認(rèn)情況下，它基于內(nèi)部維護(hù)的狀態(tài)生成隨機(jī)數(shù)序列，每次運(yùn)行游戲時(shí)初始狀態(tài)不同，生成的隨機(jī)序列也就不同。但如果手動(dòng)重置其內(nèi)部狀態(tài)，例如使用Random.InitState(int seed)方法設(shè)置種子，那么生成的隨機(jī)序列會(huì)變得固定。