本次演講將分享基于團(tuán)結(jié)引擎在 OpenHarmony（OH）平臺上的實(shí)戰(zhàn)開發(fā)經(jīng)驗(yàn)。內(nèi)容首先聚焦于技術(shù)適配與優(yōu)化，包括如何將 xLua 框架成功適配到 OH 環(huán)境、解決 Native 開發(fā)中 Worker 線程的內(nèi)存隔離問題，以及應(yīng)對手機(jī)、平板、折疊屏等多分辨率設(shè)備的 UI 適配方案。其次，將介紹結(jié)合 Unity 與團(tuán)結(jié)引擎的混合項(xiàng)目管理策略，涵蓋高效的多平臺多版本分支管理方法和自動化的混合發(fā)布管線搭建。最后，將深入探討團(tuán)結(jié)引擎的性能優(yōu)化實(shí)踐，例如異步 Shader 預(yù)熱技術(shù)等關(guān)鍵細(xì)節(jié)，旨在幫助開發(fā)者更高效、穩(wěn)健地在該生態(tài)下進(jìn)行游戲與應(yīng)用開發(fā)。

田升：非常感謝主辦方的邀請，讓我有機(jī)會在 Unite 2025 技術(shù)盛會與大家相聚。我是來自波克城市的 Unity 技術(shù)工程師，非常榮幸在這里分享我們團(tuán)隊(duì)在團(tuán)結(jié)引擎 OH 平臺上的發(fā)布經(jīng)驗(yàn)。我專注于 Unity 技術(shù)棧超過7年時(shí)間，經(jīng)歷了從 Unity 引擎到團(tuán)結(jié)引擎的技術(shù)演進(jìn)。從 2023 年底，開始主導(dǎo)了公司首款基于團(tuán)結(jié)引擎的 OH 平臺的應(yīng)用接入與發(fā)布工作。在跨平臺項(xiàng)目管理、架構(gòu)設(shè)計(jì)、性能優(yōu)化方面積累了一些實(shí)戰(zhàn)經(jīng)驗(yàn)。今天我分享的主題是《基于團(tuán)結(jié)引擎的 OH 應(yīng)用發(fā)布實(shí)踐》，將重點(diǎn)介紹我們在實(shí)際項(xiàng)目中遇到的挑戰(zhàn)、解決方案以及獲得的經(jīng)驗(yàn)教訓(xùn)，希望能為正在或計(jì)劃使用 Unity/團(tuán)結(jié)引擎進(jìn)行多平臺開發(fā)的團(tuán)隊(duì)提供參考。

在開始深入技術(shù)細(xì)節(jié)前，先簡要介紹今天的演講內(nèi)容：

第一部分將分享團(tuán)結(jié)引擎基于 OH 平臺的實(shí)戰(zhàn)經(jīng)驗(yàn)，重點(diǎn)講解三個我們遇到的核心問題及解決方案：UI 的屏幕適配、xLua 在 OH 平臺的使用，以及 Native 開發(fā)時(shí) Worker 的內(nèi)存隔離問題。

第二部分將探討 Unity 與團(tuán)結(jié)引擎的混合項(xiàng)目管理方案，包括多平臺多版本分支管理方案和多平臺自動化發(fā)布管線的建設(shè)。

第三部分將聚焦團(tuán)結(jié)引擎在體驗(yàn)和性能方面的優(yōu)化實(shí)踐，特別是異步 Shader 預(yù)熱技術(shù)的應(yīng)用效果。

團(tuán)結(jié)引擎發(fā)布 OH 的實(shí)戰(zhàn)經(jīng)驗(yàn)分享

