Flex Tutorial: memory usage

In this flex tutorial, we talk about some memory usage problems: the memory problem has always been a concern of programmers and also reflects the robustness of the program. for C/C ++ and other C languages, programmers should be cautious about the memory used by the program. Otherwise, it is easy to cause memory leakage and slow or even invalid program running. java and other object-oriented languages use a memory management mechanism called garbage collection, which greatly frees programmers from tedious memory management. however, we should not take it lightly. If this mechanism is used blindly, the program execution efficiency will be low, and there may even be great risks. this article attempts to introduce how to correctly and efficiently handle memory problems from the perspective of ActionScript, and attempts to provide you with an efficient method to build rich client programs.

Flash Player (itself an AVM, as virtual machine) garbage collection is completed by the garbage collector. The garbage collector is a process running in the background. It releases the memory occupied by objects no longer used by applications. Objects that are no longer used by applications are those that are no longer "referenced" by those active (working) objects. In as 3,

For objects of non-basic types (Boolean, String, number, uint, INT), object references are passed between objects, rather than the object itself. Deleting a variable only deletes the object reference, rather than deleting the object itself. An object can be referenced in multiple places. All these different references operate on the same object. For example:

 

Although O1 is set to null, the instance to which it points in the memory may not be deleted. this depends on the running status of the garbage collector. another typical example is that after you add a certain number of visual components to the Container Using addchild (), you intend to use the removechild () method to remove the container, although it seems that the visual components are "deleted" from the interface, but everything is not as expected, these visual components are still in the memory, and there is a serious memory leakage, we did not hear it!

For this reason, I plan to discuss the memory issue of actionscript3 in the following aspects:

 

I. AVM garbage collection mechanism

For non-basic types of objects (basic types include Boolean, String, number, Int, uint), AVM uses two methods to determine whether an object is an active reference, to determine whether the memory should be recycled

(1) reference counting method: this is a simple but effective method. After you create a reference to an object, the reference count of the object is increased by 1. After you delete a reference, the reference count of the object is reduced by 1. If the reference count of an object changes to 0, the garbage collector can delete the object from the memory. However, when circular references occur between objects, although they are no longer used by each other, their reference count is still greater than 0, so they cannot be recycled.

(2) Mark clearing: AVM traverses all references on the application's root node and marks each object it discovers. Then iterate through each marked object and mark their sub-objects. After the process ends, if no marked object exists in the memory, it indicates that the object has no active reference, so you can safely "Smash" them ".

 

The tag clearing mechanism is very accurate, but this Recursive Execution greatly increases the CPU load. Therefore, to reduce this overhead, AVM only occasionally executes this method when needed to find invalid objects.

Note: The reference mentioned above refers to "strong reference". Flash Player ignores "weakness reference" during mark clearing, that is, weak reference during mark clearing

It is not referenced and does not stop garbage collection.

By default, AVM executes garbage collection before Flash Player requires additional memory. That is, real garbage collection is triggered only when flash memory usage reaches a certain level. We need to clarify two points: When a really executes garbage collection is unpredictable; B garbage collection is always triggered when the memory is tight, rather than when the object is deleted.

 

Ii. Memory leakage

We often unconsciously make the following Memory leakage errors during development:

A. Objects referenced by global objects do not need to be used again, but forget to clear references to them from global objects. Common global objects include stage, main Application, and static members of the class.

B. Unlimited triggering of Timer will cause memory leakage .. No matter whether the infinitely triggered Timer is a global object or not, the infinitely triggered Timer itself and the listener object registered in the Timer will not be garbage collected.

C. The reference relationships between objects established by implicit method are more likely to be ignored by programmers, resulting in Memory leakage. The most common reference between objects created in implicit mode is "binding" and "adding event listeners to objects ". Through the test, we found that "binding" will not cause memory leakage, and objects can be bound to global objects with confidence. However, calling the addEventListener () method "adding event listeners to objects" may result in memory leakage, which is the cause of most memory leaks.

To solve the memory leakage problem caused by the addEventListener method, addEventlistener will not be used in the following cases:

1. register the listener using the weak reference method. Set the fifth parameter of addEventListener to true during the call,

Example: someObject. addEventListener (MouseClick. CLICK, otherObject. handlerFunction, false, 0, true );

2. Self-reference method. That is, the listening handler function added to the object is the method of the object itself. For example:

This. addEventListener (MouseClick. CLICK, this. handlerFunction );

3. Sub-object reference. That is, the listening handler function added to the sub-object is the method of the parent object. For example:

Private var childobject: uicomponent = new uicomponent;

Addchild (childobject );

Childobject. addeventlistener (mouseevent. Click, this. clickhandler );

 

Iii. memory usage optimization suggestions

1. All references of the deleted object must be deleted to be disposed of as garbage collection by the system;
2. If the child object inside the parent object is referenced by other external objects, the child object will not be deleted, and the child object will not be deleted;
3. If an object references an external object, you must remember to set the reference of this object to null when you are deleted or do not need to use this reference object;
4. The reason why this object cannot be deleted may not be because it has been referenced by itself. It may also be because the child has been referenced by external entities and cannot be deleted by the father;
5. In addition to references that need to be deleted, system components, global tools, and management classes must call the detach method to delete internal objects. Otherwise, memory leakage and performance loss may occur;
6. If the parent object is deleted immediately, it does not mean that the child object will be deleted or immediately deleted. It may be deleted after being automatically deleted by the system or during the second removal operation;
7. If the parent object does not clear references to the child object after removing the child object, the child object cannot be deleted, and the parent object cannot be deleted;
8. if the registered event is not removed, it does not affect the custom forced collection mechanism, but it may affect the normal collection mechanism. Therefore, it is best to ensure that all registered event listeners should be deleted.
9. if the parent object is deleted, it does not mean that all other sub-objects are deleted. If the leaked code in one State is not in another state, it will not be leaked. test and analyze each state of each module one by one, the entire object can be deleted in any State of the test.

 

4. Custom forced garbage collection

The so-called forced execution of Garbage Collection refers to the process of intentionally making SWF errors at runtime, then throwing errors, and continuing to run the SWF file through catch errors. Garbage collection is executed once when SWF throws an error to clear invalid data usage in memory and reduce resource consumption. However, not all error throws can trigger garbage collection, but are limited to some specific errors. It is found that the mulinrj parameter is more effective.

/*
Programmer: Jinxin
Build Date: 2010-07-21
Version: V1.0
Summary: To do garbage reconfiguring work forcefully
Copyright (c) 2010, metarnet Technologies Co., Ltd.
All Rights Reserved
*/
Package com. metarnet. controls
{
Import flash.net. LocalConnection;
Import flash. system. System;

Public final class Memory
{

Public function Memory ()
{
// TO DO
}

Public static function gc (): void
{
Try
{
New localconnection (). Connect ('"mulinrj ');
New localconnection (). Connect ('"mulinrj ');
}
Catch (E :*)
{
}
}

Public static function get used (): Number
{
Return System. totalmemory;
}
}
}

 

5. Flex Builder3 Memory leakage analysis tool 

Flex Builder3 Pro comes with a Profiler tool that helps us identify memory

Leakage. In Flex Builder3 Pro, right-click the application to be "Profiler,

Right-click "Profile As" to run the "Profiler" tool to analyze the selected

Application. As shown in:

 

From: http://www.jinflex.com/index.php/archives/168