第一：引言

記得我剛接觸FLASH那會兒，應該是FLASH6末期吧，國內的flash web還是很少的，牛X的更是屈指可數，而且這個時候所謂的牛X，一般都是指效果很酷，技術強的基本沒有。其實這是必然，國內早期的flash web開發者大都是由FLASH動畫製作者或是網頁設計師轉變而來。他們非常熱衷於片頭和過渡效果，為此不惜犧牲流覽者的等待時間並吃掉流覽者的CPU。這就是為什麼現在好多人一談起flash web就覺得它體積大，效率低的根源了。當然如果是真對個人網站，這也無可厚非，個人網站信息量小，大多都是一次性流覽的網站，酷眩的效果可以讓人過目不忘，尤其是在那個年代，還能讓人耳目一新，這是普通HTML網頁所不能企及的。印象中最深刻的應該是那款綠色版的龍城閃客，駭客帝國似的特效和動畫把我徹底征服。

可是後來MM公司對FLASH的連續兩次升級都把重點放在了AS上，AS內置類快速膨脹，功能急速擴展，AS2.0更是趨向標準的物件導向語言。這時候一大批程式師又被吸引進來了，尤其是那些有C或者JAVA背景的牛人們。可惜的是，他們總喜歡用程式師的思維去評判flash web，他們甚至用軟體發展的標準去往flash web開發上硬套。結果是必然的，他們失望了，可這時候大部分人不是從自己找原因，他們非常武斷的就把責任推給了FLASH：「flash web結構混亂，基於時間軸的AS寫法奇怪，flash web不適合大規模的商業應用開發！」。就這樣flash web的前途被宣判了死刑。

由於上述flash web在中國的特殊發展歷程，造成現在一個非常有意思的現象：很多以前動畫很牛的前輩們，都去職業搞動畫片製作了，並為FLASH動畫的產業化和商業化勇敢探索著，有些已經取得了輝煌成就；而FLASH7之後進來的程式牛人們，直接從事FLASH遊戲開發和FLASH RIA應用開發了，他們更習慣基於事件的程式設計和物件導向的開發模式，時間軸對他們的意義已經不再重要。這樣以來flash web開發成為一個中間斷檔帶，也是人才最稀缺的地帶。很多目前從事flash web開發的人員應該都是從HTML網頁製作人員簡單學了一些FLASH後過渡過來的，他們即非動畫高手也非程式高手，更多的是網頁設計高手。然而這些設計高手又總愛拿FLASH跟PS比，結果flash web開發又沒得到好的口碑。flash web現在只好和一群半道出家的非專業人士一起淪落在FLASH業內的最底層——嗚呼悲哉！

好在還有火山和像火山一樣的少部分理想主義者，並不是把錢當做全部人生追求。至少我現在還是天真的堅持：我要為我的愛好而活，然後用我的愛好賺一點吃飯的錢就可以了，反正我短期內是絕對不會為了賺更多的錢而改變自己的目標的！我從最開始學習FLASH就是以做網站為目的，這兩年多來，我所學的一切都是以flash web開發和應用為核心，我幾乎嘗試了所有常見的flash web結構形式，我時時刻刻的都在考慮如何在保存FLASH優勢的情況下，又能開發出有實際應用價值的高效率的商業作品，最終將flash web開發模式化，快速化。

那麼flash web的優勢在那裡呢？對於展示性的網站，當然是FLASH酷眩的效果，這點已經被大多數人所共識。但對於包含大量資訊，需要經常更新的flash web，它的最大優勢就不再可能是效果，因為flash的效率實在不敢恭維，大量的效果會影響人們對資訊的查詢效率，現在網路頻寬也不容樂觀，大量的動畫必將造成SWF體積膨脹，影響流覽速度。那麼大中型資訊類flash web的優勢到底是什麼呢？在火山看來，最大優勢只有兩點而已，一是介面佈局靈活，二是資料的無刷新更新。還記得我們以前在DW中拉表格的痛苦嗎？還會為了網站佈局工整寫一堆CSS和JS嗎？還用得著每次更新資料就打開一個新頁面嗎？flash web的兩大優勢使這些歷史的痛苦都成為了過去。而且，這兩點如果處理恰當的話，就已經足夠給普通的流覽者帶來全新的用戶體驗了。

