Flash Memory cleanup

The garbage collection (GC) of Flash Player is run in two modes: Reference Counting and Mark Sweeping ).

The reference counting method calculates the number of references pointing to an object to determine whether to clear the object. If the number of references to an object is 0, the object is cleared if the program cannot access the object again. If the reference count is not 0, the object is not cleared. The running cost of this method is small, but this method cannot clear the object set with a circular reference relationship. The mark-clearing method starts from the root object of the program and traverses the objects pointed to by each reference. Mark the retrieved object. Finally, clear all unmarked objects. This method is relatively thorough, but the operation cost is high.

The GC running time of Flash Player is not fixed. It determines the GC running time based on your memory usage. It sets a threshold value based on the memory value of the user's machine, and then stores the amount of memory occupied by the program about the threshold value.

For details, see the article "Understanding garbage collection in Flash Player 9 ".

Because of the "uncertain" GC mechanism such as flash player, the main task we need to do is to ensure that the created object can be released when it is not needed. The principle of ensuring that an object can be released is that there is no external reference pointing to this object, except in general, the external reference is not explicitly set to null, objects cannot be released in the following situations:

1. events not listened for by remove. For example, if object A listens to an Event and the listening function (Event Handler) exists in object B, It is equivalent that object A will save A reference to the method of object B, the memory of object B cannot be released.
Solution: remove the listener event, or set the listener function to weak reference when addEventListener () is called. However, this method is only applicable to one-time listeners.

2. After BindingUtils. bindSetter () and ChangeWatcher. watch () are bound to an object, the binding is not cleared. In principle, 1 binds an object, that is, listening to its PropertyChange event.
Solution: Use changewatcher. unwatch () to clear the binding relationship.

3. The style is declared and embedded resources are used in the style. For example, the style name is defined in the <mx: style> label. An object defines a style, which is equivalent to declaring a globally available style. Therefore, the reference of this object is stored externally, and the object may not be released.
Solution: There are many solutions. You can use Dynamically Loaded styles, or use a class or module to manage styles. These solutions depend on the architectural design of the program.

4. Use externalinface. Callback () to declare external API functions. Similar to Case 1, when an object declares an API, it stores a reference pointing to the object.
Solution: If externalinface. Callback ("apiname", functionname) is used to declare an API, you can use externalinface. Callback ("apiname", null) to cancel the API.

5. some controls (like textinput), or custom components composed of these controls, even if the focus is on these controls, even if they are removed from the displaylist and the reference is deleted, these control objects cannot be released. This problem was also raised by a bug (http://bugs.adobe.com/jira/browse/SDK-14781 ). This problem is estimated to be related to the Flash focus management mechanism.
Solution: the current solution can only be to wait for the focus to be transferred to another control (for example, click another control), so that the previous control object can be released by GC.

When should we prepare for garbage removal? Some previous articles have suggested that you should listen to the removefromstage event of the component and make preparations for garbage cleaning in its handling method (such as clearing references, deleting listeners, clearing binding relationships, and canceling external APIs ).
In fact, this method is not accurate. Because the removedfromstage event is sent when the component is removed from the displaylist, it does not mean that the life cycle of the component object has ended. As long as the program retains the reference of this component object, you can add this component object to displaylist again (This component object will issue an addedtostage event ). If you do garbage cleaning preparation for this object in the listening function of the removedfromstage event, when the component is used again, the original state of the component object may be damaged and cannot be used.
Therefore, a better practice is to use the correspondence between addedtostage and removedfromstage to execute the garbage cleanup preparation (clear reference, delete listener, clear binding relationships and cancel external API operations ), in the addedtostage event processing method, execute the reverse operation of the removedfromstage event processing method (set reference, add listener, set binding relationship, set API... it can also be considered as the initialization operation of a component object). This ensures that a component object is removed from the displaylist and the corresponding memory can be released. If the reference is saved, and add it to displaylist again.

Finally, I will translate some suggestions on memory cleanup:

Original article:

1. Usage of instance members instead of static members can easily be detected with the profiler (replace by static members where possible)

2. Usage of weak references and/or removal of eventlisteners after consumption of the event (if posible) helps tuning cing the memory usage

3. moduleloader. unloadmodule leaks memory, use moduleloader. url = NULL instead

4. module memory is freed at arbitrary times (not at unload)

5. runnning debug version of modules leaks huge amounts of memory no matter which container is used

6. declaring modules as modules in the configuration of a flex builder 3 project (and not as applications like in FlexBuilder 2) and optimizing for a specific application reduces module size drastically

7. forcing garbageCollection (double LocalConnection. connect hack) is necessary in order to measure leaks and to keep memory under control

8. use the release version of the module swf

9. uninstall the debug flash player ("uninstall_flash_player.exe ")

10. install the release version of the flash player ("install_flash_player_active_x.msi ")

The following is the translation content:

1. using instance members instead of static members can be easily checked by profiler. therefore, try to use instance members instead of static members.

2. After the event is completed, set it as a reference and/or (and/or) remove it to reduce memory usage.

3. moduleloader. unloadmodule () may cause memory leakage. Therefore, we recommend that you use moduleloader. url = NULL.

4. The module memory release time is uncertain (not during unload ).

5. Using the debug module may cause a large amount of memory leakage, regardless of whether the container is used or not.

6. Declare a program block as a module instead of an application, and set each module to be optimized for an application to save a lot of memory.

7. When appropriate, you can use the garbagecollection to control the memory. The method is as follows:
Try {

Import flash.net. localconnection;

VaR conn1: localconnection = new localconnection ();

VaR conn2: localconnection = new localconnection ();

Conn1.connect ("GC ");

Conn2.connect ("GC ");

} Catch (E: Error ){}

8. Use the module SWF of the release version.

9. Uninstall the Flash Player of the debug version.

10. Install the Flash Player of release.

Reference:

1. Understanding garbage collection in Flash Player 9 (http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html)

2. FLEX memory release optimization principles (http://xinsync.xju.edu.cn/index.php/archives/1825)

3. Garbage Collection and Memory Leaks (http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html)

4. memory leak when using TextInput and TextArea when click the keyboard (http://bugs.adobe.com/jira/browse/SDK-14781)

Source: http://binary-house.spaces.live.com/blog/cns! A2B1EFCF718495C4! 269. entry