Cocos Creator源碼解讀之什么是引擎啟動與主循環(huán)

啟動流程 

index.html

對于 Web 平臺 index.html 文件就是絕對的起點。

在默認(rèn)的 index.html 文件中，定義了游戲啟動頁面的布局，并且還有一段立即執(zhí)行的代碼。

這里截取文件中一部分比較關(guān)鍵的代碼：

// 加載引擎腳本
loadScript(debug ? 'cocos2d-js.js' : 'cocos2d-js-min.ec334.js', function () {
    // 是否開啟了物理系統(tǒng)？
    if (CC_PHYSICS_BUILTIN || CC_PHYSICS_CANNON) {
        // 加載物理系統(tǒng)腳本并啟動引擎
        loadScript(debug ? 'physics.js' : 'physics-min.js', window.boot);
    } else {
        // 啟動引擎
        window.boot();
    }
});

上面這段代碼主要用于加載引擎腳本和物理系統(tǒng)腳本，腳本加載完成之后就會調(diào)用 main.js 中定義的 window.boot() 函數(shù)。

代碼壓縮

腳本文件名中帶有 -min 字樣一般代表著這個文件內(nèi)的代碼是被壓縮過的。

壓縮代碼可以節(jié)省代碼文件所占用的空間，加快文件加載速度，減少流量消耗，但同時也讓代碼失去了可閱讀性，不利于調(diào)試。

所以開啟調(diào)試模式后會直接使用未經(jīng)過壓縮的代碼文件，便于開發(fā)調(diào)試和定位錯誤。

main.js 

window.boot()

對于不同平臺 main.js 的內(nèi)容也有些許差異，這里我們忽略差異部分，只關(guān)注其中關(guān)鍵的共同行為。

關(guān)于 main.js 文件的內(nèi)容基本上就是定義了 window.boot() 函數(shù)。

對于非 Web 平臺，會在定義完之后直接就調(diào)用 window.boot() 函數(shù)，所以 main.js 才是他們的起點。

而 window.boot() 函數(shù)內(nèi)部有以下關(guān)鍵行為：

1. 定義     onStart 回調(diào)函數(shù)：主要用于加載啟動場景
2. cc.assetManager.init(...)：初始化 AssetManager
3. cc.assetManager.loadScript(...)：加載 src 目錄下的插件腳本
4. cc.assetManager.loadBundle(...)：加載項目中的 bundle
5. cc.game.run(...)：啟動引擎

這部分的代碼就不貼了，小伙伴們可以看看自己的項目構(gòu)建后的 main.js 文件。 

cc.game

cc.game 對象是 cc.Game 類的一個實例，cc.game 包含了游戲主體信息并負(fù)責(zé)驅(qū)動游戲。

說人話，cc.game 對象就是管理引擎生命周期的模塊，啟動、暫停和重啟等操作都需要用到它。 

run()

cc.game.run() 函數(shù)內(nèi)指定了引擎配置和 onStart 回調(diào)并觸發(fā) cc.game.prepare() 函數(shù)。

run: function (config, onStart) {
    // 指定引擎配置
    this._initConfig(config);
    this.onStart = onStart;
    this.prepare(game.onStart && game.onStart.bind(game));
} 

prepare()

cc.game.prepare() 函數(shù)內(nèi)主要在項目預(yù)覽時快速編譯項目代碼并調(diào)用 _prepareFinished() 函數(shù)。

prepare(cb) {
    // 已經(jīng)準(zhǔn)備過則跳過
    if (this._prepared) {
        if (cb) cb();
        return;
    }
    // 加載預(yù)覽項目代碼
    this._loadPreviewScript(() => {
        this._prepareFinished(cb);
    });
} 

對于快速編譯的細(xì)節(jié)，可以在項目預(yù)覽時打開瀏覽器的開發(fā)者工具，在 Sources 欄中搜索（Ctrl + P） __quick_compile_project__ 即可找到 __quick_compile_project__.js 文件。 

_prepareFinished()

cc.game._prepareFinished() 函數(shù)的作用主要為初始化引擎、設(shè)置幀率計時器和初始化內(nèi)建資源（effect 資源和 material 資源）。