我的愛好是flash web開發，而這塊兒又是人才斷檔地帶，正好適合我這種程式和設計兩邊都不靠的人生存，天時地利人和，看來flash web開發對我來說真的是天命所歸，我還有什麼道理不繼續堅持下去呢！但畢竟我這兩年來一直也都是處在學習和探索階段，還不是真正的理論研究階段，兩年時間太短了！我的很多想法和理論還很不成熟，甚至是幼稚的。我現在拿出來和大家分享，不求說服誰或者證明什麼，只求能給後來人一些啟發，同時自己也好好總結一下。下面就粗淺的談談我目前對flash web尤其是flash web結構的認識吧。

第二：Flash web結構概述

打開68design這類酷站收藏站，我們不難發現現在的flash web真是百花齊放、百家爭鳴。形形色色、奇奇怪怪的flash web使人應接不暇、撲朔迷離。自由靈活是flash web的生命力所在，但這也正flash web商業化的主要瓶頸之一。商業最看重的是效率，而無規則便無效率可言。那麼flash web是不是真的就一點規律都沒有呢？非也！縱觀現在所有的flash web（FLASH RIA應用程式除外，比如FLASH塗鴉板、地圖等等），不管它們技術怎麼牛，效果怎麼酷眩，都不能逃脫以下四層結構：
1、動畫層（Movie）
2、背景層（Background）
3、資料顯示層（Display）
4、數據層（Data）

這些概念其實都不新穎，看到這些我自創的名詞，一些有經驗的開發者們肯定立刻都能猜出一二來。但由於這些概念以前並沒有權威的提法，至少我沒見過，為了以後論述方便，我今天在這裡正式恬不知恥的給這種結構起個名字：火山FLASHWEB四層結構式，或者火山MBDD結構式，以下簡稱MBDD式。如果由於我的孤陋寡聞導致和某些官方或者前輩的提法相似的話，我在這裡提前說聲：如有雷同純熟巧合：）

我以下的所有討論都將緊緊圍繞這四層結構進行，因為在我看來，flash web的靈魂就是它的結構，一個flash web的技術含量不是看它某些特效多眩，更不是看這個WEB中有個什麼新穎的、牛X的技術應用，關鍵是要看它通過什麼手段有效的把各種元素統一起來的！如果你曾經試圖想把flash web做大的話，我相信你在這方面的體會肯定不會比火山少。

最後我要提前說明的一點是，MBDD式是對所有flash web的概述，很多flash web根據其功能不同可能缺失其中某些層，下面我會仔細講解。至於flash web涉及的其它方面，我都略過，畢竟我這篇是總結性的文章，不是教程。flash web也不是我一篇文章就能寫全面的。

第三：淺談過渡動畫層

早期的flash web大都含有豐富的過渡動畫，比較典型的是：龍城閃客和梵天。最新版的龍城閃客還給每個子欄目的過渡也添加了絢麗的動畫效果。總的來說動畫層可以分為三種：
1、開場動畫
2、欄目過渡動畫
3、點綴動畫

先來談談開場動畫。開場動畫時間一般比較長，反映在時間軸上就是好長好複雜的一段幀結構。第一幀一般是loading畫面，最後一幀一般是網站的主框架。這裡就存在一個如何安排幀的問題。記得以前見有人在論壇上發帖說flash web最好不要分場景，其實他的說法是片面的，對於沒有過渡動畫的flash web來說，完全可以這麼做，可對於大量過渡動畫的flash web就另當別論。如果你不分場景，必然造成代碼和動畫混雜在一起。而一般來說，控制網站主要功能的代碼都在過渡動畫之後的幀上，在後續的代碼編寫過程中，你每次可能都要把時間軸拉到幾百甚至是上千幀之後，這也非常的麻煩。火山的建議是：把過渡動畫做在一個場景中，然後複製過渡動畫最後一幀的網站框架幀到第二個場景中，主要的功能代碼也都將集中在這個場景，這樣就有效的把動畫和代碼進行了分離，編寫代碼時時間軸看上去也舒服些。還有一種比較常見的做法是，給過渡動畫加上一個skip按鈕，如果流覽者點擊了這個按鈕，馬上就會loadMovieNum(main.swf,0)進一個新的main.swf，而這個main.swf就網站的主框架了。這種做法與前一種其實類似，只不過它把動畫和主框架從分在兩個場景變成了分在兩個SWF，而且還能讓流覽者自己選擇是否觀看過渡動畫，有更大的靈活性。

