Flash Player内部机制

1. Flash 运行时

用C++、汇编语言和ActionScirpt编写

发布的Flash Player版本向前兼容

一切归结为核心周期。。。

2. 核心周期

事件、用户代码、运行时环境和输出相当于Flash Player（其实是不只这些，还有通信），而Flash Player嵌入到浏览器中

3.用户代码

由上图可以看出，Flash Player内置两个虚拟机，它们各司其职，AVM1用来执行AS1和AS2编写的swf，AVM2用来执行AS3编写的swf。AVM1和AVM2是无法直接相互访问的，可以通过间接方法来实现。（比如ExternalInterface和javascript一起，或者LocalConnection）

4.用户代码的发展历史

Flash发展的最初是一个动画引擎，Flash Pro为每一帧动画创建swf代码，估计Flash Player里面只有一个swf代码处理器

不久后，人们希望在swf中增加交互的功能，ActionScript1（AS1）出现。AS都是基于ECMAScript，AS1由AVM1解释执行，而且是在特定的帧上执行，或者响应事件。

虚拟机（AVM）让Flash异常成功，但是还是无法满足游戏和应用开发的需要，主要体现在运行时的性能（连现在都是），运行时错误报告，调试和分析器。所以Adobe重写AVM和使用AS3，还在把AS3先转化为字节码然后再让AVM2执行。

5. AVM2如何工作

主要分为四个部分，这四个部分也是最为区别AVM1的。

首先是校验器，校验是保证用户代码执行时的安全机制（而且校验和代码执行是分开的），任何函数的第一次调用之前要验证其正确性（类型安全，合法跳转和引用），一次校验便可以生成安全高效的代码（因为字节码总是在解释器里不断的被执行，而验证监测只需一次，但AS2就是循环一万次，验证也执行一万次），而且校验器决定代码的执行方式。

其次是即时编译，AS3虚拟机是一个即时编译类型的虚拟机（常见的编译机制之一），AS字节码（ABC）转换为LIR（静态单赋值形式），生成的本地代码直接在CPU上执行（编译器是执行字节码机制中的主要部分，而不是解释器，解释器的工作是针对我们桌面系统平台底层语言而言的）。LIR的出现的原因可能是大多数优化器都依赖与LIR形式提供的数据流信息。对LIR优化，比如：常量叠算、子表达式消除、内联特殊函数运算、线性扫描寄存器分配。。

然后是解释器，高级代码总是被解释执行（如java），一个单独的内循环需要重复执行以下局部操作：抓一个指令、执行指令、处理下一个指令。

最后就是垃圾回收，内存具体怎么管理，我们无需知道。计数和标记来回收。逐步回收AS3对象和内部的C++对象。内存泄露：弱引用、事件监听、字典。

6.运行时环境

显示列表和文本引擎

首先是显示列表：Flash是“保留模式”，并不直接绘制屏幕。只有在显示列表中出现的显示对象才会在屏幕上出现，通过修改显示列表来完成。渲染器将显示列表转换为屏幕上的像素。无法强制Flash渲染屏幕。

然后是文本，分为文本框TextField和Flash文本引擎

文本框完全是用C++语言实现的，对国际化支持不足（从右向左文本或者竖排文本，复杂字形渲染）。单一实现，无法修改定制。对设备相关的输入法支持的很好。

Flash文本引擎和文本布局框架，复杂格式，复杂布局，高级印刷。

7.输出

原来渲染器在这里。渲染器如果基于显示列表生成屏幕上的像素？第一步是视频解码：

第二步，分解显示列表，基于形状生成全局边缘列表，然后为栅格器优化

第三步，扫描边缘（Edges），逐行生成屏幕上的像素值，存储在缓冲区内。

第四步，将最终合成的位图交给浏览器展现在屏幕上。

最后总结一下，先看一下全图：

1.代码执行和渲染是两个完全分离的过程

2.帧执行模型：Flash Player发出事件——用户代码被执行（虚拟机以外由开发者编写的代码）——RENDER事件派发，显示列表是否失效——最后用户代码执行

3.渲染显示列表过程中不会与任何用户代码被执行。

转载：http://blog.csdn.net/sysu_2010/article/details/6592831