當(dāng)內(nèi)建資源加載完成后就會調(diào)用 cc.game._runMainLoop() 啟動引擎主循環(huán)。

_prepareFinished(cb) {
    // 初始化引擎
    this._initEngine();
    // 設(shè)置幀率計時器
    this._setAnimFrame();
    // 初始化內(nèi)建資源（加載內(nèi)置的 effect 和 material 資源）
    cc.assetManager.builtins.init(() => {
        // 打印引擎版本到控制臺
        console.log('Cocos Creator v' + cc.ENGINE_VERSION);
        this._prepared = true;
        // 啟動 mainLoop
        this._runMainLoop();
        // 發(fā)射 ‘game_inited’ 事件（即引擎已初始化完成）
        this.emit(this.EVENT_GAME_INITED);
        // 調(diào)用 main.js 中定義的 onStart 函數(shù)
        if (cb) cb();
    });
} 

_setAnimFrame()

cc.game._setAnimFrame() 內(nèi)部對不同的游戲幀率做了適配。

另外還對 window.requestAnimationFrame() 接口做了兼容性封裝，用于兼容不同的瀏覽器環(huán)境，具體的我們下面再說。

這里就不貼 _setAnimFrame() 的代碼了，有需要的小伙伴可自行查閱。

_runMainLoop()

cc.game._runMainLoop() 這個函數(shù)的名字取得很簡單直接，攤牌了它就是用來運(yùn)行 mainLoop() 函數(shù)的。

讓我們瞧瞧代碼：

_runMainLoop: function () {
    if (CC_EDITOR) return;
    if (!this._prepared) return;
    // 定義局部變量
    var self = this, callback, config = self.config,
        director = cc.director,
        skip = true, frameRate = config.frameRate;
    // 展示或隱藏性能統(tǒng)計
    debug.setDisplayStats(config.showFPS);
    // 設(shè)置幀回調(diào)
    callback = function (now) {
        if (!self._paused) {
            // 循環(huán)調(diào)用回調(diào)
            self._intervalId = window.requestAnimFrame(callback);
            if (!CC_JSB && !CC_RUNTIME && frameRate === 30) {
                if (skip = !skip) return;
            }
            // 調(diào)用 mainLoop
            director.mainLoop(now);
        }
    };
    // 將在下一幀開始循環(huán)回調(diào)
    self._intervalId = window.requestAnimFrame(callback);
    self._paused = false;
}

通過以上代碼我們可以得知，_runMainLoop() 主要通過 window.requestAnimFrame() 接口來實現(xiàn)循環(huán)調(diào)用 mainLoop() 函數(shù)。 

window.requestAnimFrame()

window.requestAnimFrame() 就是我們上面說到的 _setAnimFrame() 內(nèi)部對于 window.requestAnimationFrame() 的兼容性封裝。

對前端不太熟悉的小伙伴可能會有疑問，window.requestAnimationFrame() 又是啥，是用來干嘛的，又是如何運(yùn)行的？ 

window.requestAnimationFrame()

簡單來說，window.requestAnimationFrame() 用于向瀏覽器請求進(jìn)行一次重繪（repaint），并在重繪之前調(diào)用指定的回調(diào)函數(shù)。

window.requestAnimationFrame() 接收一個回調(diào)作為參數(shù)并返回一個整數(shù)作為唯一標(biāo)識，瀏覽器將會在下一個重繪之前執(zhí)行這個回調(diào)；并且執(zhí)行回調(diào)時會傳入一個參數(shù)，參數(shù)的值與 performance.now() 返回的值相等。

performance.now() 的返回值可以簡單理解為瀏覽器窗口的運(yùn)行時長，即從打開窗口到當(dāng)前時刻的時間差。

MDN 文檔：https://developer.mozilla.org/zh-CN/docs/Web/API/Performance/now

回調(diào)函數(shù)的執(zhí)行次數(shù)通常與瀏覽器屏幕刷新次數(shù)相匹配，也就是說，對于刷新率為 60Hz 的顯示器，瀏覽器會在一秒內(nèi)執(zhí)行 60 次回調(diào)函數(shù)。

