Flex 渲染性能
最近我发现可以采取多种措施来大幅减慢 Flex 应用程序的速度。其中之一是使用许多嵌套布局容器。另一件非常成问题的事情是大量相对定位和尺寸的使用。
我确实知道在显示布局元素之前必须完成大量计算。我不明白的是为什么渲染总是完成。当布局具有一定的复杂性时，即使布局没有变化，CPU 使用率也始终为 100%。
这是为什么？我该怎么办（无需重做整个布局）？
多谢！
Recently I found out that there are several things that one can do to massivly slowing down a Flex application. One of those things is the use of many nested layout containers. Another thing which is very problematic is the usage of lot's of relative positioning and sizes.
I do understand that there is a very big amount of calculations that must be done before the layout elements can be displayed. What I do not understand is why the rendering is done all the time. With a certain amount of complexity in your layout your CPU usage is 100% all the time even if there are no changes in the layout.
Why is that? And what can I do about that (without redoing the whole layout)?
Thanks a lot!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
确实，嵌套容器确实会减慢速度，但我还无法将 CPU 使用率提高到 100%。框架只应在调用其 invalidateDisplayList() 后重新计算组件的布局。调用此函数会安排对 updateDisplayList 的调用，其中计算容器的布局。因此，该组件的子组件的显示列表也会失效。
除了您自己执行之外，框架还可能因各种原因使 displayList 失效。例如，它总是在 invalidateProperties() 之后失效。可能是您的某些东西意外地始终使某些高级容器的显示列表无效，从而将其传播到其子容器。
您有代码可以分享吗？您正在运行什么样的系统？
It is true that nested containers do slow things down, but I haven't yet been able to get the CPU usage up to 100% yet. The framework should only recalculate the layout of a component after its invalidateDisplayList() has been called. Calling this schedules a call to updateDisplayList, in which the layout of a container is calculated. Consequently, the display lists of the component's children are invalidated as well.
Besides doing it yourself, the displayList can be invalidated by the framework for a variety of reasons. For instance, it is always invalidated after invalidateProperties(). It could be that you have something that accidentally invalidates the display list of some high-level container all the time, thus propagating it down to its children.
Do you have any code to share? And what kind of a system are you running?
除了重构布局并且不使用许多嵌套元素之外的任何其他解决方案都意味着改变 adobe 框架的工作方式，而您不想这样做！
我的建议虽然可能很痛苦，但更改视图组件，尽可能使用绝对大小和位置，不要嵌套太多元素。
嵌套组件瓶颈的原因是 invalidate 函数有两种方式，首先从更改的组件到树根，然后从根到所有其嵌套元素，这会占用您的 cpu。
Any other solution other then refactoring your layout and not use many nested elements means change the way adobe framework works, and you do not want to do it !
My suggestion although might be painfull , change your view components , use absolute size and location where possible , do not nest too many elements .
The reason for the bottle neck with nested components is that the invalidate functions go 2 way , first up the tree from the changed component to the root , then from the root to all its nested elements , that whats taking your cpu .
最后我发现我们的应用程序到底有什么问题！
问题不在于我们使用了很多嵌套布局容器。我发现我们使用了一个第三方组件，它将事件侦听器附加到 ENTER_FRAME-Event。不幸的是，该组件无法正确关闭，因此事件侦听器永远不会被删除。该事件触发的一件事是调用 invalidateDisplayList()。我发现 ENTER_FRAME-Event 经常发生（我仍然不知道为什么会发生这种情况），因此整个布局会一遍又一遍地重新计算。由于布局的嵌套结构，这是一件非常耗时的事情，因此 CPU 变得非常繁忙！
我可以通过向组件添加一些额外的代码来解决这个问题，这些代码可以在不再需要事件侦听器时正确删除它们。其结果是应用程序现在在空闲模式下不需要任何 CPU 功率。万岁！！
Finally I found out what exactly the problem with our application was!
The problem was not that we used lot's of nested layout containers. I found out that there was a third party component that we use which attaches an event listener to the ENTER_FRAME-Event. Unfortunately this component does not shutdown properly so the event listener never gets removed. One thing this event triggers is a call to invalidateDisplayList(). I found out that the ENTER_FRAME-Event occurs very often (I still don't know why exactly this happens) and because of that the whole layout is recalculated over and over again. Because of the nested structure of our layouts this is a very time consuming thing to do and therefore the CPU gets very busy!
I could solve this problem by adding some extra code to the component that properly removes the event-listeners if they are no longer needed. The result of that has been that the application now does not need any CPU-power when in idle-mode. Hooray!!