2010-03-10
吾系衰人的博客

flex项目的 dailyBuild

dailyBuild 部署 的由来历史悠久,对于一个团队产品开发,相当重要.

简单的说它能准时的让我们发布最新的项目版本,而不比依赖于默认的手动 发布.

一方面能够办证项目产品的权限管理,

再者能够更好的检查出项目的产品质量.

还有可以让测试成员能呢个每天测试到最新的版本.

上边说了一通dailyBuild 的好处,下边说说flex环境下怎么部署dailyBuild ...

随机文章：


收藏到：Del.icio.us


博客大巴，你的个人传媒早班车


小S吧 sunbright博客

你想写这样的代码吗？

如题，这样的代码可读性很差，在这发出来只是提醒一下新手，不是说写的出这种代码才是厉害，真正项目中，要是你写这样的代码，是会被同事群殴，甚至是被炒鱿鱼的！
var image:Sprite = (addChild(new Sprite) as Sprite).addChild(new ColorImage).parent as Sprite;
image.addEventListener(MouseEvent.MOUSE_DOWN,function():void{image.startDrag()});
stage.addEventListener(MouseEvent.MOUSE_UP,function():void{image.stopDrag()});
stage.addEventListener(MouseEvent.CLICK,function(event:MouseEvent):void{if(event.ctrlKey) traceText.appendText((image.getChildAt(0) as Bitmap).bitmapData.getPixel(event.localX,event.localY).toString(16) + ",")});
题外话：早几天无意中看到一封帖子，无限膜拜这种一行代码的写法，因此拿出来醒个目。
2010-03-09
兽的地盘

【续】我的FLASH情结2010——浅谈FLASH WEB GAME与创业

★前端与美术的配合
→老闪客们应该都知道，FLASH这款软件在历史很长一段时间内都是用来做动画的，闪客和美术在这段时间内本就是同根生。后来随着第二版AS1和AS2逐渐完善，以及AS3的强势出炉，闪客们才逐渐分化成纯程序和纯美术两个阵营了。但不管怎么分，FLASH程序和美术之间的关系依旧非常亲密，一个优秀的AS程序员必然要比其它语言的程序员懂得更多美术方面的知识，至少也要能熟练操作FLASH IDE，并进行简单的图形处理。FLASH程序员与美术的合作大部分时间是由AS程序员主导的，主要表现在以下几个方面：

        1，FLA文件管理：把有联系的美术素材放进一个FLA文件中统一管理，既能有效减少美术素材的数量，也方便程序员写程序。本来像这种美术素材管理应该是由美术负责的，但由于这些美术素材大部分时间可能也需要程序员写程序，美术和程序需要共享这些素材，虽然我们可以用SVN进行共享和版本控制，但程序员和美术还是要靠约定才能非常默契的知道什么时间该到什么地方找什么文件。而这个约定就什么我们程序员应该制定的，因为据我观察，程序员在条理性和制定规则方面一般比美术更靠谱。以我们公司为例，文件管理基本上都是由我负责的，我把需要多个美术和程序员共同维护的部分以项目名命名成一个文件夹，项目下如果需要还可以进行子分类，分类规则也是我制定。而大部分的子模块可能只需要一个美术加一个程序员就搞定了，这时候美术就把素材放到以自己英文名命名的文件夹下，至于他们的文件夹内如何分类，我会给出意见，但并不强制管理。模块程序员也会都有以自己英文名命名的文件夹，他们会把美术的纯FLA素材拷贝到自己的文件夹下，并根据模块进行子分类，然后写代码并发布SWF，至于SWF文件如何管理，我会在下一节中讨论。其实我的管理目标非常简单，我只需要所有的美术和程序员能在任何时候瞬间找到我们需要的素材和源代码所在地，并且把需要的版本调出来。只要这个目标还在可控范围内，我就会给所有员工最大的自由性，把自己从管理里解脱出来，把更多的时间投入开发，毕竟对于创业型公司而言，快速开发，让老板和市场看到产品才是主旋律，管理只需要在必要的时候强势出手就可以了。事实上，我们公司的文件管理，我每隔半年才会强势管理一次，用大概一周的时间重新规范规则，其它时间基本处于放任自流状态，但从没出过什么大问题。最后给大家一个数字，我们公司经过将近三年的积累，已经有几十个G，上万个美术素材了。

        2，SWF文件管理：SWF文件一般是由前端程序员发布并管理的，不过也有一些SWF可能不需要些代码，比如家具、个人面板背景等等，这些可以直接由美术管理，管理方案和FLA文件管理差不多。最大的不同就是，SWF文件最终的发布路径是内网模拟测试环境，而不是本机。像我们这样的更新驱动游戏，不可能为每一个模块都单独搭建拟真测试环境，如果这样的话，可能我们测试环境还没搭好，就该上线并准备下一周的更新了，所以所有的模块最终的整合测试都是直接上内网测试环境进行。

        3，FLA内元件的管理：这个问题相信很多AS程序员都碰到过，也都为此头痛过。美术给到程序员手里的FLA文件可能是混乱不堪，库里没有任何分类，元件名也都是清一色的“元件1、元件2，元件3……”，元件内部遮罩，组合，层次也都没啥规律。要是美术直接给我一个AI或者PS的源文件让我们自己导入FLASH，那我们就更抽了，颜色模式的改变，路径工具的失灵，大量的图层导致裁切困难，而且还不能进行打散合并，只能一层一层的切。这个时候，正如我前面提到的，一个合格的AS程序员应该对美术和图形软件有更多的了解，你应当及时纠正美术不恰当的做法，甚至给出合理的解决方案，比如你应该知道FLASH只支持RGB颜色模式，AI不但整个文档可以指定颜色模式，每个图层也可以单独指定，当美术给到你的AI导入FLASH有色彩差异的时候，能帮助美术找到哪里的颜色模式不对，并建议他们以后只使用RGB模式。很多纯AS程序员可能有图形恐惧症，他们会想尽一切办法把这部分工作推向美术，但最终他们都会很郁闷，因为他们会发现，除了能指定库文件夹的命名规则外，其它的规则很难跟美术说明白，而且由于模块的千变万化，很难总结出一个完全通用的规则，想从美术哪里拿到一个完全不用修改，自己可以直接写代码的FLA文件，几乎天方夜谭。所以，与其让FLA文件在美术和程序的你来我往中浪费时间，与其让自己在对美术的鄙视中愤懑抱怨，不如提升一下自己的美术常识和图形处理基本功。毕竟，元件在舞台上怎么命名，关联什么类，层次怎么样，怎么被程序利用，这些只有我们程序员最清楚，这部分工作由我们程序员完成完全是合理的，也是效率最高的，美术只要把我们需要的素材交给我们，并放到方便查找的地方就可以了。放下程序员的架子，主动走入美术的世界，对我们程序员绝对有好处。

        4，FP的性能问题对美术的影响：谈到这个问题，我就想起了一个让我抽搐已久的情况。我们老板总是喜欢语重心长的对我说：“火山，你给咱们前端人员和美术出一个方案吧，告诉他们怎么做可以让FLASH性能最高！”额，现在请问哪位朋友可以帮火山回答这个问题。火山真的惭愧，搞FLASH搞了7年了，始终还是没完全弄明白FLASH的诸多性能问题。不管以前的MM还是现在ADOBE，都将其图形处理和屏幕渲染部分视为其镇山之宝，不肯公开其技术内幕，我也就始终无法从理论的高度给出一个本质的回答。我现在的大多数性能解决方案，都是根据项目的实际情况，根据7年来的经验总结出的经验科学。而且我始终不相信，谁可以一个给出一个适合所有项目的、通用的性能解决方案，可以同时让内存、CPU、带宽占用都最少，而且画面又很炫，功能很强大，SWF文件非常小，可玩性非常高，而开发周期和成本却很少。内存、CPU、SWF体积、带宽、效果、成本，这几个要素往往是相互矛盾的，你对其中任何一点的过分优化，都有可能导致其它点走向反面。我深信，在目前这个时期，一个性能方面的高手，绝对不是看他能不能给出一个全面优化的方案，而是看他在面对不同的项目，不同的情况时，如何做出选择和取舍。是的，“选择和取舍”永远都是人生最艰难的话题：手心手背都是肉，削掉哪边呢？老婆孩子都掉海里了，救谁呢？在这样的情况下，我觉得一个负责的前端人员，反而不应该仅仅简单的扔给美术一份死的文档，告诉他们应该怎么做，让他们一直这么做就可以了。前端人员应该在每次面对一个实际情况时，都不厌其烦的跟美术讲清缘由，我们应该尽量授人以“渔”，而不授人以“鱼”，让他们明白选择的道理，而不是简单的告诉他们选择什么。相信只要是虚心学习的美术，经过一年半载的讲解他们就能替你做出判断了，这时候你再让他们去跟后来的美术讲，你就解脱了。很可惜，大部分不懂技术的老板可能觉得你是在故弄玄虚，非要你给出一份文档。无所谓了，你跟不懂技术的人争论不是自讨没趣么？老板更多时候是从管理的角度出发的，我们应该配合。我们也不是没什么可写，比如尽量减少元件数量啊，减小SWF体积啊，减少持续性动画啊，多做触发性动画啊，少用遮罩和滤镜啊，不要嵌入中文字体啊，提高元件重用性啊等等等等！这些建议听上去完全正确，忽悠不懂技术的人正合适。但其实在高端的开发中，这些理论都是废话，帮不上多大忙，因为地球人都知道了，我们碰到的问题肯定是超越这些技术点的高端问题！

        综上可以看出，其实前端和美术的配合过程大部分时间是由前端主导的，这也是我前面一再强调前端要多懂一些美术知识的重要原因。当你可以和美术一起谈论美术理论，在美术的电脑上直接操作给他们看，当你从美术的角度给他们提出解决方案的时候，你往往会更容易被美术所接受。担负起主导前端与美术合作的责任，用你的智**

 

★前端与后端的配合
→FLASH与后端通讯的手段多种多样，网上相关教程太多了，这里不再例举。但很多时候，创业团队由于受制于各种现实条件，可选择的方案并不多。像我们公司，刚开始基本上只能选择FMS+PHP+MYSQL。其实，对于我们前端来说，后端选择什么解决方案对我们的影响并不大，我们无非就是用的API不一样而已。多看看教程，用很少的时间我们就能掌握其要领。那么前后端合作的难点是什么呢？我觉得关键是逻辑的划分。

→“前后端合理划分逻辑”，这句话咋看上去貌似简单，其实里面蕴含着诸多方面的考虑。比如安全性、后端性能、工作量、人事分工等等。安全性：记得我们的游戏同时在线超过3000的时候，就已经有人开始攻击我们的后端了，篡改了很多人的个人资料。幸亏攻击的人只是我们一个善意的玩家，如果是恶意的商业攻击，后果不堪设想。经过这次后，老板开始缠着我们追问“怎么防止别人攻击，提高安全性”。这个问题又一次把我们难住了，我们都知道，基于HTTP的请求不被截取是不可能的，而SWF文件又不存在绝对的安全。就算你防得了恶意进攻，你也防不了良性的外挂，想从技术层面让别人完全攻击不了我们也是不可能的。那我们是不是只能坐以待毙了？不是！如果前、后端在合作的时候，数据逻辑与合法性检查都是做在后端的，就可以很好的避免一些良性外挂。首先是游戏数据逻辑要尽量全做在后端，比如用户在玩小游戏的时候，我们不要只是在用户结束小游戏后，简单的把数据传回后端，后端记录进数据库完事，一旦攻击者发现了你这个传数据的后台接口，完全可以避开SWF，做外挂直接呼叫你这个接口刷分，就算你验证用户也没用，因为他可以先注册一个合法的用户，然后在外挂中登录再刷分。当然，你还可以对游戏分数先加密在传给后端，提高攻击难度，但这也是不保险的，因为加密算法就在你的SWF文件中，别人可以很容易获得。所以正确的做法应该是：游戏开始的时候只告知后端游戏ID→后端标识ID对应的游戏已经开始并记录开始时间→用户每次获得一个分数时，前端传回来的不是分数，而是一个动作ID,后端根据动作ID给用户加分→游戏结束时，前端告知后端游戏已经结束→后端得知游戏结束，记录结束时间，计算时间差，根据时间差和最后得分是否符合标准做出相应处理，如果符合标准就把最后得分入库，并返回前端显示给用户，如果不符合标准，就启动zuobi处理系统。而这个标准一般是由数值策划给出的。经过我这么一分析，你可能头痛了，本来一个很简单的小游戏计分，怎么搞得这么复杂？前后端工作量都增加了不说，对后端性能也提出了更高的要求，服务器可能要增加了，后端人手可能要增加了，开发周期也要延长了，值得么？这个问题问的很好，这正是我下面要说的：后端性能、工作量、人事分工：一旦我们每一步进行安全性与合法性验证后，整个项目的工作量都会大大膨胀，开发周期也会大大延长；一旦我们把数据处理、业务逻辑和安全验证都移到后端时，后端的压力就会增加，服务器要增多，对后端人员的能力要求也会提高。很多初创团队在项目初期人力财力，软件硬件都不足，可能顾不上那么多，一心想着早点让项目上线。在这种情况下，我觉得安全性可以暂时放一下，众所周知的安全漏洞补上就可以了。但“数据处理和业务逻辑”这个，宁可开发的慢一点，宁可再招个后端高手，宁可多几台服务器成本，也要把它们尽量都放在后端。因为这个没分清的话，会影响到整个系统的清晰度，严重影响项目中后期的发展，为日后的重构增加难度和超多的工作量，我们还指望着在重构时加强安全性呢，到时候数据处理和业务逻辑还是要放后端！所以综合考虑，该出手时就出手，能省的不浪费，不能省的不要抠！

→前面一节谈了前后端合作的难点。这里再简单的谈两个要点：
        1，前端人员不要以前端的角度看后端：前端和后端有个本质的区别，就是前端的负荷是分担在每个客户端的，而服务端的负荷是集中在服务器上的。对于我们前端来说，一个功能多占了几K内存，SWF文件大了几K根本不是什么问题，可对后端来说就是很严重的问题了，一个人大几K，上千人就是几M了。服务器在连接数、内存和CPU之间会有微妙的平衡点，一旦这个平衡点被打破，随便再多哪怕一点点资源占用，整个服务器的性能都会严重下降，影响用户体验，当然，如果你有几十上百台冗余服务器供你负载平衡，你可以当我没说，可如果你像我们公司一样，一开始就3、5台服务器的话，就请前端人员一定要多多配合后端人员，帮他们省出每一个字节，每一次请求。比如像道具属性会有很多文字说明，这些说明应该以类似XML文件的方式储存为静态文件，后端返回给前端的道具数据包里只需要一串物品ID,前端就可以根据这些物品ID在XML文件里查询出这些道具对应的静态物品属性了。别看这些数据可能只有十几K，对后端来说意义重大。还是那句话，只要不是架构性问题，前端不要怕麻烦，要尽量配合后端提高性能。

        2，前端后端要有很明显的BUG分界点。当一个BUG出现时，后端应当很快的用一种统一的方案证明数据没有问题！这个方案必须让前端知道，并让前端也可以操作。大家熟知的php remoting里有一个servicebrowser，这个东西就很好，它能罗列出所有PHP的接口，我们输入参数，它就返回结果，我们可以根据结果直接查看数据是否正确。——确定数据的正确性，对前端DEBUG非常重要，而一个BUG的解决，一般都是由前端人员入手并进行定位的。

→其实相对于前端和美术的合作，前端与后端的合作还是简单清晰的，前后端在开发的过程中，应该是非常独立的，后端开发完全可以先启动，把数据接口提前写好，等着与前端整合，而当整合过程发生问题时，又可以很快的界定是谁的问题。

 

★公司文化与产品定位
→前面谈了那么多，无论是策划、美术、前端还是后端，大家通力合作，共同奋斗的目标无非就是希望开发出来一个好产品，而开发出一个好产品的目标无非就是成就一个好公司，这就涉及到“产品定位”与“公司文化”的问题，公司文化和产品定位没做好，其它人再努力都是枉然。可正是这两个问题，从我们公司成立到现在一直困扰着我，我抓破脑袋苦思冥想，总结出我们公司的公司文化就是“老板说了算”，而我们的产品文化就是“与时俱进，不断重新定位”。下面我先谈公司文化再谈产品文化，因为产品文化是包含在公司文化中的。

→公司文化：一个公司的文化在很大程度上是由初创团队建立的，而初创团队一般分两种，一种是权利分散型，初创团队在各个领域都有领头人，虽然也有形式上的CEO，但产品、研发、市场相互干涉的并不多，领导层内部“三权分立，民主平等”，对外发言人则可以统一由CEO代劳。这种模式的优点是大家优势互补，让懂行的人完全负责相关领域，负责人成就感大，责任心强。缺点是，权利分散就要求领导层必须非常团结，配合默契，如果他们之间出现矛盾，对公司影响会很大。我们的竞争对手淘米网络就是这种模式，到目前为止，他们公司发展的还是最好的。另外一种模式就是“老板专政”模式，专政到什么程度，跟老板对权利的欲望有关。我们公司老板就专政到事无巨细的程度了，就连买一个几百块钱的路由器都要再三跟老板请示，美术、策划、开发所有的日程安排、人事任用都要由老板点头。“专政模式”在创业初期也未必就是坏事，因为创业初期，困难重重，大家又都有自己的想法，每个人的信心都比较脆弱，如果没有一个强势的人主掌大事，所有人容易形成一盘散沙的尴尬局面。专政模式下，公司文化其实就是老板的个人文化。专政的人一定要有专政的资本，有专政的能力，掌握着公司最大的权利，就必须承担最大的责任。如果公司成功了，就算你再说成功是大家的，最大的成功者还是你，但如果公司失败了，就算你找一千个理由推脱责任，最大的失败者也是你！在这种情况下，专政者要努力提高自己的全面素质，公司管理、产品、开发、策划、美术、市场都必须有所了解，你的任何一个错误的决定都会把公司推向深渊，并引起相关部门人员的不满。我们公司就是典型，老板以前是做销售的，对策划、开发和美术，甚至是互联网都没什么概念，做海底世界前连QQ都没用过！虽然他在资历和财力方面当之无愧，但其短板也是无法否认的事实。初创很长一段时间内，他都敢拍板说一个社区一个AS一个月搞定之类的话，而且还要非常强势的让你接受，并拿出执行方案。至于他为什么敢这么坚决的做出这个错误的决定，我也不明白。可能正是因为他也不知道到底需要多长时间才能开发出来，而我们又没有取得他的信任吧，所以他就只能尽量往少的时间说，等到我们没完成工作，大不了再延长时间而已。可这对我们这些开发者就造成很大困扰了，这种根本不可能达成的目标如何拿出执行方案呢？开发规划如何做呢？最后开发不出来谁承担责任呢？于是一个怪圈形成了：老板不信任开发→制定不合理的开发目标→制定不合理的开发规划→开发规划没完成或者大打折扣→老板认为开发者能力不行更不信任开发→老板要求开发者提升自身能力满足他的要求→开发者依旧满足不了老板→老板在工作能力和员工素质上全面怀疑开着者→制定更加不合理的开发目标甚至是惩罚制度→项目更加完不成……额，这真是一个装满了苦水，倒又倒不出的杯具！当然，只要不是傻子，在这个悲剧的循环过程中，不管是老板还是开发者都会变得越来越“聪明”，老板一天天成熟了，程序员一天天世故了。只是曾经浪费的时间，错过的时机不再有，曾经不合理制度下积累的问题，明天需要继续补救！如果上天能给大家一次重来的机会，我相信，老板会说：“下次我一定要在项目刚开始就找一个靠谱的，值得信任的CTO！”，而程序员会说：“我下次再也不会跟着不懂技术还自以为是，横加干涉的老板了！”

        虽然“民主平等”和“高度专政”两种模式都有其优缺点，但最终玩的都是一个“人”字，相同项目，一个模式，不同的人玩出来的结果肯定不一样。同是专政模式，奥比岛就比海底世界成功。不过站在历史发展观上看两种模式的话，我个人更偏向于“民主平等”模式，这种模式下的公司领导层为了保证公司能长久健康发展，肯定会不得不想尽一切办法制定出平衡权利的法制规则，只要法制规则适应时代，领导层人事变动影响是可控的。而“专政模式”的专政者，为了保证其一手建立起来的商业帝国不至于在自己退位后轰然倒塌，肯定不得不想尽一切办法寻找接班人，帝国的命运系于接班人的选择。相对于“人治”，我觉得“法制”更靠谱。看到这里也许你又该搬出中国特色来反驳了，说什么中国的企业不合适。但纵观天下，历史的潮流是不可逆转的，中国作为历史发展的组成部分，脚步可以慢，但方向不会错。80后已经开始觉醒，90后会继续努力的。所以希望任何一个创业者在创业初期都认真的回答一个问题：你是只想做一个成功的企业家，还是想真正做一个成功的企业，让这个企业能长久发展，代代相传。一个成功的企业家的成功是个人的，而一个成功的企业的成功是大家的，是社会的！

→产品文化：产品文化包含于公司文化，“民主平等”的公司，产品的文化就是“管理层相同价值观”的文化，而“高度专政”的公司，产品文化就是“老板个人”的文化。不管是什么类型的公司，什么产品文化，这个文化一定要简明而清晰，要深入人心，最好能浓缩成简单的一个词或者句子，“妈妈放心，孩子喜欢”就代表着淘米网络的产品文化。这个口号从淘米成立不久就已经开始喊了，到现在没有变过。我相信他们的用户，他们用户的家长，他们公司从管理层到员工每一个人，就连他们的竞争对手都对他们公司的价值观，对他们的产品文化有一个清晰的认识。而我们公司呢？反观我们公司，在这方面做的非常差，公司从成立到现在产品定位一直在变，刚开始要做一个针对初高中生和女孩子的休闲社区，搞了几个月后，又发现企鹅，一股脑的投入到儿童这块儿蓝海市场，说要做一个中国版的企鹅俱乐部，再后来可能觉得儿童市场有点小，收费比较困难了，又想把产品目标用户群再提高一下，提高到初高中生也能玩，游戏复杂度也要随之提高，这样还没做多长时间，又看到人家淘米推出赛尔号这种PK游戏了，又觉得纯绿色游戏的可玩性不高，对用户尤其是男孩子的吸引力不够，又要在我们的游戏里也加入PK和打怪了。直到现在，公司里上上下下，除了老板之外，没几个人能弄清公司的产品定位是什么，我们的产品文化是什么！这种情况导致一个很严重的问题，就是策划在策划游戏的时候，没有核心价值观，也就更没什么游戏世界观了，最终导致游戏形散神也散！

        游戏一直在改版，功能一直在开发，BUG一直都存在，性能一直上不去，目标用户群一直在改变，老用户一直在流失，我只能用一个词形容我的心情：痛心疾首！

 

★2010年：我的梦想扬帆起航
→从毕业就一直在酷噜，一直做FLASH WEB GAME，当时的想法很简单，就是想体验一下顶尖的FLASH应用开发。转眼即将三年了，回眸探望，几多感慨，但终究还是能淡然处之。毕竟大家都不容易，大家都在摸索，也都在摸索中前进和成长，公司现在其实已经比刚开始好多了。

→如今再打开4年前那篇《我的FLASH情结2006》，激扬的文字震撼我心。而现在的我，在海底世界的前端开发中已经找不到往日的激情，每日重复的机械劳动。而自己的理想，更是逐渐飘渺远去，一种温水煮青蛙的危机感油然而生。于是2010年，我向公司递交辞呈，结束我毕业后的第一份工作；再写一篇《我的FLASH情结2010》暂时结束FLASH WEB GAME开发。

→那么2010年，我要做什么呢？没错，我要开始做自己的项目了。我们公司的一位在商场上混迹多年的大股东在年会上语重心长的对我说：“火山啊，你现在自己做项目有两个最大的问题，一是你没在大公司呆过，对一些正规的公司流程不了解；二是你原始资本积累还严重不足，很难支撑项目长久下去。”其实我自己又何尝不明白呢，我知道自己这次单干也是九死一生，但我实在等不了了，7年的技术积累，3年的工作积累，为的就是今天，我也是奔三的人了，都讲男人30而立，马上要面对结婚生孩子，上有老下有小的艰难局面，我再不趁机把握最后这两年相对轻松自由的机会，以后会更难。我的梦想可能很天真，但我会做的很认真。

→其实冷静下来想想，也没什么好怕的，想当年我敢带着一千块钱闯上海，今天我就敢拿着几万块钱自己干，大不了折腾完了再到大公司打工深造呗。虽然我工作三年才积累了几万块钱这听上去有点寒，虽然我每个月最多只能给自己播出1000块钱的创业资本这听上去有点少，虽然我自己得把策划、开发、美术和运营全做了这听上去有点假，虽然现在我还天天穿着高中和从亲戚那里捡来的衣服这看上去有点苦，但这都是外人看我的观点，我自己是乐在其中，浑然不觉，哈哈。不管怎么样，2010年，我的梦想必须扬帆起航，不以成败论英雄，只为人生少留遗憾！

 

 

转自：http://bbs.blueidea.com/thread-2969949-1-1.html

作者：寂寞火山

 

<!--EndFragment-->



已有 0 人发表留言，猛击->>这里<<-参与讨论


JavaEye推荐



【转】我的FLASH情结2010——浅谈FLASH WEB GAME与创业

★目录：
→我的FLASH WEB GAME开发历程
→当今FLASH WEB GAME概述
→创业型游戏公司面临的问题和困难
→FLASH WEB GAME的系统架构
→FLASH WEB GAME的前端架构与人事分工
→前端与美术的配合
→前端与后端的配合
→公司文化与产品定位
→2010年：我的梦想扬帆起航

★我的FLASH WEB GAME开发历程
→2007年的夏天，顶着炎炎烈日，我从学校直接跑到上海，开始了我的FLASH WEB GAME创业之旅。时至今日，转眼快三年了。作为国内比较早的一批FLASH WEB GAME开发人员，今天我粗略的总结一下这两年多的经验和心得。讲的不对的地方，请大家多多指教。

→2007年刚到上海的时候，初创团队只有四个人，一个CTO,一个美术，一个后台，一个前台。手里的产品是一个已经在台湾运行三年左右的FLASH社区，和国内的梦境非常像。这个产品还是不错的，早在FLASH5就在开发出来了，FLASH6出来后，又用新版本的AS1重写过。这个产品让我又爱又恨，爱的是，在2007年的时候，国内除了梦境和1D真的很少有能赶上它的；恨的是，这个产品竟然没有前端源码！要想修改还要破解！玩过AS1，在时间轴、MC和BTN上写过代码的朋友应该知道这是什么概念——1个字：囧！

→后来老板可能也觉得这样改下去不是办法，终于同意自己重写一个。正好07年有条新闻很火爆：国外有个FLASH社区第一次利用FLASH技术取得了重大成功，以7亿美金卖给迪斯尼，它就是“企鹅俱乐部”。老板看到了商机，我们决定做一个中国版的企鹅，于是“海底世界”应运而生了。而“海底世界”的创意，只不过是我们四个初创成员在闲聊时，我开玩笑随便说的。

→海底世界正式开发到现在差不多正好两年，期间我们碰到无数的问题和困难，不管是公司层面或技术层面，都是如此，但始终是坚持了下来。产品一天天完善，公司规模也一天天扩大。前端从最开始的两个人，到现在5个人；后端从最开始的FMS+PHP到现在自己写的socket服务器；公司规模也从最开始的4个人，到现在的50多个人。

★当今FLASH WEB GAME概述
→2007：含苞欲放！
2007年可以说是FLASH WEB GAME发展史上的分水岭。2007年之前，我们眼里只有梦境，最多再加上昙花一现的抱抱城，那时候根本没有“FLASH WEB GAME”这个概念，大家谈的都是“FLASH社区”，“FLASH社区”这个词在很长一段时间代表着FLASH应用领域的至高点。也许2007年已经有不少团队开始研发FLASH的MMORPG了，我曾经有幸知道几个，但很可惜，不少都胎死腹中，2007年国内在线上运营的FLASH WEB GAME基本上还是空白。但不管怎么说，我相信2007年是蓄势待发的一年，肯定有很多类似我们公司的团队，在默默的努力着。

