混合模式：混合模式就是综合利用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设计师的角色；而在写后台的时候，我只是机械的按架构时的要求完成数据显示和写入格式，一般来说数都是固定格式的X

上一页  [1] [2] [3] 下一页