在今年的 Unite 大會(huì)上，騰訊天美技術(shù)專家田亞濤和 Unity 中國的軟件工程師司天語為大家?guī)砹恕逗辖饛楊^：覺醒》項(xiàng)目的客戶端與服務(wù)端一體化方案，其中包括 DS 專用服務(wù)器進(jìn)程彈性啟動(dòng)、多房間管理及高性能連接能力等。

田亞濤：大家好，我是來自天美 J1 工作室的田亞濤。首先感謝團(tuán)結(jié)引擎團(tuán)隊(duì)對(duì)我們技術(shù)方案的認(rèn)可，也非常高興能在此與大家交流我們的實(shí)踐經(jīng)驗(yàn)。

我自 2014 年加入騰訊以來，先后完整參與了《魂斗羅：歸來》與《合金彈頭：覺醒》的研發(fā)工作，長期專注于 GamePlay 體系、實(shí)時(shí)聯(lián)機(jī)同步以及 DS（Dedicated Server）架構(gòu)相關(guān)的研發(fā)與優(yōu)化。《合金彈頭：覺醒》作為一款 2023 年上線的橫版射擊手游，目前已在國內(nèi)與多個(gè)海外地區(qū)穩(wěn)定運(yùn)營。

本次分享將重點(diǎn)介紹兩個(gè)方向：網(wǎng)絡(luò)同步框架以及基于 Unity 的 DS 引擎架構(gòu)優(yōu)化。在《魂斗羅：歸來》時(shí)期，我們探索并沉淀了一套基于 Unity 引擎的前后端一體化技術(shù)體系，而在《合金彈頭：覺醒》中，我們在此基礎(chǔ)上進(jìn)一步迭代，對(duì)多項(xiàng)關(guān)鍵技術(shù)進(jìn)行了系統(tǒng)化打磨與演進(jìn)。

公平精準(zhǔn)的網(wǎng)絡(luò)同步框架

對(duì)于《合金彈頭：覺醒》，我之所以在前面特別強(qiáng)調(diào)橫版射擊，是因?yàn)榕c第一人稱或第三人稱射擊不同，橫版射擊的子彈飛行路徑和命中過程對(duì)玩家是完全可見的，命中是否準(zhǔn)確非常直觀。因此，只要畫面表現(xiàn)與最終傷害結(jié)果出現(xiàn)任何不一致，玩家都會(huì)立即察覺。在第一人稱或第三人稱射擊中，受擊反饋多以閃紅等效果呈現(xiàn)，彈道細(xì)節(jié)并不會(huì)完全暴露，所以玩家對(duì)命中精度的敏感度沒有這么高；但在橫版射擊中，這種差異被無限放大。

也正因?yàn)槿绱?，早期常用的“攻擊者?yōu)先、服務(wù)器權(quán)威”機(jī)制在《合金彈頭：覺醒》中難以直接落地，會(huì)出現(xiàn)“看似沒有被擊中卻掉血”或“明明命中卻沒有傷害”的情況，讓玩家誤以為是外掛或者同步異常。在研發(fā)的整個(gè)過程中，我們在聯(lián)機(jī)相關(guān)（包括 DS）的部分投入了大量時(shí)間，希望在網(wǎng)絡(luò)環(huán)境不可控的前提下，盡可能在“實(shí)時(shí)性”和“一致性”之間找到平衡，讓玩家看到的畫面與游戲真實(shí)的判定盡可能一致，也就是實(shí)現(xiàn)我們一直追求的“所見即所得”。

要解決“同步”問題，首先必須具備一套可靠且高性能的網(wǎng)絡(luò)基礎(chǔ)設(shè)施，這是整個(gè)聯(lián)機(jī)技術(shù)的第一層能力。我們需要一個(gè)高效的網(wǎng)絡(luò)中間件，它的核心職責(zé)是承載數(shù)據(jù)傳輸，既要支持可靠的 UDP 通道，也要支持非可靠的 UDP 通道，以滿足不同類型同步數(shù)據(jù)對(duì)實(shí)時(shí)性和可靠性的要求。在此基礎(chǔ)上，我們在聯(lián)機(jī)框架層提供了 RPC 與狀態(tài)同步兩套能力，使上層邏輯能夠在統(tǒng)一的通信抽象下完成指令發(fā)送、狀態(tài)更新和關(guān)鍵事件傳遞，為后續(xù)所有同步機(jī)制提供一致而可靠的通信支持。

