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

田升：非常感謝主辦方的邀請(qǐng)，讓我有機(jī)會(huì)在 Unite 2025 技術(shù)盛會(huì)與大家相聚。我是來(lái)自波克城市的 Unity 技術(shù)工程師，非常榮幸在這里分享我們團(tuán)隊(duì)在團(tuán)結(jié)引擎 OH 平臺(tái)上的發(fā)布經(jīng)驗(yàn)。我專(zhuān)注于 Unity 技術(shù)棧超過(guò)7年時(shí)間，經(jīng)歷了從 Unity 引擎到團(tuán)結(jié)引擎的技術(shù)演進(jìn)。從 2023 年底，開(kāi)始主導(dǎo)了公司首款基于團(tuán)結(jié)引擎的 OH 平臺(tái)的應(yīng)用接入與發(fā)布工作。在跨平臺(tái)項(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)介紹我們?cè)趯?shí)際項(xiàng)目中遇到的挑戰(zhàn)、解決方案以及獲得的經(jīng)驗(yàn)教訓(xùn)，希望能為正在或計(jì)劃使用 Unity/團(tuán)結(jié)引擎進(jìn)行多平臺(tái)開(kāi)發(fā)的團(tuán)隊(duì)提供參考。

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

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

第二部分將探討 Unity 與團(tuán)結(jié)引擎的混合項(xiàng)目管理方案，包括多平臺(tái)多版本分支管理方案和多平臺(tái)自動(dò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 年的市場(chǎng)數(shù)據(jù)。首先“498萬(wàn)”是折疊屏設(shè)備的增長(zhǎng)，2025 上半年中國(guó)折疊屏設(shè)備手機(jī)出貨量達(dá)到 498 萬(wàn)部，同比增長(zhǎng) 12.6%。第二個(gè)是設(shè)備尺寸的多元化：50% 是指 6.7 英寸以上的大屏手機(jī)在國(guó)內(nèi)安卓市場(chǎng)仍然占據(jù)主導(dǎo)地位，達(dá) 50%；小于 6.5 英寸的設(shè)備，它仍然有 21.5% 的占比。第三個(gè)說(shuō)明的是分辨率的碎片化，1.5K 分辨率已成為安卓陣營(yíng)的主流選擇，占比已經(jīng)高達(dá) 37.2%。超越了 1080P 的 33.8% 和 2K 的 15.3%。這些數(shù)據(jù)表明，移動(dòng)設(shè)備的形態(tài)正呈現(xiàn)多元化的發(fā)展趨勢(shì)。從傳統(tǒng)手機(jī)到平板再到折疊屏，屏幕比例和分辨率千差萬(wàn)別。同時(shí)，操作系統(tǒng)平臺(tái)也日趨多樣化，如何實(shí)現(xiàn)高效的多平臺(tái)發(fā)布或?qū)⒊蔀槲覀冮_(kāi)發(fā)者面臨的主要挑戰(zhàn)。

UI 的屏幕適配方案

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

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

接下來(lái)，我們看一下視頻演示。

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

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

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

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

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

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

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

• 一套標(biāo)準(zhǔn)、設(shè)計(jì)兼容。這個(gè)“設(shè)計(jì)兼容”是指按照手機(jī)和平板都兼容的分辨率出圖。缺點(diǎn)是內(nèi)容可能有些緊張，優(yōu)點(diǎn)是適配方案和開(kāi)發(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)是制作過(guò)程更快捷，缺點(diǎn)是我們是需要程序適配，而且通用性它會(huì)帶來(lái)一些普遍缺點(diǎn)，我們?cè)谄桨迳系囊粋€(gè)畫(huà)面表現(xiàn)可能會(huì)比較一般。

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

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

xLua 在 OH 平臺(tái)的適配方案

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

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

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

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

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

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

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

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

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

多平臺(tái)多版本的分支管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多平臺(tái)的自動(dòng)化發(fā)布管線

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

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

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

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

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

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

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

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

自動(dòng)化是提升團(tuán)隊(duì)效率的關(guān)鍵，通過(guò)自動(dòng)化管線、我們將發(fā)布流程從原來(lái)的“數(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)等是能帶來(lái)正向收益的。

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

1.Shader變體收集：通過(guò)自動(dòng)化工具分析游戲場(chǎng)景，收集所有可能的 Shader 變體。

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

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

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

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

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

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

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

Unity 官方微信

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

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