【文章內容簡介】 pureMVC框架中，各部分通訊是用Notification消息，Proxy可以給Command和Mediator發(fā)消息，Command可以給Command和Mediator發(fā)消息，Mediator可以給Command和Mediator發(fā)消息，怎么樣？你現在是不是點暈了，這是正常的，其實我也有點暈！當你代碼寫到一定規(guī)模后，你會更暈。其實pureMVC框架這么設計本來是為了讓MVC各部分盡量脫耦，但這帶來一個負面情況就是消息發(fā)送與接收機制設計的太靈活了，靈活對小項目是好事，但對大項目來說，往往意味著混亂，甚至會導致災難。那怎么辦呢？只能靠我們的自覺性自我約束，簡化架構思想了。根據《pureMVC最佳實踐》中的建議，我的做法是這樣的，盡量使用Command，讓Command成為Mediator與Proxy之間通訊的唯一橋梁，Mediator和Proxy中發(fā)出的Notification，接收者一定是某個Command，然后再由Command處理并將結果轉發(fā)給真正的消息接收者，Command就算僅僅起一個轉發(fā)作用，僅僅有不到10行代碼，也要創(chuàng)建一個Command類。這樣不僅使你的架構更加清晰，而且也更符合MVC思想，Command類的大量存在還使你架構的業(yè)務邏輯具有了更好的封裝性和擴展性，可謂是一箭三雕，何樂而不為？唯一的負面影響可能是你需要創(chuàng)建和維護更多的Command類文件，但相對于優(yōu)勢而言，這點影響不算啥。 3，我知道現在可能還有一些朋友在用FLASH IDE寫代碼，這些朋友的執(zhí)著讓人欽佩，但我想任何一個熟練使用過FLEX BUDIER、FD或者FDT的朋友，都絕不會再回頭使用FLASH IDE寫代碼了?！粚Π?？不是談pureMVC的么？怎么扯到IDE上去了？這是因為我現在要討論的問題就和IDE有關，假如你現在用的還是FLASH IDE的話，除了隨時寫文檔外，我真的很難想出一個很好的方案可以讓你在沒文檔支撐的情況下，輕松掌握和隨時維護幾萬行代碼。可如果你使用的是FDT,就可以在沒有文檔的情況下，利用“ctrl + r”和“ctrl + 鼠標左鍵”，以及全文件搜索等工具，瞬間搞清楚代碼之間的聯系和邏輯，找出要修改的地方。OK，終于到pureMVC了。如果你使用的是FDT,并且開始嘗試使用pureMVC框架，可在使用的過程中，你發(fā)現你在寫主程序時，還是不停的使用“ctrl + 鼠標左鍵”，而不是“ctrl + r”，這說明你必須重新審視你對pureMVC框架的理解了，請審查你的Mediator類，看里面是不是充斥著大量的public方法，如果你的對象之間依舊是通過public方法進行引用，而不是通過Notification通訊的，那你也沒有必要繼續(xù)使用pureMVC框架了。 4，單例模式影響到底有多大？pureMVC是一個完全依賴單例模式的框架。單例模式似乎在AS界一直有很大爭議，這樣的話，pureMVC肯定也會有相應的爭議了。持反對意見的人，大多集中在“性能”和“團隊協作”方面，他們認為一個單例持有過多引用會帶來性能問題，而且生怕在團隊協作中自己的單例類被人無意修改，引發(fā)離奇的BUG。性能方面，我之前也沒做過10W以上的項目，不敢妄言，但10W行以下的項目，絕對沒有問題，如果你兩三萬行的架構就開始碰到主架構性能問題，估計十有八九是自己的代碼寫的有問題；團隊協作方面，我覺得pureMVC的Fa231。ade模式是非常靈活好用的，大家可以略做討論，制定一個簡單的規(guī)則，比如模塊只能通過fa231。ade獲取數據和發(fā)送Notification，不能直接調用主程序其他CLASS，只要架構程序員不犯錯，模塊程序員甚至連犯錯的機會都沒有，如果他們有，還是你的架構思路有問題，請繼續(xù)審視自己的代碼。反正單例模式的問題到底是什么，我到現在也沒完全搞懂，主要是我們的項目沒碰到過此類問題，希望碰到過的朋友能再仔細跟火山說說，我也好弄清楚問題到底出在哪里了，自己以后可以更好的避免此類問題發(fā)生。 額，框架部分先談上面4點吧，趕快進入下一個話題，模塊劃分：模塊劃分主要包括“核心模塊劃分”和“子模塊劃分”。核心模塊的劃分思路是這樣的：它們是游戲啟動所必須的，相互之間是緊密聯系的，還要經常的被子模塊調用；而相對的，子模塊的劃分思路是：他們在游戲啟動過程中不是必須的，可以在游戲過程中再加載，子模塊相互之間基本上完全沒有聯系，一個子模塊的增加和刪除不會影響到任何其他子模塊，子模塊可能需要調用主程序的接口或者獲得主程序的數據，但主程序絕對不應該依賴某個子模塊。 明確了模塊劃分思路再具體看看哪些部分應該劃分為核心模塊，哪些部分應該劃分為子模塊。一般情況下，核心模塊按照游戲啟動順序包括：一個殼子SWF → 配置文件包 → 登錄注冊SWF → 主程序SWF → 主UI的SWF → 公共素材包。而子模塊相對來說簡單很多，比如具體的某個小游戲，某個場景，以及某個場景里的觸發(fā)功能等等。下面我對核心模塊逐一略做解釋?！耙粋€殼子SWF”：這是一個體積很小，但意義很大的SWF；它后面總是跟著隨機變量，確保每次用戶加載的都是最新的；它里面定義著一些需要經常更新而且每次更新都必須保證用戶也在第一時間就得到最新值的變量；它里面最好有一個簡單背景圖，保證用戶在超低網速的時候輸入游戲網址不至于長時間面對一片空白；它里面有安全策略的設定，是我們游戲和很多第三方平臺合作的基石；它里面還定義著主程序被加載進來之前的游戲啟動流程等等。“配置文件包”：核心模塊版本號啊，全局文字說明啊，service接口定義啊，各個核心模塊需要的配置信息啊什么的，一般是一些XML文件?！暗卿涀許WF”：這個簡單，在加載重量級的SWF前，先加載登錄注冊SWF,可以保證用戶第一時間就能打開登錄注冊界面，而且可以有效節(jié)省服務器帶寬?！爸鞒绦騍WF”：這個就是我前面費了好大勁講的主程序部分了?！爸鱑I”：主程序和主UI為什么要分開兩個SWF，我前面已經提過了，后面還有說明，這里暫時不講?！肮菜夭陌保汗菜夭陌且粋€游戲不可缺少，但也不能過分依賴的東西。它包括一些全局的道具和效果，比如表情、技能特效、場景傳送門等等。公共素材包里面最好就是一些簡單的動畫，體積小功能簡單，嚴禁在公共素材包里添加上百K的東西，或者代碼上百行的小模塊，公共素材包建議500K以下。 看了上面的講解，你可以能覺得核心模塊分那么多，太麻煩了。不錯，在我看來，對SWF加載流程的分解和控制，對異步程序的掌控正是衡量一個AS程序員是否經驗豐富，是否足夠老道的重要指標，很多從其它語言轉到AS并有多年編程經驗的朋友，架構方面可能和AS程序員差不多，甚至比很多自學成才的AS程序員做的更好，但這方面往往不如長期與CPU和SWF體積搏斗的老牌AS程序員。核心模塊劃分的越合理，用戶體驗往往越好，后期編寫和維護代碼的效率會越高，但在前期會比較麻煩，而且對架構師的架構經驗和能力必須提出更高的要求。什么都不分，主程序、素材、核心模塊都弄在一個SWF里，用戶一開始必須先下載完這個SWF,或者弄了一堆核心模塊和超多公共素材，用戶一開始必須面對loading條不停的周而復始，必須等所有核心要素全部加載完成才能進行一些基本操作的做法，從架構角度上講，是最簡單的做法，因為不用過多考慮復雜的異步和SWF拆分問題，但從用戶體驗和長遠的開發(fā)維護上講是非常不利的。根據我們的經驗，用戶登錄前加載的所有資源體積應該控制在200K左右，而用戶進入游戲主場景前，加載的資源總數應該控制在1M左右。還有前面提到過的那位用了pureMVC后項目編譯一下要十幾分鐘的朋友，估計就是把所有東西都弄到一個SWF里的做法。主程序隨便改動測試一下，就要十幾分鐘，牽一發(fā)而動全身，開發(fā)效率從何談起？根據我們的經驗，任何主程序、核心模塊還有子模塊的編譯，都必須在10秒以內，這才是合理的——我的機器是07年花了3000多買的戴爾品牌機?！勍曛骷軜?，接著談主UI。主UI一般指主要的人機交互界面，這里的主UI區(qū)分于主架構中的mediator，當你看過pureMVC文檔后，你就知道了，mediator只不過起到一個真正的V和pureMVC框架之間的橋梁作用，pureMVC里的mediator其實并不實現什么功能，真正的功能都是在主UI里實現的。但主UI又不得不算是主程序的組成部分，因為它不像其他模塊，基本上只需要調用主程序的接口就行了，本身并不需要對主程序提供接口。而主UI作為用戶操作界面，必須大量的向主程序的mediator提供接口，或者發(fā)送events。所以主程序和主UI之間的配合必須非常密切才行。 不同的游戲類型，可以選擇的UI解決方案也不同。策略類非常適合用FLEX；MMORPG這類標準網游，非常適合用ASWING；而像我們海底世界這類游戲界面非?？鋸垼瑳]什么標準規(guī)則，又不是太復雜的界面，還是適合自己開發(fā)。相信任何有過游戲項目經驗的人都應該能理解，UI也是FLASH開發(fā)中的重頭戲，很多細節(jié)的處理非常麻煩，在項目早期具有很大的工作量。還是以我們的項目為例，我們的UI架構思路是這樣的： 1，所有的界面組件都是直接拖放在stage上的，其功能代碼大部分都是在發(fā)布時編譯的，基本上不用new的方式。這種方式的好處是方便編輯界面，從總體上直觀的把握所有的UI，減輕程序運行時的負擔，同時避免addToStage帶來的諸多問題。缺點是，當UI膨脹到一定規(guī)模時，可能會需要你有一臺配置比較好的電腦——哎，說到這里我就傷心啊，我那臺玩魔獸效果全關還卡的電腦，一直陪伴我的整個UI開發(fā)歷程。 2，UI的FLA層次結構是這樣的：第一層是文檔類或者與UI主類關聯的某個MC，我們選用的是MC的方式,因為MC的方式更靈活；第二層是這個MC里的所有組件，這些組件大部分是根據功能劃分在一起的一組元件，比如你的個人面板，而這個組件本身也是個MC；第三層是組件里的所有元件或者共用組件，元件就是背景啊，按鈕啊什么的，而共用組件比如滾動條啊翻頁組件啊什么的；主要的就這三層，其實那些共用組件MC再往里面雙擊還可以劃分一層。對應FLA的層次結構，AS的結構如下：文檔類或者主MC關聯的類是第一層，這個類里持有所有的界面元件的引用；第二層是這些界面元件對應的組件CLASS,組件的功能都是在這里實現的，比如個人面板的MC將會對應一個MyPanel的CLASS,這個CLASS里實現MyPanel的所有功能。至于CLASS和元件之間是怎么對應的，我用的是一種松耦合的代理模式，也就是將MyPanel對應的MC作為參數傳遞給MyPanel這個CLASS,而這個CLASS會有自己的私有變量記錄對應MC里需要進行操作的元件，具體到功能實現時，從代碼層面上看，就好像CLASS操作的都是自己的私有變量，而不是直接操作界面元件，這樣，當界面元件修改名字時，CLASS的改動很小。而且這種代理模式可以實現一個CLASS代理不同的元件，當界面只是需要修改外觀，不需要修改功能時，非常方便。那么這些CLASS是在哪里初始化并獲得它要代理的MC呢？正是在主MC對應的UI主類中，比如當獲得MyPanel對應的MC后，就會立刻public var myPanel:MyPanel = new MyPanel(myPanel_mc)。當所有的組件注冊完成后，這個UI主類就持有了所有組件的引用，可以方便主程序調用；代碼的第三層其實就是共用組件，比較特殊的是，我的共用組件，比如滾動條，也是用代理模式寫的。 3，完全代理模式為我們創(chuàng)造了一種可能，就是把UI和UI對應的代碼分開編