再來談談欄目過渡動畫。欄目過渡動畫主要指在你點擊一個導航按鈕打開一個新的欄目時所顯示的一段動畫，還拿最新版龍城閃客舉例，它在打開一個新的子欄目時會先把上一個欄目變成很多小方塊，然後飛到左邊的神秘空間中，這時又從神秘空間裡發出一道神秘的光線，並在這道光線的沐浴中出現新欄目的載入畫面。我沒有破解過最新版的龍城閃客，不知道他到底是怎麼安排這個動畫的，但我有自己的想法。如果這個過渡動畫是集成到主框架的，那過渡動畫中最好不要寫代碼，而是在主場景中通過偵測過渡動畫的當前幀和總幀數來確定何時載入子欄目SWF；如果每個子欄目的過渡動畫效果不同，那最好把每個子欄目SWF處理成一個獨立的網站，其結構應該遵循在“開場動畫”中提到的規則。

點綴動畫沒什麼好說的，你把它想像成在HTML網頁中起美化作用的GIF動畫就好了，當然它比GIF動畫更生動，使用也更靈活，還可以具有交互性。總之我的主要思想就是儘量把動畫和代碼分開，以便自己以後方便查找和修改代碼。同時保證網站結構工整。

第四：淺談背景層

背景層，顧名思義就是網站的背景，看上去很容易理解也很簡單，其實它蘊涵著很多知識和技巧，如果處理不善，將直接影響flash web的用戶體驗。
我在這裡把背景層分為以下三種模式：
1、FLASH模式
2、PS模式
3、混合模式

FLASH模式：所謂FLASH模式，就是直接在FLASH中完成網站主體框架的繪製，並利用FLASH完成框架修飾內容的填充。這種模式比較適合介面簡單，色彩單一，高效實用的flash web。它充分利用簡單向量圖形體積小的優勢，同樣一個畫面，它的體積將比點陣圖小很多。所以這樣的網站如果處理恰當的話，完全可以比同種樣式的常規HTML網頁體積更小。同時由於它直接在FLASH中繪製，非常便於修改以及同其它層結合。

PS模式：這種模式我們可以和傳統的網頁製作進行類比。傳統網頁都是先用PS繪製介面，然後切片匯出為網頁，再在DW中進行編輯。flash web開發一樣可以採用這一流程，利用PS強大的點陣圖處理功能彌補FLASH繪圖方面的不足。但是在切圖的時候，它和HTML網頁切圖思想不同，在flash web中經常要把動畫因素和各元件之間的遮擋關係考慮進去，所以我一般都是把每個欄目切成一個JPG點陣圖，涉及動畫和層級關係的元素則獨立匯出為PNG透明圖像。這樣雖然方便了在FLASH中的後期製作，但造成網站體積會一定程度的加大。為了優化下載和用戶體驗，我們可以利用FLASH流媒體的特性，把體積較小或者獨立性比較好的欄目放在開始的幀先顯示出來，相互聯繫緊密的主功能欄目放中間，體積較大獨立性也較好的欄目放最後顯示。當然不要忘記用一個loading條時刻提醒流覽者各欄目載入狀態，不至於使他們失去繼續看下去的信心。這種模式一般適合網站各欄目獨立性較好，網站色彩豐富且含有大量動畫效果，元件層級複雜的網站。另外，在我寫這篇文章的時候，從黑羽那裡得到消息，最新版的FLASH真的可以支持PSD了，而且還能保留原始圖層，再加上以後網速越來越快，PS模式在將來很有可能會大行其道。

混合模式：混合模式就是綜合利用PHOTOSHOP和FLASH，取長補短，相得益彰。先用PS設計好網站背景圖，並把內容顯示部分留空，就像設計HTML網頁一樣。然後不需切圖直接匯出為JPG，並導入FLASH。再在這張大背景圖片上新建一層，用製作動畫常用的鋼筆勾邊上色技術把網站主框架描一邊，這就涉及到我後面要講的“資料顯示層”，資料顯示層主要由與背景色相似的工整的向量色塊組成，當然像火山一樣喜歡偷懶的人也可以適當添加點陣圖，但資料顯示層體積最好控制在30K以內。資料顯示層成型後，一定要記得把背景點陣圖放在資料顯示層之後的幀上。現在大家應該差不多能猜出這種模式的優勢在那裡了吧！？對，我們可以利用FLASH流媒體的特性，無須等到整個SWF都下載完畢後再顯示網站，flash web的loading時代該過去了！偉大的流式時代就要來臨了！我們完全可以先把資料顯示層顯示出來，讓流覽者以最快的速度得到他們想要的資訊，與此同時，悄悄的下載背景層，由於我們的資料顯示層和背景層的顏色和佈局都相似，甚至是完全匹配的，所以背景層下載完成並顯示出來的一刹那也不會給流覽者帶來太大的跳躍感。當然這樣無疑加大了工程量，要求設計師的PS和FLASH都不能弱。所謂魚和熊掌不能兼得，我們必須根據具體的專案進行取捨，看是否真的有必要採用這種模式。火山個人門戶V3主站中，由於背景圖片體積過大，我便採用了這種模式，據大部分人反映，用戶體驗還是很好的：）