技術(shù)分享前，看一組 2025 年的市場數(shù)據(jù)。首先“498萬”是折疊屏設(shè)備的增長，2025 上半年中國折疊屏設(shè)備手機(jī)出貨量達(dá)到 498 萬部，同比增長 12.6%。第二個是設(shè)備尺寸的多元化：50% 是指 6.7 英寸以上的大屏手機(jī)在國內(nèi)安卓市場仍然占據(jù)主導(dǎo)地位，達(dá) 50%；小于 6.5 英寸的設(shè)備，它仍然有 21.5% 的占比。第三個說明的是分辨率的碎片化，1.5K 分辨率已成為安卓陣營的主流選擇，占比已經(jīng)高達(dá) 37.2%。超越了 1080P 的 33.8% 和 2K 的 15.3%。這些數(shù)據(jù)表明，移動設(shè)備的形態(tài)正呈現(xiàn)多元化的發(fā)展趨勢。從傳統(tǒng)手機(jī)到平板再到折疊屏，屏幕比例和分辨率千差萬別。同時(shí)，操作系統(tǒng)平臺也日趨多樣化，如何實(shí)現(xiàn)高效的多平臺發(fā)布或?qū)⒊蔀槲覀冮_發(fā)者面臨的主要挑戰(zhàn)。

UI 的屏幕適配方案

接下來我們看一下 UI 的屏幕適配方案，涵蓋了手機(jī)、平板、折疊屏。

面對設(shè)備碎片化挑戰(zhàn)，我們設(shè)計(jì)了一套安全區(qū)偏移適配法。核心思路是：不僅考慮不同分辨率的縮放，更重點(diǎn)關(guān)注異形屏、折疊屏等設(shè)備的安全區(qū)域動態(tài)變化。下圖展示了我們的適配效果。左側(cè)是異形屏（劉海屏）設(shè)備上的適配效果，右側(cè)是平板設(shè)備下的適配效果。黃色區(qū)域是安全區(qū)的邊界，在這兩種設(shè)備上我們的關(guān)鍵元素都能有比較不錯的適配效果。

接下來，我們看一下視頻演示。

下方視頻是屏幕動態(tài)比例，演示了常見的橫屏及豎屏常見比例的動態(tài)適配。關(guān)鍵元素基本都沒有出現(xiàn)被遮擋、被裁剪的一些情況。

下方視頻是自由屏的比例，是基于左邊動態(tài)屏幕比例做了一些更激進(jìn)的演示，我們可以非常定制化地去改我們的屏幕分辨比例，非常靈活。剛剛是橫屏，這是豎屏。當(dāng)然，這里面的背景元素適配，后面我們也會擴(kuò)展。

接下來是具體的適配方案設(shè)計(jì)，有三個關(guān)鍵問題：一是安全區(qū)域的數(shù)據(jù)怎么準(zhǔn)確的獲?。看蠹乙部梢钥吹较聢D右側(cè)的設(shè)計(jì)圖。設(shè)計(jì)上將屏幕數(shù)據(jù)抽離出來成為數(shù)據(jù)的提供層，以實(shí)際情況來采用不同的屏幕數(shù)據(jù)提供者。例如：通過 Unity 原生 API Screen.safeArea 獲取、Native 層自行定制 API 等。另外，可以增加任意的自定義的擴(kuò)展，來針對一些不支持獲取安全區(qū)設(shè)備時(shí)能有一種 Callback 方案。

第二個問題是橫豎屏動態(tài)切換如何適配？這里需要區(qū)分下普通的 UI 元素和 UI 背景，適配方式有所差異。

針對普通 UI 元素，我們用 Unity UGUI 自帶的錨點(diǎn)適配以及 Canvas Scaler 適配就能做到比較好的效果。

針對背景 UI 元素，我們有以下三種方案：

• 兩套標(biāo)準(zhǔn)，動態(tài)切換。什么叫兩套標(biāo)準(zhǔn)？我們在設(shè)計(jì)時(shí)按照手機(jī)的分辨率以及平板的分辨率，兩套分辨率分別出圖。制作時(shí)我們的動態(tài)根據(jù)屏幕的寬高比切換需要使用到的圖片。優(yōu)點(diǎn)是我們的室內(nèi)結(jié)果會更出色，我們在手機(jī)或者說在平板上都能有一個比較好的一個表現(xiàn)效果。缺點(diǎn)是我們美術(shù)和程序端都會多一些這工作量。