對(duì)于《合金彈頭：覺醒》這類高實(shí)時(shí)性的同步游戲而言，每秒 30 次的同步頻率對(duì)帶寬要求非常高。在帶寬優(yōu)化上，除了常規(guī)處理，我們也針對(duì)同步內(nèi)容本身做了細(xì)致打磨，包括數(shù)據(jù)類型定制、浮點(diǎn)精度控制以及差異化更新等。同時(shí)，在策略層面，我們結(jié)合對(duì)象池與緩沖機(jī)制，并在 MTU 自適應(yīng)、合包和批量發(fā)送等方面進(jìn)行了優(yōu)化，以盡量降低同步成本并提高傳輸效率。

在帶寬優(yōu)化之后，我們進(jìn)一步處理流量優(yōu)化。在壓縮和增量同步之外，我們希望將整體流量控制在可接受的量級(jí)上。為此，除了歷史記錄緩存，我們也結(jié)合序列號(hào)機(jī)制，并基于客戶端與網(wǎng)絡(luò)實(shí)際情況做了一些定制化策略，使整體流量的增長趨勢更可控，也更符合我們的預(yù)期。

游戲中也大量使用了輸入緩存和命令隊(duì)列，這類邏輯由于觸發(fā)頻率極高，對(duì) GC 的敏感度非常強(qiáng)。如果在這些高頻路徑上出現(xiàn)額外分配，就會(huì)加速觸發(fā) GC，從而導(dǎo)致主線程暫停，直接影響實(shí)時(shí)聯(lián)機(jī)體驗(yàn)。為此，我們針對(duì)這些模塊進(jìn)行了優(yōu)化，將無謂分配盡量壓縮甚至消除，以在同步過程中盡可能減少 GC 對(duì)客戶端流暢度的影響。

有了前面的優(yōu)化，所有數(shù)據(jù)與策略本身也需要被有效監(jiān)控。因此，我們在研發(fā)階段和外網(wǎng)環(huán)境中都建立了一套完整的監(jiān)控體系，用來確保網(wǎng)絡(luò)質(zhì)量與實(shí)際體驗(yàn)始終符合預(yù)期。同時(shí)，這些監(jiān)控結(jié)果也為后續(xù)的動(dòng)態(tài)調(diào)整提供了可靠的數(shù)據(jù)依據(jù)，使我們能夠更及時(shí)地評(píng)估網(wǎng)絡(luò)表現(xiàn)并進(jìn)行針對(duì)性優(yōu)化。

在此之外，我們還設(shè)計(jì)了自適應(yīng)網(wǎng)絡(luò)能力，會(huì)根據(jù)前面提到的策略與實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)，動(dòng)態(tài)選擇更適合當(dāng)前網(wǎng)絡(luò)狀況的同步方案。無論是在影子跟隨還是航位推測等模式下，系統(tǒng)都會(huì)優(yōu)先保證玩家在不同網(wǎng)絡(luò)質(zhì)量下都能獲得盡可能平滑的體驗(yàn)。

講完網(wǎng)絡(luò)層，我們再看同步框架層面。項(xiàng)目在立項(xiàng)階段首先完成了邏輯和表現(xiàn)的分離，這不是傳統(tǒng)的 UI MVC，而是將一個(gè) Game Object 拆分為邏輯體和表現(xiàn)體：邏輯體用于處理追幀、各種同步拉扯等核心邏輯，而表現(xiàn)體在動(dòng)畫、特效等層面保留更高的平滑性和表現(xiàn)靈活度?；谶@樣統(tǒng)一的邏輯層，我們在同步模式上采用了幀同步與狀態(tài)同步的融合方案，并結(jié)合早期《魂斗羅：歸來》的經(jīng)驗(yàn)以及單機(jī)、聯(lián)機(jī)都在 Unity 上統(tǒng)一研發(fā)的優(yōu)勢，使整體同步結(jié)構(gòu)更清晰、更一致。在此基礎(chǔ)上，我們從對(duì)時(shí)模式轉(zhuǎn)向多端對(duì)幀，讓所有端共享一致的幀號(hào)，使后續(xù)的同步行為與策略調(diào)整都能以統(tǒng)一幀號(hào)為依據(jù)。

