关于“流”式播放及优化技术

这部分绝对地重要：Flash做的网页固然漂亮，但漂亮是有代价的，就是大大的文件。在现有的网络速度下，MecroMedia的两种解决办法是：Preloader和“流”式播放。关于前者请参看---Preloader的两种情况。后者是本文的主题，以下我就从技术文档及自己实践做一说明。

>>> 技术文档解释 <<<

>> 数据流如何工作 <<
这是一个和Flash Player有关的术语，指的是从服务器流向客户机所要求的一股数据流。其移动的最快速度取决与最慢的网络速度（一般指28.8K以下Moden的传输率）。它和GIF及JPEG文件之间的区别在与，在Flash Player中这些数据是存储在一系列连续的Frame里的，只要一个Frame里的所有数据接收到后，便可以在不需要后续Frame里的数据到达之前就显示在客户机上。因此，这种播放是否流畅就取决于两个因素：每个Frame里数据大小和网络速度是否足够及稳定。

>> 数据流与播放指针的关系 <<
上面提到过，Flash Player只有在一个Frame 里的所有数据都接收到之后才播放，因此要想整个Movie能从头到尾都流畅，就必须考虑以下两个因素：
1。待播放的每个Frame里的数据必须尽量地小；
2。待播放的一系列Frames的下载时间不能长于他的播放时间。
所以，如果你的Movie第一的Frame里有较大量的数据（声音，中文，位图，矢量图等），则该访问者一开始就需要等待；如果以后的Frame大小也达不到要求时，那么Movie的播放指针就会在该处停下来等数据下载完成，播放将会断断续续，甚至无法忍受。

>> 用Flash生成的文件大小报告（Size Report）来优化你的Movie <<
想看看你的Movie每一Frame有多大吗？那么当你在输出Swf文件时，在对话框的上面有个Generate Site Report的选项，选定他，按OK。这样，一个和你的Movie同名的文本文件就会生成在同一个目录下。可以用记事本打开。
以下是一个样例Report中各个部分的解释：原来是有源程序的，但一时找不到，大家先大致了解一下，有个印象。应该不难理解。

Frame #    Frame Bytes    Total Bytes    Page
-------    -----------    -----------    ---------------
    1          1203           1203        Scene 1
    2             2           1205          2
    3             2           1207          3
    4            50           1257          4
    5             2           1259          5
    6            46           1305          6

我们注意到，第1个Frame大小为1K，这已足以满足来访者无须等待就可以看到；第2，第3个Frame则非常地小，因为他们所需的内容都在第1Frame里下载完了。第4Frame里的内容稍微变大了些，然而屏幕没有什么变化（这里是下面优化部分里介绍的“Preload”的概念）。到了第6Frame，里面的Symble开始发生变化（变形，移动等），但由于所需的图形还是前面已下载完的，因此这里只储存了变化要的信息指令，故不会太大。 

    7            46           1351          7
    8            46           1397          8
    9            45           1442          9
   10            45           1487          10
   11            45           1532          11
   12            45           1577          12

直到第12Frame，时间过去了1秒，我们总共需要1.5K的数据，这现有的网络速度下，是完全可以接受的。理论上，一只28.8K猫的传输率为3.6K。实际上网络在传输数据时，还要加上一些附加信息，如：目的地，传输量等。一般称这些数据为"packet overhead"或"network overhead"。因此，在传输率不变的情况下，这些附加信息就会降低你浏览速度。

   49          4907           9398          49

最后我们来到第49Frame，由于在这里有些新的Symble加了进来，所以体积变大了些。按源文件算来，此时总共需要9.4K的数据，大概到达时间要4秒钟，在最大理论传输率（3.6K）下，应该不会有迟延（3.6K*4=14.4K）。但如果网络的附加信息把该速率降到了1.8K或更低，及用14.4K猫的用户，此时就会有一个明显的停顿。
接下来的部分，则提供了更为详细的，组成本Movie的各个项目清单：

Page                       Shape Bytes    Text Bytes
-----------------------    -----------    ----------
Scene 1                        1256           616

这部分表示的是在Movie里的非Symble的项目，如文本，Groups，及直接画在Canve（即主Scene）上的东西的空间占用情况。

Symbol                     Shape Bytes    Text Bytes
-----------------------    -----------    ----------
child and hat                   375             0
curtain                         124             0
speaker                         593             0
speaker button                   40             0
text blend                      758             0
theatre seat                    121             0
traced child                   3163             0


这部分则包含了输出Movie里的所有Symble的存储情况。有一点须记住：同一个Symble在Movie里是可以反复使用而不会带来太大的体积变化的。

Bitmap                     Compressed  Original    Compression
-----------------------    ----------  ----------  ------------
child with hat                  1963      230384   JPEG Quality=1

从外面Import进来的位图文件，经过压缩之后，在最终输出的Swf文件里将小很多。这部分就是显示了经过压缩的存储情况。由于体积大小和图象品质成反比，所以，你应该通过这部分来寻求二者的平衡点。

Event sounds: 11KHz Stereo 4 bit ADPCM

Sound Name                 Bytes       Format
-----------------------    --------    --------
pop                           289        11KHz Mono 4 bit ADPCM
Pboing1                      4124        11KHz Mono 4 bit ADPCM

采样速率和持续时间是影响Sound大小的两个很重要因素。这部分反映了Sound的采样率，压缩率及占用的空间情况。如果声音太大，应考虑减少其持续时间或降低品质。

