理解Flex3的组件和框架的生命周期.docx
《理解Flex3的组件和框架的生命周期.docx》由会员分享，可在线阅读，更多相关《理解Flex3的组件和框架的生命周期.docx（27页珍藏版）》请在冰豆网上搜索。
理解Flex3的组件和框架的生命周期
理解Flex3组件和框架的生命周期
作者：
JamesPolanco&AaronPedersen译者：
李学锟
目录（TableofContents）..........................................2
说明（Introduction）...............................................4
如何阅读这本书............................................................5
Flex简史...........................................................5
都是关于帧..........................................................5
弹性粒子轨道.............................................................6
管理粒子轨道.............................................................7
Flex应用程序的生命周期.............................................8
组件的生命周期............................................................8
组件生命周期阶段:
概述.................................................8
组件的构造阶段（birth）.................................................9
组件的添加阶段（birth）................................................10
组件的初始化阶段（birth）..............................................11
组件的失效机制阶段（growth/maturity）.................................12
失效和生效机制的周期.......................................................12
失效机制的三种类型.........................................................15
组件的生效机制阶段（growthmaturity）..................................16
组件的更新阶段（maturity）.............................................18
组件的移除阶段（death）................................................18
一个Flex应用程序的诞生............................................19
Flex应用程序的构造阶段...................................................20
FlexCompiler的暗黑艺术...............................................20
坐落在顶端的SystemManager..............................................21
Flex应用程序的初始化阶段.................................................23
外部接口管理...........................................................23
Flex应用程序的预加载阶段.................................................24
Flex应用程序的子类创建阶段...............................................25
Flex应用程序的子类显示阶段...............................................26
Flex应用程序的销毁阶段...................................................27
Flex组件开发的最好实践...........................................27
使用构造器（UsingConstruction）...........................................27
实时和构造器...........................................................28
使用初始化（Initialization）..............................................29
假若你必须重写初始化方法...............................................30
失效-生效的周期和方法....................................................30
分离生命周期的阶段.....................................................30
使用标识变量...........................................................32
实现验证的方法.........................................................32
使用和访问样式...........................................................34
应用样式...............................................................34
结论..............................................................36
说明
AdobeFlex框架的SDK美中不足之处就是部分由良好的半黑盒子系统所创建；这就是说，在大多数情况下，我们这些开发者在项目周期中没有时间或精力去真正地深入到未知领域。
从技术上来讲，Flex框架的不是一个黑盒子，你可以阅读和查看它的所有源码。
由于代码的复杂性及它是如何设计的，我们往往把框架看成是如何输入、得到什么样的输出。
大多数开发人员，包括作者，往往在工作中学习Flex,通过验证、试验、研究或按照他人写的博客提到的观点来寻找新的技巧和技术。
Adobe已经做了非常了不起的工作是Flex框架的文档，它已被细分为两大类：
用户指南和API（ASDoc）文档。
然而，即使他们有大量的文档，用户指南和API文档之间的还是有一个很大的差距。
用户向导涵盖了一系列的课题，从如何开始到使用比较复杂的功能；但都停止在这些不很复杂的功能上，比如：
样式扩展的技巧，元数据可以做和不可以做的，当然也包括Flex框架和组件生命周期。
有很高层次的概述，但这些都在用户能弄明白的能力范围之外。
从API文档中我们可以推断出很多功能和命令，有时它们是引导我们，但也有时关于一些信息会戏弄我们。
通常，API文档假定你知道要查找的东西，它们只是解释一下如何去做；但不会告诉你何时或为什么去用它们。
由于这种宏观的指导与微观的API之间的差距，优化开发成为了一个黑色艺术，需要程序员通过多年的经验在试验和错误中确定最佳的做法。
加上这些与Flex只有5年左右的历史，它从最初的表现进化到了引人注目的阶段，而我们大多处于技术的初级阶段。
然而，作为第三方的开发者，并不是唯一留在外面的。
多数Adobe的工程师也没有完全了解框架的细微部分。
詹姆斯参加了Adobe2008年MAX会议关于Flex组件的介绍和Deepa论坛关于Flex的生命周期评价。
她的报告一半是关于生命周期，甚至其中一半是关于在当前Flex3的生命周期，其余的是关于Flex4的变化。
随着她在高层次的深入概述，提到近期一个Flex架构师使她最终通过了整个生命周期。
她对观众说希望能早点了解这些信息，这样能使她能成为一个更好的工程师。
我们的观点是Flex迷惑了我们许多人，甚至一些最受尊敬的工程师。
这是一个复杂的系统设计得非常强大，易扩展，灵活。
然而，这种灵活性推展和实现创造了许多可能性。
这些可能性很多都不是最好的开发方式，甚至有可能不利于整体性能，稳定性和可扩展性的应用前景。
本文的目的是尝试照耀到整个生命周期，使我们一些启示，作为一个开发社区，用Flex能创造更好的应用程序和组件。
值得提醒的是，以下信息大部分是从阅读源代码推断的，一些是好的文档，也有一些不是。
如果你看到一些不太正确的，或许可以用一个更好的解决方式，欢迎随时联络DevelopmentArc我们（info@），以便我们尽可能添加/更新此文档，使之在技术上正确的。
如何阅读
在整本书中我们所涉及许多的Flex框架源码，但为了简洁，我们不总是显示所指的代码。
当你阅读这本书时，要求你打开FlexBuilder，或能够访问Flex3框架的源码，跟随着我们所讨论源码是怎么工作及为什么这样做。
如果你跟着阅读源码，请注意，我们经常跳过功能或者具体的代码，以便我们可以对应当前的主题。
这样能防止我们远离当前的主题，主要是讲解代码的微妙之处。
这并不是说那些代码的作用不重要，而是那些代码处理特别的案例，防止潜在的错误或在生命周期的后面来处理，只是我们当前没有讨论它。
Flex简史
在我们进入Flex框架细枝末节及如何利用它的讨论之前，我们应该退一步，看看整体的Flex大局，为什么我们要使用它。
许多读者也许已有相关的Flex经验，也许你有很多的开发经验；但是为了了解Flex小组的决定，我们有必要去看一看Flex和FlashPlayer的历史。
这一点很重要，因为Flex框架的许多部分对FlashPlayer相当较低。
都是关于帧
从根本上讲，Flex就是Flash.在DevelopemntArc,当我们坐下教授初级开发者或客户时，关于Flex我们都会继续重复这一点。
因为Flex最终生成的SWF文件和AdobeFlashProfessional工具开发生成的一样。
这就意味着，Flex和任何FlashSWF都是一样地遵守相同的规定。
一个最根本的规则就是所有的SWF文件都要转换成以Flash为基础框架。
对于那些不熟悉Flash历史的人来说，玩家的最初目标就是创建动画。
传统的动画是以细胞为基础，你画的图像在某个细胞被稍微修改的图像的细胞所替换，它在一定的速度下，看起来像有运动的变化。
所以，Flash使用frame创建相同的动画效果来代替细胞。
帧依然存在，所有的逻辑和屏幕的渲染依赖于帧改变和帧率定义的大小。
帧率告诉Flash每秒多少帧应该尝试处理;Flex的默认设置为每秒24帧。
这并不能保证Flex每秒都是24帧，只保证做的帧数不会超过24.实际的帧率受很多因素的影响，比如：
复杂的代码被执行后，造成数量的改变需要重新呈现在屏幕上；另外，当然包括机器处理FlashPlayer的表现能力。
可变跑道
TedPatrick写了一篇关于Flash帧执行顺序的优秀文章并将它命名为可变跑道。
关于FlashPlayer7的旧文章，从理论上讲对于今天的FlashPlayer10仍然成立。
他的文章主要讲的是将Flash帧分为两个阶段：
代码执行和屏幕重绘/渲染阶段。
代码执行是线性的，在当前帧要求所有的代码都执行完，并没有其它线程。
在这个过程中，产生数据，计算数值和修改显示的列表。
一旦所有的代码执行完，显示列表就会更新，接着FlashPlayer把改变的部分渲染到屏幕上。
随着FlashPlayer9和ActionScript3的发布，开发组还创建了新的ActionScript虚拟机（AVM2）支持新的语言及特点。
他们还重新设计了FlashDOM使新的Player能支持早期的开发。
SeanChristmann,运用TedPatrick的可变跑道概念将EffectiveUI进行了更新，并在新的虚拟机中显示出来。
Sean给跑道添加了“TheMarshal”这个概念。
老的虚拟机（AVM1）和AVM2最主要的不同是AVM1只工作在一片帧的环境下。
AVM2的Marshal主要负责为FlashPlayer分割时间片去执行；最重要的在前面声明这些时间片，与将帧率编译在一个swf文件中并不一回事；播放器最终从这些时间片合成一个帧率。
这些时间片被分为多个步骤来完成：
播放器事件的派发，用户代码的执行，预渲染事件的派发，用户代码的代码和最终播放器的渲染。
Sean研究了这些步骤，什么时候执行和当被执行时帧率是如何被修改的。
我们强烈建议阅读本书前先查阅这两篇文章，因为我们的讨论将一直涉及到帧，及Flex框架在整个系统的重要性。
管理跑道
执行代码和渲染显示内容需要花费很多的时间去完成，代码越复杂或改变显示的内容越多，则渲染花费的时间更久。
其中最常见令开发者比较头痛的是可变跑道在处理大数据量时，动画的表现总是滞后。
例如，在DevelopmentArc的一个客户端工程中，用FlexTween系统创建了一个下载的动画。
单独运行它时看上去非常好，一旦我们去向服务端下载数据时，动画就变得非常波动。
导致这处现象的原因是我们要求播放器向服务端请求一个大量的XML数据，同时试图以编程方式让动画在屏幕上进行移动。
我们已做的是超负荷的跑道（帧播放器代码方面的），播放器在每个周期花费太多时间去计算,所以导致没有足够的时间去渲染。
这就是说播放器的帧率没有完全满足动画显示的需求，因大多时间被计算所占去。
Ted's在跑道这篇文章的最后评语是：
正如前面说过很多次，‘只是等待一帧’。
这引导我们回到Flex框架上来。
由于Flex框架的复杂性，想象它将如何执行，如果要在一个单一的每一帧处理嵌套的布局计算（HBox，VBox），动画（特效，过渡），数据加载（远程对象，HTTP服务），用户交互（鼠标，键盘），所有的定制代码。
这将使播放器屈服和Flex完全无法使用。
框架大部分为我们所做的就是‘等待一帧’。
它的架构设计就是以这种方式来创建阶段和步骤进行优化播放器该如何工作，你可以利用这一优点，采用和开发API钩子。
Flex应用程序的生命阶段
所有的生物生命周期我们都分为：
出生，生长，成熟，死亡。
正如生物的生命周期，Flex框架和它的组件也有相似的过程。
我们将检验出生过程，看组件是如何被创建的，如何生长及成熟，到最后将从系统中它们移除时即为生命的终止。
在查看完组件后，我们将查看Flex应用程序框架的生命周期。
我们将重新查看Flex框架是如何开始，及与FlashPlayer结合，创建它们的程序和它们的子组件。
我们将会关注程序在生长阶段会发生什么现象及在成熟阶段当与用户交互时会发生什么。
最后我们看一下应用程序的销毁阶段。
理解这些所有的因素和它们发生的顺序将会帮助你设计和开发出更好的组件和应用程序。
一旦你完全了解它们的生命过程，利用它们的优点来为你的程序添加新的功能。
组件生命周期的介绍
在讨论Flex应用程序如何开始和创建它们的孩子之前，我们就先花点时间看一看一般组件的生命周期。
首先理解组件的生命周期是很重要的，因为Flex应用程序的生命周期是组件生命周期的扩展，再加上一些重要的修改来帮助性能和其它所需要的系统功能。
组件阶段：
概述
一个Flex组件都经过七个不同的阶段，我们可以划分到4个生命阶段。
由于组件整个生命周期主要有七个阶段，一些阶段是重复的出现，有的只出现一次。
这七个阶段是构建，添加，初始化，失效，验证，更新和清除。
这并不是Adobe官方的条目，但我们把这些阶段组织在一起并分类，有利于帮我们定义组件什么时候做什么样的事件。
我们的七个阶段按四个生命阶段来分。
出生阶段由构建，添加，初始化组成。
生长和成熟阶段由失效，验证，更新来组成。
死亡就是清除阶段。
来看一下第一个阶段：
构建。
组件阶段：
构建（出生）
构建阶段是组件的第一个阶段，定义为组件的构建。
AdobeFlex文档用Button作为它们的示例控件，如下：
viewplaincopytoclipboardprint?
varmyButton:
Button=newButton（）;//这是我们的构建阶段
varmyButton:
Button=newButton（）;//这是我们的构建阶段
很明显的，对吧？
什么是不很明显的，在这一阶段很少发生。
在构建阶段会发生什么呢？
如果我们从Button's的构造器中开始，跟进super（）方法链,先到UIComponent类，然后到FlexSprite，最后到Sprite（到这里为止，因为它的源码包含在playerglobal.swc中）。
FlexSprite是在继承链中是足够的顶端了，可以从这里看清整个构建过程了，所以我们就从这里开始。
查看FlexSprite的构造器所做的工作仅是给name属性赋值了一个唯一的文本值。
因为FlexSprite构造器所发生的情况已结束，我们再往下看UIComponent构造器。
UIComponent在构造时做得稍微多一点，也不很多。
设置焦点管理，开始跟踪自己的添加和删除事件，侦听焦点事件、键盘事件，定义自己的资源管理索引，保存当前组件自己的私有宽度和高度值，这些宽度和高度也许已在父类中定义。
只做了这么多，没有布局、样式和子类的创建。
最后，我们回到Button类。
Button的构造函数里所做的是注册侦听MouseEvents的事件来处理用户的交互。
只有这么多。
关于在自定义组件开发中使用构造器，在后面的章节‘使用构造’最佳实践会有更详细的信息说明。
以上是我们的构造阶段，下一阶段是什么？
组件阶段：
添加（出生）
当你将组件添加上父组件时，就发生了‘添加’阶段：
viewplaincopytoclipboardprint?
this.addChild（myButton）;//这是添加阶段的开始
this.addChild（myButton）;//这是添加阶段的开始
将组件添加到父类这个过程中，父类要执行大量的功能，这也是生命周期进行更高层次的阶段的地方。
让我们查看一下UIComponent的addChild（）方法，看它是如何定义添加阶段。
addChild（）方法被分解成3个子方法：
addingChild（）,$addChild（）和childAdded（）.将一个阶段分解成几个子步骤来完成，这种模式在Flex框架中是很常见的。
一个复杂的过程分解成几个小节来完成，这样做能更好地控制整个过程。
我们在以后的章节中将会继续讲解这种模式的好处，另外在Flex组件开发最佳实践章节中会有理详细的讲解。
当addChild（）方法被调用时，先执行addingChild（）方法。
addingChild（）方法为我们做了大量的工作，比如子类的父类引用，设置子类的document（父类Application）引用,定义布局管理器（这对以后的阶段来说是很重要的），定义哪些字体是可用的，开始样式的传播及组件样式的管理。
一旦addingChild（）方法完成，addChild（）方法将调用FlashPlayer级别的将组件添加到显示列表的$addChild（）方法，确保播放器的Flash帧在渲染阶段将组件绘制在屏幕上。
最后调用的子方法是childAdded（）,它决定着子类控件是否已初始化完成，如果没有初始化完成，则调用子类的initialize（）方法，完成添加阶段后，进行初始化阶段。
组件的阶段：
初始化（出生）
初始化阶段主要负责组件的子类的创建和为进行第一个失效和验证环节做准备。
Initialize（）方法是被父类的childAdded（）方法所调用，它被分解成4个子方法：
createChildren（）,childrenCreated（）,initializedAccessibility（）和initializationComplete（）.
当initialize（）方法被调用时，UIComponent先派发FlexEvent.PREINITIALIZE事件，然后调用createChildren（）方法来确保相关的组件被创建，接着为自己添加子组件。
例如，Button组件重写了UIComponent的createChildren（）方法来生成TextField的实例作为Button的标签文本，设置TextField实例的styleName属性，然后将TextField的实例做为孩子通过addChild（）方法进行添加。
当createChildren（）方法完成后，将调用childrenCreated（）方法。
这个方法主要是为进入失效-验证环节做准备，就是下一面我们要谈的内容。
Initialize（）方法最后调用的两个方法是initializeAccessibility（）和initializationComplete（）.initializaeAccessibility（）方法是用FlashPlayer的无障碍系统来设置组件的相关属性。
initalizationComplete（）方法是最后一个被调用的方法，给processedDescriptors设置器进行赋值，从而派发FlexEvent.INITIALIZED事件。
尽管初始化已经结束，但在使用这个组件之前还有些任务要做。
关于如何使用初始化，请参考后面的"使用初始化"章节。
组件状态：
失效（生长/成熟）
失效是在组件生命中第一个可重复生命周期，也是生长和成熟的第一个阶段。
在createChildren（）方法被调用后，UIComponent类的childrenCreated（）方法被调用。
在这个方法里，在失效阶段3个子方法被调用：
invalidateProperties（），invalidateSize（）和invalidateDisplayList（）.
失效和生效环节
不讨论与生效阶段的交互和定义，我们就不能深入地了解失效阶段。
在前面我们提到了Flex框架在程序会使用‘等待下一帧’来管理性能。
失效-生效环节是Flex框架在整个生命周期中第一次显示它权力的地方。
失效-生效周期给我们提供了一个解耦的过程。
从值处理过程中单独地改变值。
解耦这一过程，我们可以得到很多方便之处，比如推迟大数量的处理直到代码处理的最后阶段，还有就是阻止没必要的代码重复执行。
看下面的例子：
viewplaincopytoclipboardprint?
myButton.width=20;
myButton.width=25;
myButton.width=20;
my
升级会员 