flex_探究Flex组件生命周期;

图4.组件出生时前交互流程

二、生活时期

组件经过出生时期之后就进入了生活时期，这个时期意味着组件可以被看见，被操作，甚至被删除。并且作为一个成熟的个体，组件可以和外界进行交互，对更新请求进行响应。Flex组件使用Invalidation–Validation模式来响应更新请求。

验证-提交模式(Invalidation-ValidationPattern):

Flex的生命周期是建立在帧模型基础之上的，所以同样遵循着先执行脚本后渲染屏幕的规则。为了达到流畅的视觉体验，我们通常期望能够尽量减少代码执行的消耗，而给画面渲染留下充足的时间，为了实现这点Flex使用了Invalidation–Validation模式，来实现资源的有效利用。

图5.Invalidation-Validation模式

Invalidation–Validation模式即验证提交模式提供了一个低耦合的处理过程，将数据的改变（旧数据的实效）和数据的处理（对新数据的重新使用）区分开来，这样做的好处是：只在有屏幕刷新需求的时候进行相应数据操作和计算;避免了不必要的重复渲染;

以清单7为例，通过Invalidation–Validation模式，第二行的代码的结果永远不会生效，即不会也从来没有显示到屏幕上：

清单7.相同属性被多次赋值的例子

myImageView.height=50;

myImageView.height=100;

那Flex框架是如何实现这一模式的呢？让我们来看一下Flex是如何将这一模式应用到组件上的。首先我们来看一下Flex可视化组件基类UIComponent是如何处理setwidth（）方法的：

清单8.UIComponent的setwidth（）方法

publicfunctionsetwidth(value:Number):void{

if(explicitWidth!=value){

explicitWidth=value;

invalidateSize();

}

//其他代码省略

}

从清单8我们可以看出，UIComponent在首先会去判断属性赋值是否改变，从而避免重复赋值带来的消耗，然后调用protected方法invalidateSize（）。invalidateSize（）是UIComponent提供的验证方法之一，它用来校验与组件尺寸大小相关的属性，当此方法被调用后，Flex组件引擎LayoutManager会首先检查该属性的更新请求是否已经调用过invalidateSize（）方法，如果调用过，说明此类型的更改请求已经记录在案，无需赘述。如果没有，则会将此次请求记录到LayoutManager校验队列上进行等待。那么对width属性值的更新什么时候生效呢？LayoutManager会在监听到下一次RENDER事件派发的时候，将组件推送到提交阶段。

在提交阶段，LayoutManager得到更新请求队列，调用commitProperties（）方法使得属性width的最新值（假设记录在了_width私有变量上）得以生效。Flex就是通过这种属性值延迟生效的方法来保证每次用于渲染画面的请求都是最新的，从而避免了不必要的资源浪费。因此，在我们的例子ImageViewer里，我们也使用了类似机制。（如清单9所示），只不过这里我们调用的是invalidateProterties（）方法。与invalidateSize（）类似，组件的scale属性值会在提交阶段通过调用commitProperties（）方法生效。

清单9.ImageViewer的setscale方法

publicfunctionsetscale(value:Number):void

{

if(_scale!=value){

_scale=value;

scaleChanged=true;

invalidateProperties();

dispatchEvent(newEvent("scaleChanged"));

}

}

验证阶段(Invalidation)

验证阶段是组件在生活时期要经历的第一步，具体地说是响应更新请求的第一步。作为invalidation-validation循环的一份子，她会在组件的生命周期中多次执行。Flex组件基类UIcomponent提供了三种验证方法：invalidateProperties()、invalidateSize（）和invalidateDisplayList()来分别响应组件对值相关，布局相关和显示相关属性的更新请求。

组件会通过两种方式进入到验证阶段：第一种方式是在初始化阶段，通过父节点调用childrenCreated()方法，组件进入第一次Invalidation–validation循环。这一次，三种验证方法都会被自动调用以确保组件初始化成功。这类调用在组件的生命周期内只会经历一次；第二种方式是响应更新请求，组件的任何一方面特性发生更新请求后，都会进入到验证阶段。而此时，用户需要根据特性的不同类别来自行决定调用哪种验证方法。还是以清单9为例，通过调用invalidateProperties（）方法，确保了在接下来的提交阶段，更新会对值计算生效。在这个时期，我们通常不去做太多的事情，因为此时只是验证阶段，更新并不生效。我们所要做的只是记录此次更新，并且等待进入提交阶段。

提交阶段(Validation)