總之三種模式可謂各有優缺點，如何取捨還是要根據具體專案決定，當然，團隊和個人能力也是重要因素。一般來說，程式師出身的可能比較喜歡FLASH模式；傳統網頁設計師出身的一般比較喜歡PS模式；半道出家，什麼都懂點的傢伙們看了火山這篇文章後，估計就要開始嘗試混合模式了。

第五：淺談資料顯示層

前面講背景層的時候已經提到了資料顯示層。由於火山基本不使用元件，所以對火山來說，資料顯示層主要是指TextField，或者用MC簡單包裝的TextField。它們是網站資訊的主體部分，一般都是動態的調用外部資訊。當然，由於我用MC進行了包裝，它們也可以作為按鈕使用，比較常見的就是標題列表，比如我主站上三個子站最新發佈列表。

就像我前面說過的，資料顯示層要儘量的精簡體積，它是一個flash web流覽效率的關鍵，不適合做大量的效果，尤其是點陣圖效果。而它的結構也要儘量清晰且工整，便於代碼控制。對於FLASH模式的網站可以考慮直接將TextField放到_root上；而對於PS模式和混合模式，則最好還是用MC對TextField進行包裝，以保證網站各欄目的獨立性。

第六：淺談數據層

資料層可謂是整個flash web的中樞神經系統，負責flash web的所有資料顯示和交換，還有功能的實現，甚至是動畫的控制。在正式開始講解資料層之前，我想先回顧一下我自己的代碼編寫歷史。最開始的時候，我一般都是直接把代碼寫在元件上，這樣寫的局限性比較大，很多功能無法實現；後來我開始嘗試在時間軸上寫，可由於當時能力有限，部分代碼還是要寫在元件上，這樣就造成代碼混亂，時間一長，自己也記不清代碼到底寫哪兒；AS能力稍微強點後，我就不再在元件上寫代碼了，而是全部寫在時間軸上，一般都是每個欄目，或者是每個MC包含自己獨自的代碼，這樣做的好處是，代碼分佈比較清晰，而且代碼獨立性比較好。但即便這樣做，還是不夠理想，因為如果網站MC嵌套結果非常複雜的話，每個MC的代碼都獨自包含，那麼代碼可能會寫在很深層的MC上，而且MC很多話，代碼也將隨之分佈很散，這樣還是不方便代碼的集中管理，也不容易從總體上把握網站資料之間的聯繫；那麼現在的我怎麼做呢？由於我現在不僅AS已經玩的很熟，而且能夠從宏觀上對網站結構進行比較到位的把握，所以我已經完全有能力根據網站的特點和功能在正式動工之前就把網站劃分為若干功能模組，然後用我自創的MC三幀式去完成每個模組的實現。打開我網站的原始檔案，你會發現，除了主時間軸和主時間軸上一系列具有“三幀式”結構的空MC外，其它地方極少有代碼，可以說核心代碼已經完全從網站中分離了出來。在主時間軸上，一般來說第一層是AS層，第二層可有可無的標籤層，第三層就是資料層，全部的“三幀式”MC都放在這一層，最下面的那些層就是網站主框架了。也許你已經忍不住要問了，你老說“三幀式”，到底什麼是“三幀式”啊？問得好，這正是我下面要講的重點。

「資料層MC三幀式」是我為了方便資料管理而自創出來的一種有效的資料組織框架，它巧妙的利用了時間軸，具有清晰的結構，而且還具有通用性。從字面意思，我們便可以猜出來，它是具有三個空白關鍵幀的影片剪輯，這三個幀的名字按在時間軸上的先後順序依次為“chuShi”、“shuaXin”、“gongNeng”。

