背景介紹

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

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

1.Unity 架構調研

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

1.1Unity與其他技術棧差異

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

1.2業界常用開源Unity框架

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

?UnityGameFramework

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

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

?QFramework

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

1.3場景適用性思考

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

?UnityGameFramework

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

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

適合需求明確的中重度游戲，商業化項目。

?QFramework

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

它與UnityGameFramework相比又太“輕”了，源碼少，可魔改的余地少。適合小而精的項目。

?其他

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

1.4架構關注點思考

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

?生命周期

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

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

?分層設計

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

?學習成本

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

?上線驗證

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

2.之家Unity架構設計

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

2.1分層設計

汽車之家Unity通用架構采用四層設計：邏輯層、中間層、基礎層和數據層。

?邏輯層

邏輯層處理不同項目的交互邏輯，調用中間層和基礎層功能。在邏輯層中，可以按照項目需求進行設計，而不需要考慮復用性。

具體模型和數據功能通過調用底基礎層和數據層接口現。

?中間層

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

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

?基礎層

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

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

?數據層

數據層用于后臺存儲、數據和模型信息等。只要使用同樣的后臺服務和美術規范，新的Unity項目就不需要對數據層再做兼容。

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

2.2架構圖

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

?Unity通用架構圖

?銷冠神器架構圖

2.3代碼示例

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

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

基礎層的NativeMessage在Plugin文件夾中，只有核心的發送消息和接受消息的能力

中間層的XGNativeMessage在Scripts/Manager文件夾中，繼承基礎層并添加業務相關的設置。

邏輯層在Module或Controller中對中間層的XGNativeMessage進行調用

大致流程如下：

?優勢總結：

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

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

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

3.架構收益

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

?代碼質量 升20%

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

?開發效率 升30%

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

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

?各項性能指標提升20%

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

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

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

?跨項目代碼復用度提升50%

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

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

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

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

數據層復用率100%，數據層由后端提供，使用相同的服務和美術規范。

4.總結

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

5.經驗分享

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

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

6.引用

分享一下本文所引用的架構鏈接：

UnityGameFramework：

https://github.com/EllanJiang/UnityGameFramework

QFramework：

https://github.com/liangxiegame/QFramework

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

作者簡介

胡春源

■ 主機廠事業部-創新項目團隊

■ 2022年2月入職汽車之家,先后負責VI銷冠神器和全息倉的架構,優化,功能開發等工作。現在主要負責Unity項目的架構和功能的相關工作。