Font Name                  Bytes       Characters
-----------------------    --------    -----------
Helvetica Bold               1977         '02AFHLSabcdefhiklmnoprstuwz

Flash只存储了字体的Outline（也是矢量处理的结果）。这部分反映了所用的文字及占用空间情况。

>> 优化技术 <<
在分析完Size Report之后，就可以针对性地做些优化措施了：
1。简单化在Flash里画的及从外部画图程序引进的元素。
在Modify菜单里的Curves的弹出子菜单里有三个选项：Smooth，Strength和Optimize。前两个会自动加重或光滑你所选定的图线（lines），最后一个选项允许你在量上控制加重和光滑操作，及是否对同一个选定元素进行反复光滑操作直到不能再优化为止（选定Use Multiple passes）。此举目的是将没有用的点及路径信息从存储中剔除掉，达到在屏幕上显示所需的最小要求。由于屏幕分辨率大大小于普通打印的分辨率，在整体显示时，一些微小细节往往会被忽略。
2。当重复同一元素时用Symble而不要用Groups
原因是：Symble只被存储一次，当再次被引用时并不会增加文件体积；而Groups在每次被引用时均会被存储。两者的优劣是显而易见的，使用Symble能很有效地减少Movie的体积。
3。当在某处有太多数据时，将Symble “Preload"
什么意思呢？上面提到过，FlashPlayer只有在一个Symble完全下载后才能显示。通过Movie的Size Report和Visual Inspector可以精确地定位究竟在那里需要下载大量的数据。如果你的Movie里有诸如上例中第2，3，5Frame那样没有太多数据需求，而在后面的Frame有较大的Symble要求下载时，可以将它们预先放在这几个Frame里下载（这里要注意，这些预下载的Symble所在的Layer必须隐藏在以上Frame中已有的图形后，即Layer编号较大。这样访问者就不会看到他们在下载了，因为Flash中对Layer的规定是：上层Layer里的内容均能覆盖住其下Layer里的所有内容。）。这一技术可以预先下载一些准备在以后Frame里用的Symble。
同时，你还可以“强迫”Flash Player在第一Frame里就把所有将用到的Symble一次全部下载完毕而不让访问者到他们在下载。但这一技术有个毛病：就是诸如声音等文件在Movie重播时，会产生停顿或延迟，一般是作者不太希望发生的。
另外一种Preload很常使用，就是利用Action里的GoTo Frame和If Frame is Loaded。这较好理解，我就不多说了，请参看有关文章或源程序。
4。避免在同一时间里占用太多的CPU资源
和基于光栅（位图）动画不同的是，基于矢量动画的Flash Movie在屏幕上显示之前都需要CPU对这些矢量图进行预计算。如：在一个Frame里有多个Symble发生Tweening；颜色Tweening；在不同Frame之间较大面积地改变区域及渐变填充都需要CPU进行进一步的深入计算，这样，你的Movie势必会变慢。
5。关于位图（Bitmap，不是矢量图Vector）
Flash提供两种对位图的压缩处理：JPEG和无损压缩（lossless）。默认为JPEG压缩。它的值从1（最大压缩绿，最低品质）到100（最小压缩率，最高品质）。由于该压缩会产生一定的图形数据丢失，因此你必须不断地测试以寻求一个较理想的平衡点。与之相反的是无损压缩，既位图将毫无改变地照样输出到最终Movie里。关于位图的第二点就是宁缺毋滥，将其用在刀刃上，较好的处理是用在背景里。第三点，避免位图的变化：位图不同于矢量图，每当其改变位置时Flash Player都必须重新计算并刷新屏幕，自然辉降低速度。第四点，打开Library，选定位图，然后从右边的弹出菜单里选择属性，在对话框里把选项Allow Smoothing去掉，这样可以保留原来位图的清晰度和精确度。
6。关于声音
这家伙可是占用资源的大户，千万慎用。最终输出的品质长度都会显著地影响其所需数据的多少。较高采样速率（25.5K或更高），虽然带来高品质的享受，却要付出访问者付出较多的货币代价。和位图压缩一样，Flash也提供了在这二者间寻求平衡点的机制。因此保持较短的声音和不断地测试是比较有效的办法。还有一点需注意的是，在声音属性框里的两个选项：Event synch（同步事件）和Stream synch（流传送同步）。前者是当播放到需要声音的Frame时才开始下载；后者则是按流的方式一步一步地下载播放。因此只要我们仔细检查Size Report后，找到发生”阻塞“的Keyframe，然后利用上面提到过的Preload技术来削平这些“山峰”。
7。关于字体
说到这里，真的是感触良多，这套软件似乎对中国人不太友好，对汉字的处理可谓糟糕极了，Flash 4也没有太多改进（这也是本站一直没用太多汉字的原因）。
Flash只存储了特殊字体的轮廓，这项技术允许你使用自定义字体而没有必要在其他画图程序里将其转化为轮廓或在Flash里将其打散（Break Apart）。因此使用字体时应注意两点：第一，被打散的或从外部图画程序以轮廓形式引进的字体，在每次被重复显示时，都会增加整个文件的体积，所以保留字体原封不动是个不错的选择；第二，不要使用太多的字体，2到3种为宜。

好了，说了这么多，您是否有些茫茫然呢？其实这里关键还是亲自实践体会才是最好的理解方法。你可以去下载一些专业人员设计的Swf文件，打开后再输出，详细查看他的Size Report，再和自己的比较一下。你很快就会明白其含义了。