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

Question

我的任务是发现(并可能修复)交付给我们的 Flex 应用程序的一些严重性能问题。当应用程序只是空闲并且不应该做任何事情时，它会持续占用 50% 到 100% 的 CPU。

我的第一步是运行 FlexBuilder 附带的分析器。我希望找到一些占用大部分时间的方法，告诉我瓶颈在哪里。然而，我得到了一些意想不到的东西。

前4种方法是:

[enterFrameEvent] - 84% 累积，32% 自拍时间

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

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

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

所有其他方法的累积时间和自我时间都低于 1%。

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

有谁知道 [enterFrameEvent] 实际上在做什么？我认为它本质上是事件循环的“主要”函数，因此预计会有很高的累积时间。但为什么自我时间如此之高？究竟发生了什么？我没想到播放器内部会占用这么多时间，特别是因为应用程序中实际上没有发生任何事情(并且没有进行 UI 更新)。

有什么好的方法可以深入了解正在发生的事情吗？我知道发生了一些不应该发生的事情(看起来必须有某种繁忙的等待或其他失控的循环)，但是分析器没有给我任何我期望的结果。我的下一步将是开始在各个地方添加调试跟踪语句，以尝试追踪实际发生的情况，但我觉得必须有更好的方法。

Answer 1

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

手动 < mycomponent enterFrame=""> 事件响应或通过 component.addEventListener(Event.ENTER_FRAME, myfunc) 手动添加的事件响应

callLater() 调用，这些在框架中发生很多，并且可能是跳下任意数量的兔子洞的副产品，开发人员倾向于使用这些来解决与时序相关的问题，有时糟糕的代码会导致这些继续调用每一帧。例如，在最新的 flex sdk 版本中有大约 120 次 calllater() 出现。

最后，我不能保证 [enterframeEvent] 只处理 enterframe 特定的事件回调，而不是计时器、鼠标等事件，因为 enterframes 发生在主事件循环期间，您可能会看到所有事件触发的累积结果从主事件池。我不是说这就是正在发生的事情，但我也不能说这不是正在发生的事情，我对那里的内部结构了解得不够确定。

/edit 也如前所述，[enterFrameEvent] 技术上应该在每帧开始时在内部触发，但它不应该做任何事情，除非事件已明确附加到它以执行用户代码。