對于 window.requestAnimationFrame() 的說明到此為止，如果想要了解更多信息請自行搜索。 

小結(jié)

畫一張圖來對引擎的啟動流程做一個小小的總結(jié)叭~

    

主循環(huán)

經(jīng)歷了一番波折后，終于來到了最期待的引擎主循環(huán)部分，話不多說，我們繼續(xù)！

cc.director

cc.director 對象是導(dǎo)演類 cc.Director 的實例，引擎通主要過 cc.director 對象來管理游戲的邏輯流程。

CCDirector.js：https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/CCDirector.js 

mainLoop()

cc.director.mainLoop() 函數(shù)可能是引擎中最關(guān)鍵的邏輯之一了，包含的內(nèi)容很多也很關(guān)鍵。

現(xiàn)在讓我們進(jìn)入 mainLoop() 函數(shù)內(nèi)部來一探究竟吧！

這里我選擇性剔除掉了函數(shù)中一些的代碼，還搞了點注釋：

mainLoop: function(now) {
    // 計算“全局”增量時間（DeltaTime）
    // 也就是距離上一次調(diào)用 mainLoop 的時間間隔
    this.calculateDeltaTime(now);
    // 游戲沒有暫停則進(jìn)行更新
    if (!this._paused) {
        // 發(fā)射 'director_before_update' 事件
        this.emit(cc.Director.EVENT_BEFORE_UPDATE);
        // 調(diào)用新增的組件（已啟用）的 start 函數(shù)
        this._compScheduler.startPhase();
        // 調(diào)用所有組件（已啟用）的 update 函數(shù)
        this._compScheduler.updatePhase(this._deltaTime);
        // 更新調(diào)度器（cc.Scheduler）
        this._scheduler.update(this._deltaTime);
        // 調(diào)用所有組件（已啟用）的 lateUpdate 函數(shù)
        this._compScheduler.lateUpdatePhase(this._deltaTime);
        // 發(fā)射 'director_after_update' 事件
        this.emit(cc.Director.EVENT_AFTER_UPDATE);
        // 銷毀最近被移除的實體（節(jié)點）
        Obj._deferredDestroy();
    }
    // 發(fā)射 'director_before_draw' 事件
    this.emit(cc.Director.EVENT_BEFORE_DRAW);
    // 渲染游戲場景
    renderer.render(this._scene, this._deltaTime);
    // 發(fā)射 'director_after_draw' 事件
    this.emit(cc.Director.EVENT_AFTER_DRAW);
    // 更新事件管理器的事件監(jiān)聽（cc.eventManager 已被廢棄）
    eventManager.frameUpdateListeners();
    // 累加游戲運(yùn)行的總幀數(shù)
    this._totalFrames++;
}

接下來我們來對主循環(huán)中的關(guān)鍵點一一進(jìn)行分解。

ComponentScheduler

cc.director 對象中的 _compScheduler屬性 是 ComponentScheduler 類的實例。

大多數(shù)小伙伴可能對于 ComponentScheduler 這個類沒有什么印象，我來簡單解釋一下。

將 ComponentScheduler 的名字直譯過來就是“組件調(diào)度器”，從名字上就可以看出，這個類是用來調(diào)度組件的。

說人話，ComponentScheduler 類是用來集中調(diào)度（管理）游戲場景中所有組件（cc.Component）的生命周期的。

文字不夠直觀，看完下面這張圖大概就懂了：

 

startPhase

// 調(diào)用新增的組件（已啟用）的 start 函數(shù)
this._compScheduler.startPhase(); 

組件的 start 回調(diào)函數(shù)會在組件第一次激活前，也就是第一次執(zhí)行 update 之前觸發(fā)。

在組件的一生中 start 回調(diào)只會被觸發(fā)一次，onLoad 和 onEnable 也一樣。

只不過 onLoad 和 onEnable 是由 NodeActivator 類的實例來管理的：

• onLoad 會在節(jié)點激活時就觸發(fā)
• onEnable 會在組件被啟用時觸發(fā)

而 start 則會等到下一次主循環(huán) mainLoop() 時才觸發(fā)。

NodeActivator