接下來，看一下角色同步。對(duì)于這樣一款高實(shí)時(shí)性的同步游戲而言，手感始終是第一優(yōu)先級(jí)，《合金彈頭：覺醒》也采用了客戶端先行的方式。這里的 1P 指本地玩家自身；2P 指服務(wù)器或 DS；3P 則是我所看到的其他玩家?；玖鞒淌潜镜叵葓?zhí)行移動(dòng)，同時(shí)同步地向服務(wù)器發(fā)送移動(dòng)指令；服務(wù)器在收到后會(huì)進(jìn)行校驗(yàn)，如果校驗(yàn)不通過，會(huì)下發(fā)糾正并觸發(fā)相應(yīng)的拉扯。對(duì)于 3P 來說，表現(xiàn)更多是基于服務(wù)器下發(fā)的緩存數(shù)據(jù)，再通過平滑插值來重建對(duì)方的移動(dòng)軌跡。但由于是橫版射擊，3P 的畫面本質(zhì)上看到的仍然是一定程度的歷史位置，因此我們也會(huì)做一定程度的預(yù)測補(bǔ)償，讓對(duì)方角色的表現(xiàn)盡量接近實(shí)時(shí)。

前面提到有預(yù)測就一定會(huì)有預(yù)測失敗的情況，那失敗該怎么處理呢？如果只是簡單地把本地移動(dòng)包發(fā)給 DS，由 DS 檢測到不一致后直接把角色位置拉回到服務(wù)器認(rèn)為的正確位置，那在玩家這邊就會(huì)出現(xiàn)很強(qiáng)的“瞬間被拽回去”的感覺：前一刻一系列操作都很流暢，下一刻因?yàn)槭盏降氖且粠酝淼姆?wù)器確認(rèn)（相對(duì)本地來說是歷史狀態(tài)），整個(gè)人突然被拉回原位置，體驗(yàn)會(huì)非常割裂。我們的做法是先回滾到出錯(cuò)時(shí)刻對(duì)應(yīng)的狀態(tài)，再基于那一刻之后的輸入記錄做一次前滾重放，讓角色按正確的軌跡重新跑一遍，使得在玩家視角下動(dòng)作依然連貫。比如說，角色原本在地面奔跑，隨后觸發(fā)一次跳躍，如果 DS 發(fā)現(xiàn)其中存在偏差并做了輕微糾正，本地會(huì)先回到糾正后的狀態(tài)，再重新模擬奔跑到起跳的過程，最終在畫面上仍然看到的是出現(xiàn)在正確位置上的那次跳躍，而不會(huì)出現(xiàn)突兀的拉扯感。

接下來是命中校驗(yàn)。在開始之前，先對(duì)《合金彈頭：覺醒》中的子彈做一個(gè)簡單介紹，共分為三類：第一類是 Hit-Scan（快速子彈）；第二類是 Projectile（帶彈道、帶軌跡）；第三類則是前兩類特性的結(jié)合。針對(duì)不同類型，我們會(huì)采用不同的命中與同步策略。以第一類快速子彈為例，在實(shí)際玩法中，無論子彈速度多快，只要玩家在畫面上成功躲開，就會(huì)自然認(rèn)為自己不應(yīng)該被擊中，因此命中并不是在“開槍瞬間”就能直接判定的，這其中涉及的處理邏輯非常多。為了優(yōu)先保證本地體驗(yàn)，快速子彈在本地命中時(shí)會(huì)立即給出反饋，同時(shí)將命中事件上報(bào)服務(wù)器，由服務(wù)器校驗(yàn)后再下發(fā)最終傷害結(jié)果。而對(duì)于另外兩類子彈，通常由服務(wù)器直接進(jìn)行命中判斷并下發(fā)傷害。因此，在很長一段時(shí)間里，我們命中相關(guān)的技術(shù)優(yōu)化主要圍繞快速子彈展開，目標(biāo)是讓其在高實(shí)時(shí)性的前提下做到準(zhǔn)確、可信，并具備足夠的反外掛能力。