• 一套標(biāo)準(zhǔn)、設(shè)計(jì)兼容。這個“設(shè)計(jì)兼容”是指按照手機(jī)和平板都兼容的分辨率出圖。缺點(diǎn)是內(nèi)容可能有些緊張，優(yōu)點(diǎn)是適配方案和開發(fā)上難度都不高。

• 一套標(biāo)準(zhǔn)、適配兼容+Aspect Ratio Fitter。這“一套標(biāo)準(zhǔn)”是指，例如：我們的主要用戶是在手機(jī)上，我們按照手機(jī)分辨率設(shè)計(jì)圖、不用考慮平板的情況。但是怎么去兼容平板呢？我們借助 Unity 的 Aspect Ratio Fitter 組件進(jìn)行組件適配。優(yōu)點(diǎn)是制作過程更快捷，缺點(diǎn)是我們是需要程序適配，而且通用性它會帶來一些普遍缺點(diǎn)，我們在平板上的一個畫面表現(xiàn)可能會比較一般。

  另外，適配后的界面內(nèi)部分元素，如果不需要適配要怎么處理？這里給到的是一個“安全區(qū)偏移適配法”。什么時(shí)候會出現(xiàn)這種情況？比如界面內(nèi)部分需要適配安全區(qū)、部分不需要適配安全區(qū)。例如某些美術(shù)設(shè)計(jì)師，他們的設(shè)計(jì)是非常好的。例如全屏背景下，可能會增加一些跟屏幕有一些交互的線條或者一些邊緣的效果。這個情況下，這些邊緣效果是不應(yīng)該去受到安全區(qū)的控制的，這個時(shí)候我們就需要讓它跟基于屏幕的邊緣去適配，所以我們這邊采用的是安全區(qū)適配法。

大家可以在下圖中看到雖然黃色線框是安全區(qū)域，但是紅色和綠色表示 UI 元素并沒有被約束在黃色線框內(nèi)。怎么做到？我們拿到準(zhǔn)確的安全區(qū)數(shù)據(jù)之后，安全區(qū)距離屏幕每條邊的距離是可以計(jì)算出來的。這些距離數(shù)據(jù)，即為安全區(qū)域和原屏幕尺寸的偏移值。只要設(shè)計(jì)一個智能化的偏移組件，我們就可以對此偏移盡量做一個反向的距離或者尺寸的應(yīng)用。如果是對位移進(jìn)行偏移，大家可以看到綠色的 UI 元素效果，只會修改位移；如果是對尺寸進(jìn)行偏移，我們可以得到紅色表示的 UI 效果，會基于原尺寸做一個拉伸的效果。這種方法保證了關(guān)鍵 UI 元素既不會超出安全區(qū)，又能充分地利用屏幕空間。

xLua 在 OH 平臺的適配方案

我們一個已上線項(xiàng)目采用 AOT 部分是 C#、資源熱更部分是 xLua 的技術(shù)棧。在面向 OH 平臺發(fā)布時(shí)，遇到了 xLua 框架代碼異常的問題。問題的根源是什么？因?yàn)?xLua 雖然是一個相當(dāng)成熟的熱更新框架，但是團(tuán)結(jié)引擎、OH 平臺發(fā)布時(shí)間都較 xLua 晚，所以 xLua 的 Assets/Plugins 目錄下不存在 OH 平臺的 so 庫。那怎么解決呢？其實(shí) xLua 設(shè)計(jì)之初就考慮到了此問題，官方文檔內(nèi)其實(shí)能找得到 Plugins 的源碼。只要有了源碼，那么接下來就很簡單了。使用 cmake 編譯源碼到 OH 平臺即可，最終我們需要生成的是一個如下圖所示的 libxlua 的一個 so 庫，集成到項(xiàng)目中，就可以提供給 OH 平臺正常使用。這個過程雖然簡單，但幾乎是所有采用類似技術(shù)棧的項(xiàng)目在發(fā)布到 OH 平臺時(shí)都會遇到的“必經(jīng)之路”。