→2008年：雨后春笋！
经过2007年的积累和准备，FLASH WEB GAME业界的战斗终于在2008年打响，以“摩尔庄园”，“海底世界”为代表的“FLASH儿童虚拟社区”开始崭露头角；以“纵横天下”为代表的FLASH策略类游戏兴起；以“昆仑”为代表的FLASH  MMORPG让“无端网游”的概念又炒了起来。还有各种基于FLASH的卡牌对战类，联机棋牌类，模拟经营类游戏等等，都如雨后春笋般破土而出。

→2009年：百花齐放！
2008年，国内虽然一下出了很多FLASH WEB GAME,但大家只要认真收集，总归还是能数的过来，可到了2009年，几乎每隔一个月，都会有几个新的FLASH WEB GAME进入大家视野，而且他们越来越完善，功能越来越强大，盈利模式也开始成熟并多样化。2007年每出一个FLASH WEB GAME,我都会为之兴奋，并很有兴趣的去研究它。而到了2009年末的时候，FLASH WEB GAME已经多到我连体验的兴趣都没了，我已经彻底搞不清楚国内到底有多少个FLASH WEB GAME在运营。而伴随着SNS行业的成熟，基于SNS的Social game进一步扩大和模糊着FLASH WEB GAME的概念。FLASH在游戏领域里的应用，在经历了“社区”、“策略类”、“MMORPG”后，发展到今天创意无限，精彩纷呈的“Social game”，已经很难用一个词，根据游戏类型概括所有的FLASH应用了。所以我觉得“FLASH WEB GAME”，也就是“FLASH网页游戏”这个词还是相对最恰当的，这也是我前面一直使用这个词的原因。

→2010年 – 2011年：胜者为王！
就像春秋战国时期，在经历过“百家争鸣”后，必然是“天下一统”。随着游戏巨头和互联网大亨对网页游戏的逐渐重视，以及政府的介入，还有最早领跑某些领域的创业公司不断壮大，相信在不久的将来，网页游戏领域也会出现几个真正的领袖。别的领域不敢说，在我们儿童市场这块儿，淘米公司已经逐渐呈现一家独大的趋势，不信的话，你可以随便找几个小学生问问，比如你父母辈亲戚朋友的孩子，问他们是否知道摩尔庄园和赛尔号，是否充值了，相信你会得到非常惊讶的答案。所以，2010年后，任何小作坊型的创业团队再想进入FLASH WEB GAME行业，都需要更加谨慎了！

 

★创业型游戏公司面临的问题和困难
→在正式进入FLASH WEB GAME的技术探讨前，我左思右想，还是觉得必须先说一下创业公司存在的问题和困难，为后面可能不太“正规”的做法找一个合适的“理由”。——人不能太爱找客观理由，但也绝对不能为了避免“找理由”之嫌，而弃客观现实于不顾，毛爷爷曾告诫我们要懂得“实事求是”。

→任何有过创业经验的技术团队和公司应该都知道，教科书那套从成功公司抽象出来的模式在创业初期几乎只能是神话一般的存在，相信没有几个公司能完全做到。当然那种千万级启动资金，有成功背景的新公司除外。像我们公司，一开始就4个人，前台和后台各一个人，如果我们两个都每天用一半时间考虑架构和写文档，我们的产品猴年马月也上不了线了，况且我们写了给谁看呢？在这个阶段最最重要的目标就是尽快把产品做出来，上线运营出一定效果，给产品更加明确的方向，给团队信心，然后尽最大努力去融资，以求下一阶段的发展。产品出不来，只靠一个idea和产品策划书就想找投资的时代早就一去不复返了。

→我觉得一个创业公司最现实的发展观应该是这样的：初创阶段（技术导向型阶段）：这个阶段要一切以“我们能做什么”为基础，在财力、人力、经验都不足的情况下，找出我们的优势，“把我们所擅长的做到最好”是我们唯一的筹码，毕竟初创人员能走到一起，必然是有一定共识，在某方面有优势的。而“我们能做什么”，在初创阶段很大程度上就是指技术能做什么。没钱、没人还想把项目做的又快又好，绝对是痴心妄想。这个阶段就开始叫嚣“市场主导产品”，“不看过程只看结果”等口号，完全是不务实的态度，市场上最热门的产品你未必能开发出来，创业阶段，前途未卜，你不看过程看什么？发展阶段（人力导向型阶段）：假设我们顺利度过了第一阶段，公司开始有现金流或者找到了天使投资，我们就开始布置进一步的发展了，这个阶段招人将是公司的一个要务，招有创业精神的人，更要招我们需要和缺少的人。以前我们公司只有AS，于是游戏server只能用FMS，现在应该招一个C++ socket的人了；以前公司没有网页前端，网站都是原画和PHP代劳的，现在该弥补了；以前整个游戏都是架构师们设计并实现的，现在应该招一两个做模块打下手的人了。这个阶段虽然不适合大规模扩展人手，但在要害人力点上，也绝对不能抠门，我们公司就是吃亏在socket上，公司一直不肯招一个专业写server端的，一直让前端和PHP代劳，结果游戏同时在线人数一超过5000就会出各种离奇问题，最恐怖是大家都不清楚问题到底在哪里，只能大眼瞪小眼，这个时候老板就会臭骂公司这帮技术都是饭桶，这么多人还搞不定这个问题。老板不懂技术，说出这样的话无可厚非，但老板不听劝，死活不愿意招要害人员，这就是他的错了。总之这个阶段要以人力发展为核心，尽最大的努力把必要的人手配备齐。必须注意的是，这个阶段不适合空降部门领导，公司发展阶段，只有初创人员陪公司一路走来，最明白公司的问题，以及各种问题的根源。而空降的领导容易只看到问题，不明白为什么会有问题，有时候难免说出“道理上很正确，但实际上不可行”的话，而老板为了配合新领导树立威信，很多时候不得不偏向新领导，这样以来很容易打击到初创人员的积极性。更严重的是可能让初创人员看不到前途，创业的激情沦为打工的无味。这个阶段挖墙脚空降领导，希望他们能把公司制度正规化，希望他们拯救公司的做法可能适得其反！公司初创人员这时候应该依旧是公司的顶梁柱！成熟阶段（产品导向型阶段）：如果有幸过了前两个阶段，到了这个阶段的时候，公司应该已经实现了正向盈利，作为一个游戏公司，一旦靠自己实现盈利，相信各种投资机构肯定会主动找上门，千万美元的投资绝对不夸张，你将会为到底接受哪家的投资而烦恼。人力、财力、物力都不再是问题，产品研发和运营的经验也成熟了，这时候唯一要关注的就是市场，什么样的产品更被市场和用户接受，争取开发出更多更好的产品。产品要多样化，公司要规模化，要形成自己的产品链和平台，抓住更多的用户，开拓更多的盈利模式。这时候才是产品主导公司，才是从大公司挖人的时代。如果这些都做到了，当老板再次开会谈“上市”的问题时，每个人脸上将会笑容依旧，只不过初创阶段的笑容是那种开玩笑试的玩世不恭，而现在则是对未来的美好憧憬。

→其实任何理论都是有前提的，牛顿定律也只是在低于光速的情况下才适用。公司发展的历程中，老板和员工肯定都会有其信仰和观念，都会用各种言辞来说服别人。但我相信没有那种理论和言辞是永远正确的，尤其是书上和大公司的那些所谓的成功经验更是要警惕，因为它们身上有太多的光环，一场本来可能很有价值的讨论，说不定就会被一句“盛大就是这么做的”给结束掉！所以在我们谈任何理论的时候，不妨看看公司现在所处的阶段，不妨时刻谨记毛爷爷的话，实事求是的看待自己。我们公司就曾屡次吃类似的亏，公司在第一阶段刚拿到天使投资，就想做第三阶段的事了，结果做了很多，一件也没做好，白白浪费了很多时间和大好机遇。其实当时老板用来说服人的理论也都是正确的，只不过不适合公司的实际发展情况而已。还有一点要强调的是，不管公司现在处于第几阶段，坚决不能全盘否定其它阶段的付出和努力以及很多不得不犯的“错误”。之所以强调这一点，也是我们公司曾踩过的雷区，当我们发展到第二阶段的时候，公司就开始忙着空降领导，然后这些领导对我们之前的做法开始逐一否定，把做后台的哥们儿说的一无是处，搞得团队气氛极不融洽，吵架红脸的情况经常发生。这就好比我黨在经历了长征、抗战和解放战争的原始积累后，在最终发动三大战役攻打大城市时，指着毛爷爷的鼻子说：“你以前那套只敢打农村，打的过就打，打不过就跑的逃跑主义路线完全是错误的！”试想，如果黨内空降领导都是这种态度的话，将会对我们黨和战士们的积极性产生多大的打击！这种情况其实在长征途中就发生过，差点就葬送了黨，好在遵义会议及时纠正了苏联空降回来的_明等人的左倾激进主义，挽救了黨。而我们的公司，谁来挽救我们的公司呢！

 

★FLASH WEB GAME的系统架构
→我在这里把一款FLASH WEB GAME的架构分为三部分：系统架构、前端架构、后端架构。“系统架构”主要是指根据一款游戏的特点以及公司的实际情况选择合适的技术实现方案，主要包括美术方案，前端方案和后端方案；“前端架构”主要指FLASH前端的主程序以及模块划分；“后端架构”主要指即时通讯部分和数据库。这章先谈系统架构。

→谈到架构，我不得不说，那些所谓的完美架构，能够一次架构好，永远不用改的说法只能是传说，或者技术人员忽悠老板的说法，对于创业公司更是如此。创业公司初创时期更多的时候需要在游泳中学会游泳，因为大家都没有经验，失败是最好的教科书。就算大家知道应该怎么做，很多时候条件也不允许。比如我们在一开始就知道应该自己写socket服务器，可就是没socket的人才，于是不得不先使用FMS+PHP。公司一开始的美术更精通FLASH一些，而且我们计划的是要做“企鹅”，于是我们选用矢量图。可后来随着公司产品定位的不断改变，我们的架构和解决方案也会不断调整，当达到一个临界点时，修改的代价已经超过重新开发，我们就不得不对架构进行“重构”了！这时候聪明的老板应该支持程序员们的意见，充分调动他们的积极性尽快改完，全公司应全力配合，尽快度过难关。而不明事理的老板肯定会每天抱怨程序员无能，搭出一个垃圾架构不能满足产品的持续快速发展，拖了产品和市场的后腿，给程序员造成很大的压力，积极性没了不说，在长期经验积累之后本来可能是一次非常好的机会能做出一个相对完美的架构，满足日后很长一段时间的需求变更，结果因为老板过分催促和施压，又烙下了许多隐患，而这些欠下的债，总有一天要还的，这一天来临之时，责任虽然可以完全由程序员承担，但整个公司都要为之付出代价！所以关键时刻程序员该坚持还是要坚持自己的观点，要尽量说服老板，程序员的社交能力在这个时候就凸显作用了，你要明白你不但是在对自己负责，也是对公司负责！另外，真的很希望天下的老板们都能明白一个道理：能够根据公司实际情况不断调整的程序员才是最可爱最辛苦的程序员，而不是那些什么都不管，上去就提一大堆要求，必须都满足他，他才愿意做的程序员。

→就算时至今日，FLASH WEB GAME在国内发展差不多三年了，但我敢说FLASH WEB GAME还是没有什么行业标准的技术解决方案，尤其是前端，大家都是自成一派。在这个时候，让我们再次搬出那句老话：不管黑猫白猫，抓住老鼠的就是好猫。不过经过这几年的摸索，还是有一些规律可循的：
        1，美术：如果游戏画面简单，色彩构成相对单一，场景内总体元件能控制在100个以下，则非常适合直接使用矢量图，画面各组成部分尽量拆分为能重用的独立元件。这样虽然牺牲了客户端的CPU，但能因为重用最大化而大大减少美术的工作量，也方便他们日后应对需求变更，比如某些元件的尺寸变动。在画面简单，元件又少的情况下，利用递归全元件位图缓存，拿少量内存还能换回大量CPU，找出这个平衡点，完全可以做出很好的用户体验。
        可大部分时间，我们的游戏场景可能都非常炫，画面复杂，色彩鲜艳。使用矢量图的话，一方面不容易画出想要的效果和精细度，这时候使用矢量图反而增加了美术的工作量和难度；另一方面，使用矢量图还有可能导致客户端CPU严重飙升，超出普通客户端电脑的承受范围。这时候我们应当用位图做游戏背景，重用性不大的元件要尽量合并到背景位图里，减少位图总个数，一些简单的动画如果非要用FLASH做成矢量动画的话，也要尽量做成逐帧的，相信FLASH IDE玩的转的美术同志们应该知道怎么把一个渐变动画瞬间转换成逐帧动画。逐帧动画虽然会导致SWF文件体积增大，但相对于换回来的客户端CPU来说还是值得，这其实是牺牲了一些服务器带宽和用户等待时间，换回严重的客户端CPU超载。而如果你的动画非常复杂和精细，精细到只有AE等粒子特效软件才能表达的话，建议还是直接从AE里导出位图序列，在FLASH里弄成逐帧动画，太过复杂的动画绝对不能用FLASH直接做，不但很难做出想要的效果，而且复杂矢量图的SWF文件体积也会大大超过位图，有可能导致用户因为SWF文件加载时间过长，失去等待的耐心，这时候我们情愿牺牲美术的工作量和工作流程，换回想要的效果，减小SWF文件体积。还有一点要提醒的，时间轴动画不可见时，程序一定要记得将其stop掉，不像程序动画，时间轴动画不可见时，FP内部其实依旧在重绘，对CPU还是有影响的。
        还有一种极端情况是场景元件超标，比如整个游戏内所有元素（包括各种MC、BTN、位图以及程序创建的displayObject，总量超过500，这时候你会发现，画面静止还好，但只要游戏上鼠标随便一晃，或者有几个人物随便走一下路，CPU都会狂飙，就算这500个元件都是位图也无济于事。其实这是FLASH的一个瓶颈所在，是目前所有FLASH大型项目都有可能碰到的问题，也是我觉得阻碍FLASH进一步发展的主要障碍之一。在一个元件超多的背景图上进行任何的鼠标动作、动画、文本渲染，都会导致CPU严重飙升，甚至画面很卡。要解决这个问题，本质的也是唯一的方案就是减少元件数量，要想尽一切办法降到200以下。而这需要美术、前端和策划通力合作才行，绝对不是前端程序员就能搞定的事。策划要从产品的角度上看能不能简化目前场景同一时间出现的元素，美术要把能合并成一张图的元件在绘图软件中合并成一张位图，前端AS程序要把不需要响应鼠标事件的元件的mouseEnable和mouseChildren都设置成false，一些能利用copyPixels合并的位图就合并成一张，比如可以平铺创建的房间地板和墙面，要copyPixels成一张图，而不是new出好几百个元件。
        其实元件超标的情况是大多数没有经验的团队很容易发生的问题，这时候前端程序员要起到领头羊的作用，给大家讲明白道理，用事实让大家信服，组织大家一起把事情做的更好，而不是一味的在那里抱怨FP效率低。因为这时候你是团队唯一可以依靠的人，如果这个问题解决不了，虽然大家都有责任，但前端毫无疑问是罪魁祸首！
        极端情况下的极端解决方案：如果游戏策划的非常酷，一个子弹爆炸效果就需要几十个元件支撑，画面上同时又需要几十个坦克混战，这时候常规的解决方案是根本达不到的，但不是说就一定无法做了，你可以利用强大的BitmapData类把每帧要显示的游戏画面完全计算好并且在内存中绘制，然后以一张图的方式渲染给用户，这时候用户玩你的游戏仿佛就像在看逐帧的动画，此时FP占用的CPU大部分都是计算耗用的，而不是渲染耗用的。其实AS的执行效率远远高于屏幕渲染，你把CPU的主要负荷转移给AS，反而能做更多更炫的事情。据我的初步研究，前段时间名噪一时的FLASH版3D雷神，还有现在很多国外效率高的“有点假”的TD类和飞机类单机游戏都是这么做的。可这种模式适合用来做多人联机并且有大量交互界面的FLASH WEB GAME么？我初步思考了一下，感觉是不可能的。首先，大量的交互界面意味着需要用鼠标点击，试想在一个逐帧动画中，每帧都要响应鼠标是什么概念？所以UI部分首先排除了；然后是大量的即时数据交互，每当一个异步的请求得到响应，画面就需要做出相应的改变，这将对本来还可能比较工整的内部绘制算法制造非常大的麻烦，难度太高！基本上也不可行；最后是很多FLASH WEB GAME的画面重用性并不是很高，比如像我们游戏的每个场景都是美术专门画的，而不是用地图编辑器编辑的，这就意味着你无法完全用程序拼出一个场景来；综上我觉得一个款FLASH WEB GAME基本不可能完全使用copyPixels完成，最多是部分实现，比如我上面说的墙面和地板。除非你的游戏策划很NB，知道什么游戏能最大限度的利用copyPixels，而这样的策划估计本身肯定也是个前端程序员。
        2，前端：从系统架构的角度上讲，前端其实很简单。现在WEB GAME主流的前端技术无非就是AS和JS。JS的前端地位其实比AS要老，很多人的JS经过这么长时间的磨练，功力深厚，做一个策略类甚至简单的MMORPG都没问题。但现在用AS来做的话可能更简单，更容易做出更酷的效果和更好的用户体验。所以最近两三年，随着基于面向对象的AS3逐渐完善和普及，FLASH WEB GAME似乎逐渐成了唯一的主流。
其实除了as和js外，还有很多前端技术可以供我们选择，比如shockwave，java，还有那传说中的flash killer：silverlight和html5等等。每种技术都有其优劣势，比如shockwave在图形渲染方面比flash强了千百倍啊千百倍，因为它可以完全调用显卡，我在网页上玩过一个基于shockwave的CS，流畅度和操作感完全不亚于桌面版的CS，还有国外的哈宝以及国内的娜娜米米都是基于shockwave的。而Java和silverlight也都有强大的背景，HTML5最近也是来势汹汹。但不管怎么样，2010年，FLASH仍以其广泛的覆盖率、酷炫的效果和逐渐成熟的开发社区，以最高的综合评分独领WEB GAME业界风骚。所以任何公司和团队，如果现在想做WEB GAME的话，如果实际情况允许，FLASH还是最好的选择。
        3，后端：后端不是我的强项，我就不多说了，我只根据我们公司的经验谈谈心得。我同意前后端编程有很大区别，但绝不同意前后端谁简单谁复杂之说。根据我这几年的观察，我发现，前端偏重的是效果，是用户体验和细节处理，有时候可能还要涉及一些图形算法；而后端则偏重数据结构和数据处理，讲究的是性能、安全和扩展性。前端工作量一般比后端大，而后端需要的工作经验比前端多，想依靠一个只掌握了理论知识的大学毕业生就支撑一个公司的后端架构是严重不靠谱的！前端架构师必须是一个编程高手，十几、几十万行代码要在他的手里安排的井然有序，后端架构师则必须有过大型项目经验，并且项目同时在线人数达到过一定规模。前端架构出现问题，会严重拖垮开发周期，而后端架构一旦出现问题，对公司将是致命性打击。所以在公司里宣传所谓前端重要还是后端重要的说法，是完全错误的，任何一款好的产品，必将是策划、美术、前端、后端都达标的产品，缺失任何一块儿，都成功不了！不同部门之间的比较和较真儿没有任何正面影响！
        至于后端的技术解决方案，我感觉如果是需要大量即时交互，并且对即时性要求很高的游戏，就必须使用socket服务器。而如果对即时性要求不高，完全可以用PHP，部分的即时交互可以用socket实现或者HTTP轮询也可以。如果你的公司也像我们一样刚开始没有合适的C或者JAVA socket程序员，选择fms和sfs也未尝不可，这样至少可以让前端人员代劳，让项目可以启动。切记这只是为解燃眉之急的下下策，长久不了，公司要想办法尽快找到一个合适的人，在合适的时机重构。

 

 

★FLASH WEB GAME的前端架构与人事分工
→前端的主程序架构和模块划分与人手和人事分工是紧密联系在一起的，而这些很大程度上又是由项目本身决定的。纵观现在国内绝大多数FLASH WEB GAME的规模和难度，我觉得前端AS人员大概需要2-7个之间，主程序有效代码一般不会超过10W行。在这种情况下，人事分工应当以功能和模块进行划分，尽量避免多人维护同一份代码，每个人各司其职，减少维护和协作的成本。这种模式非常适合人手不够，制度不健全，而且追求效率的初创公司。

→根据各种游戏类型的不同，分工也应该不同。策略类更注重界面开发，分工上应该向UI偏重，MMORPG类注重主架构一些，而像我们的海底世界，是更新驱动类社区游戏，每周都要发布新内容，还需要大量的小游戏和场景功能支撑，所以需要更多的模块和小游戏程序员。

→下面就以我们公司为例详细谈一下，我们公司最多的时候，一共5个AS程序员，分工是这样的：1个主架构，1个主UI,1个小游戏，2个场景和模块程序员。主架构同时负责FMS的sever端；主UI同时负责前端人员管理和文件管理；小游戏人员以平均每月两个单机或者联机游戏的速度循环不停开发，是相对最独立的一部分；而两个模块程序员，负责每周发布的新场景和新模块功能，他们的工作量其实蛮大的。

→先谈前端主架构，前端程序主架构有两个主要任务：1，要从架构高度合理划分前端各模块，提出可行的实现方案；2，从AS级别搭建程序架构（非文档级别），制定前端编程规则和接口，规范程序各部分的职责划分。这两个任务其实包括很多具体工作，比如：游戏启动流程制定，确定哪些SWF文件需要外部加载，那些功能可以从主程序剥离出去单独实现，前端配置文件怎么处理，公共素材怎么处理，MVC三层怎么划分，主程序框架的选定，主程序怎么和后台通讯，主程序如何与模块协作，哪些代码应该放在主程序中，哪些代码应该放在模块里，主程序如何既能提供模块所需要的一切功能和数据，同时又相对模块自我保护等等等等。其实我谈的还只是一些大的方面，具体到实现的级别，还有大量细节工作要做。而这些工作在项目启动之初都是非常重要的，直接影响到项目中后期的开发和维护效率。

→上面提到的那些点，我不可能全讲一遍，不然就不叫“浅谈FLASH WEB GAME”了！我只挑两个比较核心的内容跟大家略做探讨，就是前端AS框架和模块划分的问题。先谈前端框架：现在市面上流行很多前端框架，不管是针对“FLASH”的，“FLEX”的还是“通用的”都有。我们是否一定需要框架，或者必须使用某个框架，这完全是仁者见仁智者见智的事，从最终的结果上讲，争论这个问题意义不大，我相信一个5W行左右的项目，任何有5年以上编程经验的人，不管用什么作战策略，最终都能攻下山头，把项目做出来。但有一点至关重要：你必须能完全把握你的架构和你使用的框架，并能跟你的前端同事解释清楚。那好坏架构的区别在哪里呢？区别在于好的架构在开发过程中会更轻松，你不用天天担心的你代码，不用每天不停的写文档，以防止自己忘了复杂的逻辑，你可以在任何时间开始写代码，在任何时间去玩会儿游戏然后回来接着写；区别在于好的架构更符合业界标准，更容易被传统和正统的程序员接受理解；区别在于你可以用很简单的几句话就把你的架构思想描述清楚，用几个很简单的文档就能让别人接手你的代码，在人事变动和工作交接的时候让自己更轻松；区别在于当你掌握了一种通用框架或者自己总结一套成熟的架构后，你几乎可以套用以后的大部分项目，并不断完善它，开发越来越轻松，速度却越来越快！

