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

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

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

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

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

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

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

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

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

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

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

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

C# 中情況：
System.Random類：如果使用 System.Random 類，默認情況下每次運行程序生成的隨機數(shù)序列可能不同，因為它通常使用系統(tǒng)時間等不斷變化的值作為種子。但如果手動指定相同的種子來初始化 System.Random 對象，那么后續(xù)生成的隨機數(shù)序列就是固定的固定的。
System.Security.Cryptography.RandomNumberGenerator類：該類生成的隨機序列是不可預(yù)測且不固定的。它依賴于操作系統(tǒng)提供的加密安全隨機數(shù)生成機制，通常基于物理噪聲源（如硬件設(shè)備的熱噪聲等）。

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