chuShi：這一幀負責系統的初始化，主要分兩部分，第一部分一般都是一大串變數。這些變數又分為三種，第一種是所有這個MC要操作的物件和其它元件介面；第二種是一些系統初始變數，比如將負責留言顯示的頁碼變數初始為1，就可以讓留言初始為顯示第一頁；最後還有一個比較特殊的布林變數，就是“yiJiaZai”，我們把它的值初始為false，表明此MC內控制的外部資料此時還未進行過載入，一旦這個MC控制下的資料載入成功，我們立刻將其值變為true。這樣做的好處是可以根據此值判斷資料是否是第一次載入，然後進行不同的設置和回應。第二部分則是註冊刷新函數，有經驗的動態flash web開發者都應該知道，FLASH中的資料刷新是重點，這也是flash web較常規網頁的最大優勢之一。在這裡，我們需要註冊倆個負責資料刷新的函數：
1、function chuShi(){gotoAndPlay("chuShi");}
2、function shuaXin(){play();}

稍候我會解釋為什麼。shuaXin：這個幀是個空白關鍵幀，什麼都沒有，它的意義也將在下面解釋：）

gongNeng：這幀主要負責各種功能的實現以及資料的呈現，為了方便對整個網站的控制以及各“三幀式MC”之間的相互控制，我建議把比較重要的功能都寫成函數。在“gongNeng”幀代碼的最後一定要加上一句gotoAndStop("shuaXin")。這幀中還有一個重頭戲就是錯誤分析和處理，但為了緊扣文章中心，這裡就不多講了。

這樣以來我們就建立起一套簡單有效的資料控制機制。首先在_root上將所有的“三幀式MC”都stop到第一幀，也就是“chuShi”幀，然後建立一套資料載入機制，通過控制三幀式MC的播放來控制資料載入順序。資料載入完成後，我們就可以在任何地方通過控制三幀式MC來控制這個MC負責的網站某特定部分。比如有個名字為“lieBiao_mc”的三幀式MC是負責網站文章標題清單這部分的功能，我們就可以通過下面極其簡單的代碼來實現對文章列表的控制：

如果我們要得到文章清單的初始狀態，只需要調用：_level0.lieBiao_mc.chuShi();
如果我們要得到文章清單的某特定狀態，只需要對負責此狀態的變數賦值，然後調用：_level0.lieBiao_mc.shuaXin();
如果我們只需要調用文章列表中的某一項功能，只需要調用：_level0.lieBiao_mc.特定功能函數名();
由於我們在“gongNeng”幀中就有錯誤分析、過渡動畫等這些重複性內容，所以當調用shuaXin函數時，這些內容就會自動觸發，非常簡單好用。
資料層MC三幀式就簡單介紹到這裡，具體細節其實非常豐富，這裡只是抛磚引玉，細節全部略去。

第七：綜述

通過上面的簡單介紹，相信大家對MBDD式的每層都應該有個大致的瞭解了。就像我前面說過的，MBDD式是對所有flash web的概括，並不是每個flash web都必須有四層結構的，很多flash web由於其作用不同，很可能確實某些層。比如像我的個人門戶V3，就沒有過渡動畫層；而這個酷站收藏站，可以說是既沒有過渡動畫層又沒有背景層；還有些flash web是純粹的商品展示，比如現在比較流行的房地產網站，他們大都傾向於直接通過動畫來展示他們的商品，資料層和資料顯示層則比較薄弱。

前面說了那麼多，MBDD式的真正意義是到底是什麼呢？主要有以下兩點：

1、模式化：對於各種類型的flash web，我們必須給出一套對應的通用開發模式，就像世界上的人形形色色，但大家的骨架都是一樣的。我們有了結實強健的骨架，再往上添磚加瓦就比較容易了，而且效率也會非常的高。