為什么我們會(huì)強(qiáng)調(diào)第一類快速子彈是“彈道”，而不是“彈幕”？原因在于它雖然速度很快，但仍然是以逐幀的方式在飛行。同時(shí)，在飛行過程中，它還會(huì)根據(jù)實(shí)時(shí)狀態(tài)進(jìn)行邏輯判斷，例如命中的目標(biāo)是否已死亡，從而決定是否繼續(xù)穿透、穿透次數(shù)，以及是否需要分裂、分裂成什么類型的子彈。因此，看似簡單的快速子彈，實(shí)際在邏輯上是非常重的。針對(duì)這種情況，我們采用的是客戶端命中上報(bào)，再由 DS 校驗(yàn)的方式。那如何防外掛呢？在這里我們引入了一套“影子快照（Shadow Snapshot）”技術(shù)。它的含義是：DS 不僅在命中瞬間做歷史校驗(yàn)，而是會(huì)在整個(gè)子彈飛行過程中持續(xù)采集行為數(shù)據(jù)。有了這些影子快照，DS 就可以在自己的視角下確保這些行為鏈路是可控且可信的，并在客戶端上報(bào)命中時(shí)進(jìn)行二次校驗(yàn)。

在反外掛層面，基于前面已經(jīng)構(gòu)建的一系列能力，我們會(huì)從三層來處理反外掛問題。首先是在框架層，服務(wù)器本身具備絕對(duì)權(quán)威，可以確保關(guān)鍵邏輯不會(huì)被客戶端篡改；其次是在校驗(yàn)層，我們通過“影子快照”以及多種狀態(tài)檢查與記錄機(jī)制，對(duì)行為鏈路進(jìn)行持續(xù)驗(yàn)證；最后是在監(jiān)控層，我們會(huì)對(duì)異常行為進(jìn)行監(jiān)測，包括異常加速、異常頻率發(fā)包等模式。通過這三層的協(xié)同，基本能夠覆蓋大部分外掛風(fēng)險(xiǎn)點(diǎn)并確保整體的安全性。

前面的內(nèi)容講完之后，不可避免地會(huì)提到“同步”層面的效率問題。在實(shí)際研發(fā)中，我們經(jīng)常會(huì)處理聯(lián)機(jī)調(diào)試、內(nèi)外網(wǎng)異常定位等情況，因此我們認(rèn)為聯(lián)機(jī)調(diào)試工具本身同樣至關(guān)重要。為此，我們在多個(gè)維度上構(gòu)建了相應(yīng)的模擬與調(diào)試能力，用來復(fù)現(xiàn)和分析各種網(wǎng)絡(luò)狀態(tài)，從而更有效地優(yōu)化整體的網(wǎng)絡(luò)體驗(yàn)。

最后做一個(gè)簡單總結(jié)：從底層通信能力，到預(yù)測、回滾、補(bǔ)償，再到帶寬優(yōu)化和反外掛，構(gòu)建了一套公平且精準(zhǔn)的網(wǎng)絡(luò)同步框架。

基于 Unity 引擎的 DS 架構(gòu)

下圖展示了構(gòu)建 Unity DS 的一個(gè)簡單參考。為什么選擇 Unity 來做 DS?優(yōu)勢非常明顯：一方面前后端邏輯可以直接復(fù)用，減少了重復(fù)開發(fā)；另一方面，后臺(tái)邏輯中有大量場景需要依賴物理系統(tǒng)，Unity 自帶的物理能力讓前后端能夠以更一致的方式處理相關(guān)邏輯，從而形成一套更連貫、成本更低的方案。

在實(shí)際開發(fā)過程中，除了前面提到的“邏輯與表現(xiàn)分離”之外，我們在資源和功能層面也盡可能做到前后端統(tǒng)一，一套開發(fā)同時(shí)滿足兩端需求，使整體流程更加簡潔高效。

