优酷FLASH视频流播放技术（较早）

视频流的存储位置：

在不同的区域架设有不同的视频流服务器或者做了CDN，所以当你在广东上网将就其在广东省的服务器读取视频流，在北京的时候则从北京服务器读取视频流。

视频文件分块存储：

比如用户上传了一个30分钟时长的视频，优酷会把他分割成几段（每段可能7分钟左右）并在数据库建立起相应的索引，优酷可能把它叫做playlist吧。当用户实际播放的时候，由FLASH首先自动获取flashlist再按顺序去播放单一的FLV文件。

视频文件的防盗：

优酷通过检测HTTP头的Rerfer字段来半段是否为合法请求。当然由于FLASH在FF下播放FLV文件时并不会发送RERFER头，优酷可能是考虑到了FF用户，姑当Rerfer未设置的时候也能成为合法请求。

前端优化之缓存碎片技术

众所周知网页加载慢的很大因素是在于带宽的瓶颈,尤其是当富媒体技术(flash,js)的出现，随着客户体验的提高，带宽也就有了一定的瓶颈。
这里讲述一种相应的解决方案。很多时候一个flash文件相当的庞大，导致了，页面很慢，一般可能会采取proxy的方式，先展现一个进度条之类的，虽然这个比空白要好很多，但是如果能直接先运行，再在其中每个事件中触发，下载相应的代码块，这种客户体验可能是更好的。
技术方案比较简单，就是把一个大的swf根据模块，区分出来若干的小的模块，用loadmovie这样的函数，加载小的模块，这样整体运行就非常流畅，不会因为其中某一个swf文件过大而导致了，加载过慢的现象。这种技术也常见于javascript技术，经检测，加载速度提高5-10倍。

