everything you create must be readied for gc (garbage collection). the following is an excerpt from a book i wrote, Flash Game Development: In a Social, Mobile and 3D World
Memory Management
Flash manages memory by allocating memory at the start of your game and then, as mentioned above, if Flash needs more memory, it checks for objects that can be removed from memory and, if it finds any, freeing some previously allocated and previously used memory.
Objects that have no references (i.e., there is no way to address them using ActionScript) can be removed from memory and are marked by Flash for garbage collection (gc). Actually removing an object from memory occurs at some future indeterminate (outside of the test environment) time controlled by Flash.
All objects in the display list can be referenced, using getChildAt(), even if you assign their reference name to null. Therefore, no object in the display list can be gc'd.
All objects with a non-weak listener can be referenced (via its listener function and the event's currentTarget property) so all non-weak listeners must be removed before an object can be gc'd.
At least, that was the way it used to work. With more recent Flash Players, nulled objects with strong listeners will be gc'd and their listeners removed by Flash. There is more on this below in the Strong Listeners vs Weak Listeners section.
But, you cannot depend on everyone having a Flash Player version that does that and you cannot depend on future Flash Player versions working the same way. So, you should remove all listeners when they are no longer needed as part of good memory management and CPU/GPU management.
To determine if you are practicing good memory management, you need to measure the memory used by your game. Fortunately, measuring system memory consumption is easy. ActionScript 3.0 has a static System class property totalMemory (or, totalMemoryNumber if you're using a lot of system memory), you can use to measure your game's memory consumption. Unfortunately, determining what is causing a memory problem, if you have one, is not so easy. I will address that in the next section.
If, at any time after your game starts, the amount of memory required by your game exceeds the amount of available system memory, your game's frame rate will drop to zero and the Flash Player will crash. Obviously, that is a very serious performance problem and it can occur two general ways.
One, upon initial game setup, your game needs more than the available memory. If that applies to your situation, you need to re-think your game's setup. To be sure, there is no sequence of steps that I can sketch that will help in all situations. It may even be that your game is too sophisticated for its target platform and nothing, short of gutting your game's essential elements, will get it to load and run. That is, the problem may not even be solvable in any meaningful manner that allows the game, you originally envisioned, to load and run.
And two, your game's memory use may increase the longer your game is played. If your game consumes more and more memory the longer your game is played, you will eventually see your game's performance degrade. There must be some limit to memory consumption or your game will suffer steadily worsening performance and eventually crash the Flash Player.
In both excess memory usage situations, you can test on your development platform. Because the amount of memory your game uses will be the same on the target platform as on the development platform, you just need to know the amount of memory available to your game on your target platform and then test your game's memory consumption before deploying to that platform.
This second scenario where your game's memory use may increase the longer your game is played is much more common than the first scenario. It is easy to create (and re-create ad infinitum) objects that are never cleared from memory. When that happens, you are certain to see a significant problem eventually.
Fortunately, this run-away memory consumption is always solvable. However, while finding whether a memory problem exists using one of the System properties is straightforward and while it is always solvable, actually pinpointing the problem is not straightforward. There is nothing in Flash Pro that lets you track what is in the memory used by your Flash game.
Among the ways to test a game's performance and track memory problems is to use a memory tracker class, which does track what is in the memory used by your Flash game. One such class is below. It monitors your game's realized frames per second, its memory use and, lets you track what is in your game's memory.
You should always test your game before deployment even if there appears to be no performance problem obvious to you. You should always test to ensure your game has no memory problem before testing performance on the target platform.
This is especially important for games deployed for mobile devices. While browser based games are unlikely to remain open for weeks, it is typically for mobile users to never close or shutdown a game. They are moved to the background and idle when not in use. Mobile games (and apps) are rarely, if ever, closed so memory problems can accumulate over, not just weeks, but months of game play.
Memory Tracking, Memory Use and Performance Testing
The code below is adapted from Damian Connolly's code at divillysausages.com. The MT class reports frame rate, memory consumption and what objects are still in memory. Using it is easy: Import it and initialize it from the document class
import com.kglad.MT;
MT.init(this,reportFrequency);
where this references your document class (i.e., the main timeline) and reportFrequency is an integer. The main timeline reference is used to compute the realized frame rate and reportFrequency is the frequency in seconds that you want trace output reporting the frame rate and amount of memory consumed by your Flash game. If you don't want any frame rate/memory reporting pass 0 (or anything less). You can still use the memory tracker part of this class.
To track objects you create in your game, use:
MT.track(whatever_object,any_detail);
where the first parameter is the object you want to track (to see if it is ever removed from memory) and the second parameter is anything you want (typically a string that supplies details about what, where and/or when you started tracking that object).
When you want a report of whether your tracked objects still exist in memory, use:
MT.report();
I'll show sample code using MT after discussing details of the MT class in the MT class comments. It is not necessary that you understand the class to use it but it is a good idea to check how the Dictionary class is used to store weak references to all the objects passed to MT.track().
Similar to the observer effect in physics, the mere fact that we are measuring the frame rate and/or memory and/or tracking memory, changes the frame rate and memory of the game. However, the effect of measurement should be minimal if the trace output is relatively infrequent. In addition, the absolute numbers are usually not important. It is the change in frame rate and/or memory use over time that is important and for that, this class works well.
This class does not allow more than once per second trace output to help minimize spuriously low frame rate reports caused by frequent use of trace. (i.e., frequent trace output slows performance.) And, you can always eliminate trace output as a confounder of frame rate determination by using a textfield instead of trace output.
The MT class is the only tool needed to check memory usage and pinpoint memory problems, as well as, indirectly measure CPU/GPU usage (by checking actual frame rate of an executing app).
com.kglad.MT
package com.kglad{
import flash.display.MovieClip;
import flash.events.Event;
import flash.utils.getTimer;
import flash.system.System;
import flash.utils.Dictionary;
// adapted from @author Damian Connolly
// http://divillysausages.com/blog/tracking_memory_leaks_in_as3
public class MT {
// Used to calculate the real frame rate
private static var startTime:int=getTimer();
// Used to generate trace output intermittantly
private static var traceN:int=0;
// Megabyte constant to convert from bytes to megabytes.
private static const MB:int=1024*1024;
private static var mc:MovieClip;
// d is used to store weak references to objects that you want to track. // It is the essential object used to memory track in this class. // The true parameter used in the constructor designates that // all references are weak. That is, the dictionary reference itself // won't prohibit the object from being gc'd.
private static var d:Dictionary = new Dictionary(true);
// Used to trigger a report on the tracked objects
private static var reportBool:Boolean;
// Used to (help) ensure gc takes place
private static var gcN:int;
// This is the variable that will store the reportFrequency value that // you pass.
private static var freq:int;
// A constructor is not needed
public function MT() {
}
// traceF() is the listener function for an Enter.ENTER_FRAME event. If // the game is running at its maximum frame rate (=stage.frameRate), // traceF() will be called stage.frameRate times per second.
private static function traceF(e:Event):void {
traceN++;
// This conditional ensures trace output occurs no more frequently // than every freq seconds. If the game is running at // stage.frameRate, output will occur at approximately freq // seconds.
if (traceN%(freq*mc.stage.frameRate)==0) {
// This is used to (try and) force gc.
gcN = 0;
forceGC();
trace("FPS:",int(traceN*1000/(getTimer()-startTime)),"||","Memory Use:",int(100*System.totalMemory/MB)/100," MB");
traceN=0;
startTime=getTimer();
}
}
// Called just prior to the above trace() and called just prior to a // memory report. When called just prior to a memory report, reportBool // is assigned true.
private static function forceGC():void {
// The first call to System.gc() marks items that are available // for gc. The second should sweep them and the third is for good // luck because you can't count on anything being predictably // gc'd when you think it should be.
mc.addEventListener(Event.ENTER_FRAME,gcF,false,0,true);
gcN = 0;
}
private static function gcF(e:Event):void {
// System.gc() initiates the gc process during testing only. It // does not work outside the test environment. So, if you are using this class to test a game that is installed on a mobile device, System.gc() will not clear memory of objects ready to be g
System.gc();
gcN++;
// 3 System.gc() statements is usually enough to clear memory of // objects that can be cleared from memory.
if (gcN>2) {
mc.removeEventListener(Event.ENTER_FRAME,gcF,false);
// Here's where reportBool being true triggers the memory // report.
if(reportBool){
reportBool = false;
reportF();
}
}
}
// Memory report. All objects passed to d in the track() function, // if they still exist, will be displayed by the trace statement along // with the additional information you passed to track()
private static function reportF():void{
trace("** MEMORY REPORT AT:",int(getTimer()/1000));
for(var obj:* in d){
trace(obj,"exists",d[obj]);
}
}
public static function init(_mc:MovieClip,_freq:int=0):void{
mc=_mc;
freq=_freq;
if(freq>0){
mc.addEventListener(Event.ENTER_FRAME,traceF,false,0,true);
}
}
// This the function you use to pass objects you want tracked.
public static function track(obj:*,detail:*=null):void{
d[obj] = detail;
}
// This is the function that triggers a memory report.
public static function report():void{
reportBool = true;
forceGC();
}
}
}
Before I even applied this to tank_combat, I took some steps to help ensure I would not have run-away memory consumption. In the previous chapter, I started using an
Event.REMOVED_FROM_STAGE
listener for all my DisplayObject classes and doing clean-up in the listener function. That clean-up consisted of removing the listeners I had previously added, and making sure objects created in the class were removed from the display list and nulled.
If that is done so there are no references to an object, it is not in the display and has no (strong) listeners, then it should be eligible for garbage collection (gc). Unfortunately, there are exceptions to that rule.
While testing tank_combat I found an unexpected issue with sounds and an unexpected issue with timers. There are probably more exceptions.
8
Replies
AdChoices