人人农场经验总结2003文档.pptVIP

我们开发游戏时经常会遇到这样的情况： 当flash画面中同时出现多个动画在播放时，画面就会变得很卡，鼠标的操作也变得很不连贯，特别是矢量图做的动画很轻易的就使cpu占满。这样就给用户体验带来了不好的影响。一般我们想到、采取的做法就是减少动画数量、降低动画品质，或者干脆停止动画。这样虽然可以起到一定的效果，但是治标不治本，游戏的观赏性大打折扣，很多好的设想没法实现，实在是一种遗憾。 (详见demo_大量子显示对象) 因此，优化flash画面渲染势在必行。 显示列表的淘汰机制 由于flash虚拟机的显示渲染效率比较低，一般游戏90%的性能消耗都用在了动画渲染上，因此如果我们集中主要力量去优化显示，就能获得较好的程序流畅度。 一般来说，同一时间处在显示列表中的动画越多，cpu资源消耗就越大，当我们在做一个比较大的场景的时候，肯定有很多显示对象是处在屏幕外的，虽然在屏幕外，但是flash player并不像我们想象当中的那么聪明，不对其进行处理。那么当场景很大的时候，程序就会变得很卡，因为有很多看不见的动画在消耗着cpu资源。 优化原理：计算出当前可见的对象，及时从显示列表中移除当前看不见的对象，只显示需要显示的，这样就可以让player减少很多不必要的计算量。(详见demo_淘汰机制) 显示列表的淘汰机制 显示对象仅仅移出显示列表确实达到了一定的效果，但是这些存在于内存中的对象仍然在运行，它们身上的事件侦听、脚本、动画的播放都在悄悄消耗着cpu资源。 当我们确定一个显示对象，比如MovieClip已经处于淘汰列表时，不光要将它移出显示列表，还要调用它的stop()方法让它处于停止状态，如果它对EnterFrame进行了侦听，而且侦听处理函数很复杂的话，一定要暂时移除这个事件侦听。因为即使stop了，仍然会发出EnterFrame事件。(详见demo_淘汰机制加强版) 显示列表的淘汰机制 小结： 移除不可见对象，只显示当前可见对象。 停止显示列表外显示对象的动画，移除EnterFrame等仍然会触发的事件侦听器。 显示对象的位图缓存 矢量图和位图优劣比较： 矢量图 矢量图体积较小，可以进行任意的放大和缩小仍能保持其画面品质而不出现锯齿、变模糊或粗糙。 但是矢量图的呈现是完全通过cpu计算得出的，因此大量的矢量动画对cpu消耗比较大。 显示对象的位图缓存 位图 位图是flash中渲染速度最快的对象类型，一般的机器至少可以支持超过1000个50*50的位图动画同时在舞台上播放。(详见demo_位图缓存_多显示对象) 但是位图体积较大，大量使用会大幅增加flash文件体积。并且缩放之后会产生锯齿，虽然可以对其设置smooth属性避免，但是这样会增加cpu占用。 显示对象的位图缓存 巧用位图(Bitmap) Bitmap对象是flash中渲染速度最快的，同时它还有一个特点是多个Bitmap实例可以共用同一个BitmapData对象，在这种情况下，多个Bitmap实例和单个Bitmap实例所占用的内存相差无几。 综合以上特性，我们可以使用Bitmap将矢量图动画缓存为位图动画，多个相同的对象共用同一份BitmapData数据，这样既可以大幅降低cpu占用，又可以节省内存，同时还避免了直接在库里面使用图片而造成flash文件变大的问题。(详见demo_淘汰机制+位图缓存) 显示对象的位图缓存 小结优化原理： 预先渲染好要播放的动画，将渲染结果缓存到内存中，需要用时直接从内存中获取交给flash去渲染，减少大量的重复计算。本质上就是以空间换时间的一种应用方式。 显示容器的鼠标优化 当一个Sprite里面包含了成百上千个子显示对象时，会出现的问题是当鼠标在上面划过时cpu占用率很高。这是因为flash player会遍历这个容器中的所有对象以检查是否和鼠标重合，以便发出MouseMove、Roll_Over、Roll_Out这类事件，这类计算需要消耗较多的资源，当子对象很多，特别是子对象内部也有很复杂的层级关系时计算的次数就会成倍增加，而且鼠标每移动一点都会进行一次这样的大量计算，造成程序运行缓慢。 (详见demo_大量子显示对象) 显示容器的鼠标优化 禁用子对象很多的显示容器的鼠标事件 当遇到这种情况时，将容器的MouseChildren和MouseEnabled属性设置为false，这样flash player就不会对其子对象、孙对象进行鼠标检测计算，鼠标在上面移动时cpu没有再出现大幅波动的情况。 但是带来的问题是这样就不能获得子对象的鼠标事件。替代办法是在需要的时候使用getObjectsUnderPoint()方法获取一个数组，返回目前处于鼠标