→我们的项目，主程序使用的是pureMVC框架，而主UI部分是自己写的。主程序和主UI相互独立，可以单独编译测试。主程序是纯代码，用FLEX SDK编译，而主UI则是界面和AS混写并用FLASH编译。这样就把MVC中的V从物理层面上完全独立了。pureMVC框架正如其名字，是一款“纯粹”的MVC框架，在我看来，他只是帮我们实现了MVC的编程思想和套路，其它多余的功能一点没有，这使它具有更高的通用性，也是它最可爱的地方。根据我们的经验，pureMVC单核心版就已经完全可以应对主程序有效代码在10W行以下的项目了。但在我跟很多没有用过框架的前端朋友聊天中，发现他们对这些框架本身就有抵触心理，或者有些对MVC模式都理解的不深刻，用起MVC框架又怎能得心应手？还有一些更过分的朋友把自己的问题也归结到框架上，说什么用了pureMVC框架后，自己的项目编译一下要十几分钟，我听了之后哭笑不得，项目编译慢一般是因为没有合理划分模块导致主程序过大才导致的，跟框架有什么关系？如果因为大家的种种误解和这些人的言论而导致一些新人错过学习这么一款优秀的框架，我觉得实为憾事！

        pureMVC既然是一种MVC框架，这就意味着你首先要熟悉MVC。这种熟悉绝对不是对MVC的直译：模型、视图、控制器，而是要真正理解为什么要把程序划分成这几部分，在划分主程序模块时，要时刻能站在MVC的角度考虑问题，而当面对一段实际的代码时，能快速准确的判断，这段代码应该放在MVC中的哪部分。《pureMVC最佳实践》这份短短几十页的文档中，可以说处处闪烁着MVC的思想火花，不但清楚地阐述了怎么使用框架，而且时刻从MVC的角度告诉我们应该把哪些逻辑放在哪些部分中，应该注意什么问题。这个文档早已经有中文版，有兴趣的朋友可以自己去看看，文中有的，我这里就不赘述了。我只结合自己的体验谈一些文中可能没有涉及的，也是在真正开发中才会碰到的问题。

        1，模型部分在实际开发中除了存储数据，还有其他作用么？是的，其实它的实际职责非常多。它要给Command和Mediator提供接口，响应用户操作，进行数据操作或者请求远程数据服务，进行数据的序列化和反序列化，得到异步数据后可能还要检查数据合法化。但不管怎么样，它始终是在和数据打交道，同时也应该是你的主程序中唯一可以直接和数据打交道的管道，别的部分要想和数据有接触，首先要问问它同意不同意。模型处理完数据会以Notification的消息方式通知Command或者Mediator。但绝对不能在Proxy中直接调用Mediator，这是为了保证数据层的独立性、可移植性和重用性，也简化了你的架构思想。不过可移植性这个优势，估计很多搞FLASH WEB GAME的朋友暂时都没啥机会体验，呵呵。

        2，Command，Command，Command！连叫三声“Command”，希望可以引起大家的注意。因为Command的使用，在很大程度上反映着你对pureMVC框架的理解，甚至是对MVC模式的理解深度。在pureMVC框架中，各部分通讯是用Notification消息，Proxy可以给Command和Mediator发消息，Command可以给Command和Mediator发消息，Mediator可以给Command和Mediator发消息，怎么样？你现在是不是点晕了，这是正常的，其实我也有点晕！当你代码写到一定规模后，你会更晕。其实pureMVC框架这么设计本来是为了让MVC各部分尽量脱耦，但这带来一个负面情况就是消息发送与接收机制设计的太灵活了，灵活对小项目是好事，但对大项目来说，往往意味着混乱，甚至会导致灾难。那怎么办呢？只能靠我们的自觉性自我约束，简化架构思想了。根据《pureMVC最佳实践》中的建议，我的做法是这样的，尽量使用Command，让Command成为Mediator与Proxy之间通讯的唯一桥梁，Mediator和Proxy中发出的Notification，接收者一定是某个Command，然后再由Command处理并将结果转发给真正的消息接收者，Command就算仅仅起一个转发作用，仅仅有不到10行代码，也要创建一个Command类。这样不仅使你的架构更加清晰，而且也更符合MVC思想，Command类的大量存在还使你架构的业务逻辑具有了更好的封装性和扩展性，可谓是一箭三雕，何乐而不为？唯一的负面影响可能是你需要创建和维护更多的Command类文件，但相对于优势而言，这点影响不算啥。

        3，我知道现在可能还有一些朋友在用FLASH IDE写代码，这些朋友的执着让人钦佩，但我想任何一个熟练使用过FLEX BUDIER、FD或者FDT的朋友，都绝不会再回头使用FLASH IDE写代码了。——不对啊？不是谈pureMVC的么？怎么扯到IDE上去了？这是因为我现在要讨论的问题就和IDE有关，假如你现在用的还是FLASH IDE的话，除了随时写文档外，我真的很难想出一个很好的方案可以让你在没文档支撑的情况下，轻松掌握和随时维护几万行代码。可如果你使用的是FDT,就可以在没有文档的情况下，利用“ctrl + r”和“ctrl + 鼠标左键”，以及全文件搜索等工具，瞬间搞清楚代码之间的联系和逻辑，找出要修改的地方。OK，终于到pureMVC了。如果你使用的是FDT,并且开始尝试使用pureMVC框架，可在使用的过程中，你发现你在写主程序时，还是不停的使用“ctrl + 鼠标左键”，而不是“ctrl + r”，这说明你必须重新审视你对pureMVC框架的理解了，请审查你的Mediator类，看里面是不是充斥着大量的public方法，如果你的对象之间依旧是通过public方法进行引用，而不是通过Notification通讯的，那你也没有必要继续使用pureMVC框架了。

        4，单例模式影响到底有多大？pureMVC是一个完全依赖单例模式的框架。单例模式似乎在AS界一直有很大争议，这样的话，pureMVC肯定也会有相应的争议了。持反对意见的人，大多集中在“性能”和“团队协作”方面，他们认为一个单例持有过多引用会带来性能问题，而且生怕在团队协作中自己的单例类被人无意修改，引发离奇的BUG。性能方面，我之前也没做过10W以上的项目，不敢妄言，但10W行以下的项目，绝对没有问题，如果你两三万行的架构就开始碰到主架构性能问题，估计十有八九是自己的代码写的有问题；团队协作方面，我觉得pureMVC的Façade模式是非常灵活好用的，大家可以略做讨论，制定一个简单的规则，比如模块只能通过façade获取数据和发送Notification，不能直接调用主程序其他CLASS，只要架构程序员不犯错，模块程序员甚至连犯错的机会都没有，如果他们有，还是你的架构思路有问题，请继续审视自己的代码。反正单例模式的问题到底是什么，我到现在也没完全搞懂，主要是我们的项目没碰到过此类问题，希望碰到过的朋友能再仔细跟火山说说，我也好弄清楚问题到底出在哪里了，自己以后可以更好的避免此类问题发生。

        额，框架部分先谈上面4点吧，赶快进入下一个话题，模块划分：模块划分主要包括“核心模块划分”和“子模块划分”。核心模块的划分思路是这样的：它们是游戏启动所必须的，相互之间是紧密联系的，还要经常的被子模块调用；而相对的，子模块的划分思路是：他们在游戏启动过程中不是必须的，可以在游戏过程中再加载，子模块相互之间基本上完全没有联系，一个子模块的增加和删除不会影响到任何其他子模块，子模块可能需要调用主程序的接口或者获得主程序的数据，但主程序绝对不应该依赖某个子模块。

        明确了模块划分思路再具体看看哪些部分应该划分为核心模块，哪些部分应该划分为子模块。一般情况下，核心模块按照游戏启动顺序包括：一个壳子SWF → 配置文件包 → 登录注册SWF → 主程序SWF → 主UI的SWF → 公共素材包。而子模块相对来说简单很多，比如具体的某个小游戏，某个场景，以及某个场景里的触发功能等等。下面我对核心模块逐一略做解释。“一个壳子SWF”：这是一个体积很小，但意义很大的SWF；它后面总是跟着随机变量，确保每次用户加载的都是最新的；它里面定义着一些需要经常更新而且每次更新都必须保证用户也在第一时间就得到最新值的变量；它里面最好有一个简单背景图，保证用户在超低网速的时候输入游戏网址不至于长时间面对一片空白；它里面有安全策略的设定，是我们游戏和很多第三方平台合作的基石；它里面还定义着主程序被加载进来之前的游戏启动流程等等。“配置文件包”：核心模块版本号啊，全局文字说明啊，service接口定义啊，各个核心模块需要的配置信息啊什么的，一般是一些XML文件。“登录注册SWF”：这个简单，在加载重量级的SWF前，先加载登录注册SWF,可以保证用户第一时间就能打开登录注册界面，而且可以有效节省服务器带宽。“主程序SWF”：这个就是我前面费了好大劲讲的主程序部分了。“主UI”：主程序和主UI为什么要分开两个SWF，我前面已经提过了，后面还有说明，这里暂时不讲。“公共素材包”：公共素材包是一个游戏不可缺少，但也不能过分依赖的东西。它包括一些全局的道具和效果，比如表情、技能特效、场景传送门等等。公共素材包里面最好就是一些简单的动画，体积小功能简单，严禁在公共素材包里添加上百K的东西，或者代码上百行的小模块，公共素材包建议500K以下。

        看了上面的讲解，你可以能觉得核心模块分那么多，太麻烦了。不错，在我看来，对SWF加载流程的分解和控制，对异步程序的掌控正是衡量一个AS程序员是否经验丰富，是否足够老道的重要指标，很多从其它语言转到AS并有多年编程经验的朋友，架构方面可能和AS程序员差不多，甚至比很多自学成才的AS程序员做的更好，但这方面往往不如长期与CPU和SWF体积搏斗的老牌AS程序员。核心模块划分的越合理，用户体验往往越好，后期编写和维护代码的效率会越高，但在前期会比较麻烦，而且对架构师的架构经验和能力必须提出更高的要求。什么都不分，主程序、素材、核心模块都弄在一个SWF里，用户一开始必须先下载完这个SWF,或者弄了一堆核心模块和超多公共素材，用户一开始必须面对loading条不停的周而复始，必须等所有核心要素全部加载完成才能进行一些基本操作的做法，从架构角度上讲，是最简单的做法，因为不用过多考虑复杂的异步和SWF拆分问题，但从用户体验和长远的开发维护上讲是非常不利的。根据我们的经验，用户登录前加载的所有资源体积应该控制在200K左右，而用户进入游戏主场景前，加载的资源总数应该控制在1M左右。还有前面提到过的那位用了pureMVC后项目编译一下要十几分钟的朋友，估计就是把所有东西都弄到一个SWF里的做法。主程序随便改动测试一下，就要十几分钟，牵一发而动全身，开发效率从何谈起？根据我们的经验，任何主程序、核心模块还有子模块的编译，都必须在10秒以内，这才是合理的——我的机器是07年花了3000多买的戴尔品牌机。

→谈完主架构，接着谈主UI。主UI一般指主要的人机交互界面，这里的主UI区分于主架构中的mediator，当你看过pureMVC文档后，你就知道了，mediator只不过起到一个真正的V和pureMVC框架之间的桥梁作用，pureMVC里的mediator其实并不实现什么功能，真正的功能都是在主UI里实现的。但主UI又不得不算是主程序的组成部分，因为它不像其他模块，基本上只需要调用主程序的接口就行了，本身并不需要对主程序提供接口。而主UI作为用户操作界面，必须大量的向主程序的mediator提供接口，或者发送events。所以主程序和主UI之间的配合必须非常密切才行。

        不同的游戏类型，可以选择的UI解决方案也不同。策略类非常适合用FLEX；MMORPG这类标准网游，非常适合用ASWING；而像我们海底世界这类游戏界面非常夸张，没什么标准规则，又不是太复杂的界面，还是适合自己开发。相信任何有过游戏项目经验的人都应该能理解，UI也是FLASH开发中的重头戏，很多细节的处理非常麻烦，在项目早期具有很大的工作量。还是以我们的项目为例，我们的UI架构思路是这样的：

        1，所有的界面组件都是直接拖放在stage上的，其功能代码大部分都是在发布时编译的，基本上不用new的方式。这种方式的好处是方便编辑界面，从总体上直观的把握所有的UI，减轻程序运行时的负担，同时避免addToStage带来的诸多问题。缺点是，当UI膨胀到一定规模时，可能会需要你有一台配置比较好的电脑——哎，说到这里我就伤心啊，我那台玩魔兽效果全关还卡的电脑，一直陪伴我的整个UI开发历程。
   
        2，UI的FLA层次结构是这样的：第一层是文档类或者与UI主类关联的某个MC，我们选用的是MC的方式,因为MC的方式更灵活；第二层是这个MC里的所有组件，这些组件大部分是根据功能划分在一起的一组元件，比如你的个人面板，而这个组件本身也是个MC；第三层是组件里的所有元件或者共用组件，元件就是背景啊，按钮啊什么的，而共用组件比如滚动条啊翻页组件啊什么的；主要的就这三层，其实那些共用组件MC再往里面双击还可以划分一层。对应FLA的层次结构，AS的结构如下：文档类或者主MC关联的类是第一层，这个类里持有所有的界面元件的引用；第二层是这些界面元件对应的组件CLASS,组件的功能都是在这里实现的，比如个人面板的MC将会对应一个MyPanel的CLASS,这个CLASS里实现MyPanel的所有功能。至于CLASS和元件之间是怎么对应的，我用的是一种松耦合的代理模式，也就是将MyPanel对应的MC作为参数传递给MyPanel这个CLASS,而这个CLASS会有自己的私有变量记录对应MC里需要进行操作的元件，具体到功能实现时，从代码层面上看，就好像CLASS操作的都是自己的私有变量，而不是直接操作界面元件，这样，当界面元件修改名字时，CLASS的改动很小。而且这种代理模式可以实现一个CLASS代理不同的元件，当界面只是需要修改外观，不需要修改功能时，非常方便。那么这些CLASS是在哪里初始化并获得它要代理的MC呢？正是在主MC对应的UI主类中，比如当获得MyPanel对应的MC后，就会立刻public var myPanel:MyPanel = new MyPanel(myPanel_mc);当所有的组件注册完成后，这个UI主类就持有了所有组件的引用，可以方便主程序调用；代码的第三层其实就是共用组件，比较特殊的是，我的共用组件，比如滚动条，也是用代理模式写的。

        3，完全代理模式为我们创造了一种可能，就是把UI和UI对应的代码分开编译。这跟FLEX的皮肤更换机制有异曲同工之妙，只不过它的组件是要new出来的，布局是要代码控制的，皮肤都是一个个CLASS，整体效果一般都要编译后才能看出来；而我的组件是直接拖到舞台上的，布局大部分是直接在FLASH IDE里手动布置好的，皮肤都是一个个命名过的MC，整体效果编译之前基本上就能看出来。FLEX在更换皮肤的时候，CLASS名绝对不能变，而我的UI在更换皮肤时，MC的名字和层次结构不能变。FLEX关联皮肤是在编译时完成的，而我的UI关联皮肤是在运行时，当启动程序加载完UI代码的SWF和皮肤的SWF后，动态指定的。把皮肤和功能代码分开编译成两个SWF有个好处，就是在实际开发过程中，我们会碰到有时候只需要修改代码，而有时候只需要修改界面的情况，当然，就算你把代码和界面一起编译成一个SWF文件了，也完全可以对应这种情况，无非是编译一次的时间稍微长了一点点。可当你面对这样的情况呢：某次游戏版本更新出现状况，需要你目前功能不变，但画面必须退回到上一个版本。这时候你傻眼了吧？你开始对策划们咆哮：“你们能不能想想好再让我们做啊？”但你还是不得不重新打开已经做好的UI,把里面最新的界面再修改回老版本，同时还不敢把最新的删了，因为下一个版本估计马上又要替换回最新的画面了。可如果你的皮肤和代码是分开编译成两个SWF的，这种情况就简单了，你可以让运维从SVN上拉出上一个版本的皮肤SWF重新发布一下就好了，你所要做的只不过是动一下嘴皮。

        4，最后谈一下UI的数据层吧，UI是否需要数据层呢？答案是肯定的。尽管你可以从主程序那里获得任何你想要的数据，尽管大部分时间你只是需要数据来显示一下而已，但UI自己记住某些数据会大大方便自己写代码。UI的数据层不需要主程序那么复杂，每个组件有自己的数据变量，然后整个UI再有一个存放公共数据的地方就足够了。

→谈完主程序和主UI，最后再简单谈一下小游戏、场景和模块。先说小游戏吧，小游戏是相对最独立的一块，可能只需要主程序提供用户数据，并在游戏结束后将分数发送给主程序就行了。所以这部分从管理的角度上来讲是相对轻松的，但这不意味着小游戏开发就简单了，有时候，麻雀虽小五脏俱全，想开发出一个性能和用户体验俱佳的小游戏绝非朝夕之功，要是碰到一些算法复杂的小游戏，那就有得头痛了。其实对于海底世界这类儿童社区游戏，小游戏应该走创意和简单路线，搞得太复杂了，既不好开发，小孩子又不一定玩得来。

        相对于小游戏，场景和模块就和主程序甚至是主UI关系密切了，但不管怎么密切，大部分时候它们都是在所要数据，发送事件，或者触发某个界面的显示与隐藏。如果某个模块的修改需要经常波及到主程序，或者很多模块在做同一件事，重复写着同一段代码，这时候就必须重新审视架构，看是不是某些地方架构的不合理了，不合理的地方，只要时机允许，一定要尽快改掉，绝对不能放任自流，一块儿小毒瘤最终可能引发癌症。模块和场景程序员在我们公司其实是非常累的，因为每周都需要发布新的版本，每次都很赶。在这种情况下，场景和模块程序员的责任心就非常重要，他们随便哪里随意了一下，会直接导致糟糕的用户体验，因为大部分时间，用户直接接触的东西都是他们的作品。架构写的再好，最终模块都做的很糟糕，对用户来说没有任何价值！所以，一个老道的，有责任心的，能够快速开发出优良用户体验的AS模块程序员，完全有理由拿高薪，因为他们能做到的，一些所谓的纯架构师未必做得到。

 


已有 0 人发表留言，猛击->>这里<<-参与讨论


JavaEye推荐



无所不能 - 博客园

flash builder 命令行创建 AsDoc

阅读: 66 评论: 0 作者: Seven_Yuan 发表于 2010-03-09 17:46 原文链接

1 > 开始/程序/Adobe/ ...sdk command prompt 打开命令行

2 > 到项目目录

3 > asdoc -doc-sources ./src -output ./doc

哦了

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
· Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
· IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
· Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
· 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

编辑推荐：过去十年值得关注的十大技术事件

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

laan

入手iphone

去年过年回家在长沙手机被偷。狗日的，贼快的！回到北京后纠结了一个礼拜，狠心买了个iphone, 3gs 16g。 用了一个礼拜，感觉很不错。颠覆了我多年积累的操作习惯。好在有个同事比较熟，手把手的教我。 越狱的时候差点没刷成砖头。固件是3.1.3，目前是没有该固件的越狱出来，我们就在那使劲尝试。想起来后怕。现在只能装一些免费程序了。想起《紫牛》里面的内容。似乎每个用苹果产品的都不经意的成为了苹果品牌的喷嚏者。 本来是想等待ipad出来买一款，现在是不行了。严重经济危机。一段ipad的视频：http://player.youku.com/player.php/sid/39153192/v.swf
Jinni's Blog.

HP Slate上完美运行Flash Player 10.1和AIR

HP Slate基于Windows 7，因此支持多任务，可以使用各种Windows软件，并可以完美运行Flash Player 10.1/AIR。硬件方面支持摄像头和USB接口的各种设备扩展。这样的移动设备才能称之为“平板电脑”。至于Apple那款不会掉进厕所也不能打电话的大号iPhone其实也很不错，就是有两个功能不支持：这也不支持，那也不支持。

2010-03-08
Y.Boy's Blog

3月28日•上海浦东•中国Flash开发者交流会：新技术和开发经验谈

        第二次“中国Flash开发者交流会”将于2010年3月28日在上海浦东畅星大厦举行。畅星大厦离博雅酒店很近。第一次在博雅酒店举办时，场面一度失控，不是在中场休息享受美味点心的时候，而是在演讲的会场里人多得再也挤不下的时候。在活动主页上可以看到，这次交流会将会有来自盛大的啊中大人，也有传说中的寂寞火山。当然还有其余的专家为大家分享开发经验。在这次演讲里，每一个主题都是我感兴趣的：采用三元组来存储数据、性能测试、图像开发、位图引擎和对象池、PV3D in Flash、列表操作模式。

免费参加，火热报名中：http://swfsh.com/join

        第一次交流会上，可能让你印象最深刻的是以杯具为礼品吧^_^。这次，同样地，继续让你对“中国Flash开发者交流会”印象深刻，实用杯具依然是送给大家的最好礼物（货还没到，暂时透露这么多）。不过，可以确定的，作为衬托品，让这个交流会锦上添花，本次活动将在交互环节里，额外送出由图灵出版社倾情赞助的五项小礼品：《Flash ActionScript 3.0动画教程》和姐妹篇的《Flash ActionScript 3.0动画高级教程》、由RIABook.cn站长N神和天地会核心管理员达达联合翻译的《ActionScript 3.0基础教程》、极具权威性的《Flex 3权威指南》、最后是一本印上大大的“图灵教育5周年”的笔记本。有图有真相，当然还是要以实物为准（这次我找来了专业相机拍摄并手工处理过的）。

最后感谢美丽的图灵编辑 罗婧 小姐：http://blog.sina.com.cn/sixiluoluo（图灵兜兜猫）

Flash开发者交流会奖品

来一张不同角度的：
Flash开发者交流会奖品

Flash开发者交流会奖品

标签：Flash开发者交流会

相关日志

无所不能 - 博客园

pureMVC体会

阅读: 132 评论: 0 作者: Seven_Yuan 发表于 2010-03-08 11:12 原文链接

  转:http://bbs.blueidea.com/thread-2969949-1-1.html

        1，模型部分在实际开发中除了存储数据，还有其他作用么？是的，其实它的实际职责非常多。它要给Command和Mediator提供接口，响应用户操作，进行数据操作或者请求远程数据服务，进行数据的序列化和反序列化，得到异步数据后可能还要检查数据合法化。但不管怎么样，它始终是在和数据打交道，同时也应该是你的主程序中唯一可以直接和数据打交道的管道，别的部分要想和数据有接触，首先要问问它同意不同意。模型处理完数据会以Notification的消息方式通知Command或者Mediator。但绝对不能在Proxy中直接调用Mediator，这是为了保证数据层的独立性、可移植性和重用性，也简化了你的架构思想。不过可移植性这个优势，估计很多搞FLASH WEB GAME的朋友暂时都没啥机会体验，呵呵。

        2，Command，Command，Command！连叫三声“Command”，希望可以引起大家的注意。因为Command的使用，在很大程度上反映着你对pureMVC框架的理解，甚至是对MVC模式的理解深度。在pureMVC框架中，各部分通讯是用Notification消息，Proxy可以给Command和Mediator发消息，Command可以给Command和Mediator发消息，Mediator可以给Command和Mediator发消息，怎么样？你现在是不是点晕了，这是正常的，其实我也有点晕！当你代码写到一定规模后，你会更晕。其实pureMVC框架这么设计本来是为了让MVC各部分尽量脱耦，但这带来一个负面情况就是消息发送与接收机制设计的太灵活了，灵活对小项目是好事，但对大项目来说，往往意味着混乱，甚至会导致灾难。那怎么办呢？只能靠我们的自觉性自我约束，简化架构思想了。根据《pureMVC最佳实践》中的建议，我的做法是这样的，尽量使用Command，让Command成为Mediator与Proxy之间通讯的唯一桥梁，Mediator和Proxy中发出的Notification，接收者一定是某个Command，然后再由Command处理并将结果转发给真正的消息接收者，Command就算仅仅起一个转发作用，仅仅有不到10行代码，也要创建一个Command类。这样不仅使你的架构更加清晰，而且也更符合MVC思想，Command类的大量存在还使你架构的业务逻辑具有了更好的封装性和扩展性，可谓是一箭三雕，何乐而不为？唯一的负面影响可能是你需要创建和维护更多的Command类文件，但相对于优势而言，这点影响不算啥。

        3，请审查你的Mediator类，看里面是不是充斥着大量的public方法，如果你的对象之间依旧是通过public方法进行引用，而不是通过Notification通讯的，那你也没有必要继续使用pureMVC框架了。

        4，单例模式影响到底有多大？pureMVC是一个完全依赖单例模式的框架。单例模式似乎在AS界一直有很大争议，这样的话，pureMVC肯定也会有相应的争议了。持反对意见的人，大多集中在“性能”和“团队协作”方面，他们认为一个单例持有过多引用会带来性能问题，而且生怕在团队协作中自己的单例类被人无意修改，引发离奇的BUG。性能方面，我之前也没做过10W以上的项目，不敢妄言，但10W行以下的项目，绝对没有问题，如果你两三万行的架构就开始碰到主架构性能问题，估计十有八九是自己的代码写的有问题；团队协作方面，我觉得pureMVC的Façade模式是非常灵活好用的，大家可以略做讨论，制定一个简单的规则，比如模块只能通过façade获取数据和发送Notification，不能直接调用主程序其他CLASS，只要架构程序员不犯错，模块程序员甚至连犯错的机会都没有，如果他们有，还是你的架构思路有问题，请继续审视自己的代码。反正单例模式的问题到底是什么，我到现在也没完全搞懂，主要是我们的项目没碰到过此类问题，希望碰到过的朋友能再仔细跟火山说说，我也好弄清楚问题到底出在哪里了，自己以后可以更好的避免此类问题发生。

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
· Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
· IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
· Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
· 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

编辑推荐：过去十年值得关注的十大技术事件

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

杜增强

北京ActionScript圈第二次聚会

北京ActionScript圈第二次聚会
QQ群：80478454

本次聚会计划错开上班和正餐时间，暂定在3月14日下午2：00开始。

好伦哥 朝阳门店 :北京市朝阳区朝阳门外大街19号华普国际大厦二层

聚会内容为交友，资源共享，互助互惠；
报名参加不限于ActionSctipt开发人员，可带家属或其它朋友参加；
采用AA制消费，人均费用最高不超过50元人民币。

本群群主烟圈会联系一些HR，经理人，他们有可能参加；希望换个工作或寻找外包的朋友不要错过。

...

Copyright © 2010

继续阅读《北京ActionScript圈第二次聚会》的全文内容...

分类: 网闻 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

2010-03-06
无所不能 - 博客园

AMF

阅读: 144 评论: 0 作者: Seven_Yuan 发表于 2010-03-07 01:43 原文链接

AMF，也就是Action Message Format，该协议使得Flash player和Flash remoting具有了轻量级和高性能的通信方式。

　　AMF是Adobe公司自己的协议，该协议用作数据交互和远程服务调用，使得Flex客户端与应用服务器之间传送数据。了解熟悉Webservice的读者更容易理解，其AMF本身功能跟Webservice类似。只不过说Webservice基于XML，而AMF基于binary format也就是二进制数据。

　　因为AMF是Binary format而且经过高度压缩，因此适合用来传递大量的数据，其传输效率比Webservice要高，数据量越大越明显。

　　作者简单将其通过和Webservice的比较使大家较易理解，之所以单独用一讲来说AMF，因为要深入学习FLEX，对AMF的原理深层次理解非常有必要，特别是那些用来写游戏的读者，更要深入研究。

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
· Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
· IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
· Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
· 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

编辑推荐：过去十年值得关注的十大技术事件

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

2010-03-05
杜增强

Flash + Unity3D = ?

Flash + Unity3D = Eyes on the Earth 3D
Eyes on the Earth 3D

Copyright © 2010

继续阅读《Flash + Unity3D = ?》的全文内容...

分类: 随笔 | Tags: Unity3D   | 添加评论(0)

还没有相关文章，您来说两句？

2010-03-04
无所不能 - 博客园

GRASP (职责分配原则)

阅读: 213 评论: 0 作者: Seven_Yuan 发表于 2010-03-05 00:04 原文链接

要学习设计模式，有些基础知识是我们必须要先知道的，设计模式是关于类和对象的一种高效、灵活的使用方式，也就是说，必须先有类和对象，才能有设计模式的用武之地，否则一切都是空谈，那么类和对象是从那冒出来的呢？这时就需要比23种设计模式更重要更经典的GRASP模式登场了，嘿嘿，原来这才是老大！

GRASP(General Responsibility Assignment Software Patterns)，中文名称为“通用职责分配软件模式”，GRASP一共包括9种模式，它们描述了对象设计和职责分配的基本原则。也就是说，如何把现实世界的业务功能抽象成对象，如何决定一个系统有多少对象，每个对象都包括什么职责，GRASP模式给出了最基本的指导原则。初学者应该尽快掌握、理解这些原则，因为这是如何设计一个面向对象系统的基础。可以说，

GRASP是学习使用设计模式的基础。

1.      Information Expert (信息专家)

信息专家模式是面向对象设计的最基本原则，是我们平时使用最多，应该跟我们的思想融为一体的原则。也就是说，我们设计对象(类)的时候，如果某个类拥有完成某个职责所需要的所有信息，那么这个职责就应该分配给这个类来实现。这时，这个类就是相对于这个职责的信息专家。

例如：常见的网上商店里的购物车(ShopCar),需要让每种商品(SKU)只在购物车内出现一次，购买相同商品，只需要更新商品的数量即可。如下图：

(SKUID)来唯一区分商品，而商品编号是唯一存在于商品类里的，所以根据信息专家模式，应该把比较商品是否相同的方法放在商品类里。

 

2.      Creator (创造者)

实际应用中，符合下列任一条件的时候，都应该由类Ａ来创建类Ｂ，这时Ａ是Ｂ的创建者：

a.       Ａ是Ｂ的聚合

b.       Ａ是Ｂ的容器

c.       Ａ持有初始化Ｂ的信息(数据)

d.       Ａ记录Ｂ的实例

e.       Ａ频繁使用Ｂ

如果一个类创建了另一个类，那么这两个类之间就有了耦合，也可以说产生了依赖关系。依赖或耦合本身是没有错误的，但是它们带来的问题就是在以后的维护中会产生连锁反应，而必要的耦合是逃不掉的，我们能做的就是正确地创建耦合关系，不要随便建立类之间的依赖关系，那么该如何去做呢？就是要遵守创建者模式规定的基本原则，凡是不符合以上条件的情况，都不能随便用A创建B。

例如：因为订单(Order)是商品(SKU)的容器，所以应该由订单来创建商品。如下图：

 

3.      Low coupling (低耦合)

低耦合模式的意思就是要我们尽可能地减少类之间的连接。

其作用非常重要：

a.       低耦合降低了因一个类的变化而影响其他类的范围。

b.       低耦合使类更容易理解，因为类会变得简单，更内聚。

下面这些情况会造成类A、B之间的耦合：

a.       A是B的属性

b.       A调用B的实例的方法

c.       A的方法中引用了B，例如B是A方法的返回值或参数。

d.       A是B的子类，或者A实现了B

关于低耦合，还有下面一些基本原则：

a.       Don’t Talk to Strangers原则：

意思就是说，不需要通信的两个对象之间，不要进行无谓的连接，连接了就有可能产生问题，不连接就一了百了啦！

b.       如果A已经和B有连接，如果分配A的职责给B不合适的话(违反信息专家模式)，那么就把B的职责分配给A。

c.       两个不同模块的内部类之间不能直接连接，否则必招报应！嘿！

例如：Creator模式的例子里，实际业务中需要另一个出货人来清点订单(Order)上的商品(SKU)，并计算出商品的总价，但是由于订单和商品之间的耦合已经存在了，那么把这个职责分配给订单更合适，这样可以降低耦合，以便降低系统的复杂性。如下图：

