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

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

在開始深入技術細節前，先簡要介紹今天的演講內容：

第一部分將分享團結引擎基于 OH 平臺的實戰經驗，重點講解三個我們遇到的核心問題及解決方案：UI 的屏幕適配、xLua 在 OH 平臺的使用，以及 Native 開發時 Worker 的內存隔離問題。

第二部分將探討 Unity 與團結引擎的混合項目管理方案，包括多平臺多版本分支管理方案和多平臺自動化發布管線的建設。

第三部分將聚焦團結引擎在體驗和性能方面的優化實踐，特別是異步 Shader 預熱技術的應用效果。

團結引擎發布 OH 的實戰經驗分享

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

UI 的屏幕適配方案

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

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

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

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

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

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

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

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

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

• 兩套標準，動態切換。什么叫兩套標準？我們在設計時按照手機的分辨率以及平板的分辨率，兩套分辨率分別出圖。制作時我們的動態根據屏幕的寬高比切換需要使用到的圖片。優點是我們的室內結果會更出色，我們在手機或者說在平板上都能有一個比較好的一個表現效果。缺點是我們美術和程序端都會多一些這工作量。

• 一套標準、設計兼容。這個“設計兼容”是指按照手機和平板都兼容的分辨率出圖。缺點是內容可能有些緊張，優點是適配方案和開發上難度都不高。

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

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

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

xLua 在 OH 平臺的適配方案

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

OH Native 開發時 Worker 的內存隔離解決方案

在 OH 平臺打包發布的最后階段，我們發現由 C# 調用 Native 函數后，Native 側運行時的數據異常，表現為一些值未初始化或返回的值是默認值。跟第二個問題一樣，幾乎我見過所有的團隊在發布 OH 期間都有碰到過，問題就是 OH Native 開發時 Worker 存在內存隔離。

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

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

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

以上是第一部分的內容。接下來，分享第二部分。

Unity + 團結的混合項目管理方案

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

多平臺多版本的分支管理

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

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

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

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

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

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

第三是部分團隊對代碼的保密要求比較高。如果是分支對美術開放，那代碼權管控上可能會不太方便。

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

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

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

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

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

針對美術超前研發內容，我們開發了一個“超前研發分支”即可。美術權限訪問問題，其實我們也相當于跟自己和解了。做代碼全控的目的是什么？目的是安全。這個部分的風險，我們采用職責轉移的方式來作為一個方案，交由部門內強大的 IT 權控、法務等部門做風險控制。當然，中間我們也可以做到一些代碼加密，來提前做一些防護。

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

但是問題是什么呢？是因為團結引擎的 Meta 文件的 GUID 管理方式跟 Unity 有所差異，導致我們沒有辦法將團結引擎的工程納入到正常的版本研發模式內。

這里我們提供兩個管理方案：一是目前的解決方案，就是類似圖里所示，每次版本發布上線前也創建對應的 OH 發布分支，這是因為我們有一點歷史包袱在，我們是一個已經上線多年的項目，沒有辦法完全遷移進團結引擎。

這里就引入到了第二個管理方案，就是我們可以將整個開發引擎全部換為團結引擎。這點其實也可以考慮，經過幾年的時間，目前團結引擎還算是比較穩定，作為 Android、iOS 等平臺的發布工程也可以。我們綜合評估下來也可以，但是我們現在也仍然在一個測試過程中。

還有一個細節要跟大家分享，就是Excel 配置表，如何進行多版本管理？

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

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

可以看到下圖中右側的表格。Excel 表的每一列可以單獨新建一列，然后增加對應的版本標記。最后，我們在下面的“導出工具”內設置好對應的版本號，我們就可以導出對應版本的行列。這樣的話，我們在源頭上就去規避了 Excel 合并沖突的問題。

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

多平臺的自動化發布管線

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

應用發布管線其實是類似的。前面部分是差不多的，但是后面“打包”，我們這邊是增加了一個安卓的并行構建，我們可以進行多渠道的構建，利用集群資源縮短構建時間。

接下來介紹一下我們的關鍵技術：

關鍵技術1：

• 引擎 Editor 擴展，開發定制化的構建工具。下方第一個圖就是引擎內部的打包管線。當然這個打包管線也是 CI/CD 的。

• 資源構建配置和應用發布配置。我們通過配置文件管理不同模塊/不同平臺的發布構建參數，確保構建的一致性。

關鍵技術2：

• 構建狀態的監控以及CI/CD工具的集成。通過集成開源且社區活躍的 Jenkins，來串通整條管線的鏈路。大家也可以使用其他的一些 TeamCity 等比較優秀的 CI/CD 解決方案。

自動化是提升團隊效率的關鍵，通過自動化管線、我們將發布流程從原來的“數小時”縮短到了“30 分鐘以內”。

團結引擎體驗+性能的優化實踐

主要是異步 Shader 預熱技術。主要是使用團結引擎之后，我們發現其部分特性在性能優化、用戶體驗等是能帶來正向收益的。

游戲體驗痛點
Shader 編譯卡頓，是影響游戲體驗的一大難題。團結引擎提供了一些異步 Shader 預熱技術，幫我們有效解決了這一痛點。
異步 Shader 預熱技術的步驟

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

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

3.進度顯示：在加載界面顯示 Shader 預熱進度，提升用戶體驗感知。

方案效果
相比傳統的阻塞式預熱，異步預熱將游戲啟動時間減少了 50% 以上，消除了 Shader 編譯導致的卡頓體驗。

當然除了異步 Shader 預熱，我們也實施了一系列的性能優化措施

• 資源加載：我們實現資源分包和智能預加載，根據游戲進度預測資源需求；內存管理優化方面，通過精準的引用計數和資源生命周期管理達到了比較好的優化效果。

• 渲染優化：我們利用團結引擎的渲染管線優化，減少不必要的渲染調用。

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

Unity 官方微信

第一時間了解Unity引擎動向，學習進階開發技能

每一個“點贊”、“在看”，都是我們前進的動力