Flex分析 - [enterFrameEvent]在做什么？

我的任务是找到(并可能修复)一些传递给我们的Flex应用程序的严重性能问题.当应用程序处于空闲状态且不应执行任何操作时,应用程序将始终占用CPU的50%到100%.

我的第一步是运行FlexBuilder附带的分析器.我期望找到一些占用大部分时间的方法,向我展示瓶颈所在.但是,我有意外的事情.

前4种方法是:

[enterFrameEvent] - 84%累积,32%自我时间

[收获] - 20%累积和自我时间

[tincan] - 8%累积和自我时间

global.isNaN - 4%累积和自我时间

所有其他方法的累积和自身时间均小于1%.

根据我在网上找到的内容,[括号内的方法]是分析器在没有实际的Flex方法显示时列出的内容.我看到有人声称[tincan]是RTMP请求的处理,我认为[reap]是垃圾收集器.

有谁知道[enterFrameEvent]实际上在做什么？我认为它基本上是事件循环的"主要"功能,因此预计会有很高的累积时间.但为什么自我时间如此之高？究竟发生了什么？我没想到玩家内部会花费这么多时间,特别是因为应用程序中实际上没有发生任何事情(并且没有UI更新).

有没有什么好方法可以找到正在发生的事情？我知道不应该发生的事情(看起来必须有某种忙碌的等待或其他失控的循环),但是探查器并没有给我任何我期待的结果.我的下一步是开始在各个地方添加调试跟踪语句,以尝试跟踪实际发生的情况,但我觉得必须有更好的方法.

有一些事情通常发生在flex项目中的enterframe Handler上.有些事情需要注意

手动事件响应或通过component.addEventListener手动添加的响应(Event.ENTER_FRAME,myfunc)

callLater()调用,这些在框架中发生ALOT并且可以是跳过任何数量的兔子漏洞的副产品,开发人员倾向于使用这些来解决与时间相关的问题,有时坏的代码可能导致这些继续调用每一帧.例如,最新的flex sdk构建中出现了大约120次calllater().

最后,我不能保证[enterframeEvent]只处理enterframe特定事件回调,而不是定时器,鼠标​​等事件,因为在主事件循环期间发生了enterframe,你可能会看到所有事件触发的累积结果来自主赛事池.我不是说这是发生了什么,但我不能说它也不是什么事情发生,我对那里的内部结构我不太了解.

/如前所述编辑,[enterFrameEvent]在技术上应该在每个帧的开头内部触发,但它不应该做任何事情,除非事件已经显式附加到它以执行用户代码.