Flex 性能注意事项
为了提高 Flex 应用程序的性能,Flex 开发人员应该记住哪些主要要点? 我想到的是:
- 从更轻量级的基类扩展 ItemRenderers:即 UIComponent
- 动画
- 使用 suspendBackgroundProcessing 设置为 true,以便在适当的情况下使用 ArrayList 而不是 ArrayCollections 进行
- 。 Spark DataGroups 中的 useVirtualLayout(不幸的是,此步骤需要 Scrollers 才能使此建议有效)
- 针对 AIR 应用程序(事务等)的 SQLight 性能优化
- 可能会将长数据处理拆分为不同的帧? (虽然我从未这样做过,所以我可能会弄错)
在开发 Flex3/Flex4/AIR 应用程序以提高其性能时,您尝试遵循的关键准则是什么?
What are the main key-points a Flex developer should remember in order to improve performance of Flex applications?
The ones which come to my mind are:
- extending ItemRenderers from more lightweight base classes: i.e. UIComponent
- using suspendBackgroundProcessing set to true for animations
- using ArrayLists instead of ArrayCollections where appropriate.
- useVirtualLayout in Spark DataGroups (unfortunately this step requires Scrollers to make this advice effective)
- SQLight performance optimizations for AIR apps (transactions etc)
- Probably splitting long data processing into different frames? (Never done this though, so I might be mistaken)
What are the key guidelines you try to follow while developing your Flex3/Flex4/AIR applications in order to increase their performance?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
在我看来,很多人都存在 itemRenderer 的性能问题。所以,我的一个贡献是永远不要使用绑定 itemRenderer。我修复了很多客户的“内存泄漏”错误,只需重写他们的 itemRenderer 以使用 dataChange 事件而不是绑定。
除此之外,我赞同 @Wade Mueller 关于尽可能避免嵌套容器的评论。
It seems to me a lot of people have performance issues w/ itemRenderers. So, my one contribution here to never use binding an itemRenderer. I fix a lot of customer "memory leak" bugs just by rewriting their itemRenderers to use the dataChange event instead of binding.
Beyond that, I second @Wade Mueller's comment about avoiding nested containers as much as possible.
尽管这对于重量较轻的 Spark Group 来说不太重要,但我总是尝试将嵌套容器的数量保持在最低限度,并在可能的情况下设置明确的位置/大小。具有相互嵌套的动态大小容器的复杂 UI 会导致必须进行大量(通常是不必要的)测量。这通常会导致在视图之间切换时出现巨大的滞后。
Although this is less important with the lighter weight Spark Groups, I always try to keep the number of nested containers to a minimum and set explicit positions/sizes when possible. Complicated UIs with dynamically sized containers nested within one another cause a ton of (usually unnecessary) measuring to have to occur. This often results in huge lags when switching between views.
我的清单:
它Автор,а ты русский язык знаешь? :)
My list:
P.S. Автор, а ты русский язык знаешь? :)
我考虑的主要事情(按重要性顺序排列):
绑定
创建大量额外代码,如果不删除绑定,可能会导致性能严重下降。例如,如果您在应用程序中重用组件,则监听函数在应用程序的整个流程中都会处于活动状态,从而消耗不必要的内存和 CPU 周期。对于较大的应用程序,请考虑 BindingUtils 类。
请注意,您无法解除用大括号绑定的属性
{myVariable}
验证(无效)调用是 Flex 中最昂贵的调用之一。使用它们时要小心。
validateNow();
了解 Flex 组件生命周期。重写这些方法可以简化实例化过程。
使用向量对象。 更多信息。
一些更基本的提示:
不要在循环中使用昂贵的操作。
对于
massiveArray
(一个非常大的数组)来说,length() 可能是一个昂贵的操作。分配 var MassArrayLength:int = MassArray.length; 以提高性能。http://jacksondunstan.com/ 有大量有关优化代码的文章。这个人是个天才。
避免创建不必要的变量,因为实例化的成本很高。如果可能,请始终重用变量。
相反,请立即返回。
如果您有权访问它,Flash Profile 视角就是您的朋友。它是一个功能强大的分析器,可以减少优化代码库所需的时间。
The main things I consider, in order of importance:
Binding
Creates a lot of extra code, and can cause a serious degradation in performance when bindings are not removed. For example, if you reuse components in an applications, listening functions are active throughout the entire flow of your application, consuming unnecessary memory and CPU cycles. For larger applications consider the BindingUtils class.
Note that you cannot unbind properties bound with curly braces
{myVariable}
Validate (invalidate) calls are some of the most expensive calls in Flex. Be careful when using them.
validateNow();
Understand the Flex component lifecycle. Overriding these methods can streamline the instantiation process.
Use Vector objects. More information.
Some more basic tips:
Do not use expensive operations in loops.
In the case of
massiveArray
, a very large array, length() might be an expensive operation. Assignvar massiveArrayLength:int = massiveArray.length;
to improve performance.http://jacksondunstan.com/ has a wealth of articles on optimizing your code. The man is a genius.
Avoid creating unnecessary variables, as instantiation is expensive. Always reuse variables if possible.
Instead, just return immediately.
If you have access to it, the Flash Profile perspective is your friend. It's a powerful profiler that can reduce the time involved in optimizing a codebase.