TotalPrice()方法来执行计算总价的职责，没有增加不必要的耦合。

 

      4.      High cohesion (高内聚)

高内聚的意思是给类尽量分配内聚的职责，也可以说成是功能性内聚的职责。即功能性紧密相关的职责应该放在一个类里，并共同完成有限的功能，那么就是高内聚合。这样更有利于类的理解和重用，也便于类的维护。

高内聚也可以说是一种隔离，就想人体由很多独立的细胞组成，大厦由很多砖头、钢筋、混凝土组成，每一个部分(类)都有自己独立的职责和特性，每一个部分内部发生了问题，也不会影响其他部分，因为高内聚的对象之间是隔离开的。

例如：一个订单数据存取类(OrderDAO)，订单即可以保存为Excel模式，也可以保存到数据库中；那么，不同的职责最好由不同的类来实现，这样才是高内聚的设计，如下图：

Excel的功能发生错误，那么就去检查OrderDAOExcel类就可以了，这样也使系统更模块化，方便划分任务，比如这两个类就可以分配个不同的人同时进行开发，这样也提高了团队协作和开发进度。  

 

5.      Controller (控制器)

用来接收和处理系统事件的职责，一般应该分配给一个能够代表整个系统的类，这样的类通常被命名为“XX处理器”、“XX协调器”或者“XX会话”。

关于控制器类，有如下原则：

a.       系统事件的接收与处理通常由一个高级类来代替。

b.       一个子系统会有很多控制器类，分别处理不同的事务。

关于这个模式更详细的论述，请参考《UML和模式应用》第16章。   

6.      Polymorphism (多态)

这里的多态跟OO三大基本特征之一的“多态”是一个意思。

例如：我们想设计一个绘图程序，要支持可以画不同类型的图形，我们定义一个抽象类Shape,矩形(Rectangle)、圆形(Round)分别继承这个抽象类，并重写(override)Shape类里的Draw()方法，这样我们就可以使用同样的接口(Shape抽象类)绘制出不同的图形，如下图：

(Diamond)类，对整个系统结构也没有任何影响，只要增加一个继承Shape的类就行了。  

 

7.      Pure Fabrication (纯虚构)

这里的纯虚构跟我们常说的纯虚构函数意思相近。高内聚低耦合，是系统设计的终极目标，但是内聚和耦合永远都是矛盾对立的。高内聚以为这拆分出更多数量的类，但是对象之间需要协作来完成任务，这又造成了高耦合，反过来毅然。该如何解决这个矛盾呢，这个时候就需要纯虚构模式，由一个纯虚构的类来协调内聚和耦合，可以在一定程度上解决上述问题。

例如：上面多态模式的例子，如果我们的绘图程序需要支持不同的系统，那么因为不同系统的API结构不同，绘图功能也需要不同的实现方式，那么该如何设计更合适呢？如下图：

AbstractShape，不论是哪个系统都可以通过AbstractShape类来绘制图形，我们即没有降低原来的内聚性，也没有增加过多的耦合，可谓鱼肉和熊掌兼得，哈哈哈！

 

      8.      Indirection (间接)

“间接”顾名思义，就是这个事不能直接来办，需要绕个弯才行。绕个弯的好处就是，本来直接会连接在一起的对象彼此隔离开了，一个的变动不会影响另一个。就想我在前面的低耦合模式里说的一样，“两个不同模块的内部类之间不能直接连接”，但是我们可以通过中间类来间接连接两个不同的模块，这样对于这两个模块来说，他们之间仍然是没有耦合/依赖关系的。

9.      Protected Variations (受保护变化)

预先找出不稳定的变化点，使用统一的接口封装起来，如果未来发生变化的时候，可以通过接口扩展新的功能，而不需要去修改原来旧的实现。也可以把这个模式理解为OCP(开闭原则)原则，就是说一个软件实体应当对扩展开发，对修改关闭。在设计一个模块的时候，要保证这个模块可以在不需要被修改的前提下可以得到扩展。这样做的好处就是通过扩展给系统提供了新的职责，以满足新的需求，同时又没有改变系统原来的功能。关于OCP原则，后面还会有单独的论述。

这里我们可以看到，因为增加了纯虚构类

这样的设计更符合高内聚和低耦合原则，虽然后来我们又增加了一个菱形

 这里我们把两种不同的数据存储功能分别放在了两个类里来实现，这样如果未来保存到

这里我们在订单类里增加了一个

这里因为订单是商品的容器，也只有订单持有初始化商品的信息，所以这个耦合关系是正确的且没办法避免的，所以由订单来创建商品。

针对这个问题需要权衡的是，比较商品是否相同的方法需要放到那里类里来实现呢？分析业务得知需要根据商品的编号

 

我们生活在一个充满规则的世界里，在复杂多变的外表下，万事万物都被永恒的真理支配并有规律的运行着。模式也是一样，不论那种模式，其背后都潜藏着一些“永恒的真理”，这个真理就是设计原则。记得一次参加微软的架构师培训，期间讲到设计模式，有人问了老师一个问题：“什么东西比设计模式更重要？”，老师是一位有多年丰富实践经验的开发者，他毫不犹豫地回答到：“比模式更重要的是原则”。这句话我时常能够想起，越来越觉得这是一个伟大的答案。的确，还有什么比原则更重要呢？就像人的世界观和人生观一样，那才是支配你一切行为的根本，而对于设计模式来说，为什么这个模式要这样解决这个问题，而另一个模式要那样，它们背后都遵循的就是永恒的设计原则。可以说，设计原则是设计模式的灵魂。

对于设计原则的深入探讨我还没有那个深度，推荐大家去看《敏捷软件开发—原则、模式与实践》，下面仅对部分常用的设计原则做些简单的讲解：

   1. 单一职责原则(SRP)

   “就一个类而言，应该仅有一个引起它变化的原因。”也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，管好自己的事情就可以了，多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事，我们提倡见义勇为！)

       例如：参考下图中的设计，图形计算程序只使用了正方形的Area()方法，永远不会使用Draw()方法，而它却跟Draw方法关联了起来。这违反了单一原则，如果未来因为图形绘制程序导致Draw()方法产生了变化，那么就会影响到本来毫不关系的图形计算程序。

        那么我们该怎么做呢？如下图，将不同的职责分配给不同的类，使单个类的职责尽量单一，就隔离了变化，这样他们也不会互相影响了。

 　　　

 

 

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
· Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
· IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
· Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
· 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

编辑推荐：过去十年值得关注的十大技术事件

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

布朗（随机）运动

阅读: 181 评论: 0 作者: Seven_Yuan 发表于 2010-03-04 22:59 原文链接

基础：Math.random() * 200 - 100;

代码
package
{
    import flash.display.Sprite;
    import flash.events.Event;

    public class Main extends Sprite
    {
        private var numDots:uint = 20;
        private var friction:Number = 0.95;
        private var dots:Array;

        public function Main()
        {
            init();
        }

        private function init():void
        {
            graphics.lineStyle(0, 0, .5);
            dots = new Array();
            for (var i:uint = 0; i < numDots; i++)
            {
                var dot:Ball = new Ball();
                dot.x = Math.random() * stage.stageWidth;
                dot.y = Math.random() * stage.stageHeight;
                dot.vx = 0;
                dot.vy = 0;
                addChild(dot);
                dots.push(dot);
            }
            addEventListener(Event.ENTER_FRAME, onEnterFrame);
        }

        private function onEnterFrame(event:Event):void
        {
            for (var i:uint = 0; i < numDots; i++)
            {
                var dot:Ball = dots[i];
                graphics.moveTo(dot.x, dot.y);
                dot.vx += Math.random() * 0.2 - 0.1;
                dot.vy += Math.random() * 0.2 - 0.1;
                dot.x += dot.vx;
                dot.y += dot.vy;
                dot.vx *= friction;
                dot.vy *= friction;
                graphics.lineTo(dot.x, dot.y);
                if (dot.x > stage.stageWidth)
                {
                    dot.x = 0;
                }
                else if (dot.x < 0)
                {
                    dot.x = stage.stageWidth;
                }
                if (dot.y > stage.stageHeight)
                {
                    dot.y = 0;
                }
                else if (dot.y < 0)
                {
                    dot.y = stage.stageHeight;
                }
            }
        }
    }
}
import flash.display.Sprite;
class Ball extends Sprite
{
    public var vx:Number;
    public var vy:Number;
    public function Ball():void
    {
        this.graphics.beginFill(0);
        this.graphics.drawCircle(0, 0, 2);
        this.graphics.endFill();
    }
}

 

 

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
· Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
· IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
· Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
· 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

编辑推荐：过去十年值得关注的十大技术事件

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

穿过某点绘制曲线

阅读: 174 评论: 0 作者: Seven_Yuan 发表于 2010-03-04 22:59 原文链接

// xt, yt 是我们想要穿过的一点
// x0, y0 以及 x2, y2 是曲线的两端
x1 = xt * 2 – (x0 + x2) / 2;
y1 = yt * 2 – (y0 + y2) / 2;
moveTo(x0, y0);
curveTo(x1, y1, x2, y2);

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
· Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
· IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
· Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
· 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

编辑推荐：过去十年值得关注的十大技术事件

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

杜增强

Feed Problem

There is something wrong with the feed. I don't konw why.

Copyright © 2010

继续阅读《Feed Problem》的全文内容...

分类: 随笔 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

小S吧 sunbright博客

星际争霸2的图形用户界面使用Flash搭建

国外一名玩家破解了星际2 Beta版的文件，发现其中不乏很多swf文件
http://www.xiaos8.com/uploads/201003/04_102738_goewc.png

http://www.xiaos8.com/uploads/201003/04_102722_7bldr.png

http://www.xiaos8.com/uploads/201003/04_102733_atzef.png

http://www.xiaos8.com/uploads/201003/04_102728_31aer.png

经证实，这些文件应该就是Flash文件，并不是说扩展名正好是.swf
有一个引擎叫做Scaleform GFx，其中就使用了Flash技术，而且还有一些XBox，PS3的游戏也用这套引擎，也就说也用了Flash相关技术，另外最后一张截图中gfx文件就是将Flash输出到Scaleform GFx Game Engine的相关文件。
Scaleform GFx相关介绍：http://www.scaleform.com/products/gfx
国外原文地址：http://www.reddit.com/comments/b41w1/flash_is_not_dead_starcraft_ii_uses_it/
无意中查看到这条消息后，经百度查询资料，无意中发现国内最早转载应该是 http://swfever.com/?p=1071
2010-03-03
Call me Mr.胖胖先生

Satellite TV Setup Guide

发一个安装2锅（中卫60KU锅 + 杂牌1.2米C锅)4星（134°E、138°E、146°E、115.5°E)的实战作业，希望对同学们有所帮助，本人也是新手，调星很简单，只要自己有一定动手能力：） 材料准备阶段： 主要材料：路由器一台、带共享DM500一台、有线电视同轴线缆若干、单本振KU头三个、单本振C头一个、四切一开关1个、三星夹具（建议用免调夹具）、英制自紧式螺旋F头10个。 工具：美工刀、扎带、量角器（自己在中心位置贴一个带重锤的棉线）、针式手表一块、一字十字改锥各一把、防水塑料纸一张。 辅助工具：电脑一台（最好是笔记本电脑），安装①天线角度计算器、②高频头极化角计算器、③DreamBoxEdit、④选装DM500助理 前期准备： ①根据GOOGLE地球定位安装所在地的东经E、北纬N精确数据，记下备用。 ②将上面的经纬度填入 天线角度计算器，软件自动计算出当地卫星接收参数①方位角、②仰角、③极化角 记下备用。 ③登录高频头极化角计算网站，根据四颗星的极化角，自动计算出该角度对应手表上时针所在位置， 记下备用。 正装过程： KU锅根据说明书安装好，底座固定工作一定要到位，否则调星时无辜多出一个不确定因素，就会很头痛。 我们的准备工作目的很明确，尽可能减少调星时的不确定因素（主要是角度）。 通过完善的前期准备，我们最后调星可以不用考虑极化角，仰角，唯一要调整的是方位角。（其实方位角也只需要微调）保证一锅三星在一小时内完成。 将三个KU头全部安装上去，使用免调夹具非常方便（主收138°、面对锅146°在左上、134°在右下），保证三个头接收面在同一平面内，暂时固定夹具，接下来还要细调夹具位置。 ①极化角调整： 根据准备③中得到的每个高频头对应的手表时针位置调整F头朝向，大致准确后彻底锁死高频头转动。（手表怎么拿？人面对高频头屁股，拎住手表12点端表带垂直，把F头调到时针位置ok） ②仰角调整： 仰角根据主收的138°进行调整，根据准备②中得到的138°计算仰角，计算仰角-中卫60KU偏焦角=锅面实际仰角（山寨中卫60KU偏焦角是20°），得到锅面实际仰角后就使用带重锤的量角器彻底锁死。（在哪里量比较准确？把量角器紧贴锅背面的L型支架） ③方位角调整： 暂时不要锁死螺丝，适当紧一下后保证锅面能自由转动并有一定的阻尼） 制作线缆 这个是细致活，推荐使用自紧螺线F头，好处①牢固 ②防水 ③美观 ①制作过程可能会因为线缆太粗拧不进去，用液压钳将线缆夹细一点 ②保证屏蔽层跟F头接触 ③保证屏蔽层不跟铜芯接触！（否则烧了DM500不负责） ④制作完如有条件用数字表检查一下屏蔽层与铜芯是否短路！ 连接高频头 将134°连接到四切一的LNB1 将138°连接到四切一的LNB2 [...]
无所不能 - 博客园

Flash player 10.1

阅读: 215 评论: 0 作者: Seven_Yuan 发表于 2010-03-03 20:18 原文链接

1，GPU 加速的高清视频和图片播放
2，多点触摸，重力感应，手势控制。
3，HTTP streaming
4，全局错误处理机制
5，麦克风访问（通过 AIR 2.0 直接访问麦克风录音，不需要通过 FMS）
6，内容保护方面加强

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
· Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
· IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
· Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
· 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

编辑推荐：过去十年值得关注的十大技术事件

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

杜增强

AS3 Syntax Highlight

About:

Use open source as3syntaxhighlight to syntax as3 code.
Feel free to use.

Usage:

Embed swf path:
http://www.duzengqiang.com/as3highlight.swf?file=filename
For Example:
http://www.duzengqiang.com/as3highlight.swf?file=http://dzq.googlecode.com/files/CodePrettyPrint.as

Demo:

Copyright © 2010

继续阅读《AS3 Syntax Highlight》的全文内容...

分类: 原创 | Tags: as3syntaxhighlight   | 添加评论(1)

还没有相关文章，您来说两句？

laan

哥哥的婚礼

农历的正月初九是哥哥的婚礼。留个纪念(新郎照片没找到…)：
7yue的博客 - 中国FLASH传教士

令人激动的四月份flash Platform技术峰会

Adobe中国公司计划在4月份召开一次面向Flash开发者和设计师的大会，你可以从这个网站看到具体的信息。
http://www.adobechinadeveloper.com/FlashPlatformSummit/index.htm

我需要说明的是，这个网站上关于大会的演讲主题在最近是随时更新的，因为我和我的同事正在紧张的确认更多的更具备吸引力的演讲内容给到会的朋友，这里我先私下在Blog上给大伙大致透露一下目前正在确认的主题（确认后的主题会正式更新到站点上，目前我暂时无法透露演讲人，但是都是产品团队的总监，首席科学家，主程序等级别的），真的非常令人激动，来自美国和中国两地的Flash开发的牛人们将会为大家奉上精彩的3个大类的内容。

开发类的主题可能涉及以下部分：
理解Flex 4 SDK & Framework
Flash Builder 4使用及技巧
Flex 4特效制作
Action Script 3编程
Flash Player 10.1内部机制
使用AIR进行自动化数字发布
开发全球化的AIR应用
跨平台微博客户端AIR应用开发
下一代的Flash P2P技术
Flex应用开发自动化整合实践
Open Screen Project揭露
PDF与Flex企业应用整合
以数据为中心的Flash Builder 4应用开发
企业级Flex应用框架探索，Cairngorm, Parsley,PureMVC，Spring ActionScript等
Flash,Flex,AIR应用内存优化与性能调整
Java技术之上强大的Flex应用开发
实时的Flex可视化数据图表应用开发

Flash设计类的主题可能涉及：
艺术设计在Flash中的体现
Flash CS5 窥探
设计与开发整合，Flash Catalyst与Flash Builder
设计创作针对智能手机的Flash应用
Flash Player增强现实
Flash平台支持的Multitouch技术
Flash CS5创作iPhone应用
使用PS和AI联手打造强大的Flash动画

Flash游戏和视频将作为一个独立的分类，可能涉及的主题包括:
开发Flash Platform多人在线游戏
Flash MMORPG多人游戏开发架构
Flash Web Game资源分配优化技巧
Flash游戏人工智能
Flash Drawing API探索
大规模在线视频Flash Media Server实践
网络化高清视频方案
交互式视频体验创作
OSMF框架架构分析

这次大会绝对是Adobe/Macromedia在中国市场上开办的最大规模的一场面向开发者的技术峰会，希望有Flash开发的公司和开发者们不要错过此次大会的网站的更新。
Fluid idea for Life

关注两会，向往幸福生活

两会来了，关心国事也是关心自己，有时间关心正事，而不是闲的无聊去关注刘翔的提议是不是他自己写的，姚明的小孩是什么国籍....

1.暴力拆迁

今天一则比较吸引人的新闻是有代表建议要关闭网吧，由政府出资开办公共网吧，理由是很多社会问题的产生都和网吧有关。青少年犯罪、暴力游戏、色情...等等。好家伙，这个提议好啊，绘制了一个举国的局域网蓝图，伟大的工程！！

依次推论，要关闭的东西多了，我D的很多官员腐败，要不把那些部门都撤了，这样就不会有腐败了？有钉子户妨碍伟大工程，要不都...了，什么事都没了？难道在没有网络之前，社会问题就不存在？那咱们干脆回到原始社会得了，不过即使是原始社会，还是有矛盾的，不然人类社会还怎么前进啊。

按照我D的某些人员看来，解决问题的方法很简单，就是”暴力拆迁“，这一招简直是屡试不爽啊。我觉得青少年犯罪是一个大的社会，和我们落后的教育体制和整个社会的经济文化氛围有直接关系，这些才是关键。

2.房子

两会期间，最引人关注的莫过于房子和就业这两大问题。前些天的1.5%增长率刚落幕，这边又有委员放出“买不起房不是Z F和开发商的问题”言论。

关于房子的话题太多了，对错都TM不重要，关键是结果。看看两会后有什么新政出台。

 

2010-03-02
无所不能 - 博客园

Flash性能相关

阅读: 260 评论: 0 作者: Seven_Yuan 发表于 2010-03-03 01:45 原文链接

尽量避免使用try catch

 

1、改进算法
无论对于那一种程序，好的算法总是非常重要的，而且能够极大地提高程序性能，所以任何性能的优化第一步就是从算法或者说程序逻辑的优化开始，检查自己的程序是否有多余的运算，是否在没有必要的时候做了无用功，往往从这些方面就能找到那些导致性能低下的地方。

2、优化细节代码
针对细节总是好的，有一些小技巧比如：
用 var obj:Object = {}; 要比 var obj:Object = new Object();要好；
var arr:Array = []; 要比 var arr:Array = new Array(); 要好；
for (var i:int=0, len=arr.length; i<len; i++) 要比 for (var i:int=0; i<arr.length; i++) 要好；
如果不是为了保存颜色值请不要适用uint这个类型，他的速度比起 int要慢多了；
Array的遍历要比Object或者Dictionary的枚举要快得多。
if (myObj != null) 要比 if (myObj) 的速度要快， for (var i:* in myObj) 比 for (var i:String in myObj) 要快；
Dictionary当 weak key设置为 true 的时候要比 false 慢；
var myText:String = “a” + “b” + “c”;
var myText2:String = [ "a", "b", "c" ].join(”");
在JavaScript里面在IE下后者要更快，但是在AS里面，前者更快！
在循环体内声明变量和在循环体外声明变量其实速度上不会有太大的区别。

3、权衡程序的结构
程序的架构也非常重要，良好的结构会带来性能和程序健壮性的提升，但是有的时候又是相互矛盾的，例如代码写得过于健壮，反而会影响性能，这个地方需要开发者自己去权衡。

4、小心Flash的重绘
如果你使用的是Flash Player 的Debugger版本，那么请在检查性能瓶颈的时候不要忘记打开显示重绘区域的功能，这将帮你迅速定位到舞台上有那些地方被重绘了，找出没有显示任何东西却不断重绘的地方，这些地方肯定是有问题的。Flash Player很笨，不会说你把一个DisplayObject的visible设置成false就放弃重绘那个显示对象。所以请保证你的 MovieClip在visible=false的时候为停止状态。有一点很有意思，假设两个现实物体存在 hitTest = true 这样的关系，那么重绘的区域的面积很有可能 > 两者的面积总和！

5、以空间换时间
听起来挺虚，实则很简单，说白了就是以内存换CPU，例如将不变动的值进行保存，免去下次需要此数据的时候进行再次计算，虽然原理很简单，但是有的时候却很容易疏忽掉，而这个往往就造成你的算法效率低下的问题。

6、记得销毁你的对象
对于非常驻的对象使用完之后记得消除其引用，防止出现内存溢出的问题，往往要做到这一点需要有一个良好的编程习惯。

7、清除冗余的代码
有些代码可能你的程序一辈子也不会执行到，请把这些没有用的代码或者对象清理掉，否则内存会被偷偷的蚕食掉。

8、小心使用useBitmapCache = true
一般情况下除非你确定这个显示对象不可能发生变化那么用用也无妨，不过我更推荐自己手动的用BitmapData将该对象Draw一遍，然后让这个对象彻底消失。否则每次的变动都是巨大的性能消耗。

 

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
· Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
· IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
· Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
· 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

编辑推荐：过去十年值得关注的十大技术事件

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

laan

flashplayer log查看工具

fiddler+Flex builder能解决90%的调试问题。不过还有一些特殊的，比如被打包的swf的输出，就需要使用flashplayer的log输入来查看了——第三方的Localconnection解决方案也很不错，不过需要引入第三方类，而且release的时候还需要去掉这些。使用原生的trace就是好，-debug=false即可。 但是这个log功能用起来实在是麻烦：首先还得设置，得写个mm.cfg配置文件；还得找到flashplayer的logs目录，然后找到相应的log输入文件查看信息。于是自己写了个工具去做这些事（还加上了profiling的快捷设置）。 下载地址：http://datasharing.googlecode.com/files/FPTool1.0.air 如果在您老的电脑上运行不正常的话，千万不要联系我~~ 请使用别的程序..
Catfly猫脸爬格子-廖湘宁的博客

利用AS3块传输技术呈现游戏元素

  • 资讯类型: 翻译
  • 来源页面: http://www.adobe.com/devnet/flex/articles/actionscript_blitting.html
  • 资讯原标题: Rendering game assets in ActionScript using blitting techniques and Flash Builder 4
  • 资讯原作者: Renaun Erickson
    • ———————–X>>—————————————
    许多类型的游戏，用户体验都依赖于终端可拥有的屏幕像素和移动物体有多快。当让大量的DisplayObject对象动起来时，如MovieClip或Sprite对象，Adobe Flash Player可能在表现上会大大折扣。Flash Player必须遍历显示对象树并为每个基于向量的DisplayObject计算渲染输出，这样会消耗CPU周期成为真正的瓶颈，尤其是低端机。
    许多屏幕动画游戏都是预先载入一张位图，这种技术被称为blitting(块传输)。块传输虽不能解决所有性能问题，但它能使动画运行平滑，统一大 多数机器上动画帧频。Blitting术语来自于BitBLT为Xerox Alto计算机日常中创建。BitBLT发音为“bit blit”，主张bit-block (image) transfer图像基于位块传输，是一种采用数张位图并合并成一张位图的技术。在Flash Player中复制位图像素到一张渲染图中比分别地渲染每个DisplayObject更为快速。
    在本文中，我描述了软件位块传输技术并提供示例代码，因此你可以在ActionScript中应用它。

    要求
    为了满足本文条件，你需要下列软件和文件。

    预备知识
    本文假定你已熟悉Flash Builder 4 和 ActionScript 3项目工作的知识。
    介绍sprite sheet
    一个游戏由许多图形元件组成，例如赛道上的车或森林中的一棵树。在本文中，这些元件都是位图。一组位图放在一个单独的图像文件中称为sprite sheet。例如，一个sprite sheet可能包含一个角色行走动画的所有帧。这个词衍生于sprite，在计算机图形世界中，指的是一张图像或一个大场景中集成的动画。虽然位块传输技 术可以使用不同来源的位图数据，但在本文中重点放在sprite sheet。
    一个sprite sheet由什么构成？
    一个sprite sheet可以对不同大小的位图进行组合。将所有图形元素组装到一个大的图像文件中会减少加载时 间（打开和读取一个包含100帧的较大文件比打开读取100个小文件更为快速）并提供压缩的好处。特别是sprite sheet持有同样大小形成一个序列的位图或围绕一个特定游戏元素动画。例如，本文中使用的sprite sheet有五列四行，每格40*40像素，每个都包含着一个brown collector褐色元素（见图1）。

    图1 sprite sheet示例显示了20个单元格，每格为40*40像素

    设置ActionScript项目
    在你运行示例代码前，你将需要在Flash Builder 4按照以下步骤设置项目。
    1.        下载并解压示例文件
    2.        选择File > New > ActionScript Project来创建项目
    3.        输入ActionScriptBlitting作为项目名称并点击Finish
    4.        从示例文件中复制下列文件和文件到项目默认包中：ActionScriptBlittingPart1.as, ActionScriptBlittingPart2.as, ActionScriptBlittingPart3.as, ActionScriptBlittingPart4.as和spritesheets。Spritesheets文件夹中包含了用于 ActionScript示例的PNG文件。
    5.        在Package Explorer中，右键点击ActionScriptBlitting项目在弹出菜单上选择Properties。
    6.        在Properties属性对话框中点击ActionScript Applications。
    7.        点击Add，选择ActionScriptBlittingPart1.as，并点击OK。
    8.        将ActionScriptBlittingPart2.as，ActionScriptBlittingPart3.as, 和 ActionScriptBlittingPart4.as重复第7步。
    9.        点击OK
    现在Flash Builder 4中示例代码就设置好了，你就可以运行该示例。

    用ActionScript嵌入一个sprite sheet
    在ActionScript中你可以通过使用Embed元数据标签嵌入图像。（更多信息请查看Embedding metadata with Flash）一旦它们被嵌入，你可创建类的实例并附加到显示列表，如ActionScriptBlittingPart1.as：

    
ActionScriptBlittingPart1.as

package
{
   import flash.display.Sprite;
   [SWF(width=480, height=320, frameRate=24, backgroundColor=0xE2E2E2)]
   public class ActionScriptBlittingPart1 extends Sprite
   {
      public function ActionScriptBlittingPart1()
      {
         addChild(new BrownCollector());
      }
      [Embed(source="spritesheets/browncollector.png")]
      public var BrownCollector:Class;
   }
}

    要运行第一个示例，请参照下列步骤：
            在Package Explorer中，在ActionScriptBlittingPart1.as文件上点击右键选择Run Application。
            当浏览器打开时，你会看到所有单元格都有PNG图像（browncollector.png），效果见图1.
            关闭浏览器窗口。
    Blitting a sprite sheet
    第二步，你将要用到Flash Player API的Bitmap 和 BitmapData， 从sprite sheet复制一个单元格（或帧）到屏幕上，而这个操作可以通过BitmapData.copyPixels()方法来完成，复制输入位图数据的像素到正 在制作的位图实例上。在ActionScript中纳入blitting，copyPixels()方法还提供参数来定义要复制输入位图的区域以及如何定 义和合并alpha像素。

    
ActionScriptBlittingPart2.as

package
{
   import flash.display.Bitmap;
   import flash.display.BitmapData;
   import flash.display.Sprite;
   import flash.geom.Point;
   import flash.geom.Rectangle;
   [SWF(width=480, height=320, frameRate=24, backgroundColor=0xE2E2E2)]
   public class ActionScriptBlittingPart2 extends Sprite
   {
      public function ActionScriptBlittingPart2()
      {
         // Create input bitmap instance
        spritesheet = (new BrownCollector() as Bitmap).bitmapData;

         // Add a Bitmap to the display list that will copyPixels() to.
         canvas =  new BitmapData(480, 320, true, 0xFFFFFF);
         addChild(new Bitmap(canvas));
         rect = new Rectangle(0, 0, 40,40); // 1st Tile
         //** Section 1 ** //
         // rect = new Rectangle(40, 0, 40, 40); // 2nd Tile
         // rect = new Rectangle(80, 0, 40, 40); // 3rd Tile
         // ...
         // rect = new Rectangle(160, 120, 40, 40); // 20th Tile
          canvas.copyPixels(spritesheet, rect,  new Point(0, 0));
         //** END Section 1 **/

         /** Section 2 ** //
         for (var i:int = 0; i < 20; i++)
         {
            rect.x = (i % 5) * 40;
            rect.y = int(i / 5) * 40;
            canvas.copyPixels(spritesheet, rect, new Point(i*10, 0));
            // Section 3:
            // canvas.copyPixels(spritesheet, rect,
            // new Point(i*10, 0), null, null, true);
         }
         //** END Section 2 **/
      }

      [Embed(source="spritesheets/browncollector.png")]
      public var BrownCollector:Class;
      public var canvas:BitmapData;
      public var spritesheet:BitmapData;
      public var rect:Rectangle;
   }
}

    在Package Explorer中的ActionScriptBlittingPart2.as文件上点击右键并选择Run Application。你将会看到来自sprite sheet的第一个单无格显示在浏览器中（见图2）。

    图2 ActionScriptBlittingPart2输出（利用Section 1代码）

    显示所有单元格
    现在你绘制了1个单元格了，为什么不是绘制所有单元格呢？若要绘制所有，参照以下步骤：
    1.        在Flash Builder 4中打开ActionScriptBlittingPart2.as
    2.        找到标为“Section 1”的代码处并注释掉它。
    3.        找到标为“Section 2”的代码处取消注释。
    4.        保存文件
    5.        再次运行ActionScriptBlittingPart2.as
    Section 2的代码使用了循环来绘制每格较之前的单元格效果水平偏移10像素。

    图3 ActionScriptBlittingPart2输出（利用Section 2代码）
    不过，看起来结果并不完全正确，而这正是因为BitmapData.copyPixels()的alpha参数导致的，最后三个参数 （alphaBitmapData, alphaPoint, 和 mergeAlpha）提供了不同地处理透明区的方式。由于sprite sheet中的PNG图片已处理过alpha数据，就不再需要alphaBitMapData 或 alphaPoint了。你只需要设置最后一个参数来打开alpha合成，mergeAlpha为true。
    确保改变：
    1.        注释掉Section 2中调用copyPixels()处：

    
canvas.copyPixels(spritesheet, rect, new Point(i*10, 0));

    2.        取消注释Section 3中调用copyPixels()处：

    
canvas.copyPixels(spritesheet, rect, new Point(i*10, 0), null, null, true);

    3.        保存该文件。
    4.        再次运行ActionScriptBlittingPart2.as。你会看到图像有序地重叠（见图4）

    图4 ActionScriptBlittingPart2输出（利用Section 3代码）
    让sprite sheet动起来
    现在你已知道如何显示来自sprite sheet的位图数据，接下来就是让它动起来。ActionScriptBlittingPart3.as中的代码赋予brown collector图像活力，可将它移动到舞台上鼠标点击处。
    在Flash Player中利用计时器创建一个平滑的动画
    基本思想是使用一个可以基于Flash Player帧的timer计时器，或两者结合的计时器。一个典型的方法是结合使用ENTER_FRAME事件和调用getTimer()来控制各种电脑 环境中动画的速度。下面的代码摘录自ActionScriptBlittingPart3.as（行62）：

    
/**
 *    Handles the timer
 */
private function enterFrameHandler(event:Event):void
{
   tickPosition = int((getTimer() % 1000) / framePeriod);

   if (tickLastPosition != tickPosition)
   {
     tickLastPosition = tickPosition;
     canvas.lock();
     canvas.fillRect(canvasClearRect, 0x000000);
     render();
     canvas.unlock();
   }
}

    enterFrameHandler()方法处理ENTER_FRAME事件。该代码确定了SWF启动之后经过的秒数，这一数字除以framePeriod，期间游戏设计者想要呈现动画，如果这个值不同于上一次渲染帧的事件，清除画布上的内容，动画被重新渲染。
    在Flash Player中定时（有时描述为elastic race track）可以改变，触发ENTER_FRAME事件可以在不同的机器上有显著地变化。结合这个事件和定时检测可以使动画在一致频率时平滑，即使是一台 机器运行速度远比SWF帧频快。同样如果该SWF帧频增加，动画帧频可以维持在一个一致较低的频率，使CPU能够处理其它逻辑而无需渲染每一帧。无论哪种 方式，你都需要找出渲染一致性和CPU利用率之间的平衡。如果你把帧频设置过高，低端机器可能无法处理。
    当你运行ActionScriptBlittingPart3.as程序时，你会看到一个brown collector围绕着圆圈旋转。
    Moving the animation
    Flash Player MouseEvent.MOUSE_UP 事件提供了鼠标在舞台上点击的x和y的坐标值。将鼠标点击处坐标一直作为collector的当前x和y位置，你可以在每次画布渲染时移动图像到不同的位 置处。这给予了用户移动它的能力。下面的代码是从ActionScript类ActionScriptBlittingPart3.as（79行）摘录了 如何用blitting来移动动画：

    
/**
 *    Render any bitmap data.
 */
private function render():void
{
   rect.x = (currentTile % 5) * 40;
   rect.y = int(currentTile / 5) * 40;
   collectorX += (destX-collectorX-20)/5;
   collectorY += (destY-collectorY-30)/5;
   canvas.copyPixels(spritesheet, rect,
   new Point(collectorX, collectorY), null, null, true);
   currentTile = ++currentTile % 20;
}

/**
 *    Used to move the animation around.
 */
private function mouseUpHandler(event:MouseEvent):void
{
   destX = event.stageX;
   destY = event.stageY;
}
}

    mouseUpHandler() 方法存储了鼠标点击处的x和y坐标值作为目标地址。之后的render()方法确定了一个在collector与目标位置之间非线性运动，记录点击的全局 坐标作为新位置，然后将它提供给copyPixels()方法作为blitting的位置。
    如果动画运行时在舞台中点击，该collector会朝着点击位置处移动。
    合并多张sprite sheet动画
    最后示例在一个单独的Stage上整合了多个sprite sheet。在上一个示例中，为了移动动画你需要存储位图数据放置的信息。当合并动画，你将需要保持更多位置的跟踪。除了位置，你可能需要维护并处理深度 （它决定了当两个位图重叠时会显示哪一个），变化动画状态，不同的动画帧频，碰撞检测等等。
    在ActionScriptBlittingPart4.as中，collector深度最低。随机创建地彩色凝胶从屏幕顶部下降。如果一个凝胶碰撞到collector，将会运行第三种动画——凝胶在collector上熔化。
    深度
    在Flash的中你可能曾创建过动画，如在舞台上放置多个对象。你可能还使用过mx.effects包来移动或旋转对象。如果对象重叠，其z- index（在显示列表中的深度）决定了对象叠放顺序。虽然位块传输，只有一个对象要显示：目标位置。由于正在处理渲染，那么你也将需要保持对象深度跟踪 并确保一切都按正确的顺序进行复制。
    为了保持彩色凝胶从collector的顶部开始动画，你必须管理blitting的秩序。在ActionScriptBlittingPart4.as 中的render()方法，collector已经被混合（行110）后完成所有凝胶块传输（行138和144）
    创建凝胶与其元数据
    每个彩色凝胶创建于enterFrameHandler()方法中。当一个彩色凝胶被创建，在createGel()方法中会设置其初始化属性包括一个随 机x，y为0的位置，默认状态，meltFrame为零，一个唯一名称。该凝胶随后被保存到gels中，render()方法中会遍历这个 Dictionary实例。

    
