Flex application创建顺序(转)

>preinitialize->initialize->creationComplete->applicationComplete,
preinitialize在所有的初始化之前触发,没有子组件的定义,但是可以引用组件的变量.
initialize当所有子组件生成完成后触发,在这个时间点还没有组件被渲染出来.
creationComplete组件定义完成并已经在显示列表.
applicationComplete所有的组件初始化完成并显示.

首 先介绍一下SystemManager. SystemManager是Flex应用的主控者, 它控制着应用窗口, Application实例, 弹出窗口, cursors, 并管理着ApplicationDomain中的类. SystemManager是FlashPlayer实例化的第一个类, 它存储了主应用窗口的大小和位置信息, 保存其子组件比如:浮动弹出窗口和模态窗口的痕迹. 通过SystemManager可以获得内嵌字体,样式和document对象.
自定义的可视化组件(UIComponent的子类)只有在调用过addChild()后, 才会有一个SystemManager赋给他们, 之前是Null. 所以在自定义可视化组件的构造函数中不要使用SystemManager.

通常, Application对象创建时, 发生如下事件:
1. 实例化Application对象
2. 初始化Application.systemManager
3. Application在初始化过程之前, 派发预初始化事件.
4. 调用createChild(). 此时, 所有应用组件被创建, 所有组件的createChild()被调用.
5. Application派发初始化事件, 表明所有的组件初始化完毕.
6. 派发creationComplete事件
7. Application对象添加到显示列表中
8. 派发applicationComplete事件

大 多数情况下, 我们使用<mx:Application>来创建application对象, 但如果使用ActionScript来创建的话, 那么建议不要在application的构造函数中创建组件, 推荐在crateChildren函数中, 主要是从性能方面考虑.

Flash包含的是一个时间线上的多个帧, 而Flex的SWF只包含2个帧. SystemManager, Preloader, DownloadProgressBar和少量工具类都在第一帧, 剩下的包括应用代码/ 内嵌资源全都在第二帧中. 当Flash Player下载下载SWF时, 只要接收到第一帧内足够的数据, 就会实例化SystemManager, 由它来创建Preloader, 然后创建DownloadProgressBar, 这两个对象会察看剩余字节的传输过程. 当第一帧的所有字节传输完毕后, SystemManager发送enterFrame到第二帧, 然后是其他事件. 最后Application对象派发applicationComplete事件.

Flex 是一个事件驱动的编程模型, 任何事情的发生, 其背后必然存在一个事件. 而开发者第一次看到MXML时, 很难体会到一个Xml标记的应用的事件流和实例化的生命周期. 这个对于HTML和Flash的开发者尤其会感到困惑, 因为其熟悉的方式与Flex的一点也不相似. HTML的实例化是从上到下的, Flash的执行是从Frame0开始一帧帧运行的. 而Flex则又有不同.

从我们开始学习Flex时, 我们就需要了解事件流和MXML的实例化.
我们来看一个简单的MXML的应用.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
    xmlns:mx="http://www.adobe.com/2006/mxml"
    layout="absolute"
    backgroundGradientColors="[#67cbff, #fcffff]"
    color="#000000"
    fontSize="12" 
    preinitialize="report( event , 'preinitialize' )"
    initialize="report( event , 'initialize' )"
    creationComplete="report( event , 'creationComplete' )"
    applicationComplete="report( event , 'applicationComplete' )"
    >

    <mx:Script>
        <![CDATA[               
            [Bindable]
            public var outTextData:String="";
public function report( event:Event , value:String ):void
{
   outTextData += String(flash.utils.getTimer()) + 'ms >> '+ event.currentTarget + '.' + value + '\n';
}

]]>
    </mx:Script>

    <mx:TextArea
        id="outTextArea"
        text="Unknown macro: { outTextData }"
        right="10" left="10" top="50" bottom="10" alpha="0.5"
        wordWrap="false"
        initialize="report( event , 'initialize' )"
        creationComplete="report( event , 'creationComplete' )"
        />

    <mx:Button
        y="10" height="30" left="168" width="150"
        id="HelloButton"
        label="Say Hello"
        initialize="report( event , 'initialize' )"
        creationComplete="report( event , 'creationComplete' )"
        rollOver="report( event , 'rollOver' )"
        rollOut="report( event , 'rollOut' )"
        click="report( event , 'click > Hello!' )"
        />
       
    <mx:Button
        id="GoodByeButton"
        label="Say Goodbye"
        y="10" left="10" height="30" width="150" color="#000000"
        initialize="report( event , 'initialize' )"
        creationComplete="report( event , 'creationComplete' )"
        click="report( event , 'click > Goodbye!' )"
        />
       
    <mx:Button
        id="ClearButton"
        label="Clear"
        y="10" left="326" height="30" color="#000000" right="10"       
        initialize="report( event , 'initialize' )"
        creationComplete="report( event , 'creationComplete' )"
        click="outTextData='';report( event , 'click' )"
         /> 
</mx:Application>
这个应用运行时, 输出了实例流程和事件流. 这校我们就能够看到所有事件的触发顺序. 可以发现应用启动后, 事件的顺序是一定的. 下面是输出的内容:
Unknown macro: 1287ms >> aa0.preinitialize
1310ms >> aa0.outTextArea.initialize
1315ms >> aa0.HelloButton.initialize
1318ms >> aa0.GoodByeButton.initialize
1321ms >> aa0.ClearButton.initialize
1321ms >> aa0.initialize
1407ms >> aa0.outTextArea.creationComplete
1407ms >> aa0.HelloButton.creationComplete
1407ms >> aa0.GoodByeButton.creationComplete
1407ms >> aa0.ClearButton.creationComplete
1407ms >> aa0.creationComplete
1411ms >> aa0.applicationComplete

