汽車之家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：

QFramework：

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

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