汽車之家Unity前端通用架構升級實踐

隨著之家3D虛擬化需求的增加，各產品線使用Unity引擎的專案也越來越多，新老專案共存，代碼維護成本也隨之增加，代碼質量參差加之代碼規范仍沒有完全統一產生高昂學習成本進一步加重了專案維護負擔，

為應對這些問題，我們決定借助主機廠數科產品線銷冠神器VR版本大升級為貧訓，開發一套移動端通用Unity代碼框架，旨在統一Unity專案開發流程和規范，使不同專案開發人員能夠快速上手業務開發，實作不同專案之間代碼組件化復用，降低學習成本，提高專案的健壯性和復用性，

Unity通用架構核心想幫助Unity開發人員加速專案開發效率，該架構的設計基于大量的經驗和最佳實踐，旨在使專案開發更加高效和規范化，通過使用通用架構，開發人員可以輕松地構建高質量、健壯和可擴展的專案，同時降低學習成本和維護成本，該架構的模塊化設計也允許不同的專案之間實作組件復用，從而進一步提高開發效率，無論是初學者還是經驗豐富的開發人員，使用Unity通用架構都可以獲得更好的開發體驗，

與其他平臺相比，Unity的技術生態相對較為有限，缺少許多開源專案的支持，此外，Unity專案的型別繁多，從重度MMRPG專案到輕度虛擬仿真，這本身就是整理出一套通用的基礎架構十分困難的原因之一，與此同時，大多數基礎功能都需要收費，而大型公司也很少開源他們的源代碼，因此，與其他平臺相比，Unity想要整理出一套通用前端技術框架確實面臨著很多挑戰，

 下面分析一下市面上常見的Unity架構，并列舉不適合我們的原因，

?UnityGameFramework

UnityGameFramework使用一套UnityFramework和一套Gameframework對Unity進行了一次封裝，

在封裝的基礎上做了一些方便開發者使用的擴展，如ECS/UI等功能，

?QFramework

QFramework 是提供一套簡單、強大、易上手、符合 SOLID 原則、支持領域驅動設計（DDD）、事件驅動、資料驅動、分層、MVC 、CQRS、模塊化、易擴展的架構，

 以上兩個架構已足夠優秀，但是要集成到我們的技術堆疊中還是有很多挑戰：

?UnityGameFramework

• 這套架構太“重”了，使用A模塊必須依賴架構內的B模塊甚至C/D/E模塊，只想使用簡單的UI功能可能要把整套架構都遷移進來，

• 太“重”也引起了修改一個模塊會牽連很多其他模塊的問題，

• 適合需求明確的中重度游戲，商業化專案，

   

?QFramework

• 學習成本較高，需要理解很多設計原則才可以上手使用，

• 它與UnityGameFramework相比又太“輕”了，原始碼少，可魔改的余地少，適合小而精的專案，

?其他

• 其他架構都缺少線上足夠專案實際驗證與配套的開源生態，健壯性與擴展性無法確保，

好的架構應該注重以下幾個方面：

?生命周期

• 良好的生命周期設計，可以提供簡單而高效的生命周期管理機制使開發人員在合適的時機創建、修改和銷毀物件，

• 生命周期感興趣的同學可以深入了解一下Unity的MonoBehavior設計，

?分層設計

• 分層設計可以使代碼解耦，將參考后端多種架構設計理念，MVC、DDD、洋蔥架構等，免代碼耦合，為提高架構防腐度，降低續的化和重構提的頻率，

   

?學習成本

• 考慮到員工技能水平的參差不齊，學習成本是設計架構時最需要考慮的因素之一，，果架構過于“重”，那么就需要了解很多底層/中間層邏輯才能使用，且出現問題后也不易于修改，

   

?上線驗證

• 如果一套架構已經通過多個專案的上線驗證，那么就不太需要擔心架構中還有未解決的問題，開源架構都會列出自己的產品案例，

綜合上述總結，在設計Unity通用架構時重點考慮了分層設計，好的分層邊界能降低學習成本提高復用性，

汽車之家Unity通用架構采用四層設計：邏輯層、中間層、基礎層和資料層，

?邏輯層

• 邏輯層處理不同專案的互動邏輯，呼叫中間層和基礎層功能，在邏輯層中，可以按照專案需求進行設計，而不需要考慮復用性，

• 具體模型和資料功能通過呼叫底基礎層和資料層介面現，

?中間層

• 中間層對邏輯層和基礎層進行封裝，使得邏輯層呼叫更加清晰，基礎層有更好的抽象環境，

• 中間層又分為業務層和配接器層，業務層主要針對邏輯層進行封裝和特殊處理，而配接器層則對基礎層進行二次封裝，組合多個基礎層能力以應對復雜功能，