flash压缩　
　　1、尽量减少文字的叙述。
　　2、应尽量把图画转为“电影剪辑”或“图形”。
　　3、导入的图片格式最好是*.jpg或*.gif格式
　　4、导入音乐文件，最好是*.MP3
　　5、导入音乐后，在它的属性设置里去掉“使用文件默认品质”，然后，在它的品质设置如下：“压缩”选择MP3；“位比率”选择16Kbps；“品质”选择快速。如此设置之后，3MB的MP3输出后不足500KB，音质只有少量的损失。
　　6、如果非特殊需要，就不要把图片“打碎”，应该尽量在图片帧中进行。
　　7、不要在同一帧放置过多的“电影剪辑”，否则可能使你的*.SFW成倍增肥。 
　　8、发布设置中设置jpg压缩比率，控制文件大小
　　9、采用软件进行文件大小的压缩
·如何优化Flash电影
　　1．多使用符号（Symbol）。如果电影中的元素有使用一次以上者，则应考虑将其转换为符号。重复使用符号并不会使电影文件明显增大，因为电影文件只需储存一次符号的图形数据。
　　2．尽量使用渐变动画。只要有可能，应尽量以“移动渐变”（Create Motion Tween）的方式产生动画效果，而少使用“逐帧渐变”（Frame－By－Frame）的方式产生动画。关键帧使用得越多，电影文件就会越大。
　　3．多采用实线，少用虚线。限制特殊线条类型如短划线、虚线、波浪线等的数量。由于实线的线条构图最简单，因此使用实线将使文件更小。
　　4．多用矢量图形，少用位图图像。矢量图可以任意缩放而不影响Flash的画质，位图图像一般只作为静态元素或背景图，Flash并不擅长处理位图图像的动作，应避免位图图像元素的动画。
　　5．多用构图简单的矢量图形。矢量图形越复杂，CPU运算起来就越费力。可使用菜单命令Modify （修改）/Curves（曲线）/Optimize（优化），将矢量图形中不必要的线条删除，从而减小文件。
　　6．导入的位图图像文件尽可能小一点，并以JPEG方式压缩。
　　7．音效文件最好以MP3方式压缩。MP3是使声音最小化的格式，应尽量使用。
　　8．限制字体和字体样式的数量。尽量不要使用太多不同的字体，使用的字体越多，电影文件就越大。尽可能使用Flash内定的字体。
　　9．不要包含所有字体外形。如果包含文本域，则应考虑在Text Field Properties（文本域属性）对话框中选中Include Only Specified Font Outlines（只包括指定字体外形），而不要选择Include All Font Outlines （包括所有字体外形）。
　　10．尽量不要将字体打散（菜单命令为Modify / Break Apart）。字体打散后就变成图形了，这样会使文件增大。
　　11．尽量少使用过渡填充颜色。使用过渡填充颜色填充一个区域比使用纯色填充区域要多占50字节左右。
　　12．尽量缩小动作区域。限制每个关键? 发生变化的区域，一般应使动作发生在尽可能小的区域内。
　　13．尽量避免在同一时间内安排多个对象同时产生动作。有动作的对象也不要与其它静态对象安排在同一图层里。应该将有动作的对象安排在各自专属的图层内，以便加速Flash动画的处理过程。
　　14．用Load Movie命令减轻电影开始下载时的负担。若有必要，可以考虑将电影划分成多个子电影，然后再通过主电影里的Load Movie、Unload Movie命令随时调用、卸载子电影。
15．使用预先下载画面。如果有必要，可在电影一开始时加入预先下载画面（Preloader），以便后续电影画面能够平滑播放。较大的音效文件尤其需要预先下载。
　　16．电影的长宽尺寸越小越好。尺寸越小，电影文件就越小。可通过菜单命令Modify（修改）/Movie（电影），调节电影的长宽尺寸。
　　17．先制作小尺寸电影，然后再进行放大。为减小文件，可以考虑在Flash里将电影的尺寸设置小一些，然后导出迷你SWF电影。接着将菜单File（文件）/Publish Settings…（发布设置…）中HTML选项卡里的电影尺寸设置大一些，这样，在网页里就会呈现出尺寸较大的电影，而画质丝毫无损、依然优美。
　　在进行上述修改时，不要忘记随时测试电影的播放质量、下载情况和查看电影文件的大小。
·影响FLASH文件大小的部分因素（单位byte）
一个FLASH的最小尺寸：　　　　　　３０
输出时加保护：　　　　　　　　　　２
增加一个层：　　　　　　　　　　　０（所以不要吝啬层）
增加一个场景：　　　　　　　　　　０（多用啊）
将图形定义成符号：　　　　　　　　－２（尽量定义，好处多多）
增加一个空按钮（里面无任何图形）：４
增加一个MC：　　　　　　　　　　　２６
拖一个图形符号到场景中：　　　　　１２
拖一个按钮符号到场景中：　　　　　１２
拖一个MC到场景中：　　　　　　　　１２
放置一幅位图（不是指位图大小，指放置动作）：４４
桢空间最低值：　　　　　　　　　　２
空桢：　　　　　　　　　　　　　　２
空关键桢：　　　　　　　　　　　　２
场景末端关闭（End）图或文字边框：４
过渡桢绘制：　　　　　　　　　　　３１
绘制一个实线：　　　　　　　　　　９
绘制一个矩形：　　　　　　　　　　１７
绘制一和圆形：　　　　　　　　　　５４
符号颜色属性发生变化：　　　　　　１１
填充颜色绘制：　　　　　　　　　　４
线条尺寸、颜色绘制：　　　　　　　５
精确边：　　　　　　　　　　　　　０
额外颜色填充：　　　　　　　　　　５
放置一个文本边框：　　　　　　　　１２
每增加一个字符：　　　　　　　　　２
文本空格：　　　　　　　　　　　　１ 
随着flashplayer7.0的发布，一些技术问题已经得到解决了，而且性能大体地有所提高，然而在写本文之时，flashplayer6.0仍然有着广泛的应用。所以我们还是主要集中在6.0这个版本上。-aw猜测：国外买盗版的很少，所以很多人可能都来不及使用7.0，尤其是那些非职业的 flash设计者。
何时进行优化
对现有程序进行优化的过程，有时十分的冗长与困难，这与原始代码的非优化程度有关，所以在投入大量时间进行代码优化之前，最重要的是要估计出要在什么地方对代码做出修改或替换。
一个游戏代码的最重要的部分就是主循环体，通常情况下该循环体要在flash的每一帧上执行，并控制游戏中的角色属性和重要的数据参数。而对于主循环体以外的部分，也可能是次要循环部分，同样要注意是给其否分配了过多的资源，而没有分配给那些更需要资源的核心部分。
通过积累在各处节约出来的时间(可能每处仅仅是几个毫秒)，您会明显发现自己的swf运行得更加稳定，并且游戏感也大大加强。
简洁与高效的代码
书写出十分简洁、可以再次调用的代码(有时可能是面向对象的)是一项精细的工作，但这需要多年的编程经验。对于OOP(object oriented programming，面向对象的程序设计)，有些场合根本利用不到它的优势，这使得它显得十分奢侈。在有限的资源条件下(可能是flash播放器的原因)，通过更先进的方法，像刚刚提到的OOP，就可能反而导致令人不满意的结果。
我们并不是说OOP对游戏编程不好，只是在某些场合它显得过于奢侈和多余。毕竟有时候“传统的方法”却能得到更好的结果。
大体而言，用OOP是比较好的，因为它让代码维护更加简单。但在后文中，你会看到有时为了充分发挥flashplayer性能，而不采用OOP技术。例如：处理快速滚动或者计算十分复杂的数学问题。
基本的优化
一提及代码优化，我们马上会联想到执行速度的改进，而很少去考虑系统资源的分配。这是因为当今，即使是将被淘汰的计算机，都有足够的内存来运行我们大部分的flash游戏(128M的内存足以满足大多数情况的需要，况且，512M的内存是当今新电脑的基本配置)