OH Native 開發(fā)時(shí) Worker 的內(nèi)存隔離解決方案

在 OH 平臺打包發(fā)布的最后階段，我們發(fā)現(xiàn)由 C# 調(diào)用 Native 函數(shù)后，Native 側(cè)運(yùn)行時(shí)的數(shù)據(jù)異常，表現(xiàn)為一些值未初始化或返回的值是默認(rèn)值。跟第二個問題一樣，幾乎我見過所有的團(tuán)隊(duì)在發(fā)布 OH 期間都有碰到過，問題就是 OH Native 開發(fā)時(shí) Worker 存在內(nèi)存隔離。

發(fā)布 OH，我們必須知曉一個概念，Worker。Worker 可以理解為一個多線程的運(yùn)行環(huán)境，Worker 的子線程和宿主線程擁有相同的實(shí)例，包含基礎(chǔ)設(shè)施、對象、代碼段。Worker 子線程和主線程之間的通信，主要是基于消息傳遞的。當(dāng)我們知曉了這個概念之后，我們相信這個內(nèi)存隔離問題也比較好去解決了。

我們 Native 開發(fā)時(shí)，中臺部門開發(fā)了一個通用的 SDK 其實(shí)是在主線程內(nèi)使用的，例如：登錄、支付等功能界面，而 Tuanjie 調(diào)用的 Native 代碼在其實(shí)是在子線程，所以會產(chǎn)生 OH 的 Worker 內(nèi)存隔離問題。

問題原因明確過后呢，這里提供一個簡單的方案來處理：首先，針對行為（例如：喚起登錄、支付等無需實(shí)時(shí)同步的狀態(tài)數(shù)據(jù)返回的情況），直接調(diào)用線程的異步通信即可；其次，針對數(shù)據(jù)，提前在與引擎交互的 Worker 子線程中提前緩存數(shù)據(jù)。像我們一般會去調(diào) Native 獲取的數(shù)據(jù)，主要就是一些設(shè)備信息，這些信息我們提前緩存的話，我們在后續(xù)的調(diào)用中就可以做到同步的實(shí)時(shí)性。這樣在實(shí)際需要用到數(shù)據(jù)的時(shí)候，即可以達(dá)到同步返回的及時(shí)性；當(dāng)然，我們需要統(tǒng)一入口點(diǎn)，確保所有 Native 調(diào)用都通過同一 Worker 線程處理。

以上是第一部分的內(nèi)容。接下來，分享第二部分。

Unity + 團(tuán)結(jié)的混合項(xiàng)目管理方案

項(xiàng)目管理嚴(yán)格來說涉及的領(lǐng)域和模塊都比較泛，例如版本管理、開發(fā)管理、發(fā)行管理、運(yùn)營管理等等。今天沒辦法從頭到尾跟大家理清楚這里面的全部門道，我們挑了幾個跟技術(shù)相關(guān)的命題，涉及的主要是“開發(fā)管理”。以下是多平臺多版本的分支管理和多平臺的自動化發(fā)布管線。

多平臺多版本的分支管理

有一句話說在前面：分支管理方案，沒有最好的、只有最適合的。我相信如果有這部分分支管理經(jīng)驗(yàn)的老師，應(yīng)該也深有感悟。我們的分支管理都是經(jīng)過多次迭代之后，才有了當(dāng)前的高效方案。廢話不多說，同上一部分類似，我也通過實(shí)際問題的解法向大家分享一下。在此之前，我們先備注一下使用工具。我們這里是基于 SVN 的 Unity 分支管理。當(dāng)然也有其他優(yōu)秀的分支管理（例如 Git），這里我們暫不展開。

