我們都知道，unity中，某個遊戲物體上的指令碼初始化順序是先awake，再start，那麼假如現在有這樣一種情況：
有兩個模組，它們都通過awake或者start來初始化，但其中乙個會持有對另乙個模組的引用，更具體一點，比如指令碼1是單例的，指令碼2中持有對指令碼1的引用，而且指令碼2會在初始化的時候將引用賦值為指令碼1的單例。
此時萬一指令碼2的awake和start先執行，那初始化時由於指令碼1還沒有初始化，肯定會出錯，怎麼辦呢？
一種解決方案是在edit->project settings->script execution order下設定指令碼先後次序，可以參考：
但這種方案當互相依賴的指令碼比較多時，會比較繁瑣。
另一種方案是把模組初始化的內容放在乙個單獨的函式裡，模組內部不再使用awake和start。這樣，我們就可以在乙個管理指令碼中分別控制每個模組的初始化順序，不會導致衝突。這是遊戲開發的一種常用思路，雖然不涉及什麼難的技術，但這種思想值得參考。
我們先介紹一種常用的遊戲開發架構思路：
單個業務系統模組分為很多種，比如登入系統業務模組，戰鬥業務模組，副本業務模組等等，各個單獨業務模組負責管理本業務相關的指令碼，比如某些ui視窗下是某個業務模組的介面，每個ui視窗下都會有對應的視窗管理指令碼，這些視窗管理指令碼就是由對應歸屬的單個業務系統模組指令碼來操控的，反映到**上，就是這些業務模組指令碼會持有這些視窗管理指令碼的引用。
而公共服務模組和單個業務系統模組，是統一由管理模組初始化的，因此管理模組中需要持有對這兩個模組的引用，我們可以不使用拖拽的方式來實現，可以將這兩個模組與管理模組一起，放在空物體下，管理模組初始化時用**獲取這兩個模組的引用，並控制這兩個模組的初始化順序。
下面給出實現的**和結果：
gameroot是管理模組，publicsvc是公共服務模組，singlesys是單個業務系統模組，由於業務系統模組中需要用到公共服務模組提供的服務，因此需要先初始化公共服務模組，再初始化業務模組。
再看一下它們在系統中的排布：
它們都放在空物體gameroot下，方便gameroot指令碼取到對服務模組和業務模組的引用。
輸出結果如下：
完結。
Unity方法執行順序
1.awake遊戲物體例項化後並處於啟用狀態呼叫，即使指令碼元件沒有啟用也會被呼叫 2.onenable遊戲物體 指令碼元件啟用時呼叫 會反覆觸發 3.start遊戲物體與指令碼元件處於啟用狀態呼叫 只會呼叫一次，物體關閉在啟用2會呼叫3不呼叫 4.fixedupdate根據設定的幀率執行 主要用於...
linux 開機啟動指令碼順序
linux 開機啟動指令碼順序。第一步 啟動核心 第二步 執行init 配置檔案 etc inittab 第三步 啟動相應的指令碼，並且開啟終端 etc init.d rc.sysinit rc.d 裡面的指令碼 rc.local 第四步 啟動login登入介面 login 第五步 在使用者登入的時...
Unity指令碼 事件指令碼執行順序 生命週期
下圖總結了unity在指令碼的生存期內如何排序和重複事件功能。當整個場景執行時或物體被例項化時呼叫，用於初始化資料，不能用來執行協同程式 awake onenable start，都是遊戲開始執行前就呼叫的方法 當物件變為可用時或啟用狀態被呼叫 僅呼叫一次 每幀呼叫多次，每秒呼叫固定次數，預設60幀...