在研發(fā)效率層面，下方圖中的左上部分展示了我們在實(shí)際開發(fā)過程中所使用的 DS 視圖，在其中可以直接看到前端與后臺(tái)的運(yùn)行狀態(tài)，這對(duì)于暫停、回溯以及日常調(diào)試都非常有幫助。右下部分則展示了我們在版本體驗(yàn)階段的另一種用法：在手機(jī)上游玩時(shí)一旦發(fā)現(xiàn)聯(lián)機(jī)問題，可以很輕松地將這一局接入本地 DS，并直接在編輯器中以 DS 視角進(jìn)行調(diào)試。這套研發(fā)效率體系在項(xiàng)目過程中發(fā)揮了重要作用，特別是對(duì)于《合金彈頭：覺醒》這樣一款內(nèi)容量較大的游戲，使我們能夠更高效地構(gòu)建和驗(yàn)證大量關(guān)卡內(nèi)容。

既然《合金彈頭：覺醒》是一款內(nèi)容型游戲，那么對(duì)應(yīng)的后臺(tái) DS 負(fù)擔(dān)也會(huì)隨之變重，特別是在內(nèi)存占用和整體資源壓力方面。項(xiàng)目早期我們做過一輪引擎瘦身和常規(guī)優(yōu)化，但當(dāng)這些手段都用到位之后，可繼續(xù)優(yōu)化的空間已經(jīng)非常有限，而內(nèi)容量卻還在持續(xù)增長。從后臺(tái)的視角來看，為避免運(yùn)行時(shí)加載帶來的卡頓，很多情況下 DS 在啟動(dòng)時(shí)就需要一次性加載全部內(nèi)容，這也進(jìn)一步加大了資源層面的壓力。

于是我們繼續(xù)深入分析。當(dāng)時(shí)原始的 Unity 引擎模型是：一個(gè)進(jìn)程對(duì)應(yīng)一個(gè)實(shí)例、一個(gè)實(shí)例對(duì)應(yīng)一場戰(zhàn)斗，這意味著許多基礎(chǔ)開銷，包括我們自有的對(duì)象池，都是獨(dú)占的。對(duì)于一些只需要“一名玩家 +AI”的輕量玩法來說，這種模式在資源利用上實(shí)際上相當(dāng)奢侈，因?yàn)樗鼤?huì)為這樣的小場景跑起一個(gè)完整的進(jìn)程。那么接下來該怎么辦？我們當(dāng)時(shí)有兩條思路：第一是做共享內(nèi)存，第二是做多房間。共享內(nèi)存的方案在調(diào)研后發(fā)現(xiàn)實(shí)現(xiàn)成本較高，因此最終我們選擇了多房間的方向。

改造的目標(biāo)是什么呢？在之前的項(xiàng)目中，我們的做法是左圖那種模式：一個(gè)進(jìn)程跑完一場戰(zhàn)斗后做一次 Reset，然后再串行復(fù)用這個(gè)進(jìn)程。在《合金彈頭：覺醒》中，我們希望能進(jìn)一步提升這一模式，向右圖那樣的架構(gòu)發(fā)展——也就是讓底層的基礎(chǔ)消耗（包括各類對(duì)象池和資源）保持共用，然后在其之上創(chuàng)建多個(gè)房間并行運(yùn)行。這里需要解決的關(guān)鍵問題在于：多個(gè)房間、多個(gè) Level 如何同時(shí)存在，并且彼此之間保持完全隔離。換句話說，從 DS 的視角看，即便它們位于同一個(gè)坐標(biāo)系下，各房間之間也必須做到互不干擾。

早期我們評(píng)估過三種方案：空間分割、場景疊加以及邏輯 Room?？紤]到《合金彈頭：覺醒》在早期本身就是大世界結(jié)構(gòu)，坐標(biāo)體系依賴偏移來實(shí)現(xiàn)，如果繼續(xù)采用前兩種方案，隨著時(shí)間推移不僅會(huì)引發(fā)坐標(biāo)精度的問題，整體復(fù)雜度也會(huì)大幅提升。因此最終我們選擇了第三種方案，即基于邏輯 Room 的方式來實(shí)現(xiàn)多房間并存。

要實(shí)現(xiàn)多房間完全并存，我們需要做到“三大隔離”。第一是引擎內(nèi)置對(duì)象的隔離；第二是物理層的改造與隔離；第三是邏輯狀態(tài)的隔離。由于開始進(jìn)行這些改造時(shí)項(xiàng)目內(nèi)容量已經(jīng)相當(dāng)龐大，這三類隔離在落地過程中大部分都屬于工程層面的實(shí)際挑戰(zhàn)，因此整體投入了相當(dāng)多的時(shí)間來完成。

