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

App類的職責:

1.接收Unity的生命周期事件。

2.做為游戲的入口。

3.一些框架級別的組件初始化。

本文只介紹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等等。 看下項目中的實現:

///
/// AR模塊測試入口
///
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就這樣.... #### 對未來的一些暢想:1. 最近在想著如何為項目引入自動化測試,有一個思路是這樣的,界面的所有輸入包括點擊事件等都包裝成一個命令或者一個消息。測試的時候只要不斷地自動發送消息或者命令就好了。當然只是個暢想。 那和這個有毛關系呢,有啊!界面跳轉的時候可以發命令或者消息就夠了啊,這樣還很方便。 但實際上有很多問題,包括模塊的最上層如何拿到一些界面組件的權限比如按鈕等等。處理命令或者消息的話那么所有的輸入都要經過一層過濾。。。。額。。想想好麻煩。。。以后吧。。。以后吧。。2. 框架的很多組件都是基于字典實現的。字典真好用,23333。以后還是想辦法能改的都改成List吧。#### 歡迎討論!附:[我的框架QFramework地址](https://github.com/liangxiegame/QFramework)轉載請注明地址:[涼鞋的筆記](http://liangxiegame.com/)微信公眾號:liangxiegame#output/writing/Unity游戲框架搭建

轉載于:https://www.cnblogs.com/liangxiegame/p/Unity-you-xi-kuang-jia-da-jian-qi-jian-shao-jia-ba.html

總結

以上是生活随笔為你收集整理的Unity 游戏框架搭建 (七) 减少加班利器-QApp类的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。