I was told that there is an increase in performance when using Canvas versus HBox or VBox when laying out out the position of children. As a result, a number of our components have been converted over to using Canvas. However, now there is code being added to calculate the x and y positioning of some of the child elements based off of the width and height of other children. Is it worth using a Canvas to increase performance if code needs to be added to determine the coordinates/positions of the children? Is there a better method or technique available that should be practiced other than just minimizing the number of ui components added and specifying positioning absolutely?
有人告诉我,当布局儿童的位置时,使用Canvas与HBox或VBox时性能会有所提高。因此,我们的许多组件已转换为使用Canvas。但是,现在添加了一些代码,用于根据其他子项的宽度和高度计算某些子元素的x和y位置。如果需要添加代码来确定子项的坐标/位置,是否值得使用Canvas来提高性能?是否有更好的方法或技术可以实现,而不仅仅是最小化添加的ui组件数量并绝对指定定位?
3 个解决方案
#1
There are a number of middle-of-the-road techniques, one of which is to use rendering-type components, such as TileGrid or ItemRenderers, if your layout fits a certain formula. If you're using forms, try using the Form layout component instead of using a custom layout.
如果您的布局符合某个公式,则有许多中间技术,其中一种是使用渲染类型的组件,如TileGrid或ItemRenderers。如果您正在使用表单,请尝试使用表单布局组件,而不是使用自定义布局。
If you do need to use the layout engine in Flex, the way to optimize your usage is to remember that certain techniques are used by the framework in increasing performance load, loosely following the below list, the last being the most performance intensive:
如果确实需要在Flex中使用布局引擎,那么优化使用的方法是记住框架在增加性能负载时使用某些技术,松散地遵循以下列表,最后一个是性能最高的:
- absolute positioning (
<Canvas>) - relative positioning (
<VBox>) - constraint-based positioning (
right=0) - advanced constraint-based positioning (
<constraintColumns>)
绝对定位(
相对定位(
基于约束的定位(右= 0)
高级基于约束的定位(
Using relative positioning is usually not that performance intensive. If you are finding that it is, it could be that you're using too many nested containers. Look at your layout architecture and try to find out ways in which your objects may be "over-laid out", and simplify them. A good tool for this is FlexSpy, which lets you introspect object layout at runtime.
使用相对定位通常不是性能密集型的。如果您发现它是,那可能是您使用了太多嵌套容器。查看您的布局体系结构,并尝试找出对象可能被“覆盖”的方式,并简化它们。一个很好的工具是FlexSpy,它允许您在运行时内省对象布局。
Another common performance bottleneck is that your application is attempting to do some number-crunching at the exact same time that your GUI is attempting to respond to user interaction. Although no green threading frameworks exist at the moment which enable you to run UI and logic in separate 'threads', you can use a good architectural framework such as Cairngorm or Mate (there are many) which uses Commands instead of straight up methods, so that functionality execution which may take up processing cycles waits until the UI has finished responding to the user.
另一个常见的性能瓶颈是您的应用程序试图在GUI尝试响应用户交互的同时进行一些数字运算。虽然目前不存在绿色线程框架,使您能够在单独的“线程”中运行UI和逻辑,但您可以使用一个好的架构框架,例如Cairngorm或Mate(有很多)使用命令而不是直接方法,所以可能占用处理周期的功能执行等待UI完成对用户的响应。
#2
A couple things you want to keep in mind while optimizing a Flex UI:
在优化Flex UI时,您需要记住几件事:
-
Avoiding excessive nesting of containers. Consider using a Canvas with absolute or constraint-based positioning over nesting lots of HBox / VBox elements. However this doesn't mean you should NEVER use VBox/HBox. You can mix and match, such as using a Canvas as the main container and positioning child Boxes inside them as needed, just try to avoid too much nesting.
避免过多的容器嵌套。考虑使用基于绝对或基于约束的定位的Canvas来嵌套大量HBox / VBox元素。但这并不意味着你永远不应该使用VBox / HBox。您可以混合和匹配,例如使用Canvas作为主容器,并根据需要在其中放置子框,只是尽量避免过多嵌套。
-
Using the UIComponent model properly in custom components. In particular, using invalidateProperties(), invalidateSize() and invalidateDisplayList() so that their companion functions (commitProperties(), measure() and updateDisplayList()) are invoked at an optimal time for the Flash Player. Deepa gives a great talk about this here:
在自定义组件中正确使用UIComponent模型。特别是,使用invalidateProperties(),invalidateSize()和invalidateDisplayList(),以便在Flash Player的最佳时间调用其伴随函数(commitProperties(),measure()和updateDisplayList())。 Deepa在这里给出了一个很好的讨论:
http://tv.adobe.com/#vi+f15384v1002
She explains how making heavy use of the invalidation scheme allows the Flash Player to execute your code at an ideal time, i.e. not in the middle of a screen update. These principles are used by all Flex components and can/should be leveraged regardless of the framework being used.
她解释了如何大量使用失效方案允许Flash Player在理想的时间执行代码,即不在屏幕更新的中间。所有Flex组件都使用这些原则,无论使用何种框架,都可以/应该利用这些原则。
#3
To make sure I understand:
为了确保我理解:
- You heard that Canvas can position children faster than [VH]Box
- Canvas only does absolute positioning
- Some (many?) of your components have an absolute position, so you switched to using Canvas
- But some of your components have a relative position, so you need to write code to position them
您听说Canvas可以比[VH] Box更快地定位孩子
Canvas只做绝对定位
一些(很多?)组件具有绝对位置,因此您切换到使用Canvas
但是您的某些组件具有相对位置,因此您需要编写代码来定位它们
Is that correct?
那是对的吗?
Anyway, assuming I'm correct (which may not be the case), the first thing you want to do is pick the functioning interface which requires the fewest lines of code, then decide if it's "good enough". You want the one with the fewest lines of code because studies have shown that there is a correlation between lines of code and number of bugs (and you don't want bugs). You want to see if it's "good enough" because, if it IS "good enough", you don't need to do anything (if you do try and make it faster, you're committing Premature Optimization).
无论如何,假设我是正确的(可能不是这种情况),你要做的第一件事是选择需要最少代码行的功能界面,然后决定它是否“足够好”。您希望代码行数最少,因为研究表明代码行和错误数量之间存在关联(并且您不需要错误)。你想看看它是否“足够好”,因为如果它“足够好”,你就不需要做任何事情(如果你试图让它更快,那么你就是在进行早熟优化)。
But that's probably not what you wanted to hear :)
但那可能不是你想听到的:)
So I'll also suggest that, if you want to stick with Canvas-based layout, you try sticking all the relatively positioned content inside [VH]Boxes, which are then absolutely positioned inside the Canvas. There's a good chance the code Adobe has written is faster than code, so you should try to take advantage of it.
所以我还建议,如果你想坚持使用基于Canvas的布局,你可以尝试将所有相对定位的内容粘贴在[VH] Box中,然后绝对定位在Canvas中。 Adobe编写的代码很可能比代码更快,因此您应该尝试利用它。
But the only way to know for sure is to try it and profile it.
但唯一可以确定的方法是尝试并对其进行分析。
#1
There are a number of middle-of-the-road techniques, one of which is to use rendering-type components, such as TileGrid or ItemRenderers, if your layout fits a certain formula. If you're using forms, try using the Form layout component instead of using a custom layout.
如果您的布局符合某个公式,则有许多中间技术,其中一种是使用渲染类型的组件,如TileGrid或ItemRenderers。如果您正在使用表单,请尝试使用表单布局组件,而不是使用自定义布局。
If you do need to use the layout engine in Flex, the way to optimize your usage is to remember that certain techniques are used by the framework in increasing performance load, loosely following the below list, the last being the most performance intensive:
如果确实需要在Flex中使用布局引擎,那么优化使用的方法是记住框架在增加性能负载时使用某些技术,松散地遵循以下列表,最后一个是性能最高的:
- absolute positioning (
<Canvas>) - relative positioning (
<VBox>) - constraint-based positioning (
right=0) - advanced constraint-based positioning (
<constraintColumns>)
绝对定位(
相对定位(
基于约束的定位(右= 0)
高级基于约束的定位(
Using relative positioning is usually not that performance intensive. If you are finding that it is, it could be that you're using too many nested containers. Look at your layout architecture and try to find out ways in which your objects may be "over-laid out", and simplify them. A good tool for this is FlexSpy, which lets you introspect object layout at runtime.
使用相对定位通常不是性能密集型的。如果您发现它是,那可能是您使用了太多嵌套容器。查看您的布局体系结构,并尝试找出对象可能被“覆盖”的方式,并简化它们。一个很好的工具是FlexSpy,它允许您在运行时内省对象布局。
Another common performance bottleneck is that your application is attempting to do some number-crunching at the exact same time that your GUI is attempting to respond to user interaction. Although no green threading frameworks exist at the moment which enable you to run UI and logic in separate 'threads', you can use a good architectural framework such as Cairngorm or Mate (there are many) which uses Commands instead of straight up methods, so that functionality execution which may take up processing cycles waits until the UI has finished responding to the user.
另一个常见的性能瓶颈是您的应用程序试图在GUI尝试响应用户交互的同时进行一些数字运算。虽然目前不存在绿色线程框架,使您能够在单独的“线程”中运行UI和逻辑,但您可以使用一个好的架构框架,例如Cairngorm或Mate(有很多)使用命令而不是直接方法,所以可能占用处理周期的功能执行等待UI完成对用户的响应。
#2
A couple things you want to keep in mind while optimizing a Flex UI:
在优化Flex UI时,您需要记住几件事:
-
Avoiding excessive nesting of containers. Consider using a Canvas with absolute or constraint-based positioning over nesting lots of HBox / VBox elements. However this doesn't mean you should NEVER use VBox/HBox. You can mix and match, such as using a Canvas as the main container and positioning child Boxes inside them as needed, just try to avoid too much nesting.
避免过多的容器嵌套。考虑使用基于绝对或基于约束的定位的Canvas来嵌套大量HBox / VBox元素。但这并不意味着你永远不应该使用VBox / HBox。您可以混合和匹配,例如使用Canvas作为主容器,并根据需要在其中放置子框,只是尽量避免过多嵌套。
-
Using the UIComponent model properly in custom components. In particular, using invalidateProperties(), invalidateSize() and invalidateDisplayList() so that their companion functions (commitProperties(), measure() and updateDisplayList()) are invoked at an optimal time for the Flash Player. Deepa gives a great talk about this here:
在自定义组件中正确使用UIComponent模型。特别是,使用invalidateProperties(),invalidateSize()和invalidateDisplayList(),以便在Flash Player的最佳时间调用其伴随函数(commitProperties(),measure()和updateDisplayList())。 Deepa在这里给出了一个很好的讨论:
http://tv.adobe.com/#vi+f15384v1002
She explains how making heavy use of the invalidation scheme allows the Flash Player to execute your code at an ideal time, i.e. not in the middle of a screen update. These principles are used by all Flex components and can/should be leveraged regardless of the framework being used.
她解释了如何大量使用失效方案允许Flash Player在理想的时间执行代码,即不在屏幕更新的中间。所有Flex组件都使用这些原则,无论使用何种框架,都可以/应该利用这些原则。
#3
To make sure I understand:
为了确保我理解:
- You heard that Canvas can position children faster than [VH]Box
- Canvas only does absolute positioning
- Some (many?) of your components have an absolute position, so you switched to using Canvas
- But some of your components have a relative position, so you need to write code to position them
您听说Canvas可以比[VH] Box更快地定位孩子
Canvas只做绝对定位
一些(很多?)组件具有绝对位置,因此您切换到使用Canvas
但是您的某些组件具有相对位置,因此您需要编写代码来定位它们
Is that correct?
那是对的吗?
Anyway, assuming I'm correct (which may not be the case), the first thing you want to do is pick the functioning interface which requires the fewest lines of code, then decide if it's "good enough". You want the one with the fewest lines of code because studies have shown that there is a correlation between lines of code and number of bugs (and you don't want bugs). You want to see if it's "good enough" because, if it IS "good enough", you don't need to do anything (if you do try and make it faster, you're committing Premature Optimization).
无论如何,假设我是正确的(可能不是这种情况),你要做的第一件事是选择需要最少代码行的功能界面,然后决定它是否“足够好”。您希望代码行数最少,因为研究表明代码行和错误数量之间存在关联(并且您不需要错误)。你想看看它是否“足够好”,因为如果它“足够好”,你就不需要做任何事情(如果你试图让它更快,那么你就是在进行早熟优化)。
But that's probably not what you wanted to hear :)
但那可能不是你想听到的:)
So I'll also suggest that, if you want to stick with Canvas-based layout, you try sticking all the relatively positioned content inside [VH]Boxes, which are then absolutely positioned inside the Canvas. There's a good chance the code Adobe has written is faster than code, so you should try to take advantage of it.
所以我还建议,如果你想坚持使用基于Canvas的布局,你可以尝试将所有相对定位的内容粘贴在[VH] Box中,然后绝对定位在Canvas中。 Adobe编写的代码很可能比代码更快,因此您应该尝试利用它。
But the only way to know for sure is to try it and profile it.
但唯一可以确定的方法是尝试并对其进行分析。