Since everything in the Flex framework essentially must be a UIComponent, we'll start with examining some of the inner workings of this class. In this Flexcerpt, we discuss how invalidation is implemented in UIComponent and why it is important when extending existing components or creating your own.
Invalidation is based on the premise that all displayable objects (anything that is a DisplayObject) are only drawn to the stage once every frame (since Flash is timeline based). In a nutshell, invalidation refers to delaying the drawing of a component until the next frame, so that we save processor cycles by only running that draw code once. "Drawing" can refer to things such as sizing (including measuring), displaying text, updating a skin, or changing any visible property of a component.
For example, what if the height value of a component was set 3 times during the same frame? If the component were to "redraw" itself immediately every time the height value was changed, it would be drawing 3 times, when it really only needs to draw itself once based on the last value that was set in that code block. This is a simple example, but when you consider that within the framework, there may be hundreds of lines of code executing when components are drawn (depending upon the complexity of your app), obviously, we want to prevent unnecessary redraws whenever we can. Enter invalidation...
There are 3 invalidation methods implemented in the framework:
- invalidateProperties (commits properties)
- invalidateSize (does measuring)
- invalidateDisplayList (does layout)
These methods are called interally within Flex components when the component has something done to it that requires it to be redrawn. Often, more than one of these will be called within the same method. Here is an overview of the code execution that occurs with each of the invalidation methods (not all called methods are shown here to simplify things a bit):
> UIComponent.invalidateProperties() > LayoutManager.invalidateProperties() > enterFrame/render > LayoutManager.validateProperties() > UIComponent.validateProperties() > UIComponent.commitProperties()
>UIComponent.invalidateSize() > LayoutManager.invalidateSize() > enterFrame/render > LayoutManager.validateSize() > UIComponent.validateSize() > UIComponent.measureSizes() > UIComponent.measure()
>UIComponent.invalidateDisplayList() > LayoutManager.invalidateDisplayList() > enterFrame/render > LayoutManager.validateDisplayList() > UIComponent.validateDisplayList() > UIComponent.updateDisplayList()
As you can see, the flow is very similar among these methods. So why does this really matter? Well, here are a few things I took from this:
- When extending components, the methods that you want to override if you want to draw things to your custom components are the ones at the END of the execution order, so specifically, "measure", "updateDisplayList" and "commitProperties". You can be assured that these methods will be called when needed to redraw the component. Don't forget to call the super's overriden method.
- When creating methods/properties in your component that will result in needing to redraw the component, make sure you call one of the invalidation methods. If the size is changing, call invalidateSize. If you want to update a text label, call invalidateProperties (and possibly invalidateSize and invalidateDisplayList if your label could have an impact on how your component is sized).
- Its important to note that if more than 1 of these invalidation methods gets called before the next frame, they will execute in the order above (ie., commit properties, then measure, then layout).
- Layout management plays a big role in all of this and is definitely worthy of a set of posts on its own. However, gist of it appears to be that measurement occurs "inside-out" and layout occurs "outside-in". So when measuring components for resize, the framework starts with the deepest nested child component and works up the parent chain, and once that's complete, it starts with the topmost parent and lays out its children, who then lay out their children, etc.
- Container based components also call Container.layoutChrome() from within updateDisplayList(). This is the method that draws any appropriate chrome around the container. Override this method when creating a container with custom graphics.
- Skins are generally drawn in the updateDisplayList method.
- Delaying drawing until the next frame is fine, but delaying properties (for example, TextInput.maxChars) could pose a problem because there will often be times when you need to set the value of a property then access that property's value before the next frame. So the solution is to store the value as a private variable that the getter will return, so if you need to retrieve the value, you're getting the correct value back. Once the next frame rolls around, then the value is actually set on the component (for example, maxChars gets set on the TextField contained within the TextInput).
- Related to the previous, when commitProperties is run, we need to know WHICH properties have been updated so that we don't do a wholesale property update on the component, and again use unnecessary cycles. The solution used in the framework is to set a flag within the component telling it which property has been updated (in the above example, "maxCharsChanged" is the flag), and then put your property commit code inside of an "if" statement that only runs if the flag is set to true. Could result in some longwinded code if you have a lot of properties, but it works.
To follow are more tidbits on UIComponent and examples of how to utilize these bits.
Please feel free to add your thoughts in the comments.
扫一扫
4052
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