在完成改造之后，從DS的視角來看，我們希望整個(gè)系統(tǒng)能夠以統(tǒng)一的方式驅(qū)動(dòng)更新。有了 Room 的概念之后，我們內(nèi)部把整體結(jié)構(gòu)稱為“大樓”，便于理解：一棟大樓里包含多個(gè)房間，由 RoomManager 來統(tǒng)一Tick各個(gè)房間。那么，一個(gè)進(jìn)程應(yīng)當(dāng)承載多少房間才合適？我們主要從幾個(gè)角度來評(píng)估：第一，希望在 30 幀的更新頻率下能夠穩(wěn)定地完成所有房間的 Tick；第二，從穩(wěn)定性出發(fā)，盡量避免單個(gè)房間出現(xiàn)異常時(shí)影響到整棟大樓；第三，需要結(jié)合 CPU 與內(nèi)存的占用比例，尋找一個(gè)進(jìn)程可承載房間數(shù)量的合理平衡點(diǎn)。

下方的視頻展示了改造后的一個(gè)簡單效果。從后臺(tái)視角可以看到，房間是可以直接動(dòng)態(tài)新增的，同一個(gè) DS 進(jìn)程中也能夠不斷創(chuàng)建新的房間。左側(cè)則展示了兩個(gè)獨(dú)立運(yùn)行的客戶端，它們之間完全隔離、互不影響，由此也能初步驗(yàn)證我們的多房間方案達(dá)到了預(yù)期目標(biāo)。

以 10 個(gè)房間為規(guī)模進(jìn)行 DS 架構(gòu)改造后，我們總結(jié)的收獲大致如視頻所示。實(shí)際上線外網(wǎng)后，我們又根據(jù)不同玩法在資源占用上的差異進(jìn)行了多輪調(diào)整。最終外網(wǎng)的大多數(shù)玩法穩(wěn)定在約 15 個(gè)房間的配置下運(yùn)行，而部分資源較重或流程特殊的玩法則會(huì)動(dòng)態(tài)調(diào)整為 10 個(gè)房間甚至 5 個(gè)房間，以確保資源使用保持在合理范圍內(nèi)。目前這套多房間方案已經(jīng)穩(wěn)定運(yùn)行于國內(nèi)與海外的正式環(huán)境中。

完成了 DS 的多房間優(yōu)化后，隨著游戲持續(xù)運(yùn)營、內(nèi)容規(guī)模不斷擴(kuò)大，我們又遇到了新的問題：即便在“大樓”架構(gòu)下實(shí)現(xiàn)了資源復(fù)用，同一進(jìn)程的整體內(nèi)存占用依然偏高。從后臺(tái)數(shù)據(jù)以及海外機(jī)型分布來看，部分場景已經(jīng)出現(xiàn)了明顯的內(nèi)存瓶頸，因此我們需要進(jìn)一步進(jìn)行內(nèi)存層面的優(yōu)化。另一個(gè)問題是啟動(dòng)時(shí)間過長。前面提到，服務(wù)器的進(jìn)程通常會(huì)提前拉起，但由于內(nèi)容量不斷積累，線上環(huán)境中一個(gè)進(jìn)程的拉起時(shí)間已經(jīng)達(dá)到 45 秒到 1 分鐘，這對(duì)于后臺(tái)的資源調(diào)度效率而言是明顯偏慢的。

基于這兩個(gè)問題，我們也調(diào)研了 Fork 方案。Fork 本身并不復(fù)雜，但與 Unity 結(jié)合在當(dāng)時(shí)確實(shí)存在一定挑戰(zhàn)，原理這里就不展開了。預(yù)期收益主要有兩點(diǎn)：一是希望在“大樓”之間進(jìn)一步復(fù)用內(nèi)存；二是在進(jìn)程拉起階段能夠更快啟動(dòng)，并減少 CPU 的毛刺開銷。那么在改造過程中，我們具體做了哪些事情呢？

下圖左側(cè)列出了我們認(rèn)為較為關(guān)鍵的改造點(diǎn)，包括引擎 I/O 的重定向、I/O 管理與業(yè)務(wù)側(cè)的配套調(diào)整，以及線程層面的裁減和網(wǎng)絡(luò)層的多路復(fù)用。右側(cè)則展示了我們在評(píng)估方案時(shí)重點(diǎn)考慮的問題——也就是選擇在何時(shí)進(jìn)行 Fork 才是最合適、最穩(wěn)定的時(shí)機(jī)。