一旦applicationComplete事件触发后, 组件就会在鼠标事件派发后触发自己的事件.

77264ms >> aa0.ClearButton.click
80605ms >> aa0.HelloButton.rollOver
81288ms >> aa0.HelloButton.click > Hello!
82214ms >> aa0.HelloButton.rollOut
85015ms >> aa0.GoodByeButton.click > Goodbye!

关于creationComplete事件的发生时机,手册中是这样说的:
    假设程序中有这样的结构:

Application
    OuterVBox
        InnerVBox1
            InnerVBoxLabel1
        InnerVBox2
            InnerVBoxLabel2 

    事件:preinitialize, initialize, creationComplete发生的顺序是这样的:

OuterVBox preinitialize
    InnerVBox1 preinitialize
        InnerVBox1Label preinitialize
        InnerVBox1Label initialize
    InnerVBox1 initialize
    InnerVBox2 preinitialize
        InnerVBox2Label preinitialize
        InnerVBox2Label initialize
    InnerVBox2 initialize
OuterVBox initialize
        InnerBox1Label creationComplete
        InnerVBox2Label creationComplete
    InnerVBox1 creationComplete
    InnerVBox2 creationComplete
OuterVBox creationComplete 

    所有的initialization事件完成后,creationComplete时间才开始发生,先从叶子控件开始,然后是他们的父控件,直到application。

    如果将 OuterVBox容器变成ViewStack并且creationPolicy 属性为auto, 则事件发生顺序是:

OuterViewStack preinitialize
    InnerVBox1 preinitialize
    InnerVBox2 preinitialize
OuterViewStack initialize
        InnerBox1Label preinitialize
        InnerBox1Label initialize
    InnerVBox1 initialize
        InnerBox1Label creationComplete
    InnerVBox1 creationComplete
OuterViewStack creationComplete 

然而,对于item renderer 或者 item editor, Flex 可能会重用item renderer 或者item editor的实例。但是被重用的renderer 或者item editor的实例不会再次发生creationComplete事件。作为替代,你可以使用dataChange事件。Flex 会在每次data属性发生变化时触发dataChange事件。在Accessing the listData property(Flex2 help中)一节中的例子就使用了dataChange事件来更新在DataGrid控件的item renderer中的TextArea的内容。

转:http://hi.baidu.com/woaidelphi/blog/item/1d1cb7667464ba2caa184c39.html

以下是对提供的参考资料的总结,按照要求结构化多个要点分条输出: 4G/5G无线网络优化与网规案例分析: NSA站点下终端掉4G问题:部分用户反馈NSA终端频繁掉4G,主要因终端主动发起SCGfail导致。分析显示,在信号较好的环境下,终端可能因节能、过热保护等原因主动释放连接。解决方案建议终端侧进行分析处理,尝试关闭节电开关等。 RSSI算法识别天馈遮挡:通过计算RSSI平均值及差值识别天馈遮挡,差值大于3dB则认定有遮挡。不同设备分组规则不同,如64T和32T。此方法可有效帮助现场人员识别因环境变化引起的网络问题。 5G 160M组网小区CA不生效:某5G站点开启100M+60M CA功能后,测试发现UE无法正常使用CA功能。问题原因在于CA频点集标识配置错误,修正后测试正常。 5G网络优化与策略: CCE映射方式优化:针对诺基亚站点覆盖农村区域,通过优化CCE资源映射方式(交织、非交织),提升RRC连接建立成功率和无线接通率。非交织方式相比交织方式有显著提升。 5G AAU两扇区组网:与三扇区组网相比,AAU两扇区组网在RSRP、SINR、下载速率和上传速率上表现不同,需根据具体场景选择适合的组网方式。 5G语音解决方案:包括沿用4G语音解决方案、EPS Fallback方案和VoNR方案。不同方案适用于不同的5G组网策略,如NSA和SA,并影响语音连续性和网络覆盖。 4G网络优化与资源利用: 4G室分设备利旧:面对4G网络投资压减与资源需求矛盾,提出利旧多维度调优策略,包括资源整合、统筹调配既有资源,以满足新增需求和提质增效。 宏站RRU设备1托N射灯:针对5G深度覆盖需求,研究使用宏站AAU结合1托N射灯方案,快速便捷地开通5G站点,提升深度覆盖能力。 基站与流程管理: 爱立信LTE基站邻区添加流程:未提供具体内容,但通常涉及邻区规划、参数配置、测试验证等步骤,以确保基站间顺畅切换和覆盖连续性。 网络规划与策略: 新高铁跨海大桥覆盖方案试点:虽未提供详细内容,但可推测涉及高铁跨海大桥区域的4G/5G网络覆盖规划,需考虑信号穿透、移动性管理、网络容量等因素。 总结: 提供的参考资料涵盖了4G/5G无线网络优化、网规案例分析、网络优化策略、资源利用、基站管理等多个方面。 通过具体案例分析,展示了无线网络优化中的常见问题及解决方案,如NSA终端掉4G、RSSI识别天馈遮挡、CA不生效等。 强调了5G网络优化与策略的重要性,包括CCE映射方式优化、5G语音解决方案、AAU扇区组网选择等。 提出了4G网络优化与资源利用的策略,如室分设备利旧、宏站RRU设备1托N射灯等。 基站与流程管理方面,提到了爱立信LTE基站邻区添加流程,但未给出具体细节。 新高铁跨海大桥覆盖方案试点展示了特殊场景下的网络规划需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值