通过以上的介绍，我们已经很清楚组件更新会在提交阶段实际生效。和验证阶段的随时更新随时校验不同，Flex框架为提交阶段设计了线性执行的顺序，将三个提交方法分为了三个阶段。顺序调用三个提交方法：commitProperties（），measure（）和updateDisplayList（）。这样做的目的和每个方法的功能有关。commitProperties（）方法主要负责属性值的计算和生效，因此首先执行，因为这些自己算过的值可能用于布局，也可能用于显示。这里也可以用来移除不需要的子节点，但是您需要通过标志位来判断子节点是否存在。

measure（）方法用于根据组件的内容大小计算组件尺寸。由于尺寸的计算是自下而上的，所以组件子元素的大小改变都会隐试的触发此方法。

UpdatedisplayList()方法用来更新显示列表（DisplayList）的布局以及渲染。组件的布局是一个自上而下的过程，所以在这个方法里您需要对不仅仅是组件设置布局属性，而且也要对子元素进行相应的调整。这里也是使用Flash绘图API的好地方。

这里，我们所要做的就是覆盖（override）这几个方法，在正确的时间、正确的地方做正确的事。

交互阶段(Interaction)

交互严格地说是组件生命周期中的某种行为，她是促使组件更新，推动验证-提交循环的动力。Flex使用事件驱动的交互模式，来实现一种完全松耦合的体系结构。简单地说，任何组件如果想要告诉外界当前发生了什么事或者即将发什么事的话，他可以派发一个事件，那么在该类事件可及范围内的任何组件都可以通过注册该事件的监听器的方式来对此类事件进行相应处理。关于Flex在事件机制处理方面信息的由于超出了本文的范围，这里不再多讲，感兴趣的读者可以关注后续教程《探索Flex的事件机制》，或者阅读资料部分的相应文档。

一般来说，组件的交互行为有以下几种：用户同组件的交互，比如说：输入数据，缩放大小等等；通过派发和响应事件；应用（Application）或者父节点（parent）与组件的交互。比如说ItemRenderer实例和宿主对象之间的data传递（关于ItemRenderer机制和实践讲解，也会有后续教程加以探讨）。

三、销毁时期

任何事物都会有一个归宿，Flex组件也不例外。当某个组件不再需要的时候，我们需要把她销毁（这听起来有点残酷，但是我们不得不这么做）。

拆卸阶段(removeChild)

销毁组件的一种方法是通过调用组件父亲节点（parent）的removeChild（）方法，该方法会将他从显示列表（DisplayList）上拆卸掉，并且检查是否存在对此组件的引用，如果没有的话，组件会被标记为“可以回收”，这预示着组件进入到了回收阶段，并且可以被AVM垃圾回收。

回收阶段(GC)

刚才我在上边提到removeChild（）方法将组建拆卸掉以后，组件可以被垃圾回收。这意味着该组件的实例会被从内存中完全删除掉，并且释放资源。但是请注意，垃圾回收并不一定在此刻马上发生，AVM有着自己的垃圾回收时间。因此这个打了标签的组件需要等待回收时刻的到来。拆卸阶段并不是组件销毁的必经阶段。当某个组件被拆卸掉之后，如果该组件包含了子组件，而他们都不存在外界引用的话，所有的元素都会被标记为“可以回收”，也就是说该系统中的子组件并不需要进入到拆卸阶段，也可以在回收时刻到来的时候被AVM回收掉。那么开发人员所需要注意的就是，在这个时刻发生之前，将引用去除掉。

实际编程中的应用

到目前为止我们学习的多是Flex生命周期的理论。学习理论的最终目的就是知道编程实践，现在我们来看一下生命周期是如何在例子ImageViewer里是被贯彻执行的。

关于createChildren（）方法

清单10显示了组件ImageViewer的createChildren()方法。正如大家注意的那样，在创建每一个子节点的时候，首先判断该节点是否存在是一个很好的习惯，这样可以防止子节点在某种情况下已被实例化。是的，这种情况是可能发生的。以清单11里的Table类为例，Table里的子节点row有一个set（）方法，而我们从“初生阶段”里知道，装配阶段（set方法调用）要早于初始化阶段，那么请大家思考一下清单12的执行结果会是如何.

清单10.ImageViewer的createChildren()方法

overrideprotectedfunctioncreateChildren():void{

super.createChildren();

if(!this.border){createBorder();}

if(!controlBar){controlBar=newUIComponent();}

if(!zoomInButton){

zoomInButton=newButton();

zoomInButton.label="+";

zoomInButton.addEventListener(MouseEvent.CLICK,zoomInButtonClickHandler);

controlBar.addChild(zoomInButton);

}

if(!zoomOutButton){

zoomOutButton=newButton();

zoomOutButton.label="-";

zoomOutButton.addEventListener(MouseEvent.CLICK,zoomOutButtonClickHandler);

controlBar.addChild(zoomOutButton);

}

//addedcontrolBarthelasttime

addChild(controlBar);}

