Flash AS3 Accumulation of three

Http://as3blog.com/as3/as3tip-take-care-of-resource

Abandoned the Attachmovie after the AS3, using a similar dom-like operation. Methods such as AddChild, RemoveChild, getchildat, etc., begin to become the primary method of displaying (rendering on screen) and manipulating graphics in AS3. Since AS1 and AS2 are completely dependent on the idea of Attchmovie, it does take a while for traditional flash developers to switch to a new addchild.

Because the new "Displayobject" is very "sensitive" in the use of memory. Often because of bad programming habits will cause unnecessary memory leaks, therefore, we have to more than the AS1, AS2 era more in-depth to memory management. I think every flash developer, including myself, should spend some time trying to understand the meaning of the word "memory management". After all, we learn AS3 is to develop than AS1, 2 times more advanced, efficient and small memory footprint of the application, if or to develop some simple application, also lose each of us use the meaning of AS3.

I think that because GC is the core of flash application memory management, I should start with the garbage Collector (GC) in AS3. The GC function of AS3 is much more powerful than that of AS1 and 2. However, the powerful at the same time, but also brought a degree of complexity. But not very complex, I think more than C + + and other traditional languages to master more easily.

Before studying how memory is recycled, start by talking about the creation of variables:
In Flash, each time we create a non-primary variable (Boolean, String, number, uint, int these are native variables), the variable name is just a reference (pointing, sometimes becoming "reference"), not the variable itself. For example:
var a:int = 5; A is 5.
var b:int = A; B is a, which is 5.
A = 4;
Trace (b); It's 5, not 4!
Change the value of B, and a does not change. Vice versa
var c:object = {name: "Aw", Blog: "Www.awflasher.com/blog"}; C just points to an internal object, which, for the sake of description, is called "O"
var d:object = c; D points to C, pointing to the same object "O"
C.name = "BW"
Trace (D.name); Not AW, but bw.
changing C or changing D is actually changing that "O", so when you change C, the value of D changes. So D.name has been changed to "BW".

First, make it clear that the GC will perform memory cleanup (memory sweep) in a certain time period. So don't check for system.totalmemory memory after you delete an object and doubt if the GC is normal.

So why should GC be cleaned up in a certain time period? This also has to do with the specific working principle of GC.

GC's two recycling systems:
1, "Reference Counting"-Reference counters
This system, which has been in the system since the AS1 era, works very simply: The system calculates the number of times each object is directed, or cited. For example,
var a:object = {name: "Aw", Blog: "Www.awflasher.com/blog"};
At this point, the object (which we still call "O") has one reference, and its reference counter is 1 (from a).
We then create an object B and point to a:
var b:object = A;
Then the "O" reference counter becomes 2 (from A, b)
We delete one, such as delete b:
Delete b;
This time the reference counter is (2-1=1) 1,GC does not manipulate
and then deletes another a:
delete A;
" O "Reference counter changed to (1-1=0) 0,GC to kill this object.
The system is lightweight and has less CPU pressure. But it also has flaws. When our objects are quoted internally, the trouble comes. For example:
var a:object = {name: "AW", Description: "Unknown"};
Create an object A and still assume that the internal object is "O", at which point the reference number of O is 1
var b:object = {nameobj:a, url: "awflasher.com"};
b references A and creates a new internal object "P". The number of references to O is 2,p 1
a.mydescription = b;
A's mydescription attribute points to B. This way, the number of references to P is also 2.
//Is it a little dizzy? Calm down, draw a picture and take a look:)
Delete A;
Delete B; After the
Two delete operations, the number of references to O and P is 1, and they will continue to occupy your memory. The "Reference Counting" system is powerless.

2, "Mark sweeping"-Mark elimination rule
The first mechanism of the GC, "Reference Counting", is the GC's only mechanism before the FlashPlayer8. FlashPlayer6 and 7 introduced complex OOP development patterns, especially 7, introducing syntax for powerful OOP languages like Java and C + +. More and more complex projects are being designed with flash. Because most flash developers don't understand GC, Java, C + + developers are accustomed to a powerful GC (whether automated or manual). So FlashPlayer6, 7 memory problems are beginning to emerge.
Okay,flash Player8 introduced a new "Mark sweeping" mechanism. I think that's why Marcomedia (Adobe) was based on quitting Player8. (Remember that year FLASH8 video, efficiency improvement is a revolutionary improvement)
Here's how "mark sweeping"-the principle of the tagging purge rule.
Flashplayer starts with root, traverses each variable of the system, and logs a contact between the objects that are pointing. At the end of the traversal, any object that is not associated with Root is Flashplayer mercilessly:
Okay, back to the example just now, when we delete a and delete B, Root and O and P draw the line. At this point, the GC can be cleared once.
However, because this "Mark sweeping" is going to traverse all the objects, it consumes resources very much. This goes back to the original question: "Why should GC be cleaned up in a certain time period?"-because it does not cause too much burden on the CPU.
I personally suspect that the GC's internal purge strategy should be performed after an event, such as delete, occurs when the CPU is more idle and the RAM allocation is relatively reasonable.

Okay, don't think it's all right with "Mark sweeping." Because the GC is not going to happen immediately, your object will "haunt" you for a while! For a perfect developer, this means that some of their internal mechanisms will continue to work after they are deleted: The AS statement continues to execute, the sound continues to play, and the event continues to fire!

Kirupaforum has a netizen to say, "All your got to does is pray the garbage collector doesn ' t break down." And, indeed, if an application is going to run for one hours, then slowly passing memory will allow your users Be disappointed with your product (e.g. games). Therefore, we need to have a good resource management strategy.