理解Flex3的组件和框架的生命周期（一）

　　

作者：James Polanco & Aaron Pedersen 译者：李学锟


理解Flex3的组件和框架的生命周期（一）

理解Flex3的组件和框架的生命周期（二）


说明

Adobe Flex 框架的SDK美中不足之处就是部分由良好的半黑盒子系统所创建；这就是说，在大多数情况下，我们这些开发者在项目周期中没有时间或精力去真正地深入到未知领域。从技术上来讲，Flex 框架的不是一个黑盒子，你可以阅读和查看它的所有源码。由于代码的复杂性及它是如何设计的，我们往往把框架看成是如何输入、得到什么样的输出。大多数开发人员，包括作者，往往在工作中学习Flex,通过验证、试验、研究或按照他人写的博客提到的观点来寻找新的技巧和技术。

Adobe已经做了非常了不起的工作是Flex框架的文档，它已被细分为两大类：用户指南和API（ASDoc）文档。然而，即使他们有大量的文档，用户指南和API文档之间的还是有一个很大的差距。用户向导涵盖了一系列的课题，从如何开始到使用比较复杂的功能；但都停止在这些不很复杂的功能上，比如：样式扩展的技巧，元数据可以做和不可以做的，当然也包括Flex框架和组件生命周期。有很高层次的概述，但这些都在用户能弄明白的能力范围之外。

从API文档中我们可以推断出很多功能和命令，有时它们是引导我们，但也有时关于一些信息会戏弄我们。通常，API文档假定你知道要查找的东西，它们只是解释一下如何去做；但不会告诉你何时或为什么去用它们。由于这种宏观的指导与微观的API之间的差距，优化开发成为了一个黑色艺术，需要程序员通过多年的经验在试验和错误中确定最佳的做法。加上这些与Flex只有5年左右的历史，它从最初的表现进化到了引人注目的阶段，而我们大多处于技术的初级阶段。

然而，作为第三方的开发者，并不是唯一留在外面的。多数Adobe的工程师也没有完全了解框架的细微部分。詹姆斯参加了Adobe 2008年MAX会议关于Flex组件的介绍和Deepa论坛关于Flex的生命周期评价。

她的报告一半是关于生命周期，甚至其中一半是关于在当前Flex3的生命周期，其余的是关于Flex4的变化。

随着她在高层次的深入概述，提到近期一个Flex架构师使她最终通过了整个生命周期。她对观众说希望能早点了解这些信息，这样能使她能成为一个更好的工程师。

我们的观点是Flex迷惑了我们许多人，甚至一些最受尊敬的工程师。这是一个复杂的系统设计得非常强大，易扩展，灵活。然而，这种灵活性推展和实现创造了许多可能性。这些可能性很多都不是最好的开发方式，甚至有可能不利于整体性能，稳定性和可扩展性的应用前景。

本文的目的是尝试照耀到整个生命周期，使我们一些启示，作为一个开发社区，用Flex能创造更好的应用程序和组件。值得提醒的是，以下信息大部分是从阅读源代码推断的，一些是好的文档，也有一些不是。如果你看到一些不太正确的，或许可以用一个更好的解决方式，欢迎随时联络DevelopmentArc我们（info@developmentarc.com），以便我们尽可能添加/更新此文档，使之在技术上正确的。

如何阅读

在整本书中我们所涉及许多的Flex框架源码，但为了简洁，我们不总是显示所指的代码。当你阅读这本书时，要求你打开Flex Builder，或能够访问Flex3框架的源码，跟随着我们所讨论源码是怎么工作及为什么这样做。

如果你跟着阅读源码，请注意，我们经常跳过功能或者具体的代码，以便我们可以对应当前的主题。这样能防止我们远离当前的主题，主要是讲解代码的微妙之处。这并不是说那些代码的作用不重要，而是那些代码处理特别的案例，防止潜在的错误或在生命周期的后面来处理，只是我们当前没有讨论它。

Flex 简史

在我们进入Flex框架细枝末节及如何利用它的讨论之前，我们应该退一步，看看整体的Flex大局，为什么我们要使用它。许多读者也许已有相关的Flex经验，也许你有很多的开发经验；但是为了了解Flex小组的决定，我们有必要去看一看Flex和Flash Player的历史。这一点很重要，因为Flex框架的许多部分对Flash Player相当较低。

都是关于帧