2、獨立性和模組化開發：其實“MBDD式”是我自己在漫長實戰路程中的血淚史，從接觸FLASH到現在，自己也做個十幾個flash web了吧，雖然數量不算多，但每次做我都是自己一個人從介面設計一路殺到後臺。剛開始的時候，由於我還不能在一開始就準確把握整個網站的架構，所以只能逐功能去完成，比如先設計導航部分的介面，然後在FLASH中完成導航部分的前臺功能，最後寫後臺並再回到FLASH中完成整個導航部分，如此循環往復直至完成整個網站。採用這種方式還能按預期完成一個功能複雜的flash web，此人的意志力和隨機應變的能力一定不能弱。因為一個人的思維如果頻繁的在設計、前臺、後臺之間跳轉的話，真的很容易精神崩潰。再加上前期沒有很好的規劃，很可能出現後來的部分和已經完成的部分衝突，造成前面的勞動全部付諸東流，甚至不得不重新來過，這時候還有多少人能堅持下來呢？後來我覺得長此以往確實不是辦法，就開始考慮如何才能在一開始就對整個flash web有個大概的把握，並能長時間的把精力集中在一件事情上呢？於是MBDD式就應運而生了！在MBDD式下，我完全可以遵循這樣的開發流程：→選擇架構模式→介面設計（網站主體框架及背景層）→後臺（FLASH中資料層需要的資料顯示格式和寫入格式）→FLASH前臺合成（動畫層以及資料顯示與交換）。在流程的每一步中，我都會最大限度的把所有精力都集中在這步上，直到開始下一步的製作。而且如果在製作的過程中發現有架構不對的地方，我也可以有能力從宏觀上去把握，做出最合理的調整。但是很可惜的是，通過火山對一些flash web的分析，我發現現在還有很多人，包括有過flash web開發經驗的人，還是不能很好的認識flash web的結構，他們做flash web隨意性還是很大，背景層與動畫層不分、資料表現層與資料層曖昧，甚至是想到那裡做到那裡，各層混合在一起，最後自己終於把自己搞迷糊了，卻把責任都推給FLASH，這到底是FLASH的可悲還是開發者的可悲？

關於flash web開發團隊協作的簡單思考：火山現在還是學生，可以說沒有任何團隊開發經驗，在這裡談團隊協作是典型的紙上談兵，但我在開發自己的網站時，是嚴格的給自己分角色的，也有幾分團隊的意味，很多想法在這裡不吐不快。比如我一開始做架構分析的時候，除了簡單的書寫文檔，是絕對不會開工的，此時我扮演的是一個架構師的角色；而在PS中繪製介面的時候，我會儘量不去想後臺，此時我又在扮演一個PS設計師的角色；而在寫後臺的時候，我只是機械的按架構時的要求完成資料顯示和寫入格式，一般來說數都是固定格式的XML，此時我根本不會去考慮什麼FLASH和PS，完全在扮演一個後臺工程師的角色；最後在FLASH中合成的時候，我則又扮演著FLASH設計師和AS工程師。尤其是在開發我自己的個人門戶V3的時候，我更是“嚴於律己”，在開發流程的每個階段，儘量讓自己少管“閒事”，看到最後能否按預期目標完成任務，結果還是比較滿意的。我的想法是：在MBDD式下，一個flash web開發團隊應該至少有以下五個人：架構師、PS設計師、FLASH動效設計師、AS工程師、後臺工程師。架構師負責對整個網站的把握，他必須瞭解flash web開發的每個環節，豐富的開發經驗使其在接到一個專案的時候可以根據需求很快的決定採用那種開發模式，並把這個專案支解為若干功能模組，然後為PS設計師提供內容框架草圖，並指定後臺資料格式。而且在開發的整個過程中，他要負責其他人的調節和溝通。所以如果說架構師是這個團隊的靈魂人物，一點都不為過。

PS設計師則需要根據框架草圖設計網站介面，他最好懂得一點FLASH基礎操作，知道那些部分是在FLASH中可以很方便的直接繪製的，而那些部分必須由PS完成。當然，如果他還能把動畫因素也考慮進去，並在PS中部分完成效果圖，那就更好了。FLASH動效設計師主要是完成FLASH中的動畫和特效，他最好懂得一點AS，這樣他在做動畫的時候，就會把程式設計的因素考慮進去，使他的動畫儘量便於程式控制，特效也不至於太吃CPU，如果他的AS能力足夠強，我們還要讓他根據架構師劃分的模組在FLASH中完成網站主介面的佈置，當然這時候架構師最好從旁協助。AS工程師主要是根據架構師的要求完成特定功能模組，同時完成前後臺的資料交換，他最好懂得一點後臺知識，至少要知道FLASH如何通過幕後程式寫資料，另外他的XML解析一定要精通。最後是後臺工程師，他只需要根據架構師的要求寫入讀出特定格式的資料就行了，當然，如果他學一點AS的話，將更有利於他理解他為什麼要那麼做，另外他的存在還有更大的意義，那就是完成網站資料結構分析以及負責資料庫管理。

總之我覺得，除了SEO的處理現在還不夠完美外，如果我們深入理解了flash web的結構，建立起一套完善的開發模式，再加上平時積累的代碼庫、元件庫、特效庫、資料庫等，flash web開發快速化、高效化將不再只是夢，flash web完全可以達到HTML網站的開發效率，而且有著比HTML網站更好的視覺和交互效果。

（此篇文章為網路轉載，如有冒犯，請來信告知，當即刻移除！）