下圖展示了我們在引入 Fork 后獲得的收益。可以看到，F(xiàn)ork 之后的內(nèi)存占用下降得非常明顯；在進(jìn)程拉起方面，原本需要 45 秒到 1 分鐘的啟動(dòng)時(shí)間，使用 Fork 生成子進(jìn)程后基本能夠縮短到毫秒級(jí)。隨著這一優(yōu)化落地，服務(wù)器的整體資源成本也隨之顯著下降。

完成上述改造后，我們在后臺(tái) DS 的開發(fā)過程中也經(jīng)常需要進(jìn)行大量性能測試。有些測試場景動(dòng)輒要幾十個(gè)房間，僅依靠人工很難構(gòu)建和復(fù)現(xiàn)。因此，我們在這一層面也做了相應(yīng)的自動(dòng)化能力，包括在 DS 性能出現(xiàn)問題時(shí)，能夠快速觸發(fā)并復(fù)現(xiàn)相關(guān)場景。通過這套方案，只需執(zhí)行一條指令，就能在 10 分鐘內(nèi)完成一輪完整的數(shù)據(jù)采集，并在右側(cè)所示的分析工具中基于各模塊輸出清晰的耗時(shí)分布。

下方的視頻展示了我們在測試過程，能夠在本地編輯中直接看到在整個(gè)測試階段發(fā)生的具體情況，幫助我們更直觀地了解各項(xiàng)表現(xiàn)并定位可能的問題。

以上就是對(duì)這兩個(gè)方案的介紹。我們在項(xiàng)目中的探索最終沉淀為一套完整且經(jīng)過線上驗(yàn)證的解決方案，不僅支撐了我們的自身項(xiàng)目，也即將通過團(tuán)結(jié)引擎服務(wù)于更多開發(fā)者。關(guān)于這項(xiàng)技術(shù)如何進(jìn)一步融入團(tuán)結(jié)引擎并開啟新的可能，下面有請(qǐng)團(tuán)結(jié)引擎的技術(shù)同學(xué)司天語為大家揭曉。謝謝大家！

團(tuán)結(jié)引擎 DS 聯(lián)機(jī)方案

司天語：感謝亞濤精彩的分享！接下來，由我跟大家講一講這套方案如何融入團(tuán)結(jié)引擎，如何讓各位開發(fā)者今天不僅僅是來聽一場技術(shù)方案的分享，也是可以真實(shí)的把這一套方案運(yùn)用到自己的游戲上去。我是來自于 Unity 中國底層架構(gòu)組的軟件工程師司天語。我們之所以會(huì)選擇使用這套聯(lián)機(jī)方案融入到引擎，最重要的是看中這一套框架成熟。如果一套框架沒有經(jīng)過大量線上游戲的驗(yàn)證，也沒有經(jīng)歷過大規(guī)模的實(shí)踐檢驗(yàn)，我們是沒有足夠的信心向開發(fā)者去推薦這套框架和技術(shù)的。

如今不管是穩(wěn)定性、功能性還是性能，各個(gè)方面都已經(jīng)非常成熟。因此在騰訊天美 J1 工作室的框架方案基礎(chǔ)上，團(tuán)結(jié)引擎進(jìn)行了代碼編寫，一起將它從“專用”打造成“通用”網(wǎng)絡(luò) DS 連接框架帶給開發(fā)者們。既然這套框架已經(jīng)非常成熟了，那么我接下來講一下團(tuán)結(jié)引擎會(huì)做些什么？我們在引擎中會(huì)使用更高性能的 C++ 來實(shí)現(xiàn)這套框架的內(nèi)核，相比于純 C# 的實(shí)現(xiàn)，我們可以預(yù)見會(huì)有進(jìn)一步的性能提升。同時(shí)，我們也會(huì)繼續(xù)優(yōu)化這一套框架，對(duì)一些復(fù)雜模塊進(jìn)行解耦和重新封裝，并且會(huì)設(shè)計(jì)一套簡潔明了、易拓展的接口供開發(fā)者調(diào)用。我們會(huì)努力將這套框架變成更強(qiáng)大、更通用、更易用的產(chǎn)品。