我們先看看常規(guī)的分支管理方案，存在主干、版本分支、發(fā)布分支、修復(fù)分支等。常規(guī)開發(fā)時(shí)可能會先創(chuàng)建對應(yīng)的版本分支，開發(fā)完后會立即合并到主干，同時(shí)創(chuàng)建發(fā)布分支用于發(fā)布。當(dāng)線上出現(xiàn) Bug 的時(shí)候可能會創(chuàng)建修復(fù)分支去修復(fù) Bug，再合回發(fā)布分支發(fā)布。正常對于非游戲客戶端來說是一個比較標(biāo)準(zhǔn)的管理方案，但是對于例如 Unity 的游戲開發(fā)、特別是涉及到資源量級特別大、版本多且復(fù)雜的一些項(xiàng)目的時(shí)候，過多的分支對于開發(fā)并不是很友好。

首先，美術(shù)同學(xué)對于 SVN 熟練度是存在差異的。過去有一段時(shí)間我經(jīng)常幫美術(shù)同學(xué)處理各種更新沖突，分支 checkout 不下來等問題。

其次，美術(shù)開發(fā)模式和程序開發(fā)模式是有區(qū)別的。這里要說個前提，這個是我們的一些實(shí)際經(jīng)驗(yàn)，不代表所有人都會碰到這個問題。什么區(qū)別呢？就是程序正常是按照版本排序去制作的，但是美術(shù)在此基礎(chǔ)上會再去按照功能模塊進(jìn)行排期。我們有看到美術(shù)內(nèi)部管理時(shí)可能會有內(nèi)部的功能排期表，列了每個人員按照時(shí)間線、按照功能模塊，一一排得比較明確。當(dāng)然，不同項(xiàng)目組可能是不一樣的。

最后，就是我們可能在美術(shù)人力富余的情況下存在一些美術(shù)先行的制作方式。這個情況可能也不是特別全面適用，因?yàn)榕e個例子，比如版本制作排期正常假如說不會超過3個月，但是我們項(xiàng)目設(shè)計(jì)路線可能考慮得比較完善，考慮到未來半年、甚至未來一年內(nèi)的規(guī)劃。那么美術(shù)，特別是針對一些美術(shù)開發(fā)工作量比較大的內(nèi)容，我們可能就要去提前規(guī)劃、去設(shè)計(jì)好。

第二是用該分支管理方案，其實(shí)并沒有考慮到多 trunk 的形式。什么情況下會用到？假如線上同時(shí)存在運(yùn)營多個版本的情況下，而且我們每個版本之間是不兼容的。但是不兼容的版本之間，它仍然需要有不同的開發(fā)路線。例如我們 1.0 的 APP，我們要開發(fā) 2.0 的資源。2.0 的 APP，也要開發(fā) 2.0 的資源，甚至也要同時(shí)開發(fā) 3.0 的資源。針對這種情況，這個分支是不太適合的。

第三是部分團(tuán)隊(duì)對代碼的保密要求比較高。如果是分支對美術(shù)開放，那代碼權(quán)管控上可能會不太方便。

接下來，針對美術(shù)開發(fā)的差異及代碼保密的要求，我們迭代了第二個分支管理方案，即雙分支管理方案。