变量
在各种重要的代码优化手段中，有这么一条：在定义局部变量的时候，一定要用关键字var来定义，因为在Flash播放器中，局部变量的运行速度更快，而且在他们的作用域外是不耗占系统资源的。
aw附：var变量仅仅在花括号对中才有“生命”，个人认为没有系统学过编程的人容易出错的一个地方：
awMC.onLoad = function(){
var aw = 1;
}
awMC.onEnterFrame = function(){
//不存在aw这个变量
}
一段非优化
一些优化的小建议
         好了，我想我来在优化建议方面开个头吧
         大家尽管跟贴
         在 (enterframe关键帧)中，避免使用for语句作循环
         使用蒙版
         不要改变影片的尺寸 (不要把它拉大)
         使用卸载mc命令removemovieclip
         从这个网站 http://www.moock.org/ 获得Fps的计数器
避免使用Dynamic text boxes
      Outlines 'round your vector images have a performance hit.
      在大多数情况下，while的运算速度要比for快（尽管for in语句在它们之中是
    最快的）
      不是所有的代码都要在每一帧中运行，在那些对时间要求不是十分苛刻的情况
下，使用flip flops（跳跃的关键帧）来代替（即使是对于碰撞的表现也如此）
       尽可能的少使用关键帧
       这种赋值a=b=c=0 要比
   a=0
   b=0
   c=0快一些
       在mc中定义局部变量为parent，比如var p=_parent，这样可以减少寻找这个变
量的时间
   当使用if和else的语句搭配的时候用（ condition?true action:false action）
代替
   在mc中，尽量不要使用this.这个表达式
mc.setMask()'这种命令不能加快速度，至少我的测试结果是这样的，我宁愿相
信
       这样的结果了，尽管我还没有找到根据。我看到速度变慢了，因为flash要拖动
整
       个mc，然后将蒙板效果作用上去。
       Squize，你基本上全说到了，没有太多可以在补充的了
       我还发现，你使用越多的Key.isDown(Blah)命令，就会越慢…这是不是很奇怪…
.
   
       (condition ? action : else),这条命令我不认为会执行的更快，在编译的时候
，这就会被编译为if和else的语句。
       把所有的代码都放到一起并不是好的编程方法，但是确实能提高速度。因为不必
再在整个mc中去找代码，而且通过这种方法，你经常能够更多的复用代码
       建立一个碰撞数组来代替1000帧的关键帧，或者代替计算一个串1000次。你可以
用下面的代码实现：
       for(i = 0;i < collisionArray.length;i++){
       if(hitTest(collisionArray)){
   //OMFG IM DEAD?!?#!
   break;
   }
   }
       我想我可以在这方面编写一个简单的教程，因为这样做确实比其他方法要快许多
。
BlinkOk：考虑一下flash在字典查找时所花费的时间和自检是所花费的时间。
      下面这段代码要在一个mc中查找所有的objects，而且要为每一个mc调用
      .render()函数
       code:
       for (i in mc) {
       if (typeof(eval(i)) == "movieClip")
       mc.render();
       }
       这段代码会使得对于每一个mc都要在字典中检查两遍，而且其他的objects要检
查一遍。我可以更改这段代码，让它仍执行原来的功能，只是不用检查条件了
       for (i in mc)
       mc.render();
       这段代码有同样的效果，但是现在每一个object只需要在字典中查找一次，当f
lash发现一个object不是mc的时候，它就什么也不做。
这几种图片格式都差不多吧，gif的透明度当然要花费多一点的时间，
而
       且png的alpha透明度可能要花费更长的时间
       我觉得，对于 mc.render()这个语句，即使对那些不具有render()函数
       Objects来说，也要花费时间，flash仍然要把object压到栈中，检查一遍它是否
有
       render()函数。这只是我的一点意见，他们都知道我经常说错的：—）
Squize：我敢肯定，Tomsason最近在哪个帖子中说过，jpeg的格式是最快的. 说老实话,
我
       也不敢肯定,我只是在作sprites/tile的时候用png，而在作大一些的bitmap的时
候
       使用jpeg(只是为了减小文件的体积的缘故而不是为了优化影片的表现)
   
       我知道会有很多人不同意了，老的flash4的语法要比dot语法快一些（我必须承
认
       我使用dot语法：P）
      telltarget命令要好于with命令
      不要来回的移动渐变效果，而且尽量少的使用alpha
      变量名的长度倒不是一个很有杀伤力的因素。我见过许多帖子，生猛到要把sc
ore
      这个变量名缩减到s（不仅仅是为了局部循环）.不要在这方面简省，如果你这
么
      缩减的话，当你在一周之后再看你的代码的时候，如果你想再理出一个清晰的
头
      绪，你会感到头疼的。
      
      尽可能在一个if的语句中避免使用and或or作判断。大部分情况下，如果一个声
明
      不为真，这往往导致flash每一次都要重新计算一遍所有的声明。尽量使用分开
的
       if语句，（而且如果你有许多if/else语句搭配，尽量把最可能的放到最前面，
尽
      管在现实中，这往往很难做到，但是。。。）