★目录：
→引言
→flash web结构概述
→浅谈过渡动画层
→浅谈背景层
→浅谈数据显示层
→浅谈数据层
→综述
★引言
→记得我刚接触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结构的认识吧：）
★概述
→打开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网站更好的视觉和交互效果！
→2007.4.23
---- 标题的星号我给去了 by mirycat
[
本帖最后由 mirycat 于 2007-4-27 10:52 编辑 ]