當(dāng)前這里前提說的是一個彎路，是基于我們經(jīng)驗(yàn)的一個判斷。我們將工程拆為程序工程和美術(shù)工程，兩邊各自維護(hù)。中間通過 SVN 外鏈的形式，將美術(shù)對應(yīng)版本的資源外鏈接到程序工程內(nèi)，然后程序工程使用程序工程發(fā)布。聽到這里大家也能夠想像出該方案的優(yōu)缺點(diǎn)。優(yōu)點(diǎn)是我們可以解決美術(shù)研發(fā)模式差異的問題。因?yàn)槊佬g(shù)分支變成了美術(shù)資源庫的概念，美術(shù)超前研發(fā)的內(nèi)容也完全內(nèi)聚在美術(shù)分支，并不會影響到程序內(nèi)的內(nèi)容。其次也可以解決美術(shù)訪問權(quán)限問題。因?yàn)槊佬g(shù)單獨(dú)分支，程序可以通過代碼加密或者其他方式提供美術(shù)使用。缺點(diǎn)是什么呢？就是復(fù)雜，分支管理極度復(fù)雜。我們每次創(chuàng)建分支發(fā)布時(shí)，需要操作兩邊的分支同時(shí)進(jìn)行，而且需要專人或者說比較熟練的人員來處理分支合并。如果外鏈異常，可能會導(dǎo)致資源體提交到錯誤的分支上。外鏈如果中斷了，可能會導(dǎo)致一些版本存檔的丟失。特別是后面我們增加了 OH 平臺的支持之后，這些問題更加尖銳了。

痛定思痛，我們重新整理了思路，堅(jiān)持了以解決開發(fā)效率為核心的目標(biāo)。如果說不影響開發(fā)效率的開發(fā)問題，那么我們可以想其他辦法解決或者說根本就無需解決。

最終的管理方案，大家可以看到我們精簡了分支種類，只存在trunk、master、branch 和 OH branch。Trunk 和 OH branch 可以暫時(shí)忽略，我們主要的兩條線路就是版本主干和版本分支。

正常來說線上兼容版本不會有特別多的情況，正常 master 一根線就可以了。特點(diǎn)是什么呢？就是我們的分支數(shù)量減少，管理復(fù)雜度大大降低了。還有就是我們美術(shù)和程序研發(fā)模式的差異問題怎么去解決？我覺得我們還是要去正確的對待這個差異。美術(shù)最終其實(shí)也是要去為版本發(fā)布服務(wù)的。明確了這一核心目的之后，美術(shù)就正常按照程序的版本分支走就可以了。

針對美術(shù)超前研發(fā)內(nèi)容，我們開發(fā)了一個“超前研發(fā)分支”即可。美術(shù)權(quán)限訪問問題，其實(shí)我們也相當(dāng)于跟自己和解了。做代碼全控的目的是什么？目的是安全。這個部分的風(fēng)險(xiǎn)，我們采用職責(zé)轉(zhuǎn)移的方式來作為一個方案，交由部門內(nèi)強(qiáng)大的 IT 權(quán)控、法務(wù)等部門做風(fēng)險(xiǎn)控制。當(dāng)然，中間我們也可以做到一些代碼加密，來提前做一些防護(hù)。

最后為了匹配這個方案，其實(shí)我們實(shí)際也會增加開發(fā)環(huán)境內(nèi)的一些對應(yīng)的版本分支選擇。例如客戶端 1.0 就連接 1.0 的服務(wù)器，使用 1.0 的資源。接下來，后面大家看到灰色的線，其實(shí)我們增加了 OH 平臺的發(fā)布路線之后，就是新增了這樣一條線路。

但是問題是什么呢？是因?yàn)?strong>團(tuán)結(jié)引擎的 Meta 文件的 GUID 管理方式跟 Unity 有所差異，導(dǎo)致我們沒有辦法將團(tuán)結(jié)引擎的工程納入到正常的版本研發(fā)模式內(nèi)。

這里我們提供兩個管理方案：一是目前的解決方案，就是類似圖里所示，每次版本發(fā)布上線前也創(chuàng)建對應(yīng)的 OH 發(fā)布分支，這是因?yàn)槲覀冇幸稽c(diǎn)歷史包袱在，我們是一個已經(jīng)上線多年的項(xiàng)目，沒有辦法完全遷移進(jìn)團(tuán)結(jié)引擎。

