汽車之家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幫忙檢查語法和拼寫錯誤，並提供優化建議以提高文章的流暢性和可讀性。

作者|胡春源