?基礎層

• 基礎層對基礎功能進行抽象，使用統一的介面設計，支持所有Unity專案，這一層可以使用市面上普及的解決方案如TMP/DoTween等，

• 基礎層應對功能抽象，不關心具體需求，具有良好的健壯性和可擴展性，

?資料層

• 資料層用于后臺存盤、資料和模型資訊等，只要使用同樣的后臺服務和美術規范，新的Unity專案就不需要對資料層再做兼容，

• 如有特殊需求，也可以在中間層對資料層進行處理，參考洋蔥架構設計，

以下是汽車之家Unity通用架構的架構設計圖與銷冠神器使用通用架構后的架構圖：

?Unity通用架構圖

?銷冠神器架構圖

 以原生端通信功能為例，說明分層和復用性設計在架構中的體現，

這里ativeMessage是一個可以與原生端進行通信的模塊，該模塊負責向iOS和Android平臺發送和接收訊息，用于處理一些原生互動的邏輯，

基礎層的NativeMessage在Plugin檔案夾中，只有核心的發送訊息和接受訊息的能力

?優勢總結：

這種設計可以確保基礎層有100%的復用性，使其可以方便地將其遷移至其他專案中使用，此外，中間層的封裝可以集中處理發送訊息的邏輯，從而避免在邏輯層中撰寫大量代碼，

采用分層設計的具有很方便的升級和擴展性，如果需要對其中某一層進行升級，可以直接修改對應層級的代碼，而不會影響其他層的功能，這使得系統更加靈活和可維護，

分層設計和復用性是非常重要的架構設計原則，在NativeMessage模塊的設計中，成功應用了這些原則，使得該模塊具有高度的可復用性和可維護性，

通用架構1.0上線后，我們量化了架構收益：

?代碼質量 升20%

底層和中間層按照功能解耦，可以提高代碼質量，也降低單個迭代SP的bug率20%以上，

?開發效率 升30%

• 按照相同的框架發可規范，高開單人力研發需求交付效率30%以上同時，不同專案組之間可以共享同一套底層功能，從而互相幫助和提高生產力，

• 代碼規范和模塊拆分的方式符合Unity行業的通用解決方案，這可以幫助Unity開發人員更快地理解和掌握專案的架構設計和開發規范，

?各項性能指標提升20%

• 通過架構升級，不僅解耦了代碼，還帶來了其他收益，例如，將GLB升級為AssetBundle，可以顯著降低記憶體占用量，并減少CPU負載30%以上，

• 功能模塊化設計使得我們可以更好地統計啟動時各個階段所占用的時間，并針對下載/加載等階段進行優化，從而使啟動時間降低了50%，

• 這些優化措施可以進一步提高應用程式的性能和用戶體驗，提高產品的競爭力，

?跨專案代碼復用度提升50%

• 通用架構需要支持之家的所有Unity專案，所以需要考慮不同專案中的代碼復用，代碼復用性可以根據分層由低到高來考慮，最底層的代碼復用性越高，

• 邏輯層復用率0%，因為每個專案的互動邏輯不同，過多考慮復用會引起很多問題，這一層不需要考慮復用性的設計，

• 中間層復用率60%，中間層對邏輯層和基礎層進行抽象和二次封裝，應該在開發程序中盡量考慮復用性，至少配接器層要能快速地復用到其他專案中，

• 基礎層復用率100%，基礎層抽象基礎功能，只考慮功能而不關心業務，

• 資料層復用率100%，資料層由后端提供，使用相同的服務和美術規范，

分層設計降低了上手成本，只要邏輯層足夠清晰簡單，那么初級程式員就可以很容易的去寫一些業務相關的功能，有能力的程式員可以持續為架構輸出健壯的中間層和底層能力，邏輯層只采用最簡單的狀態機設計，如果之后業務需求復雜也可以擴展成分層狀態機來實作復雜的業務需求，

架構設計應該注重分層設計與上手成本，當這兩點設計較好時，像易用性，復用性，解耦等優點就會自然出現，

分層設計可以讓業務代碼不會侵入功能代碼，而學上手本低也會帶來易維護，提效等好處，

分享一下本文所參考的架構鏈接：

UnityGameFramework：

https://github.com/EllanJiang/UnityGameFramework

QFramework：

https://github.com/liangxiegame/QFramework

本人技術水平有限，文筆水平也有待提高，歡迎任何建議和意見，

本文使用ChatGPT幫忙檢查語法和拼寫錯誤，并提供優化建議以提高文章的流暢性和可讀性，

作者|胡春源