Flash Memory Management (Ellis)

-

Thursday, September 6th, 2007

References

When you assign a value of a simple type to a variable, the variable actually stores the value (i.e., myNum = 5, myNum actually equals 5). Variables that point to objects are different. Instead of storing the object in the variable, the object exists somewhere else in memory. The variable just stores the address of the object. That address pointing to the object is called a reference.

var mySprite = new Sprite();

This 1) creates a new Sprite object, 2) creates a new variable named mySprite, 3) stores a reference to that new object in the mySprite variable.

Keeping Track of and Removing References

Objects take up memory so you should delete them when they’re no longer going to be used.There are two kinds of references, strong and weak. For an object to be deleted in Flash 9 you need to get rid of all the strong references to it. There are five things that hold references to objects:

• Class variables – these are variables that are declared in a class file (.as or .mxml). Class variables can not be deleted. To remove a reference from a class variable you can either assign the variable a difference object reference (i.e., mySprite = myOtherSprite) or set the variable to null (i.e., mySprite = null)
• Dynamic variables – If a class is dynamic that means that variables can be added to an instance of the class while the program is running. The variable that is added is called a dynamic variable (i.e., Object is a dynamic class so you can add variables to it like this: var obj = new Object(); obj.myNewSprite = new Sprite(), where myNewSprite is the dynamic variable). Dynamic variables can be deleted (delete obj.myNewSprite). They can also be set to null.
• Local variables – You can make a local variable with the “var” keyword inside a function. Parameters are also local variables. When the function is finished they are discarded automatically, so you don’t need to worry about deleting them.
• Event Listeners – When you add a listener to an object for a specific event (i.e., a mouse click is an event), that object will hold a reference to the object that the listener function lives on (i.e., stage.addEventListener(MouseEvent.CLICK, mySprite.onMouseClick); stage will keep a reference to the object that the onMouseClick function lives on, in this case that object is mySprite). There are two ways that you can manage this reference. When you’re done listening to the event you can remove the listener (i.e., stage.removeListener(MouseEvent.CLICK, mySprite.onMouseClick)) this will remove the reference to mySprite from the stage object). The other thing you can do is use a weak reference to the listener function by setting the last parameter in the addEventListener function to true (i.e., stage.addEventListener(MouseEvent.CLICK, mySprite.onMouseClick, false, 0, true)). See the next section on Garbage collection for why using a weak reference works.

Best practice tip: You should remove your listener (i.e., stage.removeListener…) regardless of whether or not your reference to the listener function is strong.

• Bindings – Binding is a way to add an event listener for when a variable changes value. Tyler has covered this one.

Garbage Collection

When Flash needs more memory, before it asks for more memory from the system it runs garbage collection. Garbage collection uses a mark and sweep method where it runs through all the objects and marks the ones that aren’t being used then later sweeps them away (removes them from memory). The garbage collection says that an object isn’t being used anymore when there are no strong references to it that tie it to the global object. So if the global object has a direct strong reference to the object (i.e., global.mySprite) or a indirect strong reference to it (i.e., global.myObj.mySprite) then that object will stay in memory. If there are no more strong references to the object or there are only weak references to it, then the object will be marked for deletion.Garbage collection is iterative, which means that it doesn’t run through it’s whole process every time. So the object may stay in memory for a while even when it has been marked for deletion. Eventually it will be removed from memory.–Ellis

Flash Memory Management (Ty)

-

Wednesday, September 5th, 2007

Flash Player 9 has a powerful Virtual Machine that runs ActionScript 3 at speeds worthy of high-end applications while managing memory automatically. To help keep up that performance and minimize unused memory there are some basic principles to remember when building those applications.ActionScript 3 manages memory using a method called “mark and sweep”, which effectively removes data that isn’t referenced by any other part of the application. As long as all references to a piece of data are removed (pointers set to null or assigned to another piece of data) the data can be cleared and the memory freed. However there are often unnoticed references or “memory leaks” that can compound and eventually slow and crash any system. Following are the principles and techniques to keep in mind while building up Flex and Flash applications:

• architect and code your application using good object oriented principles such as abstraction, composition, loose coupling, etc
• identify the parts of the application that have frequent clearing of data (particularly DisplayObjects, these are often expensive in terms of memory)
• identify and limit the number of references to a particular object (the principles of abstraction and “black box” strengthen your ability to limit these)
• use weak referenced listeners and bindings everywhere that makes sense (if in question, use everywhere)
• give objects that will be removed a cleanUp() method where they can remove listeners and clean up bindings
• avoid listening or binding to objects outside of yourself except in manageable cases, such as a global data source
• don’t use the Flex PopupManager

By following these principles and techniques you will be able to avoid most common memory problems. Flex has a built in profiler that will help you identify the remainder of memory and performance issues and help you know where to spend your time in optimization.Code responsibly.– Tyler

Welcome

-

Wednesday, September 5th, 2007

Contribute. Share. Learn. Brag about foosball victories. Get some feedback on a design. Decry the quirks of Internet Explorer. Display your last freelance project. Ask a design question. Make an announcement. Demonstrate code skillz.Please register (or email me some content) so I can mark you as an Author/Contributor on the mediaRAIN development blog.(I highly recommend keeping tabs on the posts here – and the comments on them – with RSS)