AirMVC
代碼托管地址：https://git.oschina.net/wl/AirMVC
名稱含義：
airmvc喻意像空氣一樣輕的框架。這里的mvc并不是指傳統的mvc，這里沒有model，m表示的是ModulesManager。但有傳統mvc中邏輯視圖代碼分離的Controller和View。
框架用途：
主要目的在于降低代碼耦合和減少主程序體積。
airmvc引導使用者運用RSL技術和類似flex modules的模塊分離思想去設計你的程序，達到降低模塊之間的耦合度和減少主程序的體積的目的，有助于團隊合作，便于維護和減少程序初始化的時間。RSL技術可以使公用類不編譯到程序里，減少每個模塊的體積，而且在IDE中也跟普通類一樣有API智能提示，不影響開發。
使用方法：
Airmvc提供兩種模式，加載模式和非加載模式。加載模式是將各模塊分別編譯成swf，在運行時加載，因為使用了RSL以及各模塊在設計時互不依賴，所以打包的swf文件可以達到最小化；非加載模式則是把所有的模塊都編譯進主程序，方便調試，如果程序不是很大的話發布時也可以使用非加載模式。
具體步驟如下：
1、建一個庫文件，把mornUI和airmvc添加進去，并在這里添加項目的公共類，編譯成swc作為RSL。
2、新建工程，在工程里編寫模塊。每個模塊里都應該至少包括一個Controller的子類，和一個View的子類。Controller子類之間可以相互接發消息，宏觀表現為模塊間通訊。Controller子類需要注冊一個View子類，CV之間可以相互接發消息，即為模塊內通訊。因為每個模塊之間都是通過消息通訊，互不依賴，所以可以單獨編譯成swf而不受其他模塊影響。模塊內通訊是為了將邏輯代碼與視圖代碼分離，降低耦合度。
View子類本身是一個flash里的容器，可以隨意添加子顯示對象。它的子顯示對象我們在這里稱為ViewComponent。ViewComponent可以通過Dispatcher.send(msg:String, source:DisplayObject, ... args)方法來發送模塊內部消息，但不能接收任何消息。source參數傳ViewComponent(即this)本身即可，Dispatcher.send方法內會從其祖先容器中找到View的子類，并使用其向Controller子類發送消息的功能。
View子類的文件需要包含mxmlc的編譯參數，使用FlashDevelop的快速編譯功能打包模塊。因為swf的入口文件必須是可顯示類型，所以使用view作為編譯入口而不是使用controller。為了保證controller能編譯到swf里面，view中需要引用controller。推薦的作法是在view里使用controller的靜態常量作為消息名。
運作流程：
airmvc使用ModulesManager.init(config:*, isLoadMode:Boolean = true)方法來初始化。config可以是XML或ModulesConfig類，里面記錄了模塊的相關信息。這里簡單介紹一下使用加載模式的運作流程。
初始化的時候airmvc會記錄所有模塊的類定義和加載路徑，然后監聽以類定義作為消息名的消息事件。最后啟動在config里配置的第一個模塊，下一個模塊則通過第一個模塊發送消息來啟動。
例如消息名為”begin.BeginC”，ModulesManager收到這個消息后會從服務器加載對應的模塊到當前域，然后獲取begin.BeginC定義，實例一個BeginC并保持對它的引用，再去掉對這個消息的監聽，轉由BeginC監聽。以后其他模塊再次發送”begin.BeginC”這個消息的時候，由BeginC的startup(args:Array)方法來處理。我們可以在startup方法里進行初始化并注冊View的子類，打開或關閉窗口等的工作。
因為ModulesManager收到任何消息時都是執行加載模塊的方法，但此時它并不知道應該加載哪個模塊，所以第一次啟動模塊的消息應該帶有一個與模塊定義一樣的參數，例如，broadcast(“begin.BeginC”,”begin.BeginC”);
因為airmvc使用了morn的資源加載管理器，所以必須先初始化morn框架再初始化airmvc。
具體內容請參考demo。
Demo說明：
編譯core項目的時候需要引入airmvc和morn。
如果你想直接運行demo看效果可以直接運行bin下的Game.swf或Game-debug.swf。
Game.swf只有2KB，運行時加載assets/library.swf和assets/modules/里的模塊。
Game-debug.swf把需要用到的庫和所有模塊都編譯到同一個文件并且包含調試信息，因此比較大。
雖然在這個demo里加載模式的所有文件總和比非加載模式的要大，但當你的工程達到一定程度，編譯文件超過1M時，加載模式帶來的好處是顯而易見的。
作者附言：
airmvc只是筆者覺得自己在公司所用的框架比較臃腫，耦合度太高，不易維護，為了弱化（還不敢說能解決）這些問題而設計的。airmvc僅僅是筆者在了解了RSL技術和模塊分離思想后設計出來的，沒經歷過任何項目的考驗，如果在框架中埋了什么大坑請吐槽。筆者比較傾向簡潔高效的東西，如果你有什么好的方法去實現請留言。
airmvc可以說是專門針對游戲開發而生的吧，筆者自大四開始就一直跟flash游戲打交道，至此也快兩年了。受職業局限只能從接觸過的游戲框架去思考問題。現在在公司里用的框架是不考慮model發送消息來通知view去更新的，而是直接在Controller里接收Socket模塊發過來的消息然后由Controller更新視圖。筆者也覺得這樣比較簡便，所以在airmvc里沒有使用像puremvc那樣可以發送消息的Proxy類作為遠程代理。在airmvc里的model類結構跟項目有關，應該自行定義，一般是單純的值對象類(VO)就足夠了，或者建一個DataManager類來管理數據。
說到這里順便提一下puremvc框架。本來筆者是想使用RSL和模塊分離思想結合puremvc實現一套工作流的。在看完puremvc所有的源碼后，再一次讓筆者想到了“編程不僅是一門技術，更是一門藝術”這句話。puremvc巧妙地將6個設計模式（筆者能數出來的是6個）組合到一起來實現mvc設計思想。不過筆者覺得有一點不足的是解耦過度了，Command文件過多，維護起來相當麻煩（可能是筆者資歷尚淺而且又沒深入使用過puremvc的原因），江湖中也傳言puremvc普遍存在濫用的情況，初學者會越用越亂，所以筆者干脆就把以前用于規范項目結構的airmvc1.0升級到了airmvc2.0。現在比1.0多了一個類（實際是兩個，還有一個包外類），但功能卻有了很大變化。使用面向對象語言實現的框架本來應該考慮開放-封閉原則的，應該依賴接口而不是具體類，但想來想去都不知道怎樣使用接口，所以還望有高人能指點一二。
轉載于:https://www.cnblogs.com/wldragon/p/3551719.html
總結
- 上一篇： Maximum Subarray wit
- 下一篇： Android PowerImageVi