NodeActivator 類主要用于啟用和禁用節(jié)點以及身上的組件。

cc.director 對象中就擁有一個實例 _nodeActivator，游戲中所有節(jié)點的啟用和禁用都需要通過它來操作。

像這樣：cc.director._nodeActivator.activateNode(this, value);

updatePhase

// 調(diào)用所有組件（已啟用）的 update 函數(shù)
this._compScheduler.updatePhase(deltaTime);

組件的 update 函數(shù)在每一幀都會被觸發(fā)一次。

lateUpdatePhase

// 調(diào)用所有組件（已啟用）的 lateUpdate 函數(shù)
this._compScheduler.lateUpdatePhase(deltaTime);

組件的 lateUpdate 函數(shù)會在 update 和調(diào)度器 cc.Scheduler 更新之后被觸發(fā)。調(diào)度器的更新內(nèi)容包括緩動、動畫和物理等，這一點下面會展開。

ParticleSystem

BTW，粒子系統(tǒng)組件（cc.ParticleSystem）就是在 lateUpdate 回調(diào)函數(shù)中進(jìn)行更新的。

Tips

請謹(jǐn)慎使用 update 和 lateUpdate 回調(diào)，因為它們每一幀都會被觸發(fā)，如果 update 或 lateUpdate 內(nèi)的邏輯過多，就會使得每一幀的執(zhí)行時間（即幀時間 Frame time）都變長，導(dǎo)致游戲運(yùn)行幀數(shù)降低或出現(xiàn)不穩(wěn)定的情況。

注意這不是不讓你用，該用還得用，只是不要濫用，不要啥玩意都往里邊賽~

Scheduler

cc.director 對象的 _scheduler 屬性為 cc.Scheduler 類的實例。

cc.Scheduler 是負(fù)責(zé)觸發(fā)回調(diào)函數(shù)的類。

你絕對猜不到下面這一行看起來如此平平無奇的代碼執(zhí)行之后會發(fā)生什么。

// 更新調(diào)度器（cc.Scheduler 類實例）
this._scheduler.update(this._deltaTime); 

cc.director.mainLoop() 中使用 _scheduler.update() 函數(shù)來分發(fā) update，在調(diào)度器（cc.director._scheduler）內(nèi)部會根據(jù)優(yōu)先級先后觸發(fā)各個系統(tǒng)模塊和組件計時器的更新。

系統(tǒng)模塊

調(diào)度器的更新會先觸發(fā)以下系統(tǒng)模塊的更新：

• ActionManager
• AnimationManager
• CollisionManager
• PhysicsManager
• Physics3DManager
• InputManager

以上這些模塊都以 cc.director._scheduler.scheduleUpdate() 的方式注冊到調(diào)度器上，因為這些模塊每一幀都需要進(jìn)行更新。

除了 InputManager 以外的模塊的優(yōu)先級都為 cc.Scheduler.PRIORITY_SYSTEM，也就是系統(tǒng)優(yōu)先級，會優(yōu)先被觸發(fā)。

ActionManager

ActionManager 即動作管理器，用于管理游戲中的所有動作，也就是緩動系統(tǒng) Action 和 Tween（其實它們本質(zhì)上是同一種東西）。 

AnimationManager

AnimationManager 即動畫管理器，用于管理游戲中的所有動畫，驅(qū)動節(jié)點上的 Animation 組件播放動畫。 

CollisionManager

CollisionManager 即碰撞組件管理器，用于處理節(jié)點之間的碰撞組件是否產(chǎn)生了碰撞，并調(diào)用相應(yīng)回調(diào)函數(shù)。 

PhysicsManager

PhysicsManager 即物理系統(tǒng)管理器，內(nèi)部以 Box2D 作為 2D 物理引擎，加以封裝并開放部分常用的接口。同時 PhysicsManager 還負(fù)責(zé)管理碰撞信息的分發(fā)。 

Physics3DManager

Physics3DManager 即3D 物理系統(tǒng)管理器，Cocos Creator 中的 3D 物理引擎有 Cannon.js 和 Builtin 可選，Physics3DManager 給它們封裝了統(tǒng)一的常用接口。

InputManager

