黑羽翔天 § Kingda's Weblog

火山写的的第一贴：

总体说明：每个人玩FLASH一段时间后，肯定都会形成自己的一套开发习惯。好的习惯可以尽可能避免低级失误和不必要的麻烦，从而加速开发进程，提高开发质量。火山现在虽然只是业余爱好者，但两年的积累，再加上“火山之家”的开发，也自然而然的形成了火山特色的开发习惯。这些习惯从某种程度反映了我现在的开发水平，所以它基本上都是围绕着小型、快捷、面向过程的开发模式形成的，很多地方还很幼稚。不过以后随着我能力的不断提高，以及对面向对象编程思想的学习，它肯定还要不断的更新和完善。

→库文件夹分类习惯：
1，声音、图片各自放到独立的文件夹。
2，MC则根据栏目进行分类到不同的文件夹。
3，一般不用图形元件。

→时间轴管理习惯：
1，最上层为AS层，如果AS层超过三层，则建立专门的AS图层文件夹。多层AS层需要注意代码执行顺序。
2，主场景其它图层按栏目进行文件夹分类，但一个MC内一般仅为一个栏目，不用分类。
3，相同性质而且相互影响不大的元件放一层，其它的独立分层，并按视觉效果进行上下分层。
4，loading、过渡动画、功能页面分在不同的场景。
5，特定贞使用贞标签，方便以后修改。

→元件命名习惯：
1，库中元件的命名：采用中文命名，后边添加特定元件的后缀，比如我有一个“导航”的元件，按钮则命名为：“导航BTN”，影片剪辑则命名为：“导航MC”。声音和图片则直接使用“导航”命名。
2，命名的三步统一性：即元件在库中的名字，在场景中的实例名，以及所在层的名字尽量保持统一。比如一个元件在库中的名字为：“导航MC“，则它在场景中的实例名将为“daohang_mc”，它所在的层名将为“导航”。这样在元件非常多，代码编写量非常大的时候，可以有效的节省命名和查找时间，同时避免引用错误。
3，文本域命名：如果一个MC中仅有一个动态文本域，则统一命名为：“wenben_txt”，其变量名为“wenben_var”。如果有两个以上动态文本域，则根据其功能进行命名。

→架构习惯：
1，三层分离：主场景数据层，动画层，代码功能层进行分离。由于数据加载完成时，会导致短暂的动画不流畅，所以我一般在loading场景中把数据一起加载完成，然后进入动画场景。大量的时间轴动画又会导致项目结构混乱，所以我一般又会把动画也处理成独立场景，将动画最后一贞复制，然后建立新的功能场景并粘贴，所有的核心代码都集中在功能场景中。
2，MC结构：由于每个MC基本又相当一个独立的小SWF，所以它的结构也尽量遵从“三层分离”的思想。
3，MC双贞式：每个MC都保持两贞。尽管大部分情况下，都可以用一贞完成任务，但我还是会专门留一贞，为可能的贞数据刷新留有余地。
4，元件嵌套结构一般不超过三层，迫不得已的情况下，也要保证代码不写在三层以下的元件上。
5，外部调用SWF全部定义：_lockroot = true。
6，外部调用的SWF中绝不使用_level0，除非特别需要。

→火山中文拼音面向过程结构化代码编写习惯：
一，代码分布：所有代码均写在时间轴上，一般都在第一贞，元件上绝不写代码。主场景上的代码负责对整个系统的初始设置，各MC时间轴上的代码各成一体。
二，代码结构：（按代码编辑器中从上到下的顺序）
1，系统初始化：
①界面初始化：包括编码设置，舞台设置，元件可见性，可用性等等初始设置。
②变量初始化：时间轴或者全局变量初始化。
③数组初始化：初始需要的数组，并利用循环进行赋值。
④对象初始化：初始需要的所有对象，并注册侦听器。
2，代码逻辑结构：这里是整个代码的逻辑结构，一般通过一系列的函数调用使各种功能有机结合。
3，功能块儿：一般按逻辑结构中的顺序定义各个功能块儿，并封装到函数中。
三，命名习惯：全部采用中文拼音全拼。
1，变量命名：使用“var”进行时间轴变量声明，并且采用中文全拼命名，示例：var liuyan="";
2，数组和对象命名：采用全拼加对应的后缀，示例：var shuzu_array=new Array(); var liuyan_lv=new LoadVars();
3，函数局域变量命名：使用全拼加“fc”后缀，示例：function fanye(anniu_fc);
4，外部通信变量命名：外部传递给FLASH的变量，添加对应的后缀:
示例：txt传递给FLASH的变量用：liuyan_txt，ASP则为：liuyan_asp。
FLASH传递给外部的变量加“flash”后缀，示例：yeshu_flash。
四，注释习惯：
1，注释的位置：我一般习惯把注释写在代码前面。也就是先注释再代码。
2，注释频率：基本上是逐行注释，最少也是逐功能注释。
3，注释结构：
模块级代码用"==============="分隔。
功能级代码用"——————"分隔。
一般注释直接用"//"。

