Unity 游戲框架搭建 2017 (七) 減少加班利器-QApp類

本文轉載自查看原文 2017-11-07 09:27 1064 blog

本來這周想介紹一些框架中自認為比較好用的小工具的,但是發現很多小工具都依賴一個類----App。

App 類的職責:

接收 Unity 的生命周期事件。
1. 做為游戲的入口。
2. 一些框架級別的組件初始化。

本文只介紹App的職責2:做為游戲的入口。

Why?

在我小時候做項目的時候,每次改一點點代碼(或者不止一點點),要看下結果就要啟動游戲->Loading界面->點擊各種按鈕->跳轉到目標界面看結果或者Log之類的。一天如果10次這種行為會浪費很多時間,如果按照時薪算的話那就是......很多錢(捂嘴)。流程圖是這樣的:

為什么會出現這種問題呢?

1.模塊間的耦合度太高了。下一個模塊要依賴前一個模塊的一些數據或者邏輯。 2.或者有可能是這個模塊設計得太大了,界面太多,也會發生這種情況。

解決方案:

針對問題1:在模塊的入口提供一個測試的接口,用來寫這個模塊的資源加載或者數據初始化的邏輯,...什么!?...你們項目就一個模塊...來來來我們好好聊聊..... 針對問題2:在模塊的入口提供一個測試接口,寫跳轉到目標界面的相關代碼。流程圖是這樣的:

雖然很low但是勉強解決了問題。

階段的划分

資源加載亂七八糟的代碼和最好能一步跳轉到目標界面的代碼,需要在出包或者跑完整游戲流程的時候失效。如何做到?答案是階段的划分。我的框架里分為如下幾個階段: 1.開發階段: 不斷的編碼->驗證結果->編碼->驗證結果->blablabla。 2.出包/真機階段: 這個階段跑跑完整流程,在真機上跑跑,給QA測測。 3.發布階段: 上線了,yeah!。

對應的枚舉:

public enum AppMode { Developing, QA, Release }

很明顯,亂七八糟的代碼是要在開發階段有效，但是在QA或者Release版本中無效的。那么只要在游戲的入口處判斷當前在什么階段就好了。開始編碼:

/// <summary> /// 全局唯一繼承於MonoBehaviour的單例類，保證其他公共模塊都以App的生命周期為准 /// </summary> public class App : QMonoSingleton<App> { public AppMode mode = AppMode.Developing; private App() {} void Awake() { // 確保不被銷毀 DontDestroyOnLoad(gameObject); mInstance = this; // 進入歡迎界面 Application.targetFrameRate = 60; } void Start() { CoroutineMgr.Instance ().StartCoroutine (ApplicationDidFinishLaunching()); } /// <summary> /// 進入游戲 /// </summary> IEnumerator ApplicationDidFinishLaunching() { // 配置文件加載 類似PlayerPrefs QSetting.Load(); // 日志輸出 QLog.Instance (); yield return GameManager.Instance ().Init (); // 進入測試邏輯 if (App.Instance().mode == AppMode.Developing) { // 測試資源加載 ResMgr.Instance ().LoadRes ("TestRes",delegate(string resName, Object resObj) { if (null != resObj) { GameObject.Instantiate(resObj); } // 進入目標界面等等 }); yield return null; // 進入正常游戲邏輯 } else { yield return GameManager.Instance ().Launch (); } yield return null; } }

首先App是Mono單例,要接收Unity的生命周期. 然后要維護一個AppMode類型的變量,便於區分。

之后在 ApplicationDidFinishLaunching 中有這么一段代碼:

        // 進入測試邏輯 if (App.Instance().mode == AppMode.Developing) { // 測試資源加載 ResMgr.Instance ().LoadRes ("TestRes",delegate(string resName, Object resObj) { if (null != resObj) { GameObject.Instantiate(resObj); } // 進入目標界面等等 }); yield return null; // 進入正常游戲邏輯 } else { yield return GameManager.Instance ().Launch (); }

在這段代碼中做了階段的區分。所有的邏輯都可以寫在這里。這樣基本的需求就滿足啦。

還有一個問題:

假如一個游戲的業務邏輯分為模塊A,B,C,D,E,分為5個不同的人來開發,那App是一個mono單例,除非不提交App代碼,否則每次都要解決沖突,同樣很浪費時間。怎么辦? 答案是通過多態來解決,先定義一個ITestEntry接口,只定義一個方法。

    /// <summary> /// 測試入口 /// </summary> public interface ITestEntry { /// <summary> /// 啟動 /// </summary> IEnumerator Launch(); }

然后每個模塊分別實現ITestEntry接口,例如AModuleTestEntry,BModuleTestEntry等等。看下項目中的實現:

/// <summary> /// AR模塊測試入口 /// </summary> public class ARSceneTestEntry :MonoBehaviour,ITestEntry { public IEnumerator Launch() { Debug.LogWarning ("進入AR場景開始"); yield return GameObject.Find ("ARScene").GetComponent<ARScene> ().Launch (); yield return null; } }

App類中階段區分的代碼要改成這樣:

        // 進入測試邏輯 if (App.Instance().mode == AppMode.Developing) { yield return GetComponent<ITestEntry> ().Launch (); // 進入正常游戲邏輯 } else { yield return GameManager.Instance ().Launch (); }

因為Launch方法的返回類型是IEnumerator,所以很好控制跳轉的時間。看下在Unity中是什么樣的:

每個模塊都要有個 App 的 GameObject，原因是因為,框架的其他的組件依賴於App,也想過把依賴的部分抽離出來,那樣的話可能命名為 QMonoLifeCircleReceiver 和 ModuleEntry 之類的,這樣遵循了單一職責原則。不過孰優孰略各有千秋。我覺得叫App更直觀一些,因為入口、組件初始化、啟動某個模塊應該是通常放在一起更人性化,還有一些 ApplicationDidEnterBackground之類的事件還是模仿 iOS 的 AppDelegate 人性化一些。

如果要跑完整流程,那么把模塊的 App GameObject 關掉就好了。要注意一點是:在整個游戲的入口場景要有個 App GameObject 放在上面,並且 AppMode 要為Release 或者 QA。這樣才能正常地跑起來。

OK就這樣....

對未來的一些暢想:

最近在想着如何為項目引入自動化測試,有一個思路是這樣的,界面的所有輸入包括點擊事件等都包裝成一個命令或者一個消息。測試的時候只要不斷地自動發送消息或者命令就好了。當然只是個暢想。那和這個有毛關系呢,有啊!界面跳轉的時候可以發命令或者消息就夠了啊,這樣還很方便。但實際上有很多問題,包括模塊的最上層如何拿到一些界面組件的權限比如按鈕等等。處理命令或者消息的話那么所有的輸入都要經過一層過濾。。。。額。。想想好麻煩。。。以后吧。。。以后吧。。
框架的很多組件都是基於字典實現的。字典真好用,23333。以后還是想辦法能改的都改成List吧。

歡迎討論!

轉載請注明地址：涼鞋的筆記：liangxiegame.com