从根本上讲，Flex 就是 Flash. 在DevelopemntArc,当我们坐下教授初级开发者或客户时，关于Flex我们都会继续重复这一点。因为Flex最终生成的SWF文件和Adobe Flash Professional 工具开发生成的一样。这就意味着，Flex 和任何 Flash SWF都是一样地遵守相同的规定。一个最根本的规则就是所有的SWF文件都要转换成以Flash为基础框架。对于那些不熟悉Flash历史的人来说，玩家的最初目标就是创建动画。传统的动画是以细胞为基础，你画的图像在某个细胞被稍微修改的图像的细胞所替换，它在一定的速度下，看起来像有运动的变化。所以，Flash使用frame创建相同的动画效果来代替细胞。帧依然存在，所有的逻辑和屏幕的渲染依赖于帧改变和帧率定义的大小。

帧率告诉Flash每秒多少帧应该尝试处理; Flex的默认设置为每秒24帧。这并不能保证Flex 每秒都是24帧，只保证做的帧数不会超过24. 实际的帧率受很多因素的影响，比如：复杂的代码被执行后，造成数量的改变需要重新呈现在屏幕上；另外，当然包括机器处理FlashPlayer的表现能力。


可变跑道

Ted Patrick 写了一篇关于Flash 帧执行顺序的优秀文章并将它命名为可变跑道。关于Flash Player7的旧文章，从理论上讲对于今天的Flash Player 10仍然成立。

他的文章主要讲的是将Flash 帧分为两个阶段：代码执行和屏幕重绘/渲染阶段。代码执行是线性的，在当前帧要求所有的代码都执行完，并没有其它线程。在这个过程中，产生数据，计算数值和修改显示的列表。一旦所有的代码执行完，显示列表就会更新，接着Flash Player把改变的部分渲染到屏幕上。

随着Flash Player 9和Action Script 3的发布，开发组还创建了新的Action Script 虚拟机(AVM2) 支持新的语言及特点。他们还重新设计了Flash DOM 使新的Player能支持早期的开发。Sean Christmann, 运用Ted Patrick的可变跑道概念将EffectiveUI进行了更新，并在新的虚拟机中显示出来。

Sean给跑道添加了“The Marshal”这个概念。老的虚拟机(AVM1)和AVM2最主要的不同是AVM1只工作在一片帧的环境下。AVM2的Marshal主要负责为Flash Player分割时间片去执行；最重要的在前面声明这些时间片，与将帧率编译在一个swf文件中并不一回事；播放器最终从这些时间片合成一个帧率。

这些时间片被分为多个步骤来完成：播放器事件的派发，用户代码的执行，预渲染事件的派发，用户代码的代码和最终播放器的渲染。Sean 研究了这些步骤，什么时候执行和当被执行时帧率是如何被修改的。

我们强烈建议阅读本书前先查阅这两篇文章，因为我们的讨论将一直涉及到帧，及Flex框架在整个系统的重要性。

管理跑道

执行代码和渲染显示内容需要花费很多的时间去完成，代码越复杂或改变显示的内容越多，则渲染花费的时间更久。其中最常见令开发者比较头痛的是可变跑道在处理大数据量时，动画的表现总是滞后。

例如，在DevelopmentArc的一个客户端工程中，用Flex Tween 系统创建了一个下载的动画。单独运行它时看上去非常好，一旦我们去向服务端下载数据时，动画就变得非常波动。导致这处现象的原因是我们要求播放器向服务端请求一个大量的XML数据，同时试图以编程方式让动画在屏幕上进行移动。

我们已做的是超负荷的跑道（帧播放器代码方面的），播放器在 每个周期花费太多时间去计算,所以导致没有足够的时间去渲染。这就是说播放器的帧率没有完全满足动画显示的需求，因大多时间被计算所占去。Ted's 在跑道这篇文章的最后评语是：

正如前面说过很多次，‘只是等待一帧’。

这引导我们回到Flex 框架上来。由于Flex框架的复杂性，想象它将如何执行，如果要在一个单一的每一帧处理嵌套的布局计算（HBox，VBox），动画（特效，过渡），数据加载（远程对象，HTTP服务），用户交互（鼠标，键盘），所有的定制代码。这将使播放器屈服和Flex 完全无法使用。

框架大部分为我们所做的就是‘等待一帧’。它的架构设计就是以这种方式来创建阶段和步骤进行优化播放器该如何工作，你可以利用这一优点，采用和开发API 钩子。