★唠叨两句：
今天暂时就能想到这么多了，既然是第一时间想到的，肯定都是我根深蒂固的习惯，以后想到了，再补上来。其实我发这个帖子主要有三个用意：第一，自我巩固和提高；第二，以后没事的时候，我可能会来写写教程，这个东西会方便新手们看懂我的源文件；第三，希望富有开发经验的前辈高手们也谈谈自己的习惯，好给我们这些后辈指条名路！
另外，这篇文章写的其实都是些最基本的操作习惯概述，还有很多高级的或者是特别的习惯以及很多细节，这里先不写了，不然会把文章的整体性搞乱，而且一时半会儿、一句两句肯定也写不完。具体到哪个项目再具体问题具体分析吧：）

我回的第二贴：
Very Good!
论坛就是需要这样的经验总结贴。
继续，加油。 ^_^
我要转载到我的博客上，先打个招呼。呵呵。

另外抛砖引玉，我有几点不同看法：

AS1.0开发：
因为火山谈的是在时间轴中的开发，因此我下面的意见只是AS1.0开发经验。
1.对于火山这样的老手，我建议应当把图形元件看成MovieClip的私有元件，在单帧矢量图片和循环播放这两种情况下尽可能多用它，有利于执行效率提高。对于新手，则干脆全用MC好了。
2.文件夹只是用来理顺图层关系的，多用不太好。应当尽可能的把动画分解成一个个MC，增加重用率。改动时也方便统一改动。
如果你发现自己文件夹过多时，往往是你的动画没有分解好。
3.赞同火山，库中元件分类是很好的习惯。怎么强调也不过分。
4.动态文本框再也不要用变量名了，统一用xxx.text来赋文本。动态文本变量名这种用法是应该废弃的，弊端多多。
5.AS代码不论是在主时间轴，还是在单独MC中都不应超过一层。集中管理。
把主要的代码集中在关键的几个关键帧，所有代码都用#include 外部文件。使用外部文本编辑器编辑，提高效率，如FD，SEPY。
6.把全局变量减少到最低限度。所有MC都应该看成独立的组件，与上层父组件保持最少的联系。

再小谈一下2.0中的时间轴的特征：
好的2.0开发，是没有时间轴概念的，整个Fla只有一帧，而Loading功能抽象出单独的swf比如我的KLoader组件在RIA项目就是扮演这样的角色。很好的东东，可以带来很多的益处：
1，轻松解决了频繁改动代码Export到第xx帧，完全不用管。
2.所有的外部设置初始化统一在loader.swf中完成，例如：可以统一控制帧频，初始化右键菜单，增加logo，等等所有初始化工作。便于维护管理。
3.轻松统一更换站点所有loader皮肤，更新一个loader.swf即可。
4.统一管理父级向子级swf传参数。
等等等，好处多多啊。
.......
2.0的开发，经验和注意之点太多了，日后有机会整理出来和大家分享。

而时间轴中，我的习惯，一般分两三层，背景等美工单独放置一层。一般，只有三层，第一层as代码，第二层功能组件，第三层放一些美工背景等等之类的视觉元件。只有一帧。

noahgenius第三贴：

呵呵，难得有人开个头，不然平时也没想到哈
我也来交流一下自己的经验吧

1 自定义元件库的管理
推荐用文件夹分类。最大的类别应该是功能模块，比如说就是导航，建立导航文件夹，文件夹里再有第二级的分类，我按照的是图片，按钮（包括MC按钮）， MC，有关联类的MC，主场景MC（就是可以被其他模块使用的，像Interface中的接口）。另外还有有个common功能模块，放组件，声音，视频什么的共用元件。