說完了高性能的設(shè)計(jì)理念，在這個(gè) feature 上面，我們還有另外一個(gè)思路，就是 All In One。一直我們都會(huì)思考：“哪些功能應(yīng)該引擎去做，哪些功能應(yīng)該讓開發(fā)者自己去寫業(yè)務(wù)代碼？”一直以來我們在引擎的研發(fā)過程中都會(huì)去思考，哪些功能應(yīng)該去引擎去做，哪些功能又應(yīng)該讓開發(fā)者自己去寫業(yè)務(wù)代碼。

一直以來團(tuán)結(jié)引擎都保持著盡量只做引擎該做的事情，這就使得團(tuán)結(jié)引擎是非常精簡、高性能且高拓展的一個(gè)引擎。在這個(gè) feature 上面，我們希望引擎可以盡可能做更多的事情。不僅是 DS 框架會(huì)下沉到引擎當(dāng)中，同時(shí)我們也會(huì)將更多的業(yè)務(wù)核心的邏輯也封裝成組件，下沉為引擎的能力。我們希望可以給開發(fā)者帶來真正“開箱即用”的體驗(yàn)。除此之外，剛才亞濤剛才提到了關(guān)于分析 ping 值、ds 幀率、模擬斷線、弱網(wǎng)模擬、軌跡校對(duì)、預(yù)測、插值等一系列的 Debugger 和 Profiler 工具。我們都會(huì)集成進(jìn)引擎，而且會(huì)在部分分析工具中提供引擎源碼級(jí)別的更加深入到引擎層面的分析能力。這些工具我們也都會(huì)內(nèi)置的引擎當(dāng)中，同時(shí)在部分工具（如果可以的話），我們還會(huì)提供引擎原碼級(jí)別更加深入到引擎底層的一些分析和調(diào)試的能力。

我們框架會(huì)做到或者說我們希望幫助開發(fā)者做到的就是降低成本，這是所有項(xiàng)目在開發(fā)過程中都非常關(guān)心的問題。為了盡可能地榨干服務(wù)器的性能、避免造成浪費(fèi)，這套方案在服務(wù)器高承載方面也做了很多的創(chuàng)新。一臺(tái) Linux 服務(wù)器先是通過 DSA 拉起“種子進(jìn)程”，然后再 Fork 出多個(gè) DS 進(jìn)程，然后每個(gè) DS 進(jìn)程又可以并行地運(yùn)行多個(gè)房間支撐起很多個(gè)對(duì)局，這就可以讓我們盡可能榨干一臺(tái)服務(wù)器的性能，以達(dá)到降低服務(wù)器的成本。其次，這套框架還會(huì)幫助項(xiàng)目降低開發(fā)成本。首先，該框架前后端會(huì)使用同一套邏輯，既保證一致性，也大大減輕邏輯開發(fā)的負(fù)擔(dān)。接著就是剛才提到的，我們會(huì)將多數(shù)項(xiàng)目都有可能用到的核心功能、核心業(yè)務(wù)邏輯都組件化封裝，然后常用的功能都會(huì)有官方提供的組件，大家不用再去造輪子、重復(fù)地去進(jìn)行開發(fā)。同時(shí)，我們也會(huì)給出完整的功能、詳細(xì)的文檔，并且會(huì)積極地建設(shè)社區(qū)的專題，讓大家可以快速地和研發(fā)人員面對(duì)面的交流問答，并且我們也會(huì)長期維護(hù)這套聯(lián)機(jī)方案。

最后，我們希望和天美 J1 工作室，一起共同將這套方案盡可能地打造為迄今為止團(tuán)結(jié)引擎上最全面、最豐富、最完整的通用 DS 聯(lián)機(jī)框架。我們會(huì)在 2026 年的上半年帶著這套框架與各位開發(fā)者見面，敬請(qǐng)期待。謝謝大家！

Unity 官方微信

第一時(shí)間了解Unity引擎動(dòng)向，學(xué)習(xí)進(jìn)階開發(fā)技能

每一個(gè)“點(diǎn)贊”、“在看”，都是我們前進(jìn)的動(dòng)力