這里就引入到了第二個管理方案，就是我們可以將整個開發(fā)引擎全部換為團(tuán)結(jié)引擎。這點(diǎn)其實(shí)也可以考慮，經(jīng)過幾年的時(shí)間，目前團(tuán)結(jié)引擎還算是比較穩(wěn)定，作為 Android、iOS 等平臺的發(fā)布工程也可以。我們綜合評估下來也可以，但是我們現(xiàn)在也仍然在一個測試過程中。

還有一個細(xì)節(jié)要跟大家分享，就是Excel 配置表，如何進(jìn)行多版本管理？

常規(guī)情況下，Excel 的版本管理就應(yīng)該跟普通的資源文件一樣的，不同的工程存在不同的配置表。但是會存在一個問題，當(dāng)我們碰到 Excel 合并沖突的時(shí)候怎么辦？可能有人都能碰到過，每一個單元格的合并簡直是痛苦，簡直是災(zāi)難，特別是單元格還存在公式的情況下，你就需要一個非常強(qiáng)大的 Excel 合并工具。但是經(jīng)過我們的嘗試，該解法非常復(fù)雜。我們使用過一些常用的工具，例如：Beyond Compare、xlCompare 等工具，但實(shí)際的開發(fā)體驗(yàn)和帶來的效果都不是很理想。

最后我們換了一個角度來解決這個問題。我們將沖突合并的痛點(diǎn)轉(zhuǎn)移到了導(dǎo)出工具之上，這個難度就比較低了。我們開發(fā)導(dǎo)出工具的難度，大大是低于開發(fā) Excel 合并工具的難度的。

可以看到下圖中右側(cè)的表格。Excel 表的每一列可以單獨(dú)新建一列，然后增加對應(yīng)的版本標(biāo)記。最后，我們在下面的“導(dǎo)出工具”內(nèi)設(shè)置好對應(yīng)的版本號，我們就可以導(dǎo)出對應(yīng)版本的行列。這樣的話，我們在源頭上就去規(guī)避了 Excel 合并沖突的問題。

分享以上經(jīng)歷并不是說推薦使用我們采用的方式，還是那句話，版本分支管理方案只有最適合的。我們核心目的是分享解決問題的思路，對復(fù)雜的內(nèi)容往往需要化繁為簡：首先需要明確問題是什么，以及目標(biāo)是什么。只有明確了目標(biāo)，我們才能找到解決問題的關(guān)鍵路徑。還有就是我們要去從多維度看待問題，例如 Excel 這個合并工具。有些問題換個角度看，其實(shí)可能根本就不算問題，可能就迎刃而解了。

多平臺的自動化發(fā)布管線

這個往往是比較繁瑣，且到后期可能是趨于一些重復(fù)的事情。從提效角度上思考，我們不得不把自動化發(fā)布管線落實(shí)。自動化發(fā)布是提升團(tuán)隊(duì)效率的關(guān)鍵。我們的發(fā)布管線主要包含資源發(fā)布管線和應(yīng)用發(fā)布管線。
資源發(fā)布管線包含一些核心環(huán)節(jié)：資源預(yù)測處理、自動化測試、自動化分發(fā)。從下圖右側(cè)可以看到，點(diǎn)擊 Jenkins 打包按鈕就可以開始自動化操作。我們可能先更新代碼資源、解決沖突，最后做一些代碼預(yù)處理、資源預(yù)處理。最后，等到構(gòu)建完成，通知到對應(yīng)的執(zhí)行人。接下來會觸發(fā) QA 的自動化測試任務(wù)，減少人工測試。最后點(diǎn)擊“發(fā)布”，就可以執(zhí)行自動化的發(fā)布操作，最后再去提交“運(yùn)維工單”就可以了。這是我們的資源發(fā)布管線。

