但是我很困惑。因?yàn)閾?jù)說“Flash全站”開始運(yùn)行后，就不再請求或者很少請求URL了，換頁是通過換禎完成的。我開始無法理解，從網(wǎng)上下載了幾個成品的源文件。

可是非常抱歉，所有的源文件都是巨型的，極其復(fù)雜的。action分布到各個frame和剪輯實(shí)例里，而實(shí)例都是托放的，你無法知道到底有多少個實(shí)例，主時間線有幾十層.......。這樣的東西既不是動畫也不是代碼。結(jié)果就是無法調(diào)試，無法升級和修改。

不知道大家是怎么做的。

推薦的是，像Flex或Laszlo那樣做，或者干脆選擇它們的一個，雖然我還不知道什么是Flex還有Laszlo。

不選擇它們的理由是：

1，我沒有空間，幾乎沒有虛擬空間對它們提供支持。
2，我沒有學(xué)Java，而是php或者.net什么的，而那兩個技術(shù)還不很支持其他技術(shù)。

即使是這樣，也應(yīng)該使用XML來描述你的程序，把代碼和資源盡可能徹底的分開。如果你熟悉Asp.net，就是< ..../>的形式。用這種語法定義任何諸如label的組件（我認(rèn)為這是最困難的組件了）。

然后，為程序?qū)懸粋€XML解釋器，按照你寫的some-page.xml文件，create，loadMovie，attach，duplicate一通，把它顯示出來。換頁就是請求新的xml文件，再解釋。

對拉！這聽起來比在時間線上“蓋高樓”更困難和復(fù)雜。但是我覺得至少這樣做有三個好處：

1，我喜歡程序勝過畫畫，我完成這樣一個站點(diǎn)等于實(shí)現(xiàn)了一個framework，會超有成就感。（光說不練啊，這孩子）
2，這個站點(diǎn)變得可擴(kuò)展（flexible，MM的產(chǎn)品寓意于此吧？），盡管僅僅對于它的開發(fā)者來說（要是有一套標(biāo)準(zhǔn)及不一樣了，MM就不學(xué)學(xué)sun呢？）。
3，對用戶來說，因?yàn)榻M件個數(shù)有限，即使大量重復(fù)也是flyweight的（享元模式），能很大的提高訪問速度。

上述第3個優(yōu)勢意義不僅僅如此。

Html只是表達(dá)，Asp，Jsp，php這些東西最終也是生成Html。用戶只有一點(diǎn)點(diǎn)通過form參與互動的機(jī)會，所以叫傳統(tǒng)的browser是瘦client。而Actionscript盡管效率低下，卻有了較強(qiáng)的client端計算能力。*可能強(qiáng)大到C/S的client一樣的程度。那么就厲害了。

可是，要是把和Server交互的代碼都堆在frame里......所以如果你的程序最重要不是動畫，而是要和用戶交互的所謂RIA，必須選擇組件化。

這里要提一下“偷偷下載”的問題了?，F(xiàn)在的用戶，比如我，才不會老老實(shí)實(shí)的看你的東西，這個頁面出來了，看不上兩秒就要點(diǎn)點(diǎn)什么按鈕啦。那就是換到別的頁了，你正在“偷偷下載”的東西自然是被拋棄了。不幸的，沒有下載完的swf好象不會存到本地緩存。那么一個100多k甚至幾百多k的頁面就沒有緩存的價值。

相反的，我要“偷偷下載”一些供顯示的組件，它們通常不應(yīng)該超過30k。盡管數(shù)量可能較大（其實(shí)不會，你有耐心做50個花色的button？），但是等用到時，它們大都在緩存里，會非?？焖?。

組件化的代價是，用戶的CPU要大轉(zhuǎn)了，也更消耗內(nèi)存，因?yàn)榧虞d組件是在運(yùn)行時。但是我覺得，比起網(wǎng)絡(luò)帶寬，CPU算什么資源？這正符合調(diào)劑高速CPU和低速IO的邏輯嘛。

以上內(nèi)容和Flash課件，F(xiàn)lash動畫里的action沒有任何關(guān)系啊。