/**
 *    Create a gel
 */
private function createGel():void
{
   var gel:Object = new Object();
   gel.posX = ((Math.random() * 0xffffff) % 280) + 20
   gel.posY = 0;
   gel.state = "animate";
   gel.meltFrame = 0;
   gel.name = "gel" + gelCount++;
   gels[gel.name] = gel;
}

    凝胶的逻辑与渲染状态
    render()方法移动彩色凝胶的逻辑并更改熔解状态。

    
/**
 *    Render any bitmap data.
 */
private function render():void
{
   rect.x = (currentTile % 5) * 40;
   rect.y = int(currentTile / 5) * 40;
   collectorX += (destX-collectorX-20)/5;
   collectorY += (destY-collectorY-30)/5;
   canvas.copyPixels(spritesheetCollector, rect,
   new Point(collectorX, collectorY), null, null, true);
   // Render Gel at half the frame rate, to slow it down
   if (currentTile % 2 == 1)
   {
      rect.x = ((currentTile-1) % 5) * 40;
      rect.y = int((currentTile-1) / 5) * 40;
   }
   for each (var gel:Object in gels)
   {
      // Hit Check 5 px within Y and X
      if (Math.abs(gel.posY - collectorY + 6) < 14
        && Math.abs(gel.posX - collectorX) < 10)
      {
        gel.state = "melt";
      }
      if (gel.state == "melt")
      {
        // Clear out if done melting
        if (gel.meltFrame < 20)            gel.meltFrame++;         else         {            delete gels[gel.name];            continue;         }                 rect.x = (gel.meltFrame % 5) * 40;         rect.y = int(gel.meltFrame / 5) * 40;         canvas.copyPixels(spritesheetGelMelt, rect, new Point(collectorX-1, collectorY-12), null, null, true);         continue;       }       else       {         canvas.copyPixels(spritesheetGel, rect, new Point(gel.posX, gel.posY), null, null, true);       }             gel.posY += 3;       if (gel.posY > 320)
      {
        delete gels[gel.name];
        continue;
      }

   }

   currentTile = ++currentTile % 20;
}

    凝 胶动画是collector速度的一半，通过为奇数帧重置rect值为currentTile-1。接下来，在屏幕上代码循环所有彩色凝胶并检测 collector碰撞。如果发生碰撞它会更改状态为“melt”。在这种状态下，render()用彩色凝胶熔解sprite sheet并且其meltFrame总数为20帧时移除。当凝胶与collector的x和y位置发生碰撞时，会出现溶解动画，只要凝胶在移动就会紧随 collector。如果没有发生碰撞，凝胶向下移动3像素，当它的y坐标超出320时将会从舞台上移除。正如你所看到的，利用blitting你必须处 理所有动画的逻辑。

    延伸阅读
    在本文中你已学会如何创建一个软blitting引擎。你可以使用这些技术在其它Flash Player中渲染情景。你可能想要探索位块传输过程中创建源位图数据的不同方法，例如，转换DisplayObject动画帧到一个位图中并缓存它们到一个数组中。
    •        dieselblittingengine: Blitting engine for Flash Player 9 and later (Google Code)
    •        Blitting and duble-buffering for tile-based games in Flash and Flex: Part 1 of 3 (Jesse Warden)
    •        AS3 Basic Blitting #2 : Rotation – Part 1 (Jeff Fulton)
    •        Basics of tile sheet animation (or blitting) (Jeff Fulton)

    关于作者
    Renaun Erickson在Adobe Systems里工作，负责ActionScript, Flex和不同地服务器技术开发。他活跃于组织中积极地发言并用博客(renaun.com/blog)记录各个Flash Platform下的子项目，包括视频，音频，logging，和Flash游戏。当他不编程时，喜欢玩游戏，户外运动，吉普车，和陪着家人。

    猫抓鱼
    点滴点点滴滴

    在Directshow中使用VMR9

    用directshow做的一个简单播放器的核心代码，使用了VMR9来rendering。在这个类中实现了directshow播放器的基本功能，播放、暂停、seeking等，后面有时间会继续加上VMR9的一些特效。

    Y.Boy's Blog

    封装了位操作的 BitArray 类

            AS3有对位进行操作的运算符，但ByteArray 类没有对位进行操作的方法。详细请见前：ByteArray写入位（bit）及评论（尤其是lite3的评论）。自己写了一个 BitArray 类，扩展自 ByteArray 类。没什么特别，只添加了两个方法：getBitAt() 和 setBitAt() ，用法及注释请到GoogleCode上查看：

    http://code.google.com/p/yboys-as3libs/source/browse/trunk/src/com/riaoo/utils/BitArray.as

    附上位的三种基本操作（更多的可以查看语言参考手册中对位运算符的描述）：

    获取位：byte & flag;
设置位：byte |= flag;
取消位：byte &= ~flag;
    标签：BitArray, ByteArray, 位操作

    相关日志

    7yue的博客 - 中国FLASH传教士

    Flash Player 10.1在Google Eclair系统上的安装步骤简图

    Eclair是Google Android系统的2.x版本的code name，针对拥有这个版本的手机，比如Nexus One，Adobe的工程师给出了一个以后用户在设备上安装Flash Player的步骤草图（看下面），个人认为基本和PC上一致，但是Flash Player将来自于Google Market，让我们看看以后Flash Player能在Google Market被下载多少次吧，:)
    2010-03-01
    兽的地盘

    【原创】解决本地安全沙箱问题（无法访问本地资源）

    开发flex的时候经常会出现安全沙箱问题，说白了，其实就是访问资源受限。如果是服务器端的资源需要在服务器端加个策略文件，这个就不说了。通常自己本地开发做测试，也会出现这种问题。比如资源不是内嵌的，在IDE下是没问题的，把bin文件夹拿到桌面上，就出现安全沙箱错误了。下面就尽快的解决这个问题！

     

    flash player有自己的安全机制，有四种权限控制，为了尽快解决问题就不多白呼了。。。

     

    定位到以下目录中

    ■Windows：system\Macromed\Flash\FlashPlayerTrust
    （例如， C:\windows\system32\Macromed\Flash\FlashPlayerTrust）
    ■ Mac：app support/Macromedia/FlashPlayerTrust
    （例如， /Library/Application Support/Macromedia/FlashPlayerTrust）

     

    增加一个文件（或者修改这个文件）

    mms.cfg-----关于flash player的一些权限设置，部分内容可以由AS控制，绝大多数不可以。

     

    加入以下内容

    # Trust files in the following directories:
    C:\

     

    这样，C盘里的所有东西flash player就都可以访问了，比如以前bin放在桌面上报本地沙箱错误，经过上面步骤就可以正常运行了。



    已有 0 人发表留言，猛击->>这里<<-参与讨论


    JavaEye推荐



    杜增强

    话说程序员的职业生涯[转]

    dzq:关于转型是所有程序员都会遇到的问题,这篇文章写的太好了,不得不转.

    转自:http://blog.csdn.net/programmer_editor/archive/2009/05/07/4159246.aspx

    作者: IBM软件集团大中华区总架构师 寇卫东
    原文:
    有一些年轻的程序员向我咨询，将来的路应该怎么走？俗话说，条条大路通罗马。不同的路都能走向成功。到底选哪条路，取决于自己的兴趣。可能有程序员会问：如果还没找到自己的兴趣怎么办？我的建议是多尝试，努力做，这是职业生涯的必经之路。当你积累了一定的技术和经验之后，就会面临多种选择。选择哪条路，因人而异。
    ...

    Copyright © 2010

    继续阅读《话说程序员的职业生涯[转]》的全文内容...

    分类: 资料 | Tags: | 添加评论(1)

    还没有相关文章，您来说两句？

    2010-02-28
    Catfly猫脸爬格子-廖湘宁的博客

    as3四种方法实现文本居中

    有如下四种方法可以实现文本居中。


    1. Text.autoSize
    这种方法可以设置文本的对齐方法，按后计算文字长度再通过设置文本的x坐标，从而达到居中显示的目的。
    但这种方法无法在不自动换行的情况下限制文本的长度。也就是说指定txt.width属性是无效的。

    
myText.autoSize=TextFieldAutoSize.LEFT;
myText.x=stage.stageWidth/2-myText.textWidth/2;


    2. TextFormat.align = “center”
    这种方法是通过指定一个TextFormat对象给文本的txt.defaultTextFormat属性。并设置这个TextFormat对象的TextFormat.align = “center”。这种方法需要设置文本长度，文字将在指定的文本长度中处于居中位置。

    
var tf:TextFormat = new TextFormat ();
tf.align = "center";
myText.width = 400;
myText.defaultTextFormat = tf;

    3. htmlText的p标签；
    这种方法是在文本的txt.htmlText属性值得中设置对齐方式。在flash中支持的html标签中，p标签支持align属性。这种方法需要设置文本长度，文字将在指定的文本长度中处于居中位置。

    
myText.width = 400;
myText.htmlText = "<p align='center'>文本内容...</p>";

    4. styleSheet的textAlign = “center”
    这种方法是设置文本的txt.styleSheet，在styleSheet中设置textAlign = “center”。这种方法需要设置文本长度，文字将在指定的文本长度中处于居中位置。

    
var style:StyleSheet = new StyleSheet();
var p:Object = new Object();
p.textAlign = "center";
style.setStyle("p", p);
myText.width = 400;
myText.styleSheet = style;
    猫抓鱼

    无锯齿缩放图片【缩放时对位图进行平滑处理】

    在as3中，可以通过设置Bitmap的smoothing参数或属性值为true来实现在缩放时对位图进行平滑处理。
    那么从外部加载的图片，如何获得图片的bitmapData对象？
    可以这样，在图片加载完成的函数中：e.target.loader.content["bitmapData"]
    下图是有无锯齿的对比效果：


    设置bitmap的smoothing属性

    
var picLoad:Loader = new Loader();
picLoad.load(new URLRequest(picUrl));
picLoad.contentLoaderInfo.addEventListener(Event.COMPLETE,newLoadedFun);
private function newLoadedFun(e:Event):void{
	var bt:Bitmap = new Bitmap(e.target.loader.content["bitmapData"]);
	bt.smoothing = true;
	picContent.addChild(bt);
}

    在创建Bitmap时参数中设置：
    new Bitmap(e.target.loader.content["bitmapData"],”auto”,true)

    