應(yīng)用發(fā)布管線其實(shí)是類似的。前面部分是差不多的，但是后面“打包”，我們這邊是增加了一個安卓的并行構(gòu)建，我們可以進(jìn)行多渠道的構(gòu)建，利用集群資源縮短構(gòu)建時(shí)間。

接下來介紹一下我們的關(guān)鍵技術(shù)：

關(guān)鍵技術(shù)1：

• 引擎 Editor 擴(kuò)展，開發(fā)定制化的構(gòu)建工具。下方第一個圖就是引擎內(nèi)部的打包管線。當(dāng)然這個打包管線也是 CI/CD 的。

• 資源構(gòu)建配置和應(yīng)用發(fā)布配置。我們通過配置文件管理不同模塊/不同平臺的發(fā)布構(gòu)建參數(shù)，確保構(gòu)建的一致性。

關(guān)鍵技術(shù)2：

• 構(gòu)建狀態(tài)的監(jiān)控以及CI/CD工具的集成。通過集成開源且社區(qū)活躍的 Jenkins，來串通整條管線的鏈路。大家也可以使用其他的一些 TeamCity 等比較優(yōu)秀的 CI/CD 解決方案。

自動化是提升團(tuán)隊(duì)效率的關(guān)鍵，通過自動化管線、我們將發(fā)布流程從原來的“數(shù)小時(shí)”縮短到了“30 分鐘以內(nèi)”。

團(tuán)結(jié)引擎體驗(yàn)+性能的優(yōu)化實(shí)踐

主要是異步 Shader 預(yù)熱技術(shù)。主要是使用團(tuán)結(jié)引擎之后，我們發(fā)現(xiàn)其部分特性在性能優(yōu)化、用戶體驗(yàn)等是能帶來正向收益的。

游戲體驗(yàn)痛點(diǎn)
Shader 編譯卡頓，是影響游戲體驗(yàn)的一大難題。團(tuán)結(jié)引擎提供了一些異步 Shader 預(yù)熱技術(shù)，幫我們有效解決了這一痛點(diǎn)。
異步 Shader 預(yù)熱技術(shù)的步驟

1.Shader變體收集：通過自動化工具分析游戲場景，收集所有可能的 Shader 變體。

2.分級預(yù)熱策略：將 Shader 分為關(guān)鍵、重要和普通三個級別，按優(yōu)先級進(jìn)行預(yù)熱。在游戲啟動的時(shí)候，可以對關(guān)鍵、重要的 Shader 先行預(yù)熱；對于普通的，可以在游玩過程中，當(dāng) CPU 空閑或占用不高的時(shí)候，在后臺進(jìn)行異步預(yù)熱。

3.進(jìn)度顯示：在加載界面顯示 Shader 預(yù)熱進(jìn)度，提升用戶體驗(yàn)感知。

方案效果
相比傳統(tǒng)的阻塞式預(yù)熱，異步預(yù)熱將游戲啟動時(shí)間減少了 50% 以上，消除了 Shader 編譯導(dǎo)致的卡頓體驗(yàn)。

當(dāng)然除了異步 Shader 預(yù)熱，我們也實(shí)施了一系列的性能優(yōu)化措施

• 資源加載：我們實(shí)現(xiàn)資源分包和智能預(yù)加載，根據(jù)游戲進(jìn)度預(yù)測資源需求；內(nèi)存管理優(yōu)化方面，通過精準(zhǔn)的引用計(jì)數(shù)和資源生命周期管理達(dá)到了比較好的優(yōu)化效果。

• 渲染優(yōu)化：我們利用團(tuán)結(jié)引擎的渲染管線優(yōu)化，減少不必要的渲染調(diào)用。

由于時(shí)間的原因，這里就不展開了。以上就是我們今天分享的全部內(nèi)容，希望對大家在實(shí)際開發(fā)中有所啟發(fā)和幫助。謝謝大家！

Unity 官方微信

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

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