清单11.Table类的例子

vart:Table=newTable();

t.row=newRow();

addChild(t);

overrideprotectedfunctioncommitProperties():void{

super.commitProperties();

if(sourceChanged){

if(!this.image){

image=newImage();

this.addChild(image);

image.source=this._source;

}else{

image.source=this._source;

}

sourceChanged=false;

}

if(scaleChanged){

this.imageWidth=this.imageWidth*this.scale;

this.imageHeight=this.imageHeight*this.scale;

scaleChanged=false;

}

}

CommitProperties（）是验证方法invalidateProperties（）所对应的提交方法，也是初始化阶段会被调用的第一个提交方法。她的目的就是使得任何通过set方法提交的数值更改生效。所以您可以看到在清单9的setscale（）方法里，按照invalidation-validation模式，调用invalidateProperties（）方法从而将值的生效延迟到了commitProperties（）里，并且为了做到“局部更新”，我们使用了标志位scaleChanged。另外，这里一个奇怪的地方，那就是为什么在commitProperties（）会有添加子节点的操作呢？这也是我们要特意举例说明的一个地方。对于有些子节点，她的诞生可能是和某些属性值相关联的，也就是我们在编程提示四里提到的动态创建或者数据驱动的子节点。这些子节点，由于他们并不是随着组件的产生而产生，而是要受属性值的变化而产生或者变化，甚至在某些情况下，根本就不需要存在。所以我们应该在值的提交阶段，也就是commitProperties（）方法调用的时候，当新值真正生效的时候再去创建它。

关于measure()方法

measure（）方法是组件自动计算尺寸大小的地方，在例子ImageViewer的measure（）方法里（如清单14所示），我们做的事很少。这是因为，我们ImageViewer被设计为：需要显式指定大小（当然这里只是为了举例方便，您可以根据需要，制作可以自动度量大小的组件）。即在应用时设置width和height值。如清单15所示

清单14.ImageViewer的measure()方法

overrideprotectedfunctionmeasure():void{

super.measure();

measuredWidth=Math.max(image.width,controlBar.getExplicitOrMeasuredWidth());

measuredHeight=image.height+controlBar.getExplicitOrMeasuredHeight();

measuredMinWidth=measuredWidth;

measuredMinHeight=measuredHeight;

}

<sample:ImageViewerwidth="400"height="350"imageWidth="150"imageHeight="140"source="product.jpg"borderColor="0x000000"/>

updateDisplayList（）方法用于对组件内容进行布局以及渲染，一切屏幕上可见的内容都需要在这里被处理，所以updateDisplayList（）可以说是最繁忙的一个提交方法，他所包含的实现可以非常多。清单16中，我们省略了部分代码。只留下了需要讲解的部分。

清单16.ImageViewer的updateDisplayList()方法

overrideprotectedfunctionupdateDisplayList(unscaledWidth:Number,unscaledHeight:Number):void{

super.updateDisplayList(unscaledWidth,unscaledHeight);

//省略部分代码

zoomInButton.setActualSize(50,20);

zoomOutButton.setActualSize(50,20);

vartmpx:Number=20;

controlBar.setActualSize(tmpx,20);

controlBar.move(0,unscaledHeight-25);

zoomInButton.move(tmpx,0);

tmpx+=60;

zoomOutButton.move(tmpx,0);

if(imageHeightChanged||imageWidthChanged){

image.width=this.imageWidth;//w;

image.height=this.imageHeight;//h-20;

vartempX:Number=x+(w-imageWidth)*0.5;

vartempY:Number=y+(h-imageHeight)*0.5;

image.x=tempX;

image.y=tempY;

imageHeightChanged=false;

imageWidthChanged=false;

varg:Graphics=graphics;

g.clear();

g.beginFill(0x6F7777);

g.drawRect(tempX-1,tempY-1,imageWidth+2,imageHeight+2);

g.endFill();

}}

清单17.ImageViewer的setimageWidth()方法。

publicfunctionsetimageWidth(value:Number):void{

if(_imageWidth!=value){

_imageWidth=value;

imageWidthChanged=true;

this.invalidateDisplayList()

dispatchEvent(newEvent("imageWidthChanged"));

}

}

结束语

本文对Flex生命周期的各个阶段进行了分类和讲解，根据各个时期的特点提出了一些编程方面的提示，并且通过实例分析将这些编程提示应用到实践中，希望对您的Flex开发工作有所帮助。