var picLoad:Loader = new Loader();
picLoad.load(new URLRequest(picUrl));
picLoad.contentLoaderInfo.addEventListener(Event.COMPLETE,newLoadedFun);
private function newLoadedFun(e:Event):void{
	picContent.addChild(new Bitmap(e.target.loader.content["bitmapData"],"auto",true));
}
    猫抓鱼
    2010-02-27
    无所不能 - 博客园

    Flash中的NaN

    阅读: 349 评论: 0 作者: Seven_Yuan 发表于 2010-02-28 00:35 原文链接

    NaN具有独特的数学属性，任何涉及该属性的比较运算都计算为false。改用全局isNaN()函数检测NaN值，如下面的示例所示：

    trace(NaN==NaN);//false！

    trace(NaN!=NaN);//还是false！

    trace(isNaN(NaN));//true

    评论: 0　查看评论　发表评论

    找优秀程序员，就在博客园

    最新新闻：
    · 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
    · Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
    · IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
    · Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
    · 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

    编辑推荐：过去十年值得关注的十大技术事件

    网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

    BitmapData转化为ByteArray之后的像素级处理

    阅读: 358 评论: 0 作者: Seven_Yuan 发表于 2010-02-28 00:31 原文链接

    代码
    var myParentSquareBitmapData:BitmapData = new BitmapData(178, 178, false, 0xff000000);
    myParentSquareBitmapData.draw(ldr);
    var bounds:Rectangle     = new Rectangle(0, 0, myParentSquareBitmapData.width, myParentSquareBitmapData.height);
    var BA:ByteArray     = new ByteArray();
    BA.position     = 0;
    BA     = myParentSquareBitmapData.getPixels(bounds);
    var myParentSquareContainer:Bitmap     = new Bitmap();
    var myClonedChild:BitmapData     = new BitmapData(200, 178, false, 0xff000000);
    trace(BA.length);
    // 4位
    for (var i:int = 0; i < BA.length; i += 4)
    {
            if ((BA[i] == 255) && (BA[i + 1] <= 32) && (BA[i + 2] <= 32) && (BA[i + 3] <= 32))
        {
            BA[i]     = 255; //透明度
            BA[i + 1] = 255; //red
            BA[i + 2] = 255; //green
            BA[i + 3] = 255; //blue
        }
    }

     

    评论: 0　查看评论　发表评论

    找优秀程序员，就在博客园

    最新新闻：
    · 谷歌雅虎等抗议英国屏蔽含盗版内容网站计划(2010-03-10 22:47)
    · Twitter开始监控所有外部链接 以防钓鱼式攻击(2010-03-10 22:40)
    · IBM联手大学开发老年与文盲群体易用手机(2010-03-10 21:32)
    · Arm称今年将有五十余款iPad类平板电脑上市(2010-03-10 21:31)
    · 互联网泡沫十周年 当年热股今何在(2010-03-10 21:22)

    编辑推荐：过去十年值得关注的十大技术事件

    网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

    I'm Emment

    解决IE6、IE7在CSS中设置最小高度遇到的问题

    当设置某一个区域的最小高度为某个值的时候，在Firefox、IE6以及IE7中的表现并不一样。如果只是设定了min-height值，那么在IE6中不能识别；但设定了height值，在 IE7和Firefox中，位置就会固定了。这是一个很大的问题。那么为了协调各个浏览器和各个版本，我们怎样做才能解决最小高度的问题呢？

    .distance {
    height:auto!important;
    height:100px;
    min-height:100px;
    }
    2010-02-26
    Catfly猫脸爬格子-廖湘宁的博客

    我的FLASH情结2010——浅谈FLASH WEB GAME与创业【转:寂寞火山】

    ★目录：
    →我的FLASH WEB GAME开发历程
    →当今FLASH WEB GAME概述
    →创业型游戏公司面临的问题和困难
    →FLASH WEB GAME的系统架构
    →FLASH WEB GAME的前端架构与人事分工
    →前端与美术的配合
    →前端与后端的配合
    →公司文化与产品定位
    →2010年：我的梦想扬帆起航

    ======================================正文========================================

    ★我的FLASH WEB GAME开发历程
    →2007年的夏天，顶着炎炎烈日，我从学校直接跑到上海，开始了我的FLASH WEB GAME创业之旅。时至今日，转眼快三年了。作为国内比较早的一批FLASH WEB GAME开发人员，今天我粗略的总结一下这两年多的经验和心得。讲的不对的地方，请大家多多指教。

    →2007年刚到上海的时候，初创团队只有四个人，一个CTO,一个美术，一个后台，一个前台。手里的产品是一个已经在台湾运行三年左右的FLASH社区，和国内的梦境非常像。这个产品还是不错的，早在FLASH5就在开发出来了，FLASH6出来后，又用新版本的AS1重写过。这个产品让我又爱又恨，爱的是，在2007年的时候，国内除了梦境和1D真的很少有能赶上它的；恨的是，这个产品竟然没有前端源码！要想修改还要破解！玩过AS1，在时间轴、MC和BTN上写过代码的朋友应该知道这是什么概念——1个字：囧！

    →后来老板可能也觉得这样改下去不是办法，终于同意自己重写一个。正好07年有条新闻很火爆：国外有个FLASH社区第一次利用FLASH技术取得了重大成功，以7亿美金卖给迪斯尼，它就是“企鹅俱乐部”。老板看到了商机，我们决定做一个中国版的企鹅，于是“海底世界”应运而生了。而“海底世界”的创意，只不过是我们四个初创成员在闲聊时，我开玩笑随便说的。

    →海底世界正式开发到现在差不多正好两年，期间我们碰到无数的问题和困难，不管是公司层面或技术层面，都是如此，但始终是坚持了下来。产品一天天完善，公司规模也一天天扩大。前端从最开始的两个人，到现在5个人；后端从最开始的FMS+PHP到现在自己写的socket服务器；公司规模也从最开始的4个人，到现在的50多个人。

    ★当今FLASH WEB GAME概述
    →2007：含苞欲放！
    2007年可以说是FLASH WEB GAME发展史上的分水岭。2007年之前，我们眼里只有梦境，最多再加上昙花一现的抱抱城，那时候根本没有“FLASH WEB GAME”这个概念，大家谈的都是“FLASH社区”，“FLASH社区”这个词在很长一段时间代表着FLASH应用领域的至高点。也许2007年已经有不少团队开始研发FLASH的MMORPG了，我曾经有幸知道几个，但很可惜，不少都胎死腹中，2007年国内在线上运营的FLASH WEB GAME基本上还是空白。但不管怎么说，我相信2007年是蓄势待发的一年，肯定有很多类似我们公司的团队，在默默的努力着。

    →2008年：雨后春笋！
    经过2007年的积累和准备，FLASH WEB GAME业界的战斗终于在2008年打响，以“摩尔庄园”，“海底世界”为代表的“FLASH儿童虚拟社区”开始崭露头角；以“纵横天下”为代表的FLASH策略类游戏兴起；以“昆仑”为代表的FLASH MMORPG让“无端网游”的概念又炒了起来。还有各种基于FLASH的卡牌对战类，联机棋牌类，模拟经营类游戏等等，都如雨后春笋般破土而出。

    →2009年：百花齐放！
    2008年，国内虽然一下出了很多FLASH WEB GAME,但大家只要认真收集，总归还是能数的过来，可到了2009年，几乎每隔一个月，都会有几个新的FLASH WEB GAME进入大家视野，而且他们越来越完善，功能越来越强大，盈利模式也开始成熟并多样化。2007年每出一个FLASH WEB GAME,我都会为之兴奋，并很有兴趣的去研究它。而到了2009年末的时候，FLASH WEB GAME已经多到我连体验的兴趣都没了，我已经彻底搞不清楚国内到底有多少个FLASH WEB GAME在运营。而伴随着SNS行业的成熟，基于SNS的Social game进一步扩大和模糊着FLASH WEB GAME的概念。FLASH在游戏领域里的应用，在经历了“社区”、“策略类”、“MMORPG”后，发展到今天创意无限，精彩纷呈的“Social game”，已经很难用一个词，根据游戏类型概括所有的FLASH应用了。所以我觉得“FLASH WEB GAME”，也就是“FLASH网页游戏”这个词还是相对最恰当的，这也是我前面一直使用这个词的原因。

    →2010年 – 2011年：胜者为王！
    就像春秋战国时期，在经历过“百家争鸣”后，必然是“天下一统”。随着游戏巨头和互联网大亨对网页游戏的逐渐重视，以及政府的介入，还有最早领跑某些领域的创业公司不断壮大，相信在不久的将来，网页游戏领域也会出现几个真正的领袖。别的领域不敢说，在我们儿童市场这块儿，淘米公司已经逐渐呈现一家独大的趋势，不信的话，你可以随便找几个小学生问问，比如你父母辈亲戚朋友的孩子，问他们是否知道摩尔庄园和赛尔号，是否充值了，相信你会得到非常惊讶的答案。所以，2010年后，任何小作坊型的创业团队再想进入FLASH WEB GAME行业，都需要更加谨慎了！

    ★创业型游戏公司面临的问题和困难
    →在正式进入FLASH WEB GAME的技术探讨前，我左思右想，还是觉得必须先说一下创业公司存在的问题和困难，为后面可能不太“正规”的做法找一个合适的“理由”。——人不能太爱找客观理由，但也绝对不能为了避免“找理由”之嫌，而弃客观现实于不顾，毛爷爷曾告诫我们要懂得“实事求是”。

    →任何有过创业经验的技术团队和公司应该都知道，教科书那套从成功公司抽象出来的模式在创业初期几乎只能是神话一般的存在，相信没有几个公司能完全做到。当然那种千万级启动资金，有成功背景的新公司除外。像我们公司，一开始就4个人，前台和后台各一个人，如果我们两个都每天用一半时间考虑架构和写文档，我们的产品猴年马月也上不了线了，况且我们写了给谁看呢？在这个阶段最最重要的目标就是尽快把产品做出来，上线运营出一定效果，给产品更加明确的方向，给团队信心，然后尽最大努力去融资，以求下一阶段的发展。产品出不来，只靠一个idea和产品策划书就想找投资的时代早就一去不复返了。

    →我觉得一个创业公司最现实的发展观应该是这样的：初创阶段（技术导向型阶段）：这个阶段要一切以“我们能做什么”为基础，在财力、人力、经验都不足的情况下，找出我们的优势，“把我们所擅长的做到最好”是我们唯一的筹码，毕竟初创人员能走到一起，必然是有一定共识，在某方面有优势的。而“我们能做什么”，在初创阶段很大程度上就是指技术能做什么。没钱、没人还想把项目做的又快又好，绝对是痴心妄想。这个阶段就开始叫嚣“市场主导产品”，“不看过程只看结果”等口号，完全是不务实的态度，市场上最热门的产品你未必能开发出来，创业阶段，前途未卜，你不看过程看什么？发展阶段（人力导向型阶段）：假设我们顺利度过了第一阶段，公司开始有现金流或者找到了天使投资，我们就开始布置进一步的发展了，这个阶段招人将是公司的一个要务，招有创业精神的人，更要招我们需要和缺少的人。以前我们公司只有AS，于是游戏server只能用FMS，现在应该招一个C++ socket的人了；以前公司没有网页前端，网站都是原画和PHP代劳的，现在该弥补了；以前整个游戏都是架构师们设计并实现的，现在应该招一两个做模块打下手的人了。这个阶段虽然不适合大规模扩展人手，但在要害人力点上，也绝对不能抠门，我们公司就是吃亏在socket上，公司一直不肯招一个专业写server端的，一直让前端和PHP代劳，结果游戏同时在线人数一超过5000就会出各种离奇问题，最恐怖是大家都不清楚问题到底在哪里，只能大眼瞪小眼，这个时候老板就会臭骂公司这帮技术都是饭桶，这么多人还搞不定这个问题。老板不懂技术，说出这样的话无可厚非，但老板不听劝，死活不愿意招要害人员，这就是他的错了。总之这个阶段要以人力发展为核心，尽最大的努力把必要的人手配备齐。必须注意的是，这个阶段不适合空降部门领导，公司发展阶段，只有初创人员陪公司一路走来，最明白公司的问题，以及各种问题的根源。而空降的领导容易只看到问题，不明白为什么会有问题，有时候难免说出“道理上很正确，但实际上不可行”的话，而老板为了配合新领导树立威信，很多时候不得不偏向新领导，这样以来很容易打击到初创人员的积极性。更严重的是可能让初创人员看不到前途，创业的激情沦为打工的无味。这个阶段挖墙脚空降领导，希望他们能把公司制度正规化，希望他们拯救公司的做法可能适得其反！公司初创人员这时候应该依旧是公司的顶梁柱！成熟阶段（产品导向型阶段）：如果有幸过了前两个阶段，到了这个阶段的时候，公司应该已经实现了正向盈利，作为一个游戏公司，一旦靠自己实现盈利，相信各种投资机构肯定会主动找上门，千万美元的投资绝对不夸张，你将会为到底接受哪家的投资而烦恼。人力、财力、物力都不再是问题，产品研发和运营的经验也成熟了，这时候唯一要关注的就是市场，什么样的产品更被市场和用户接受，争取开发出更多更好的产品。产品要多样化，公司要规模化，要形成自己的产品链和平台，抓住更多的用户，开拓更多的盈利模式。这时候才是产品主导公司，才是从大公司挖人的时代。如果这些都做到了，当老板再次开会谈“上市”的问题时，每个人脸上将会笑容依旧，只不过初创阶段的笑容是那种开玩笑试的玩世不恭，而现在则是对未来的美好憧憬。

    →其实任何理论都是有前提的，牛顿定律也只是在低于光速的情况下才适用。公司发展的历程中，老板和员工肯定都会有其信仰和观念，都会用各种言辞来说服别人。但我相信没有那种理论和言辞是永远正确的，尤其是书上和大公司的那些所谓的成功经验更是要警惕，因为它们身上有太多的光环，一场本来可能很有价值的讨论，说不定就会被一句“盛大就是这么做的”给结束掉！所以在我们谈任何理论的时候，不妨看看公司现在所处的阶段，不妨时刻谨记毛爷爷的话，实事求是的看待自己。我们公司就曾屡次吃类似的亏，公司在第一阶段刚拿到天使投资，就想做第三阶段的事了，结果做了很多，一件也没做好，白白浪费了很多时间和大好机遇。其实当时老板用来说服人的理论也都是正确的，只不过不适合公司的实际发展情况而已。还有一点要强调的是，不管公司现在处于第几阶段，坚决不能全盘否定其它阶段的付出和努力以及很多不得不犯的“错误”。之所以强调这一点，也是我们公司曾踩过的雷区，当我们发展到第二阶段的时候，公司就开始忙着空降领导，然后这些领导对我们之前的做法开始逐一否定，把做后台的哥们儿说的一无是处，搞得团队气氛极不融洽，吵架红脸的情况经常发生。这就好比我党在经历了长征、抗战和解放战争的原始积累后，在最终发动三大战役攻打大城市时，指着毛泽东的鼻子说：“你以前那套只敢打农村，打的过就打，打不过就跑的逃跑主义路线完全是错误的！”试想，如果党内空降领导都是这种态度的话，将会对我们党和战士们的积极性产生多大的打击！这种情况其实在长征途中就发生过，差点就葬送了党，好在遵义会议及时纠正了苏联空降回来的王明等人的左倾激进主义，挽救了党。而我们的公司，谁来挽救我们的公司呢！

    ★FLASH WEB GAME的系统架构
    →我在这里把一款FLASH WEB GAME的架构分为三部分：系统架构、前端架构、后端架构。“系统架构”主要是指根据一款游戏的特点以及公司的实际情况选择合适的技术实现方案，主要包括美术方案，前端方案和后端方案；“前端架构”主要指FLASH前端的主程序以及模块划分；“后端架构”主要指即时通讯部分和数据库。这章先谈系统架构。

    →谈到架构，我不得不说，那些所谓的完美架构，能够一次架构好，永远不用改的说法只能是传说，或者技术人员忽悠老板的说法，对于创业公司更是如此。创业公司初创时期更多的时候需要在游泳中学会游泳，因为大家都没有经验，失败是最好的教科书。就算大家知道应该怎么做，很多时候条件也不允许。比如我们在一开始就知道应该自己写socket服务器，可就是没socket的人才，于是不得不先使用FMS+PHP。公司一开始的美术更精通FLASH一些，而且我们计划的是要做“企鹅”，于是我们选用矢量图。可后来随着公司产品定位的不断改变，我们的架构和解决方案也会不断调整，当达到一个临界点时，修改的代价已经超过重新开发，我们就不得不对架构进行“重构”了！这时候聪明的老板应该支持程序员们的意见，充分调动他们的积极性尽快改完，全公司应全力配合，尽快度过难关。而不明事理的老板肯定会每天抱怨程序员无能，搭出一个垃圾架构不能满足产品的持续快速发展，拖了产品和市场的后腿，给程序员造成很大的压力，积极性没了不说，在长期经验积累之后本来可能是一次非常好的机会能做出一个相对完美的架构，满足日后很长一段时间的需求变更，结果因为老板过分催促和施压，又烙下了许多隐患，而这些欠下的债，总有一天要还的，这一天来临之时，责任虽然可以完全由程序员承担，但整个公司都要为之付出代价！所以关键时刻程序员该坚持还是要坚持自己的观点，要尽量说服老板，程序员的社交能力在这个时候就凸显作用了，你要明白你不但是在对自己负责，也是对公司负责！另外，真的很希望天下的老板们都能明白一个道理：能够根据公司实际情况不断调整的程序员才是最可爱最辛苦的程序员，而不是那些什么都不管，上去就提一大堆要求，必须都满足他，他才愿意做的程序员。

    →就算时至今日，FLASH WEB GAME在国内发展差不多三年了，但我敢说FLASH WEB GAME还是没有什么行业标准的技术解决方案，尤其是前端，大家都是自成一派。在这个时候，让我们再次搬出那句老话：不管黑猫白猫，抓住老鼠的就是好猫。不过经过这几年的摸索，还是有一些规律可循的：
    1，美术：如果游戏画面简单，色彩构成相对单一，场景内总体元件能控制在100个以下，则非常适合直接使用矢量图，画面各组成部分尽量拆分为能重用的独立元件。这样虽然牺牲了客户端的CPU，但能因为重用最大化而大大减少美术的工作量，也方便他们日后应对需求变更，比如某些元件的尺寸变动。在画面简单，元件又少的情况下，利用递归全元件位图缓存，拿少量内存还能换回大量CPU，找出这个平衡点，完全可以做出很好的用户体验。
    可大部分时间，我们的游戏场景可能都非常炫，画面复杂，色彩鲜艳。使用矢量图的话，一方面不容易画出想要的效果和精细度，这时候使用矢量图反而增加了美术的工作量和难度；另一方面，使用矢量图还有可能导致客户端CPU严重飙升，超出普通客户端电脑的承受范围。这时候我们应当用位图做游戏背景，重用性不大的元件要尽量合并到背景位图里，减少位图总个数，一些简单的动画如果非要用FLASH做成矢量动画的话，也要尽量做成逐帧的，相信FLASH IDE玩的转的美术同志们应该知道怎么把一个渐变动画瞬间转换成逐帧动画。逐帧动画虽然会导致SWF文件体积增大，但相对于换回来的客户端CPU来说还是值得，这其实是牺牲了一些服务器带宽和用户等待时间，换回严重的客户端CPU超载。而如果你的动画非常复杂和精细，精细到只有AE等粒子特效软件才能表达的话，建议还是直接从AE里导出位图序列，在FLASH里弄成逐帧动画，太过复杂的动画绝对不能用FLASH直接做，不但很难做出想要的效果，而且复杂矢量图的SWF文件体积也会大大超过位图，有可能导致用户因为SWF文件加载时间过长，失去等待的耐心，这时候我们情愿牺牲美术的工作量和工作流程，换回想要的效果，减小SWF文件体积。还有一点要提醒的，时间轴动画不可见时，程序一定要记得将其stop掉，不像程序动画，时间轴动画不可见时，FP内部其实依旧在重绘，对CPU还是有影响的。
    还有一种极端情况是场景元件超标，比如整个游戏内所有元素（包括各种MC、BTN、位图以及程序创建的displayObject，总量超过500，这时候你会发现，画面静止还好，但只要游戏上鼠标随便一晃，或者有几个人物随便走一下路，CPU都会狂飙，就算这500个元件都是位图也无济于事。其实这是FLASH的一个瓶颈所在，是目前所有FLASH大型项目都有可能碰到的问题，也是我觉得阻碍FLASH进一步发展的主要障碍之一。在一个元件超多的背景图上进行任何的鼠标动作、动画、文本渲染，都会导致CPU严重飙升，甚至画面很卡。要解决这个问题，本质的也是唯一的方案就是减少元件数量，要想尽一切办法降到200以下。而这需要美术、前端和策划通力合作才行，绝对不是前端程序员就能搞定的事。策划要从产品的角度上看能不能简化目前场景同一时间出现的元素，美术要把能合并成一张图的元件在绘图软件中合并成一张位图，前端AS程序要把不需要响应鼠标事件的元件的mouseEnable和mouseChildren都设置成false，一些能利用copyPixels合并的位图就合并成一张，比如可以平铺创建的房间地板和墙面，要copyPixels成一张图，而不是new出好几百个元件。
    其实元件超标的情况是大多数没有经验的团队很容易发生的问题，这时候前端程序员要起到领头羊的作用，给大家讲明白道理，用事实让大家信服，组织大家一起把事情做的更好，而不是一味的在那里抱怨FP效率低。因为这时候你是团队唯一可以依靠的人，如果这个问题解决不了，虽然大家都有责任，但前端毫无疑问是罪魁祸首！
    极端情况下的极端解决方案：如果游戏策划的非常酷，一个子弹爆炸效果就需要几十个元件支撑，画面上同时又需要几十个坦克混战，这时候常规的解决方案是根本达不到的，但不是说就一定无法做了，你可以利用强大的BitmapData类把每帧要显示的游戏画面完全计算好并且在内存中绘制，然后以一张图的方式渲染给用户，这时候用户玩你的游戏仿佛就像在看逐帧的动画，此时FP占用的CPU大部分都是计算耗用的，而不是渲染耗用的。其实AS的执行效率远远高于屏幕渲染，你把CPU的主要负荷转移给AS，反而能做更多更炫的事情。据我的初步研究，前段时间名噪一时的FLASH版3D雷神，还有现在很多国外效率高的“有点假”的TD类和飞机类单机游戏都是这么做的。可这种模式适合用来做多人联机并且有大量交互界面的FLASH WEB GAME么？我初步思考了一下，感觉是不可能的。首先，大量的交互界面意味着需要用鼠标点击，试想在一个逐帧动画中，每帧都要响应鼠标是什么概念？所以UI部分首先排除了；然后是大量的即时数据交互，每当一个异步的请求得到响应，画面就需要做出相应的改变，这将对本来还可能比较工整的内部绘制算法制造非常大的麻烦，难度太高！基本上也不可行；最后是很多FLASH WEB GAME的画面重用性并不是很高，比如像我们游戏的每个场景都是美术专门画的，而不是用地图编辑器编辑的，这就意味着你无法完全用程序拼出一个场景来；综上我觉得一个款FLASH WEB GAME基本不可能完全使用copyPixels完成，最多是部分实现，比如我上面说的墙面和地板。除非你的游戏策划很NB，知道什么游戏能最大限度的利用copyPixels，而这样的策划估计本身肯定也是个前端程序员。
    2，前端：从系统架构的角度上讲，前端其实很简单。现在WEB GAME主流的前端技术无非就是AS和JS。JS的前端地位其实比AS要老，很多人的JS经过这么长时间的磨练，功力深厚，做一个策略类甚至简单的MMORPG都没问题。但现在用AS来做的话可能更简单，更容易做出更酷的效果和更好的用户体验。所以最近两三年，随着基于面向对象的AS3逐渐完善和普及，FLASH WEB GAME似乎逐渐成了唯一的主流。
    其实除了as和js外，还有很多前端技术可以供我们选择，比如shockwave，java，还有那传说中的flash killer：silverlight和html5等等。每种技术都有其优劣势，比如shockwave在图形渲染方面比flash强了千百倍啊千百倍，因为它可以完全调用显卡，我在网页上玩过一个基于shockwave的CS，流畅度和操作感完全不亚于桌面版的CS，还有国外的哈宝以及国内的娜娜米米都是基于shockwave的。而Java和silverlight也都有强大的背景，HTML5最近也是来势汹汹。但不管怎么样，2010年，FLASH仍以其广泛的覆盖率、酷炫的效果和逐渐成熟的开发社区，以最高的综合评分独领WEB GAME业界风骚。所以任何公司和团队，如果现在想做WEB GAME的话，如果实际情况允许，FLASH还是最好的选择。
    3，后端：后端不是我的强项，我就不多说了，我只根据我们公司的经验谈谈心得。我同意前后端编程有很大区别，但绝不同意前后端谁简单谁复杂之说。根据我这几年的观察，我发现，前端偏重的是效果，是用户体验和细节处理，有时候可能还要涉及一些图形算法；而后端则偏重数据结构和数据处理，讲究的是性能、安全和扩展性。前端工作量一般比后端大，而后端需要的工作经验比前端多，想依靠一个只掌握了理论知识的大学毕业生就支撑一个公司的后端架构是严重不靠谱的！前端架构师必须是一个编程高手，十几、几十万行代码要在他的手里安排的井然有序，后端架构师则必须有过大型项目经验，并且项目同时在线人数达到过一定规模。前端架构出现问题，会严重拖垮开发周期，而后端架构一旦出现问题，对公司将是致命性打击。所以在公司里宣传所谓前端重要还是后端重要的说法，是完全错误的，任何一款好的产品，必将是策划、美术、前端、后端都达标的产品，缺失任何一块儿，都成功不了！不同部门之间的比较和较真儿没有任何正面影响！
    至于后端的技术解决方案，我感觉如果是需要大量即时交互，并且对即时性要求很高的游戏，就必须使用socket服务器。而如果对即时性要求不高，完全可以用PHP，部分的即时交互可以用socket实现或者HTTP轮询也可以。如果你的公司也像我们一样刚开始没有合适的C或者JAVA socket程序员，选择fms和sfs也未尝不可，这样至少可以让前端人员代劳，让项目可以启动。切记这只是为解燃眉之急的下下策，长久不了，公司要想办法尽快找到一个合适的人，在合适的时机重构。

    ★FLASH WEB GAME的前端架构与人事分工
    →前端的主程序架构和模块划分与人手和人事分工是紧密联系在一起的，而这些很大程度上又是由项目本身决定的。纵观现在国内绝大多数FLASH WEB GAME的规模和难度，我觉得前端AS人员大概需要2-7个之间，主程序有效代码一般不会超过10W行。在这种情况下，人事分工应当以功能和模块进行划分，尽量避免多人维护同一份代码，每个人各司其职，减少维护和协作的成本。这种模式非常适合人手不够，制度不健全，而且追求效率的初创公司。

    →根据各种游戏类型的不同，分工也应该不同。策略类更注重界面开发，分工上应该向UI偏重，MMORPG类注重主架构一些，而像我们的海底世界，是更新驱动类社区游戏，每周都要发布新内容，还需要大量的小游戏和场景功能支撑，所以需要更多的模块和小游戏程序员。

    →下面就以我们公司为例详细谈一下，我们公司最多的时候，一共5个AS程序员，分工是这样的：1个主架构，1个主UI,1个小游戏，2个场景和模块程序员。主架构同时负责FMS的sever端；主UI同时负责前端人员管理和文件管理；小游戏人员以平均每月两个单机或者联机游戏的速度循环不停开发，是相对最独立的一部分；而两个模块程序员，负责每周发布的新场景和新模块功能，他们的工作量其实蛮大的。

    →先谈前端主架构，前端程序主架构有两个主要任务：1，要从架构高度合理划分前端各模块，提出可行的实现方案；2，从AS级别搭建程序架构（非文档级别），制定前端编程规则和接口，规范程序各部分的职责划分。这两个任务其实包括很多具体工作，比如：游戏启动流程制定，确定哪些SWF文件需要外部加载，那些功能可以从主程序剥离出去单独实现，前端配置文件怎么处理，公共素材怎么处理，MVC三层怎么划分，主程序框架的选定，主程序怎么和后台通讯，主程序如何与模块协作，哪些代码应该放在主程序中，哪些代码应该放在模块里，主程序如何既能提供模块所需要的一切功能和数据，同时又相对模块自我保护等等等等。其实我谈的还只是一些大的方面，具体到实现的级别，还有大量细节工作要做。而这些工作在项目启动之初都是非常重要的，直接影响到项目中后期的开发和维护效率。

    →上面提到的那些点，我不可能全讲一遍，不然就不叫“浅谈FLASH WEB GAME”了！我只挑两个比较核心的内容跟大家略做探讨，就是前端AS框架和模块划分的问题。先谈前端框架：现在市面上流行很多前端框架，不管是针对“FLASH”的，“FLEX”的还是“通用的”都有。我们是否一定需要框架，或者必须使用某个框架，这完全是仁者见仁智者见智的事，从最终的结果上讲，争论这个问题意义不大，我相信一个5W行左右的项目，任何有5年以上编程经验的人，不管用什么作战策略，最终都能攻下山头，把项目做出来。但有一点至关重要：你必须能完全把握你的架构和你使用的框架，并能跟你的前端同事解释清楚。那好坏架构的区别在哪里呢？区别在于好的架构在开发过程中会更轻松，你不用天天担心的你代码，不用每天不停的写文档，以防止自己忘了复杂的逻辑，你可以在任何时间开始写代码，在任何时间去玩会儿游戏然后回来接着写；区别在于好的架构更符合业界标准，更容易被传统和正统的程序员接受理解；区别在于你可以用很简单的几句话就把你的架构思想描述清楚，用几个很简单的文档就能让别人接手你的代码，在人事变动和工作交接的时候让自己更轻松；区别在于当你掌握了一种通用框架或者自己总结一套成熟的架构后，你几乎可以套用以后的大部分项目，并不断完善它，开发越来越轻松，速度却越来越快！

    →我们的项目，主程序使用的是pureMVC框架，而主UI部分是自己写的。主程序和主UI相互独立，可以单独编译测试。主程序是纯代码，用FLEX SDK编译，而主UI则是界面和AS混写并用FLASH编译。这样就把MVC中的V从物理层面上完全独立了。pureMVC框架正如其名字，是一款“纯粹”的MVC框架，在我看来，他只是帮我们实现了MVC的编程思想和套路，其它多余的功能一点没有，这使它具有更高的通用性，也是它最可爱的地方。根据我们的经验，pureMVC单核心版就已经完全可以应对主程序有效代码在10W行以下的项目了。但在我跟很多没有用过框架的前端朋友聊天中，发现他们对这些框架本身就有抵触心理，或者有些对MVC模式都理解的不深刻，用起MVC框架又怎能得心应手？还有一些更过分的朋友把自己的问题也归结到框架上，说什么用了pureMVC框架后，自己的项目编译一下要十几分钟，我听了之后哭笑不得，项目编译慢一般是因为没有合理划分模块导致主程序过大才导致的，跟框架有什么关系？如果因为大家的种种误解和这些人的言论而导致一些新人错过学习这么一款优秀的框架，我觉得实为憾事！

    pureMVC既然是一种MVC框架，这就意味着你首先要熟悉MVC。这种熟悉绝对不是对MVC的直译：模型、视图、控制器，而是要真正理解为什么要把程序划分成这几部分，在划分主程序模块时，要时刻能站在MVC的角度考虑问题，而当面对一段实际的代码时，能快速准确的判断，这段代码应该放在MVC中的哪部分。《pureMVC最佳实践》这份短短几十页的文档中，可以说处处闪烁着MVC的思想火花，不但清楚地阐述了怎么使用框架，而且时刻从MVC的角度告诉我们应该把哪些逻辑放在哪些部分中，应该注意什么问题。这个文档早已经有中文版，有兴趣的朋友可以自己去看看，文中有的，我这里就不赘述了。我只结合自己的体验谈一些文中可能没有涉及的，也是在真正开发中才会碰到的问题。

    1，模型部分在实际开发中除了存储数据，还有其他作用么？是的，其实它的实际职责非常多。它要给Command和Mediator提供接口，响应用户操作，进行数据操作或者请求远程数据服务，进行数据的序列化和反序列化，得到异步数据后可能还要检查数据合法化。但不管怎么样，它始终是在和数据打交道，同时也应该是你的主程序中唯一可以直接和数据打交道的管道，别的部分要想和数据有接触，首先要问问它同意不同意。模型处理完数据会以Notification的消息方式通知Command或者Mediator。但绝对不能在Proxy中直接调用Mediator，这是为了保证数据层的独立性、可移植性和重用性，也简化了你的架构思想。不过可移植性这个优势，估计很多搞FLASH WEB GAME的朋友暂时都没啥机会体验，呵呵。

    2，Command，Command，Command！连叫三声“Command”，希望可以引起大家的注意。因为Command的使用，在很大程度上反映着你对pureMVC框架的理解，甚至是对MVC模式的理解深度。在pureMVC框架中，各部分通讯是用Notification消息，Proxy可以给Command和Mediator发消息，Command可以给Command和Mediator发消息，Mediator可以给Command和Mediator发消息，怎么样？你现在是不是点晕了，这是正常的，其实我也有点晕！当你代码写到一定规模后，你会更晕。其实pureMVC框架这么设计本来是为了让MVC各部分尽量脱耦，但这带来一个负面情况就是消息发送与接收机制设计的太灵活了，灵活对小项目是好事，但对大项目来说，往往意味着混乱，甚至会导致灾难。那怎么办呢？只能靠我们的自觉性自我约束，简化架构思想了。根据《pureMVC最佳实践》中的建议，我的做法是这样的，尽量使用Command，让Command成为Mediator与Proxy之间通讯的唯一桥梁，Mediator和Proxy中发出的Notification，接收者一定是某个Command，然后再由Command处理并将结果转发给真正的消息接收者，Command就算仅仅起一个转发作用，仅仅有不到10行代码，也要创建一个Command类。这样不仅使你的架构更加清晰，而且也更符合MVC思想，Command类的大量存在还使你架构的业务逻辑具有了更好的封装性和扩展性，可谓是一箭三雕，何乐而不为？唯一的负面影响可能是你需要创建和维护更多的Command类文件，但相对于优势而言，这点影响不算啥。

    3，我知道现在可能还有一些朋友在用FLASH IDE写代码，这些朋友的执着让人钦佩，但我想任何一个熟练使用过FLEX BUDIER、FD或者FDT的朋友，都绝不会再回头使用FLASH IDE写代码了。——不对啊？不是谈pureMVC的么？怎么扯到IDE上去了？这是因为我现在要讨论的问题就和IDE有关，假如你现在用的还是FLASH IDE的话，除了随时写文档外，我真的很难想出一个很好的方案可以让你在没文档支撑的情况下，轻松掌握和随时维护几万行代码。可如果你使用的是FDT,就可以在没有文档的情况下，利用“ctrl + r”和“ctrl + 鼠标左键”，以及全文件搜索等工具，瞬间搞清楚代码之间的联系和逻辑，找出要修改的地方。OK，终于到pureMVC了。如果你使用的是FDT,并且开始尝试使用pureMVC框架，可在使用的过程中，你发现你在写主程序时，还是不停的使用“ctrl + 鼠标左键”，而不是“ctrl + r”，这说明你必须重新审视你对pureMVC框架的理解了，请审查你的Mediator类，看里面是不是充斥着大量的public方法，如果你的对象之间依旧是通过public方法进行引用，而不是通过Notification通讯的，那你也没有必要继续使用pureMVC框架了。

    4，单例模式影响到底有多大？pureMVC是一个完全依赖单例模式的框架。单例模式似乎在AS界一直有很大争议，这样的话，pureMVC肯定也会有相应的争议了。持反对意见的人，大多集中在“性能”和“团队协作”方面，他们认为一个单例持有过多引用会带来性能问题，而且生怕在团队协作中自己的单例类被人无意修改，引发离奇的BUG。性能方面，我之前也没做过10W以上的项目，不敢妄言，但10W行以下的项目，绝对没有问题，如果你两三万行的架构就开始碰到主架构性能问题，估计十有八九是自己的代码写的有问题；团队协作方面，我觉得pureMVC的Façade模式是非常灵活好用的，大家可以略做讨论，制定一个简单的规则，比如模块只能通过façade获取数据和发送Notification，不能直接调用主程序其他CLASS，只要架构程序员不犯错，模块程序员甚至连犯错的机会都没有，如果他们有，还是你的架构思路有问题，请继续审视自己的代码。反正单例模式的问题到底是什么，我到现在也没完全搞懂，主要是我们的项目没碰到过此类问题，希望碰到过的朋友能再仔细跟火山说说，我也好弄清楚问题到底出在哪里了，自己以后可以更好的避免此类问题发生。

    额，框架部分先谈上面4点吧，赶快进入下一个话题，模块划分：模块划分主要包括“核心模块划分”和“子模块划分”。核心模块的划分思路是这样的：它们是游戏启动所必须的，相互之间是紧密联系的，还要经常的被子模块调用；而相对的，子模块的划分思路是：他们在游戏启动过程中不是必须的，可以在游戏过程中再加载，子模块相互之间基本上完全没有联系，一个子模块的增加和删除不会影响到任何其他子模块，子模块可能需要调用主程序的接口或者获得主程序的数据，但主程序绝对不应该依赖某个子模块。

    明确了模块划分思路再具体看看哪些部分应该划分为核心模块，哪些部分应该划分为子模块。一般情况下，核心模块按照游戏启动顺序包括：一个壳子SWF → 配置文件包 → 登录注册SWF → 主程序SWF → 主UI的SWF → 公共素材包。而子模块相对来说简单很多，比如具体的某个小游戏，某个场景，以及某个场景里的触发功能等等。下面我对核心模块逐一略做解释。“一个壳子SWF”：这是一个体积很小，但意义很大的SWF；它后面总是跟着随机变量，确保每次用户加载的都是最新的；它里面定义着一些需要经常更新而且每次更新都必须保证用户也在第一时间就得到最新值的变量；它里面最好有一个简单背景图，保证用户在超低网速的时候输入游戏网址不至于长时间面对一片空白；它里面有安全策略的设定，是我们游戏和很多第三方平台合作的基石；它里面还定义着主程序被加载进来之前的游戏启动流程等等。“配置文件包”：核心模块版本号啊，全局文字说明啊，service接口定义啊，各个核心模块需要的配置信息啊什么的，一般是一些XML文件。“登录注册SWF”：这个简单，在加载重量级的SWF前，先加载登录注册SWF,可以保证用户第一时间就能打开登录注册界面，而且可以有效节省服务器带宽。“主程序SWF”：这个就是我前面费了好大劲讲的主程序部分了。“主UI”：主程序和主UI为什么要分开两个SWF，我前面已经提过了，后面还有说明，这里暂时不讲。“公共素材包”：公共素材包是一个游戏不可缺少，但也不能过分依赖的东西。它包括一些全局的道具和效果，比如表情、技能特效、场景传送门等等。公共素材包里面最好就是一些简单的动画，体积小功能简单，严禁在公共素材包里添加上百K的东西，或者代码上百行的小模块，公共素材包建议500K以下。

    看了上面的讲解，你可以能觉得核心模块分那么多，太麻烦了。不错，在我看来，对SWF加载流程的分解和控制，对异步程序的掌控正是衡量一个AS程序员是否经验丰富，是否足够老道的重要指标，很多从其它语言转到AS并有多年编程经验的朋友，架构方面可能和AS程序员差不多，甚至比很多自学成才的AS程序员做的更好，但这方面往往不如长期与CPU和SWF体积搏斗的老牌AS程序员。核心模块划分的越合理，用户体验往往越好，后期编写和维护代码的效率会越高，但在前期会比较麻烦，而且对架构师的架构经验和能力必须提出更高的要求。什么都不分，主程序、素材、核心模块都弄在一个SWF里，用户一开始必须先下载完这个SWF,或者弄了一堆核心模块和超多公共素材，用户一开始必须面对loading条不停的周而复始，必须等所有核心要素全部加载完成才能进行一些基本操作的做法，从架构角度上讲，是最简单的做法，因为不用过多考虑复杂的异步和SWF拆分问题，但从用户体验和长远的开发维护上讲是非常不利的。根据我们的经验，用户登录前加载的所有资源体积应该控制在200K左右，而用户进入游戏主场景前，加载的资源总数应该控制在1M左右。还有前面提到过的那位用了pureMVC后项目编译一下要十几分钟的朋友，估计就是把所有东西都弄到一个SWF里的做法。主程序随便改动测试一下，就要十几分钟，牵一发而动全身，开发效率从何谈起？根据我们的经验，任何主程序、核心模块还有子模块的编译，都必须在10秒以内，这才是合理的——我的机器是07年花了3000多买的戴尔品牌机。

    →谈完主架构，接着谈主UI。主UI一般指主要的人机交互界面，这里的主UI区分于主架构中的mediator，当你看过pureMVC文档后，你就知道了，mediator只不过起到一个真正的V和pureMVC框架之间的桥梁作用，pureMVC里的mediator其实并不实现什么功能，真正的功能都是在主UI里实现的。但主UI又不得不算是主程序的组成部分，因为它不像其他模块，基本上只需要调用主程序的接口就行了，本身并不需要对主程序提供接口。而主UI作为用户操作界面，必须大量的向主程序的mediator提供接口，或者发送events。所以主程序和主UI之间的配合必须非常密切才行。

    不同的游戏类型，可以选择的UI解决方案也不同。策略类非常适合用FLEX；MMORPG这类标准网游，非常适合用ASWING；而像我们海底世界这类游戏界面非常夸张，没什么标准规则，又不是太复杂的界面，还是适合自己开发。相信任何有过游戏项目经验的人都应该能理解，UI也是FLASH开发中的重头戏，很多细节的处理非常麻烦，在项目早期具有很大的工作量。还是以我们的项目为例，我们的UI架构思路是这样的：

    1，所有的界面组件都是直接拖放在stage上的，其功能代码大部分都是在发布时编译的，基本上不用new的方式。这种方式的好处是方便编辑界面，从总体上直观的把握所有的UI，减轻程序运行时的负担，同时避免addToStage带来的诸多问题。缺点是，当UI膨胀到一定规模时，可能会需要你有一台配置比较好的电脑——哎，说到这里我就伤心啊，我那台玩魔兽效果全关还卡的电脑，一直陪伴我的整个UI开发历程。

    2，UI的FLA层次结构是这样的：第一层是文档类或者与UI主类关联的某个MC，我们选用的是MC的方式,因为MC的方式更灵活；第二层是这个MC里的所有组件，这些组件大部分是根据功能划分在一起的一组元件，比如你的个人面板，而这个组件本身也是个MC；第三层是组件里的所有元件或者共用组件，元件就是背景啊，按钮啊什么的，而共用组件比如滚动条啊翻页组件啊什么的；主要的就这三层，其实那些共用组件MC再往里面双击还可以划分一层。对应FLA的层次结构，AS的结构如下：文档类或者主MC关联的类是第一层，这个类里持有所有的界面元件的引用；第二层是这些界面元件对应的组件CLASS,组件的功能都是在这里实现的，比如个人面板的MC将会对应一个MyPanel的CLASS,这个CLASS里实现MyPanel的所有功能。至于CLASS和元件之间是怎么对应的，我用的是一种松耦合的代理模式，也就是将MyPanel对应的MC作为参数传递给MyPanel这个CLASS,而这个CLASS会有自己的私有变量记录对应MC里需要进行操作的元件，具体到功能实现时，从代码层面上看，就好像CLASS操作的都是自己的私有变量，而不是直接操作界面元件，这样，当界面元件修改名字时，CLASS的改动很小。而且这种代理模式可以实现一个CLASS代理不同的元件，当界面只是需要修改外观，不需要修改功能时，非常方便。那么这些CLASS是在哪里初始化并获得它要代理的MC呢？正是在主MC对应的UI主类中，比如当获得MyPanel对应的MC后，就会立刻public var myPanel:MyPanel = new MyPanel(myPanel_mc);当所有的组件注册完成后，这个UI主类就持有了所有组件的引用，可以方便主程序调用；代码的第三层其实就是共用组件，比较特殊的是，我的共用组件，比如滚动条，也是用代理模式写的。

    3，完全代理模式为我们创造了一种可能，就是把UI和UI对应的代码分开编译。这跟FLEX的皮肤更换机制有异曲同工之妙，只不过它的组件是要new出来的，布局是要代码控制的，皮肤都是一个个CLASS，整体效果一般都要编译后才能看出来；而我的组件是直接拖到舞台上的，布局大部分是直接在FLASH IDE里手动布置好的，皮肤都是一个个命名过的MC，整体效果编译之前基本上就能看出来。FLEX在更换皮肤的时候，CLASS名绝对不能变，而我的UI在更换皮肤时，MC的名字和层次结构不能变。FLEX关联皮肤是在编译时完成的，而我的UI关联皮肤是在运行时，当启动程序加载完UI代码的SWF和皮肤的SWF后，动态指定的。把皮肤和功能代码分开编译成两个SWF有个好处，就是在实际开发过程中，我们会碰到有时候只需要修改代码，而有时候只需要修改界面的情况，当然，就算你把代码和界面一起编译成一个SWF文件了，也完全可以对应这种情况，无非是编译一次的时间稍微长了一点点。可当你面对这样的情况呢：某次游戏版本更新出现状况，需要你目前功能不变，但画面必须退回到上一个版本。这时候你傻眼了吧？你开始对策划们咆哮：“你们能不能想想好再让我们做啊？”但你还是不得不重新打开已经做好的UI,把里面最新的界面再修改回老版本，同时还不敢把最新的删了，因为下一个版本估计马上又要替换回最新的画面了。可如果你的皮肤和代码是分开编译成两个SWF的，这种情况就简单了，你可以让运维从SVN上拉出上一个版本的皮肤SWF重新发布一下就好了，你所要做的只不过是动一下嘴皮。

    4，最后谈一下UI的数据层吧，UI是否需要数据层呢？答案是肯定的。尽管你可以从主程序那里获得任何你想要的数据，尽管大部分时间你只是需要数据来显示一下而已，但UI自己记住某些数据会大大方便自己写代码。UI的数据层不需要主程序那么复杂，每个组件有自己的数据变量，然后整个UI再有一个存放公共数据的地方就足够了。

    →谈完主程序和主UI，最后再简单谈一下小游戏、场景和模块。先说小游戏吧，小游戏是相对最独立的一块，可能只需要主程序提供用户数据，并在游戏结束后将分数发送给主程序就行了。所以这部分从管理的角度上来讲是相对轻松的，但这不意味着小游戏开发就简单了，有时候，麻雀虽小五脏俱全，想开发出一个性能和用户体验俱佳的小游戏绝非朝夕之功，要是碰到一些算法复杂的小游戏，那就有得头痛了。其实对于海底世界这类儿童社区游戏，小游戏应该走创意和简单路线，搞得太复杂了，既不好开发，小孩子又不一定玩得来。

    相对于小游戏，场景和模块就和主程序甚至是主UI关系密切了，但不管怎么密切，大部分时候它们都是在所要数据，发送事件，或者触发某个界面的显示与隐藏。如果某个模块的修改需要经常波及到主程序，或者很多模块在做同一件事，重复写着同一段代码，这时候就必须重新审视架构，看是不是某些地方架构的不合理了，不合理的地方，只要时机允许，一定要尽快改掉，绝对不能放任自流，一块儿小毒瘤最终可能引发癌症。模块和场景程序员在我们公司其实是非常累的，因为每周都需要发布新的版本，每次都很赶。在这种情况下，场景和模块程序员的责任心就非常重要，他们随便哪里随意了一下，会直接导致糟糕的用户体验，因为大部分时间，用户直接接触的东西都是他们的作品。架构写的再好，最终模块都做的很糟糕，对用户来说没有任何价值！所以，一个老道的，有责任心的，能够快速开发出优良用户体验的AS模块程序员，完全有理由拿高薪，因为他们能做到的，一些所谓的纯架构师未必做得到！
    我的FLASH情结2010——浅谈FLASH WEB GAME与创业

    ★前端与美术的配合
    →老闪客们应该都知道，FLASH这款软件在历史很长一段时间内都是用来做动画的，闪客和美术在这段时间内本就是同根生。后来随着第二版AS1和AS2逐渐完善，以及AS3的强势出炉，闪客们才逐渐分化成纯程序和纯美术两个阵营了。但不管怎么分，FLASH程序和美术之间的关系依旧非常亲密，一个优秀的AS程序员必然要比其它语言的程序员懂得更多美术方面的知识，至少也要能熟练操作FLASH IDE，并进行简单的图形处理。FLASH程序员与美术的合作大部分时间是由AS程序员主导的，主要表现在以下几个方面：

    1，FLA文件管理：把有联系的美术素材放进一个FLA文件中统一管理，既能有效减少美术素材的数量，也方便程序员写程序。本来像这种美术素材管理应该是由美术负责的，但由于这些美术素材大部分时间可能也需要程序员写程序，美术和程序需要共享这些素材，虽然我们可以用SVN进行共享和版本控制，但程序员和美术还是要靠约定才能非常默契的知道什么时间该到什么地方找什么文件。而这个约定就什么我们程序员应该制定的，因为据我观察，程序员在条理性和制定规则方面一般比美术更靠谱。以我们公司为例，文件管理基本上都是由我负责的，我把需要多个美术和程序员共同维护的部分以项目名命名成一个文件夹，项目下如果需要还可以进行子分类，分类规则也是我制定。而大部分的子模块可能只需要一个美术加一个程序员就搞定了，这时候美术就把素材放到以自己英文名命名的文件夹下，至于他们的文件夹内如何分类，我会给出意见，但并不强制管理。模块程序员也会都有以自己英文名命名的文件夹，他们会把美术的纯FLA素材拷贝到自己的文件夹下，并根据模块进行子分类，然后写代码并发布SWF，至于SWF文件如何管理，我会在下一节中讨论。其实我的管理目标非常简单，我只需要所有的美术和程序员能在任何时候瞬间找到我们需要的素材和源代码所在地，并且把需要的版本调出来。只要这个目标还在可控范围内，我就会给所有员工最大的自由性，把自己从管理里解脱出来，把更多的时间投入开发，毕竟对于创业型公司而言，快速开发，让老板和市场看到产品才是主旋律，管理只需要在必要的时候强势出手就可以了。事实上，我们公司的文件管理，我每隔半年才会强势管理一次，用大概一周的时间重新规范规则，其它时间基本处于放任自流状态，但从没出过什么大问题。最后给大家一个数字，我们公司经过将近三年的积累，已经有几十个G，上万个美术素材了。

    2，SWF文件管理：SWF文件一般是由前端程序员发布并管理的，不过也有一些SWF可能不需要些代码，比如家具、个人面板背景等等，这些可以直接由美术管理，管理方案和FLA文件管理差不多。最大的不同就是，SWF文件最终的发布路径是内网模拟测试环境，而不是本机。像我们这样的更新驱动游戏，不可能为每一个模块都单独搭建拟真测试环境，如果这样的话，可能我们测试环境还没搭好，就该上线并准备下一周的更新了，所以所有的模块最终的整合测试都是直接上内网测试环境进行。

    3，FLA内元件的管理：这个问题相信很多AS程序员都碰到过，也都为此头痛过。美术给到程序员手里的FLA文件可能是混乱不堪，库里没有任何分类，元件名也都是清一色的“元件1、元件2，元件3……”，元件内部遮罩，组合，层次也都没啥规律。要是美术直接给我一个AI或者PS的源文件让我们自己导入FLASH，那我们就更抽了，颜色模式的改变，路径工具的失灵，大量的图层导致裁切困难，而且还不能进行打散合并，只能一层一层的切。这个时候，正如我前面提到的，一个合格的AS程序员应该对美术和图形软件有更多的了解，你应当及时纠正美术不恰当的做法，甚至给出合理的解决方案，比如你应该知道FLASH只支持RGB颜色模式，AI不但整个文档可以指定颜色模式，每个图层也可以单独指定，当美术给到你的AI导入FLASH有色彩差异的时候，能帮助美术找到哪里的颜色模式不对，并建议他们以后只使用RGB模式。很多纯AS程序员可能有图形恐惧症，他们会想尽一切办法把这部分工作推向美术，但最终他们都会很郁闷，因为他们会发现，除了能指定库文件夹的命名规则外，其它的规则很难跟美术说明白，而且由于模块的千变万化，很难总结出一个完全通用的规则，想从美术哪里拿到一个完全不用修改，自己可以直接写代码的FLA文件，几乎天方夜谭。所以，与其让FLA文件在美术和程序的你来我往中浪费时间，与其让自己在对美术的鄙视中愤懑抱怨，不如提升一下自己的美术常识和图形处理基本功。毕竟，元件在舞台上怎么命名，关联什么类，层次怎么样，怎么被程序利用，这些只有我们程序员最清楚，这部分工作由我们程序员完成完全是合理的，也是效率最高的，美术只要把我们需要的素材交给我们，并放到方便查找的地方就可以了。放下程序员的架子，主动走入美术的世界，对我们程序员绝对有好处。

    4，FP的性能问题对美术的影响：谈到这个问题，我就想起了一个让我抽搐已久的情况。我们老板总是喜欢语重心长的对我说：“火山，你给咱们前端人员和美术出一个方案吧，告诉他们怎么做可以让FLASH性能最高！”额，现在请问哪位朋友可以帮火山回答这个问题。火山真的惭愧，搞FLASH搞了7年了，始终还是没完全弄明白FLASH的诸多性能问题。不管以前的MM还是现在ADOBE，都将其图形处理和屏幕渲染部分视为其镇山之宝，不肯公开其技术内幕，我也就始终无法从理论的高度给出一个本质的回答。我现在的大多数性能解决方案，都是根据项目的实际情况，根据7年来的经验总结出的经验科学。而且我始终不相信，谁可以一个给出一个适合所有项目的、通用的性能解决方案，可以同时让内存、CPU、带宽占用都最少，而且画面又很炫，功能很强大，SWF文件非常小，可玩性非常高，而开发周期和成本却很少。内存、CPU、SWF体积、带宽、效果、成本，这几个要素往往是相互矛盾的，你对其中任何一点的过分优化，都有可能导致其它点走向反面。我深信，在目前这个时期，一个性能方面的高手，绝对不是看他能不能给出一个全面优化的方案，而是看他在面对不同的项目，不同的情况时，如何做出选择和取舍。是的，“选择和取舍”永远都是人生最艰难的话题：手心手背都是肉，削掉哪边呢？老婆孩子都掉海里了，救谁呢？在这样的情况下，我觉得一个负责的前端人员，反而不应该仅仅简单的扔给美术一份死的文档，告诉他们应该怎么做，让他们一直这么做就可以了。前端人员应该在每次面对一个实际情况时，都不厌其烦的跟美术讲清缘由，我们应该尽量授人以“渔”，而不授人以“鱼”，让他们明白选择的道理，而不是简单的告诉他们选择什么。相信只要是虚心学习的美术，经过一年半载的讲解他们就能替你做出判断了，这时候你再让他们去跟后来的美术讲，你就解脱了。很可惜，大部分不懂技术的老板可能觉得你是在故弄玄虚，非要你给出一份文档。无所谓了，你跟不懂技术的人争论不是自讨没趣么？老板更多时候是从管理的角度出发的，我们应该配合。我们也不是没什么可写，比如尽量减少元件数量啊，减小SWF体积啊，减少持续性动画啊，多做触发性动画啊，少用遮罩和滤镜啊，不要嵌入中文字体啊，提高元件重用性啊等等等等！这些建议听上去完全正确，忽悠不懂技术的人正合适。但其实在高端的开发中，这些理论都是废话，帮不上多大忙，因为地球人都知道了，我们碰到的问题肯定是超越这些技术点的高端问题！

    综上可以看出，其实前端和美术的配合过程大部分时间是由前端主导的，这也是我前面一再强调前端要多懂一些美术知识的重要原因。当你可以和美术一起谈论美术理论，在美术的电脑上直接操作给他们看，当你从美术的角度给他们提出解决方案的时候，你往往会更容易被美术所接受。担负起主导前端与美术合作的责任，用你的智慧征服他们，用你的诚意打动他们，让美术与前端完美结合，让你的产品第一时间抓住用户！

    ★前端与后端的配合
    →FLASH与后端通讯的手段多种多样，网上相关教程太多了，这里不再例举。但很多时候，创业团队由于受制于各种现实条件，可选择的方案并不多。像我们公司，刚开始基本上只能选择FMS+PHP+MYSQL。其实，对于我们前端来说，后端选择什么解决方案对我们的影响并不大，我们无非就是用的API不一样而已。多看看教程，用很少的时间我们就能掌握其要领。那么前后端合作的难点是什么呢？我觉得关键是逻辑的划分。

    →“前后端合理划分逻辑”，这句话咋看上去貌似简单，其实里面蕴含着诸多方面的考虑。比如安全性、后端性能、工作量、人事分工等等。安全性：记得我们的游戏同时在线超过3000的时候，就已经有人开始攻击我们的后端了，篡改了很多人的个人资料。幸亏攻击的人只是我们一个善意的玩家，如果是恶意的商业攻击，后果不堪设想。经过这次后，老板开始缠着我们追问“怎么防止别人攻击，提高安全性”。这个问题又一次把我们难住了，我们都知道，基于HTTP的请求不被截取是不可能的，而SWF文件又不存在绝对的安全。就算你防得了恶意进攻，你也防不了良性的外挂，想从技术层面让别人完全攻击不了我们也是不可能的。那我们是不是只能坐以待毙了？不是！如果前、后端在合作的时候，数据逻辑与合法性检查都是做在后端的，就可以很好的避免一些良性外挂。首先是游戏数据逻辑要尽量全做在后端，比如用户在玩小游戏的时候，我们不要只是在用户结束小游戏后，简单的把数据传回后端，后端记录进数据库完事，一旦攻击者发现了你这个传数据的后台接口，完全可以避开SWF，做外挂直接呼叫你这个接口刷分，就算你验证用户也没用，因为他可以先注册一个合法的用户，然后在外挂中登录再刷分。当然，你还可以对游戏分数先加密在传给后端，提高攻击难度，但这也是不保险的，因为加密算法就在你的SWF文件中，别人可以很容易获得。所以正确的做法应该是：游戏开始的时候只告知后端游戏ID→后端标识ID对应的游戏已经开始并记录开始时间→用户每次获得一个分数时，前端传回来的不是分数，而是一个动作ID,后端根据动作ID给用户加分→游戏结束时，前端告知后端游戏已经结束→后端得知游戏结束，记录结束时间，计算时间差，根据时间差和最后得分是否符合标准做出相应处理，如果符合标准就把最后得分入库，并返回前端显示给用户，如果不符合标准，就启动作弊处理系统。而这个标准一般是由数值策划给出的。经过我这么一分析，你可能头痛了，本来一个很简单的小游戏计分，怎么搞得这么复杂？前后端工作量都增加了不说，对后端性能也提出了更高的要求，服务器可能要增加了，后端人手可能要增加了，开发周期也要延长了，值得么？这个问题问的很好，这正是我下面要说的：后端性能、工作量、人事分工：一旦我们每一步进行安全性与合法性验证后，整个项目的工作量都会大大膨胀，开发周期也会大大延长；一旦我们把数据处理、业务逻辑和安全验证都移到后端时，后端的压力就会增加，服务器要增多，对后端人员的能力要求也会提高。很多初创团队在项目初期人力财力，软件硬件都不足，可能顾不上那么多，一心想着早点让项目上线。在这种情况下，我觉得安全性可以暂时放一下，众所周知的安全漏洞补上就可以了。但“数据处理和业务逻辑”这个，宁可开发的慢一点，宁可再招个后端高手，宁可多几台服务器成本，也要把它们尽量都放在后端。因为这个没分清的话，会影响到整个系统的清晰度，严重影响项目中后期的发展，为日后的重构增加难度和超多的工作量，我们还指望着在重构时加强安全性呢，到时候数据处理和业务逻辑还是要放后端！所以综合考虑，该出手时就出手，能省的不浪费，不能省的不要抠！

    →前面一节谈了前后端合作的难点。这里再简单的谈两个要点：
    1，前端人员不要以前端的角度看后端：前端和后端有个本质的区别，就是前端的负荷是分担在每个客户端的，而服务端的负荷是集中在服务器上的。对于我们前端来说，一个功能多占了几K内存，SWF文件大了几K根本不是什么问题，可对后端来说就是很严重的问题了，一个人大几K，上千人就是几M了。服务器在连接数、内存和CPU之间会有微妙的平衡点，一旦这个平衡点被打破，随便再多哪怕一点点资源占用，整个服务器的性能都会严重下降，影响用户体验，当然，如果你有几十上百台冗余服务器供你负载平衡，你可以当我没说，可如果你像我们公司一样，一开始就3、5台服务器的话，就请前端人员一定要多多配合后端人员，帮他们省出每一个字节，每一次请求。比如像道具属性会有很多文字说明，这些说明应该以类似XML文件的方式储存为静态文件，后端返回给前端的道具数据包里只需要一串物品ID,前端就可以根据这些物品ID在XML文件里查询出这些道具对应的静态物品属性了。别看这些数据可能只有十几K，对后端来说意义重大。还是那句话，只要不是架构性问题，前端不要怕麻烦，要尽量配合后端提高性能。

    2，前端后端要有很明显的BUG分界点。当一个BUG出现时，后端应当很快的用一种统一的方案证明数据没有问题！这个方案必须让前端知道，并让前端也可以操作。大家熟知的php remoting里有一个servicebrowser，这个东西就很好，它能罗列出所有PHP的接口，我们输入参数，它就返回结果，我们可以根据结果直接查看数据是否正确。——确定数据的正确性，对前端DEBUG非常重要，而一个BUG的解决，一般都是由前端人员入手并进行定位的。

    →其实相对于前端和美术的合作，前端与后端的合作还是简单清晰的，前后端在开发的过程中，应该是非常独立的，后端开发完全可以先启动，把数据接口提前写好，等着与前端整合，而当整合过程发生问题时，又可以很快的界定是谁的问题。

    ★公司文化与产品定位
    →前面谈了那么多，无论是策划、美术、前端还是后端，大家通力合作，共同奋斗的目标无非就是希望开发出来一个好产品，而开发出一个好产品的目标无非就是成就一个好公司，这就涉及到“产品定位”与“公司文化”的问题，公司文化和产品定位没做好，其它人再努力都是枉然。可正是这两个问题，从我们公司成立到现在一直困扰着我，我抓破脑袋苦思冥想，总结出我们公司的公司文化就是“老板说了算”，而我们的产品文化就是“与时俱进，不断重新定位”。下面我先谈公司文化再谈产品文化，因为产品文化是包含在公司文化中的。

    →公司文化：一个公司的文化在很大程度上是由初创团队建立的，而初创团队一般分两种，一种是权利分散型，初创团队在各个领域都有领头人，虽然也有形式上的CEO，但产品、研发、市场相互干涉的并不多，领导层内部“三权分立，民主平等”，对外发言人则可以统一由CEO代劳。这种模式的优点是大家优势互补，让懂行的人完全负责相关领域，负责人成就感大，责任心强。缺点是，权利分散就要求领导层必须非常团结，配合默契，如果他们之间出现矛盾，对公司影响会很大。我们的竞争对手淘米网络就是这种模式，到目前为止，他们公司发展的还是最好的。另外一种模式就是“老板专政”模式，专政到什么程度，跟老板对权利的欲望有关。我们公司老板就专政到事无巨细的程度了，就连买一个几百块钱的路由器都要再三跟老板请示，美术、策划、开发所有的日程安排、人事任用都要由老板点头。“专政模式”在创业初期也未必就是坏事，因为创业初期，困难重重，大家又都有自己的想法，每个人的信心都比较脆弱，如果没有一个强势的人主掌大事，所有人容易形成一盘散沙的尴尬局面。专政模式下，公司文化其实就是老板的个人文化。专政的人一定要有专政的资本，有专政的能力，掌握着公司最大的权利，就必须承担最大的责任。如果公司成功了，就算你再说成功是大家的，最大的成功者还是你，但如果公司失败了，就算你找一千个理由推脱责任，最大的失败者也是你！在这种情况下，专政者要努力提高自己的全面素质，公司管理、产品、开发、策划、美术、市场都必须有所了解，你的任何一个错误的决定都会把公司推向深渊，并引起相关部门人员的不满。我们公司就是典型，老板以前是做销售的，对策划、开发和美术，甚至是互联网都没什么概念，做海底世界前连QQ都没用过！虽然他在资历和财力方面当之无愧，但其短板也是无法否认的事实。初创很长一段时间内，他都敢拍板说一个社区一个AS一个月搞定之类的话，而且还要非常强势的让你接受，并拿出执行方案。至于他为什么敢这么坚决的做出这个错误的决定，我也不明白。可能正是因为他也不知道到底需要多长时间才能开发出来，而我们又没有取得他的信任吧，所以他就只能尽量往少的时间说，等到我们没完成工作，大不了再延长时间而已。可这对我们这些开发者就造成很大困扰了，这种根本不可能达成的目标如何拿出执行方案呢？开发规划如何做呢？最后开发不出来谁承担责任呢？于是一个怪圈形成了：老板不信任开发→制定不合理的开发目标→制定不合理的开发规划→开发规划没完成或者大打折扣→老板认为开发者能力不行更不信任开发→老板要求开发者提升自身能力满足他的要求→开发者依旧满足不了老板→老板在工作能力和员工素质上全面怀疑开着者→制定更加不合理的开发目标甚至是惩罚制度→项目更加完不成……额，这真是一个装满了苦水，倒又倒不出的杯具！当然，只要不是傻子，在这个悲剧的循环过程中，不管是老板还是开发者都会变得越来越“聪明”，老板一天天成熟了，程序员一天天世故了。只是曾经浪费的时间，错过的时机不再有，曾经不合理制度下积累的问题，明天需要继续补救！如果上天能给大家一次重来的机会，我相信，老板会说：“下次我一定要在项目刚开始就找一个靠谱的，值得信任的CTO！”，而程序员会说：“我下次再也不会跟着不懂技术还自以为是，横加干涉的老板了！”

    虽然“民主平等”和“高度专政”两种模式都有其优缺点，但最终玩的都是一个“人”字，相同项目，一个模式，不同的人玩出来的结果肯定不一样。同是专政模式，奥比岛就比海底世界成功。不过站在历史发展观上看两种模式的话，我个人更偏向于“民主平等”模式，这种模式下的公司领导层为了保证公司能长久健康发展，肯定会不得不想尽一切办法制定出平衡权利的法制规则，只要法制规则适应时代，领导层人事变动影响是可控的。而“专政模式”的专政者，为了保证其一手建立起来的商业帝国不至于在自己退位后轰然倒塌，肯定不得不想尽一切办法寻找接班人，帝国的命运系于接班人的选择。相对于“人治”，我觉得“法制”更靠谱。看到这里也许你又该搬出中国特色来反驳了，说什么中国的企业不合适。但纵观天下，历史的潮流是不可逆转的，中国作为历史发展的组成部分，脚步可以慢，但方向不会错。80后已经开始觉醒，90后会继续努力的。所以希望任何一个创业者在创业初期都认真的回答一个问题：你是只想做一个成功的企业家，还是想真正做一个成功的企业，让这个企业能长久发展，代代相传。一个成功的企业家的成功是个人的，而一个成功的企业的成功是大家的，是社会的！

    →产品文化：产品文化包含于公司文化，“民主平等”的公司，产品的文化就是“管理层相同价值观”的文化，而“高度专政”的公司，产品文化就是“老板个人”的文化。不管是什么类型的公司，什么产品文化，这个文化一定要简明而清晰，要深入人心，最好能浓缩成简单的一个词或者句子，“妈妈放心，孩子喜欢”就代表着淘米网络的产品文化。这个口号从淘米成立不久就已经开始喊了，到现在没有变过。我相信他们的用户，他们用户的家长，他们公司从管理层到员工每一个人，就连他们的竞争对手都对他们公司的价值观，对他们的产品文化有一个清晰的认识。而我们公司呢？反观我们公司，在这方面做的非常差，公司从成立到现在产品定位一直在变，刚开始要做一个针对初高中生和女孩子的休闲社区，搞了几个月后，又发现企鹅，一股脑的投入到儿童这块儿蓝海市场，说要做一个中国版的企鹅俱乐部，再后来可能觉得儿童市场有点小，收费比较困难了，又想把产品目标用户群再提高一下，提高到初高中生也能玩，游戏复杂度也要随之提高，这样还没做多长时间，又看到人家淘米推出赛尔号这种PK游戏了，又觉得纯绿色游戏的可玩性不高，对用户尤其是男孩子的吸引力不够，又要在我们的游戏里也加入PK和打怪了。直到现在，公司里上上下下，除了老板之外，没几个人能弄清公司的产品定位是什么，我们的产品文化是什么！这种情况导致一个很严重的问题，就是策划在策划游戏的时候，没有核心价值观，也就更没什么游戏世界观了，最终导致游戏形散神也散！

    游戏一直在改版，功能一直在开发，BUG一直都存在，性能一直上不去，目标用户群一直在改变，老用户一直在流失，我只能用一个词形容我的心情：痛心疾首！

    ★2010年：我的梦想扬帆起航
    →从毕业就一直在酷噜，一直做FLASH WEB GAME，当时的想法很简单，就是想体验一下顶尖的FLASH应用开发。转眼即将三年了，回眸探望，几多感慨，但终究还是能淡然处之。毕竟大家都不容易，大家都在摸索，也都在摸索中前进和成长，公司现在其实已经比刚开始好多了。

    →如今再打开4年前那篇《我的FLASH情结2006》，激扬的文字震撼我心。而现在的我，在海底世界的前端开发中已经找不到往日的激情，每日重复的机械劳动。而自己的理想，更是逐渐飘渺远去，一种温水煮青蛙的危机感油然而生。于是2010年，我向公司递交辞呈，结束我毕业后的第一份工作；再写一篇《我的FLASH情结2010》暂时结束FLASH WEB GAME开发。

    →那么2010年，我要做什么呢？没错，我要开始做自己的项目了。我们公司的一位在商场上混迹多年的大股东在年会上语重心长的对我说：“火山啊，你现在自己做项目有两个最大的问题，一是你没在大公司呆过，对一些正规的公司流程不了解；二是你原始资本积累还严重不足，很难支撑项目长久下去。”其实我自己又何尝不明白呢，我知道自己这次单干也是九死一生，但我实在等不了了，7年的技术积累，3年的工作积累，为的就是今天，我也是奔三的人了，都讲男人30而立，马上要面对结婚生孩子，上有老下有小的艰难局面，我再不趁机把握最后这两年相对轻松自由的机会，以后会更难。我的梦想可能很天真，但我会做的很认真。

    →其实冷静下来想想，也没什么好怕的，想当年我敢带着一千块钱闯上海，今天我就敢拿着几万块钱自己干，大不了折腾完了再到大公司打工深造呗。虽然我工作三年才积累了几万块钱这听上去有点寒，虽然我每个月最多只能给自己播出1000块钱的创业资本这听上去有点少，虽然我自己得把策划、开发、美术和运营全做了这听上去有点假，虽然现在我还天天穿着高中和从亲戚那里捡来的衣服这看上去有点苦，但这都是外人看我的观点，我自己是乐在其中，浑然不觉，哈哈。不管怎么样，2010年，我的梦想必须扬帆起航，不以成败论英雄，只为人生少留遗憾！

    →完

    猫推拼盘
    Tencent ISD Flash Team

    Flash Player 10.1 beta3 大幅性能提升

    最近的Flash Player 10.1 beta3有了大幅的性能提升，相对目前的10正式版测试结果会怎么样呢？
    左边的为最新的10正式版，右边为10.1 beta3版本，测试平台为XP。

     pref

    可以看到细节，12个测试项都是一边倒的有了提升，最明显的是字符串拼接的速度，如果针对这个版本开发，字符串的拼接性能几乎可以不考虑了。同时VM的版本也从1.0提升到了1.4。

    有兴趣的可以在这里测试和对比一下，同时提供JS测试版本 : http://www.cbmland.com/perf/TestRunner.html，可以测试浏览器的脚本性能。

    附上beta3下载地址

    下载:Adobe Flash Player 10.1.51.95 Beta 3 for (Internet Explorer) (1.87 MB)
    下载:Adobe Flash Player 10.1.51.95 Beta 3 for (Firefox, Safari, Opera) (1.84 MB)
    下载:Adobe Flash Player 10.1.51.95 Beta 3 for Linux (3.86 MB)
    下载:Adobe Flash Player 10.1.51.95 Beta 3 for Mac OS X (1.87 MB)

    7yue的博客 - 中国FLASH传教士

    必须推荐的文章：诠释Flash的职业发展道路

    最近一段我真是好运，连续遇到能够打动读者的文章，前者就是火山写的《我的FLASH情结2010——浅谈FLASH WEB GAME与创业》，当我还没有完全从这边充满诚意与分享精神的文章中回过神来的时候，来自Tencent的Flash骨灰级的老友Demon.S又写了一篇文章：《诠释Flash的职业发展道路》，该文清晰的阐释了作为一名Flash开发者或设计者，如何更清晰的看到自己的Career Path，其中也不乏作者本身的切身体会与经验分享。

    这些文章才是我们Flash从业者最需要的养分，希望我们以后的开发者社区能出现越来越多这样的好文。让那些天天愤怒的对吐口水的烂文见鬼去吧。
    2010-02-25
    Jinni's Blog.

    Happy Birthday to Adobe AIR!

    今天(2月25日)是Adobe AIR发布两周年纪念日，Happy Birthday!

    I'm Emment

    javascript中实现命名空间

    javascript本身不支持命名空间，但是我们可以模拟它
    例如，要创建一个名为 arc90.components 命名空间，我们首先定义一个空对象arc90：

    arc90 = {}


    如果叫做arc90的对象已经存在，我们需要先检查一下，然后创建一个空对象：
    Jinni's Blog.

    Flash Player 10.1在Android上是耗电大户？

    Flash Player 10.1在Android上的出色性能让某些别有用心的无聊人士大跌眼镜之后，这些人又开始想办法攻击Flash Player对设备电池的消耗问题了。这倒也合乎常理，这个世界上没有完美的技术，性能上去了，功耗也自然不小，那么Flash Player会成为Android手机上的耗电大户吗？Adobe的Mark Doherty做了一系列实验，简单来说结论：使用Flash Player 10.1在Google N1上通过WiFi联网观看H264视频可以持续3个小时以上。而且这其中WiFi对电池的消耗比例要远远大于Flash Player。

    Adobe Connect Pro Mobile可以从App Store下载了

    Adobe Connect Pro Mobile是一款Flash应用程序，也是第一款由Adobe官方开发的使用Flash Packager for iPhone的应用程序。现在已经可以从App Store中免费下载了。主要特性包括通过VoIP参加电话会议，即时聊天，接收远程屏幕共享，文档和摄像头视频等。

    视频演示：

    更多信息，请访问Adobe Connect Pro用户社区。

    7yue的博客 - 中国FLASH传教士

    Flash Player 10.1 Beta 3


    Adobe昨日在Labs上推出了Flash Player 10.1 Beta 3，仅仅一天时间，来自开发者的表扬就充溢了整个欧美的大型Flash社区，其直接原因是对于10.1 Beta3这个版本所改进的大量工作有了共同的认可，那么让我们来看看这些社区在对Flash Player 10.1 Beta 3的赞扬背后，Beta 3到底改进了什么东西。

    经过欧美社区里参与Flash Player 10.1测试的开发者和10.1团队的工程师验证，10.1 Beta 3 修正了400多个bugs，同时在Player内部机制上做了大量的重新架构工作（比如重绘渲染切片模型，idle模式等，节省电池寿命，内存管理有效性等）。同时，Beta 3的目标使得10.1向最终的目标进一步前进，支持17个操作系统，15个浏览器，15中语言支持，5个GPU生产厂商的驱动支持。另外，10.1 Beta3在功能方面已经相当完善，目前加入了强劲的功能。

    我们在10.1 Beta 3里已经实现了对于6家全球生产GPU的厂商的GPU驱动支持，包括NVidia（Ion和其他桌面GPU类型），AMD，Broadcom Link and Flea以及Intel GMA 500和G45, TI OMAP(Img Tech GPU on DRoid)，Qualcomm snapdragon(Nexus one的芯片组），目前10.1 B3已经可以通过这些GPU实现Video视频的硬件加速，对于硬件图形加速还仍然在紧张的开发工作中。10.1 Beta3里还实现了内存控制(Memory Limits，主要是防止一些滥用assets资源的SWF内容可能造成的播放器挂起和崩溃现象)。还加入了基于浏览模型的增强模式，这个增强模式能够有效的使Flash内容在后台或睡眠模式下使用最小资源保持应用状态，有效的节省移动设备资源和电池电量。此外，10.1里面还加入了DRM，对于MAC OSX系统的Safari浏览器，也有对应的性能提升。

    好了，如果你对Flash Player 10.1充满期待，那么就先尝鲜Beta3吧！
    http://labs.adobe.com/technologies/flashplayer10/
    更值得高兴的是，Beta3也有Debug Version给开发者使用了！

    FP10.1Beta3里有2个类包，希望广大Flash开发者能多关注一下。
    flash.globalization.*
    http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/index.html?flash/globalization/package-detail.html&flash/globalization/class-list.html
    flash.sensors.*
    http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/flash/sensors/package-detail.html
    2010-02-24
    Tencent ISD Flash Team

    诠释Flash的职业发展道路

    作为极少数的还活着的纯flash枯骨之一， 在经历了从mm到adobe，从as1到as3，从当年flash等同于动画的代名词，到当今的flash程序员大批的崛起的时代，一直想抽时间写一个职业发展总结来给新学习flash的，以及对于flash职业很模糊的同学同事同乡同人类们分享下这方面的心得，让大家少走一些弯路，能重新认识下flash技术和flash行业。

    首先，我是一个幸运的flash开发者，我所在的公司一直都把flash作为公司最主要的技术之一，所以我有机会从很早的时候就一直深入接触flash和相关技术并从事as开发职位以及相关职位的招聘。不过这在5，6年前来说，是很难找到这种公司的，那时中国市场依然普遍对flash不感冒，但是随着flash的普及以及flash游戏和网站项目的市场进化和发展，flash程序员现在有了很好的契机，很多新公司都有对flash人才重视起来，各种职位层出不穷，让热爱flash技术的人们有了很多更适合自己的选择。

    那么如何区分用人单位招你过去是否偏重于flash技术呢？很简单，从职位title的名字可以过滤多数，如UI Designer（UI设计师），网站设计师（很含糊的一个职位），软件工程师等。 这些职位描述多数也都包含flash，但却很少使用到flash，多数是让你作为一个技术备份，如果选择这类职位，将直接让你走出flash行业。

    那么让我们看看正规的flash行业内的圈子是怎样的：

    ＃注：上图从左至右依次表明了flash职位的发展道路， 从上至下表明了从设计师到程序员的偏重度。

    在flash行业内

    第一阶段：

    当你刚学习flash时，无论你是作为设计师还是之前从事别的程序的程序员，都是一片空白，所以都在一个模糊混沌的起点，这个阶段统称为flash newbie（新手） 阶段，在这个阶段内，你会根据你自己的喜好，选择适合自己的技术，如设计师会偏重动画，motion graphics以及手绘，程序员会偏重as，网站编程和视觉特效，设计和程序都会一些的人学的就比较杂，各方面的技术都会搞一些，在第一阶段内我推荐尽量让自己多学习一些各方面flash技术，多发掘自己的综合潜力，这对你后面在职位选择时就多一些范围。

    第二阶段：

    随着你对flash的逐步深入，你会发现自己的特长会被凸显，这时会有一些职位适合你入行

    Flash Designer（设计师）， 这个职位在以前很常见，是美工专职做flash的一个特殊职位，会一些简单的as，并且会画动画，做一些motion graphics，同时也会做一些平面设计。

    NewMedia Developer（新媒体开发者），新媒体开发者的概念是公司需要综合能力的人才，需要会as，但不需要特别强，也要会做一些动画，拼装素材以及会写简单的js，通常是flash网站项目的公司多一些这类职位。

    Actionscript Programmer（纯as开发），纯as开发者多见于程序员出身的背景，这两年比较多的java和javascript前端开发者加入了flash阵营，这个职位的个性就更加明显：完全不需要管界面，甚至有不会用flash ide的人，使用flex以及第三方编辑器直接运行flash项目，但这类人群对flash的综合技术认知不够，还需要时间深入了解flash，不能完全用java和js的想法开发flash项目，这个阶段的as开发者，暂时还没有显著的职业特性来区分。

    第三阶段：

    慢慢的，随着经验的积累和对flash的了解深入，和公司项目需要，已经慢慢走出了flash的范畴，出现了三个更明显的职位：

    Interactive Designer（互动设计师），这个职位是因为设计师随着个人发展的喜好以及对于程序的了解深入而有的一个职位，广告公司这种职位多一些，除了会设计外，还需要你写一些程序，但偏向前端表现，如粒子特效和tween动画。这类职位并非一般意义上的交互设计师。

    Interactive Programmer （互动程序员），这个职位和上面的职位很类似，但是偏重点偏程序多一些，但平时的工作也会做一些动画，但可能是video（aftereffect），有时也会涉及到director lingo编程和网页js和flash小游戏，这个职位其实很累，需要会很多的技术，但是通常职业选择面会广一些。

    Game Programmer （游戏程序员），这个职位就在08年之前都很少见，而且是纯flash游戏开发，但这两年就随着sns游戏的普及以及webgame的投资增多就很抢手，导致现在看flash简历基本都说自己会写游戏。这个职位的基本需求其实很多人没有搞清楚，下面我略微详细的说下以便大家能多补充下知识。 首先你要热爱游戏，如果你不爱玩游戏那么你也开发不出什么好体验的游戏。技术方面还要会很综合的各种游戏算法，如A*,各种排序，数据结构，地图技术以及需要你对性能优化有一定的经验，如知道矢量图和位图在flash中运行时的差异，地图的按需加载，如何写程序才更有效率（苛刻到毫秒级微秒级）等，并且需要一定的设计模式知识，如果是3d项目，还需要有一定的3d知识，还需要对客户端服务器端传输有一定的优化经验，客户端安全性，防外挂以及协议安全等，如果是海量服务还需要针对流量优化。 所以想要成为一个真正的flash游戏程序员，你背负着n多需要挑战的使命（不归路？），但如果你有一颗热爱游戏的心，上面所列的各种技术都会迎刃而解，会慢慢兴趣式的攻破，所以这也是为什么我把热爱游戏放到首要条件之一。

    就这样慢慢走出了flash……

    进入到了第四阶段，也是你flash职业生涯的黄金时段

    这时因为你在flash之路所接触到的经验，已经不在拘泥于flash了，但仍然以flash项目为主。当然如果你选择了转行，就不是本文所谈论的范畴了。

    黄金阶段里面所出现的几个职位是这样的：

    交互设计后，通常其实直接进入到了art director/newmedia director，但本文没有画出这两个职位。这里是一个发展瓶颈，交互设计师、程序员走到了这里已经在业界有了一定的资历和名气，也就自然走出了flash，万精油类型的发展适合开一些studio和广告公司合作，做单子或在一个大一些的公司做director走管理路线长期发展。

    如果对管理路线不感冒，下面还有更深入的”职位“，这些职位可能你在市场上看不到，但能进入到此，你也是能独当一面的超级flash人才了：

    3D Programmer，这个职位现在还不多，但是随着硬件以及flash技术的发展，这个职位也许在未来会火起来，也是游戏开发者的一个比较好的进阶选择，偏重于图形学和前端表现多一些。

    Architecture，构架师，随着经验的积累以及对设计模式等框架技术的深入发掘，一个flash开发者最终会把自己定位成构架师，框架设计师，通常有一些企业型项目需要这类人才来建造项目框架，学过java的人很容易的走进这里，相当于在flash之路中仅仅是个过路人。

    Evangelist，flash传教士，这个其实不算一个真正意义的职位，是一类人群，早期是积极推广flash技术，并有影响力的一批外国人，如flashguru，gskinner等。这类人群的技术其实很全面，前后端技术都会懂一些，但深浅不一，对flash技术也很痴迷，能够对业界产生影响。这类人群在中国现在依然比较少，希望多一些技术全面的中国flash开发者能发扬此类精神弘扬flash文化。

    说了这么多，也许有人会问，楼主是哪类人呢？

    其实我的路非常曲折，在上图中窜梭不同职位多次，否则也很难有这么多感慨，呵呵。

    最后，希望此文能对热爱flash的你有帮助，祝你们在flash的职业生涯中一帆风顺。

    亲爱的Adobe，很有压力，才有推力

    亲爱的Adobe，最近应该感受到了某些方面的压力了，产品长期积累的未能解决的问题，终于有了一次小的爆发。

    被不断发现安全漏洞、Flash被HTML5挑战、Flash Player被Apple以种种借口拒绝进入iPhone OS。

    其实除了这些，使用Adobe各种软件产品设计师、开发者，都希望能提供更稳定的，更安全的软件平台。

    如今就有一个亲爱的Adobe网站， http://dearadobe.com ，上面有Adobe的各种软件在使用过程中发起的牢骚和抱怨。

    随便摘录几句话关于Flash、Reader的吧：

    • Please improve Flash Player performance on OS X #672
    • Please make a Flash plugin for Linux that doesn't suck. #226
    • flash for iphone,now. #91
    • Have an auto-save function in the Flash IDE! #4265
    • Flash Player needs to perform the same on Mac as it does on Windows. Crazy idea, right? #857
    • Please make a version of Reader that just views PDFs and doesn't require a 200MB install and 20 second launch. #1601
    • Please make a lightweight version of the pdf reader #668

    这下有对Adobe有抱怨有建议的有个专业点的地方去发泄一下了。

    而且，Adobe确实也在关注这里的问题，Adobe的回复在blog.dearadobe.com有整理。

    使用Twitter的朋友可以有兴趣可以追随这个地址 http://twitter.com/dearadobe（需翻墙）。

    兽的地盘

    【原创】flex控制flash元件

    最近跟后台研究的hessian协议，通信技术和接口已经基本差不多了，开始转战与前台的合作。

    前台做的flash元件要能比较方便的在flex里使用，我的思路大致是这样的。比较“死”的东西做成图片，具有一些方法，相对比较活跃的组件做成.swf，然后在flex里用as3来控制，这样比较方便也比较容易变化和修改。

     

    首先flash里制作元件，属性啊方法啊这些名字要沟通好。

     

    在flex里有两种使用方法：

    第一种方法是用as3直接使用，通过loader加载.swf，然后显示到程序中。这里有个小技巧，flash做的东西直接addchild到flex的容器里是会出现强制类型转换的，不过有一个例外，就是UIComponent，道理可以参看flex类图的继承关系。

     

    第二种方法是用SWFLoader加载,如果组件比较少我倾向于这种，因为比较懒，也比较容易布局。。。

     

    demo我只做了个控制属性，方法同样是没问题的哈，上代码：

    <?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationPolicy="all" creationComplete="init()">
	<mx:Script>
		<![CDATA[
		import mx.core.UIComponent;
			private var swfurl:String="我的现金.swf";
			//创建Loader类的实例
			private var context:LoaderContext=new LoaderContext();
			private var loader:Loader=new Loader(); 
			private var myUI:UIComponent = new UIComponent();
			private var something:Object;
			private function init():void
			{
				this.addChild(myUI);
				context.applicationDomain=ApplicationDomain.currentDomain;
				//加载外部的swf库 loader.load()的第2个参数 用来确定是否能使用加载的SWF中的库
				loader.load(new URLRequest(swfurl), context);
				loader.contentLoaderInfo.addEventListener(Event.COMPLETE, onComplete);
			}
			private function onComplete(e:Event):void
			{
				trace(loader);
				something = loader.content;
				something.myCash.text = 3000;
				myUI.x = 300;
				myUI.y = 300;
				myUI.addChild(loader);
			}
			private function cc():void
			{
				var ss:Object = mm.content;
				ss.myCash.text =50000;
			}
			private function addMoney():void
			{
				var ss:Object = mm.content;
				ss.myCash.text = int(ss.myCash.text) + 10000;
			}
		]]>
	</mx:Script>
	<mx:SWFLoader id="mm" source="我的现金.swf" creationComplete="cc()">
		
	</mx:SWFLoader>
	<mx:Button x="273" y="10" label="+10000" click="addMoney()"/>
</mx:Application>

     

     更进一步，可以由flash提供一个类库，里面可以有多个元件，来重复使用资源：

    <?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
				creationComplete="init()"
				layout="absolute">
	<mx:Script>
		<![CDATA[
			import mx.core.UIComponent;
			import flash.display.Loader;
			import flash.display.Sprite;
			import flash.net.URLRequest;
			import flash.events.Event;
			//
			import flash.system.ApplicationDomain;
			import flash.utils.getDefinitionByName;
			import flash.display.MovieClip;
			import flash.system.LoaderContext;
			/**
			 * ...
			 * @author 齐齐兽
			 * QQ：649723623
			 *
			 * 实现库的重复利用
			 */
			//库资源的地址
			private var myUI:UIComponent = new UIComponent();
			private var swfurl:String="element.swf";
			//创建Loader类的实例
			private var context:LoaderContext=new LoaderContext();

			private var loader:Loader=new Loader(); 

			public function init():void
			{
				//指定为当期域
				this.addChild(myUI);
				context.applicationDomain=ApplicationDomain.currentDomain;
				//加载外部的swf库 loader.load()的第2个参数 用来确定是否能使用加载的SWF中的库
				loader.load(new URLRequest(swfurl), context);
				loader.contentLoaderInfo.addEventListener(Event.COMPLETE, onComplete);
			}

			private function onComplete(e:Event):void
			{
				//得到类定义    MCExample  aaaa
				var className:Class=ApplicationDomain.currentDomain.getDefinition("aaaa") as Class;
				//从库中导出资源    
				var mc:MovieClip=new className();
				//放到场景中间
				mc.x=275;
				mc.y=200;
				//添加到显示列表
				myUI.addChild(mc);
			}
		]]>
	</mx:Script>
</mx:Application>

     附件是第一个Demo的flash元件，放在src目录下即可





    已有 0 人发表留言，猛击->>这里<<-参与讨论


    JavaEye推荐



    Jinni's Blog.

    Google Nexus One上的Flash 3D演示

    一起来看看效果如何：

    另外附上FarmVille on N1的Demo:

    Google N1 Rocks!!

    小S吧 sunbright博客

    一道AS3面试题的解答

    最近在网上看到一个AS3面试题，感兴趣写了个答案，当然标不标准我就不知道了~
    题目：对一批编号为1-100全部开关朝上（开）的灯进行以下操作：
    开关编号凡是1的倍数反方向拨一次开关；若该编号也是2的倍数反方向又拨一次开关；若该编号又是3的倍数反方向又拨一次开关……以此类推一直计算到100为止。
    目的：请trace出经过反复开关操作后所有关闭的灯的开关编号。
    这是我写给大家看的易懂版本：
    var n:int, m:int;
    var range:int = 100;
    for(var i:int = 1; i <= range; i ++){
      n = 1;
      while(true){
        if(n > i / n){
          break;
        }
        if(i % n == 0){
          if(i / n == n){
            trace("结果",i);
            break;
          }
        }
        n ++;
      }
    }
    下面是写着玩的缩写版本，不过正常写项目代码，我不会这样干的，在这儿只是娱乐一下而以
    下面这段代码想玩就看看，不想玩的看上面就行了，判断原理是一样，没区别！
    var n:int = 1, range:int = 1000;
    for(var i:int = 1; i <= range; i += n = 1){
      while(n > 0) n = n > i / n ? 0 : !(i % n) ? i / n == n ? -1 : n + 1 : n + 1;
      if(n == -1) trace("结果",i);
    }
    我将range都改成100000后，
    第一种方法耗时7233毫秒
    第二种缩减的写法耗时1840毫秒
    对于易读易懂，你会选择那中方法呢？

    对于暗泪同学的回复，下面增加一点内容：
    其实上面写的是正常算法，如果2亿次，通过分析题目，可以得出只要该数能被开平方时，就是关闭状态
    因此这道题目如果是写在项目里面，可以这样写：
    var range:int = 1000000000;
    var num:int = Math.pow(range,0.5);
    for(var i:int = 1; i <= num; i ++){
      trace("结果",i * i)
    }
    我测试过10亿次的效率，仅需要6毫秒~何其快啊！