InputManager 即輸入事件管理器，用于管理所有輸入事件。開發(fā)者主動啟用加速度計（Accelerometer）之后，引擎會定時通過 InputManager 發(fā)送 cc.SystemEvent.EventType.DEVICEMOTION 事件（默認(rèn)間隔為 0.2 秒）。

組件計時器

相信大多數(shù)小伙伴都使用過組件的 schedule() 和 scheduleOnce() 接口，主要用來重復(fù)執(zhí)行或定時執(zhí)行函數(shù)。

實際上，cc.Component 的 schedule() 接口依賴的也是 cc.Scheduler 類，具體使用的也是 cc.director 對象中的 _scheduler 實例。

組件的 schedule() 接口在 cc.director._scheduler.schedule() 接口之外加了一層封裝，以組件自身作為 target，這樣一來組件內(nèi)的定時任務(wù)就與組件生命周期綁定，當(dāng)組件被銷毀時定時任務(wù)也會被移除。

而 scheduleOnce() 接口則是在組件的 schedule() 接口之外又加了一層封裝，固定只會在指定時間后執(zhí)行一次。

setTimeout & setInterval

setTimeout() 和 setInterval() 都是由瀏覽器或 Node.js 這類 runtime 所提供的接口。

• setTimeout() 接口用于設(shè)置一個定時器，該定時器在定時器到期后執(zhí)行一個函數(shù)或指定的一段代碼。
• setInterval() 接口用于重復(fù)調(diào)用一個函數(shù)或執(zhí)行一個代碼段，在每次調(diào)用之間具有固定的時間延遲。

再補(bǔ)充一個小知識：

在瀏覽器中 setTimeout() 和 setInterval() 的最小延時（間隔）是 4ms。

如果是未激活（后臺）的標(biāo)簽頁（tab），最小延時（間隔）則加長到 1000ms。

舉個栗子

假如我在當(dāng)前標(biāo)簽頁設(shè)置了一個每 500ms 輸出一個 log 的定時器，當(dāng)我切換到別的標(biāo)簽頁之后，那么這個定時器就會變成每 1000ms 才輸出一個 log。

像這樣，感興趣的話可以自己去試試：

setInterval(() => {
    console.log(new Date().getTime());
}, 500);
// 模擬輸出
// 標(biāo)簽頁在前臺
// 1604373521000
// 1604373521500
// 1604373522000
// 切換到別的標(biāo)簽頁后
// 1604373523000
// 1604373524000
// 1604373525000  
  

區(qū)別 & 用法

組件的計時器依賴于引擎的 mainLoop() 和組件自身，如果引擎被暫停，那么組件的計時器也會被暫停，如果組件或組件所在的節(jié)點被銷毀了，那么計時器也會失效。

setTimeout() 和 setInterval() 都依賴于當(dāng)前所處的 window 對象，也就是說只要當(dāng)前瀏覽器標(biāo)簽頁不關(guān)閉，setTimeout() 和 setInterval() 都還是會執(zhí)行的。

當(dāng)你需要在組件內(nèi)部定時或重復(fù)執(zhí)行某一函數(shù)或操作某個節(jié)點，那么可以使用組件的計時器。

讓我們想象一個場景：

在當(dāng)前場景中的某個腳本內(nèi)使用 setInterval() 來重復(fù)移動場景中的某個節(jié)點，當(dāng)我們切換場景后會發(fā)生什么？

當(dāng)定時器再次調(diào)用回調(diào)嘗試移動節(jié)點的時候，會無法找到目標(biāo)節(jié)點而報錯，因為節(jié)點已經(jīng)跟著之前的場景一起被銷毀了，而定時器還在繼續(xù)執(zhí)行。

這種情況下使用組件的計時器就不會有這種問題，因為計時器會隨著組件的銷毀而被清除。

而當(dāng)我們需要執(zhí)行一些與游戲場景沒有關(guān)聯(lián)的事情的時候，就可以考慮使用 setTimeout() 或 setInterval()。

當(dāng)然能用組件計時器的話最好還是用組件計時器啦~

小結(jié)

依然還是畫一張圖來小小總結(jié)一下 Scheduler。