2 方法的命名
变量的命名楼主都说了，我想谈谈函数的命名。推荐“骆驼”试命名法，从语法上来说是动宾结构，比如getMovieClipName()，四个词，第一个是动词，除第一个词外首字母大写，这样的命名比较好说明函数的用途。

3 提高类的颗粒度，类功能单一化
多写几个类没有坏处，类的功能尽量单一，不要让一个类做各种各样不相干的事，这样后期的修改会非常麻烦。

4 基于接口的OOP编程
java要求为每个类都配个interface，其实不用那么夸张。但是这个思路值得借鉴，让接口来代替具体的实现类跟别的类交互，如果以后有扩展，只需要再写个实现类，不用修改交互部分的代码了。

5 设计比编码重要
一上来写代码绝对是不行的。先好好规划自己的系统，从大的流程到细小的逻辑实现，尽量的做到心中有数。这样才不会在做的过程中感觉混乱。

本帖最近评分记录
KingdaSun 2006-12-8 13:00 威望 +1 好回复
火山第四贴：

大家的激情很高啊，现在突然发现我这个帖子题目有点自我了，干脆改成“FLASH基础开发习惯讨论”算了，这样方便大家一起参与讨论

TO：KingdaSun，谢谢鼓励，等待你更详细的总结。
不过你帖子中有两个知识点我太理解：
1，你说使用图形元件可以提高执行效率，这点我有怀疑，以前还专门测试过，跟MC相比，没见有太大差异啊？
2，动态文本域不推荐使用变量名，这个我也好多地方说了，但一直没搞懂它的弊端到底是什么？还望指明。
3，你那个loader.swf的做法很值得借鉴！
另外，我现在对面向对象编程还没深入研究，就不乱发言了：）

TO：noahgenius，你提到了库的管理，KingdaSun斑竹也强调了这点，本来我想等到《火山之家开发总结》中再详细谈这个的，但现在忍不住先说两句把，在我看来，库的管理应该跟网站文件夹分类一样有两大模式。一个模式主要面向小型开发，这时可以采用按功能模块儿分，比如我的网站有一个导航栏目，就专门建立一个“导航栏目”文件夹，把导航栏目所用到的所有元件，图片，声音都放进来，然后又有一个“新闻更新”栏目了，再建一个“新闻更新”文件夹，也把所有元件都放进去。但如果我们的“导航栏目”和“新闻更新”文件夹下又有好多文件怎么办呢？当然我们还可以在每个栏目文件夹下再建立类似 “MC”，“图形”，“声音”，“图片”这样的文件夹。这样做的好处是方便查询，但弊端也出来了，就是文件夹累赘，在每个模块文件夹下都建立一遍元件类型文件夹。所以第二中面向中型开发的分类模式就出来了，就是按元件类别进行最顶级分类，然后大型功能模块，然后是小型功能模块。其实这是一个很丰富的课题，这个帖子中就先说这么多吧：）

TO：heimuxiao，在FLASH开发，尤其是追求效果的FLASH WEB开发中，一点不用时间轴有点不切实际，我想斑竹的意思是把动画动放到独立的MC中，然后把MC放到第一贞吧。

TO：kvgnt，没办法啊，我英语不好，又想进行大规模开发，暂时只有用这个办法。可能是你对拼音命名不习惯不吧，其实我的命名不算长的，你看看MM组件里的命名，那才叫长

TO：HBrO，你也写写自己的开发习惯啊，我们一起来研究研究：）

HBrO版主第五贴：
图形元件跟脚本没有关系,因此,运行的时候不需要像MovieClip类那样,储存太多的信息.而且,图形不是独立于时间轴的,那么,运行的时候,也就不会太消耗资源.
至于库的管理,我好像真的不太喜欢用文件夹,虽然自己知道这个习惯不好.主要是不同文件夹里头的元件,名称也不能重复的原因吧,我通常都是用folder1_folder2_symbol1这样的格式来给库的东西命名的.
至于单帧,在Flash Web里头,我觉得也没必要太刻意地去追求.毕竟动画也是Flash的优势嘛.当然,如果是对动画要求不高的程序开发就另当别论.这里,我说下2AD的吧,它的V5版就是用AS2.0类开发的,不同的类在不同的时间轴里调用,但是我个人感觉也不是一个失败的AS2.0开发啊,毕竟我看它的结构跟表现还是分离得不错的.

目前这个贴的内容就这么多了。想看最新的话，就点击原帖看吧。 :)