jasu's blog

var tf:TextField = new TextField();
tf.text = "Hello Hello";

var format1:TextFormat = new TextFormat();
format1.color = 0xFF0000;

var format2:TextFormat = new TextFormat();
format2.font = "Courier";

tf.setTextFormat(format1);
var startRange:uint = 6;
tf.setTextFormat(format2, startRange);

addChild(tf);

var style:StyleSheet = new StyleSheet();

var styleObj:Object = new Object();
styleObj.fontSize = "bold";
styleObj.color = "#FF0000";
style.setStyle(".darkRed", styleObj);

var tf:TextField = new TextField();
tf.text ="Hello Hello";
tf.styleSheet = style;
tf.htmlText = "<span class = 'darkRed'>Red</span> apple";

addChild(tf);

import flash.display.*;
var circle:Shape = new Shape()
var xPos:Number = 100;
var yPos:Number = 100;
var radius:Number = 50;
circle.graphics.beginFill(0xFF8800);
circle.graphics.drawCircle(xPos, yPos, radius);
this.addChild(circle);

var mySprite:Sprite = new Sprite();
mySprite.graphics.beginFill(0xFFCC00);
mySprite.graphics.drawCircle(30, 30, 30);
var label:TextField = new TextField();
label.text = "hello";
label.x = 20;
label.y = 20;
mySprite.addChild(label);
this.addChild(mySprite);

package {
        import flash.display.MovieClip;
        public class StaticExample extends MovieClip {
                public function StaticExample() {
                        var myExt:Extender = new Extender();
                }
        }
}

class Base {
        public static var test:String = "static";
}

class Extender extends Base {
        public function Extender () {
                trace(test); //
        }
}

출력 : static

package {
        import flash.display.MovieClip;
        public class StaticExample extends MovieClip {
                public function StaticExample() {
                        var myExt:Extender = new Extender();
                }
        }
}

class Base {
        public static var test:String = "static";
}

class Extender extends Base {
        public var test:String = "instance";
        public function Extender () {
                trace(test); //
        }
}

출력 : instance

parent_mc.child_mc.addEventListener(MouseEvent.CLICK, childClickHandler);
parent_mc.addEventListener(MouseEvent.CLICK, parentClickHandler);

function childClickHandler(evt:Event):void{
        trace(evt.target.name +" is a child");
}
function parentClickHandler(evt:Event):void{
        trace(evt.target.name +" is a parent");
}
출력 :
child_mc is a child
child_mc is a parent

trace(evt.target.parent.name +" is a parent");

class ThisTest {
        private var num:Number = 3;
        function foo () {                 // 정의된 Bound methods
                trace ("foo's this: " + this);
                trace ("num: " + num);
        }
        function bar () {
                return foo;              // 돌려주는 Bound methods
        }
}

var myTest:ThisTest = new ThisTest();
var myFunc:Function = myTest.bar();
trace(this);
myFunc();

I've been playing around with ActionScript 3.0 for a while now, and I'm really excited by its capabilities. The raw execution speed by itself provides so many possibilities. Toss in E4X, sockets, byte arrays, the new display list model, RegEx methods, a formalized event and error model, and a few dozen other features for flavor, and you have a pretty heady brew.

With great power comes great responsibility, and this is very true for ActionScript 3.0. A side effect of all this new control is that the garbage collector is no longer able to make as many assumptions about what it should automatically tidy up for you. This means that Flash developers moving to ActionScript 3.0 will need to develop a very strong understanding of how the garbage collector operates, and how to work with it effectively. Building even seemingly simple games or applications without this knowledge could result in SWFs that leak like a sieve, hogging all of a system's resources (CPU/RAM) and causing the user's system to hang—potentially even forcing them to hard reboot their computer.

To understand how to optimize your code for ActionScript 3.0, you'll first need an understanding of how the garbage collector works in Flash Player 9. Flash has two processes for finding objects that are not in active use and removing them. This article looks at both techniques and describes how they are relevant to your code.

At the end of this article you can find a simulation of the garbage collector in Flash Player 9 that visually demonstrates the concepts explained herein.

About the garbage collector

The garbage collector is a behind-the-scenes process that is responsible for deallocating the memory used by objects that are no longer in use by the application. An inactive object is one that no longer has any references to it from other active objects. In order to understand this, it is very important to realize that when working with non-primitive types (anything other than Boolean, String, Number, uint, int), you are always passing around a reference to the object, not the object itself. When you delete a variable you remove the reference, not the object itself.

This is easily demonstrated in the code below:

// create a new object, and put a reference to it in a:
var a:Object = {foo:"bar"}
// copy the reference to the object into b:
var b:Object = a;
// delete the reference to the object in a:
delete(a);
// check to see that the object is still referenced by b:
trace(b.foo); // traces "bar", so the object still exists.

If I were to update the code in the example above and delete "b" as well, it would leave my object with no active references and free it for garbage collection. The ActionScript 3.0 garbage collector uses two methods for locating objects with no active references: reference counting and mark sweeping.

Reference counting

Reference counting is one of the simplest methods for keeping track of active objects, and has been used in Flash since ActionScript 1.0. When you create a reference to an object, its reference count is incremented. When you delete a reference, its reference count is decremented. If the reference count of an object reaches zero, it is marked for deletion by the garbage collector.

Here's an example:

var a:Object = {foo:"bar"}
// the object now has a reference count of 1 (a)
var b:Object = a;
// now it has a reference count of 2 (a & b)
delete(a);
// back to 1 (b)
delete(b);
// the reference count down is now 0
// the object can now be deallocated by the garbage collector

Reference counting is simple, it doesn't carry a huge CPU overhead, and it works well in most situations. Unfortunately, the reference counting method for garbage collection is not optimal when it comes to circular referencing. Circular referencing is the situation when objects cross-reference each other (directly, or indirectly via other objects). Even if the application is no longer actively using the objects, their reference counts remain above zero, so the garbage collector never removes them. The code below illustrates how this works:

var a:Object = {}
// create a second object, and reference the first object:
var b:Object = {foo:a};
// make the first object reference the second as well:
a.foo = b;
// delete both active application references:
delete(a);
delete(b);

In the code shown above, both of the active application references have been deleted. I no longer have any way of accessing the two objects from my application, but the reference counts of both objects are 1 because they reference each other. This situation can become much more complex (a references c, which references b, which references a, etc.) and can be difficult to deal with in code. Flash Player 6 and 7 had issues relating to circular referencing in XML objects: each XML node referenced both its children and its parent, so they were never deallocated. Fortunately, Flash Player 8 added a new garbage collection technique called mark and sweep.

Mark sweeping

The second strategy employed by the ActionScript 3.0 (and Flash Player 8) garbage collector to find inactive objects is a method called mark and sweep. Flash Player starts at the root object of your application (which is conveniently called the "root" in ActionScript 3.0) and walks through every reference in it, marking each object it finds.

Next, Flash Player iterates through each of the marked objects. It continues this behavior recursively until it has traversed the entire object tree of your application, marking everything it can reach through an active reference. At the end of this process, Flash Player can safely assume that any objects in memory that are not marked no longer have any active references to them and can be safely deallocated. Figure 1 illustrates how this works: The green references were followed by Flash Player during marking, the green objects are marked, and the white objects will be deallocated.

Figure 1. Objects that no longer have active references are identified by Flash Player using the mark and sweep method

Mark and sweep is very accurate. However, because Flash Player has to traverse your entire object structure, the process is costly in terms of CPU usage. Flash Player 9 reduces this cost by carrying out iterative mark and sweep—the process occurs over a number of frames, instead of all at once—and by running this process only occasionally.

Deferred garbage collector and indeterminacy

In Flash Player 9, the garbage collector's operations are deferred. This is a very important thing to understand. Your objects will not be removed immediately when all active references are deleted. Rather, they will be removed at some indeterminate time in the future (from a developer standpoint). The garbage collector uses a set of heuristics that look at the RAM allocation and the size of the memory stack, among other things, to determine when to run. As a developer, you must accept the fact that you will have no way of knowing when, or even if, your inactive objects will get deallocated. You must also be aware that inactive objects will continue to execute indefinitely, until the garbage collector deallocates them, so your code will keep running (enterFrame events will continue), sounds will keep playing, loads will keep happening, other events will keep firing, and so on.

It's very important to remember that you have no control over when the garbage collector in Flash Player will deallocate your objects. As a developer, you will want to make the objects in your games and applications as inert as possible when you are finished with them. Strategies to manage this process will be the focus of my companion article, Resource management strategies in Flash Player 9.

Notice the sawtooth pattern of the total memory in the following garbage collection simulation (click Figure 2 or the link below it). The dips are caused when the collector carries out a sweep. Click on the chart to focus it, then press Spacebar to pause or restart, and hold the up/down arrows to change the memory usage trend as it runs.

Figure 2. Garbage collection simulation

• Garbage collection simulation

As shown in the following simulation (click Figure 3 or the link below it), drag out objects (round rectangles) and references to those objects. Then run reference counts or mark and sweep to see which objects would be collected. The number in an object indicates the number of references to that object.

Figure 3. Garbage collection simulation: mark and sweep

• Garbage collection simulation: mark and sweep

Where to go from here

Understanding garbage collection is going to be one of the most important steps for writing optimized code that ensures that your Flash project runs with minimal impact on the user's computer. Read my companion article, Resource management strategies in Flash Player 9, and visit the Flash Developer Center and Flash Player Developer Center.

Also check out my blog at gskinner.com to read more about weak references and download helper classes that I've written.

About the author

오랜만에 포스트를 쓰게 된다.
플래시라는 툴을 알게 된지 벌써 10년 가까이 되어가는 듯 하다. 그때는 액션스크립트라는 개념 보다는 웹디자인을 위한 저작도구로서의 가치가 급부상 하던 시절이었기 때문에 언어 형태의 작업을 할 일은 거의 없었다.

대학시절 내가 졸업을 하고 무엇을 하며 살 것인가를 고민할 때 플래시는 안중에도 없었다. 단지 개인 홈페이지를 만들 때 보기 좋게 하기 위한 방법에 불과했고 그런 작업 자체가 그냥 나의 작은 즐거움이었기에 관심만 갖고 있을 뿐이었다.

대학 졸업과 여러가지 우여곡절 끝에 난 지금의 회사에서 자리를 잡게 되었다. 집에서 개인 홈페홈페이지를 만들 때 사용했던 MX는 더 이상 실무에서는 사용되지 않고 있었다. 한번도 사용해 보지 않았던 Mx 2007 플래시를 열어보고 툴 사용법부터 하나하나 책을 뒤져가며 다시 공부해야 했고 그 과정속에서 짧지만 좌절도 겪었다.

혼자 서울로 상경하여 두번째 직장인 이곳에서 과연 내가 살아남을 수 있을 까 하는 의구심도 들었고 무엇보다도 내가 하는 작업 자체에 만족할 수 없는 경험의 연속이었기 때문에 더더욱 내가 작게만 느껴졌었다.

2년 3개월이라는 시간은 적으면 적은 시간이고 길다고 하면 긴 시간이다. 그 기간동안 내가 할 수 있는 최선의 노력을 다 했는가라는 질문을 스스로 던져보면 쉽게 ‘예’라고 대답할 수가 없다. 마땅히 집에서 할일 없어서, 또는 해야하는 일이였던 경우가 많았다. 물론 그 속에서 재미를 느꼈기 때문에 지금까지 플래시를 만지고 있지만 그것만으로 부족한 것이 사실이다.

얼마전에 플래시 모임에 처음으로 나가게 되었다. 회사내 팀 회식이 같은 날에 잡혔었는데 두 모임 모두 공교롭게도 1주가 밀리면서 같은 날자에 잡혔으나 약간의 슬럼프에 빠져있는 나에게 조금이나마 돌파구를 찾아보고자 플래시 모임에 참가를 했다.

온라인 상에서 안면이 있던 많은 분들을 만날 수 있었다. 나보다 나이 많은 형님들도 있었고 나보더 나이어린 동생들도 볼 수 있었는데 그 두 부류 모두 하나의 공통점은 배울점이 있다는 것이다.

나는 항상 배움이라는 것을 생각하면 눈에 보이고 머리로 익혀야 하는 배움 보다는 눈으로 보이지 않지만 느낌으로 배우는 배움이 더 중요하다고 생각한다. 눈에 보이는, 머리로 배우는 배움은 단편적인 영화라고 한다면 눈이 보이지 않으나 느낌으로 배울 수 있는 배움은 소설과도 같다.

후자는 시간과 장소를 떠나서 언제 어느 때나 배울 수 있다. 다만 그 배움이란 것은 남이 알려주는 것이 아니라 내 안에서 느끼는 것이기에 자신의 것으로 만들기 위해서는 긍정적인 생각속에서 살아갈 필요가 있을 듯 싶다.

나는 한참 플래시를 공부하는 후배들에게 하고싶은 말이 있다면 이것 하나만 기억했으면 좋겠다.플래시라는 툴은 공부하는 것이 아니라 느끼는 것이라고 말이다.

오랜만에 좋은 분들과 즐거운 이야기 속에서 작지만 큰 배움을 얻었던 하루였다. 그날 참석했던 모든 분들에게 고마움을 전한다.

이 구조를 넣으면서 여러가지 문제점이 생겼는데 문제점들은 아래와 같다.

1. 자바스크립트에서 플래시로 값을 넘겨주기 위해서는 플래시에서 ExternalInterface 클래스를 사용하게 된다. 이 클래스를 이용하면 html에 삽입된 javascript와 플래시간 상호 지정한 function을 호출할 수 있으며 return값도 전달 할 수 있다.
하지만 배경 화면에 해당하는 플래시에서 티스토리 스킨에 제공하고 있는 skin.html안에 삽입된 자바스크립트를 호출하는 것은 가능하나 그 자바스크립트에서 플래시로 값을 넘겨주지 못하는 문제점이 있다. 아마도 크로스 도메인 문제인 듯 싶다.

하루정도 고민 하다가 결국은 우회하기로 결정했다. 일단 하단에 있는 메뉴플래시에서 infinite 버튼을 클릭할 시에 상위에 있는 레이어를 display = block을 적용하고 플래시의 LocalConnection을 이용하여 레이어 안에 있는 플래시와 통신을 하는 방법이다.
여기도 또다시 문제점이 발생했는데 하위 플래시에서 레이어를 살리는 동시에 상위 플래시와 통신을 할 경우에는 기존에 있던 플래시가 포함된 레이어가 작동을 정지하면서 제대로 호출해주지 않는 문제가 발생했다. Display를 대신해 visibility을 이용해 보았지만 마찮가지였다.

상위 레이어가 살아났을 때 플래시에 레이어가 나타났다는 메시지를 전달함으로써 infinite의 초기 시작 모션을 적용해야 하는데 그 문제가 해결되지 않아서 발생하는 문제점이다.

익스플로러와 파이어폭스 두 브라우저에서 테스트해본 결과 두 브라우저 간의 약간의 차이가 발생했다.

그래서 LocalConnection으로 플래시간 통신을 하되 약간은 딜레이 타임을 적용하기로 하고 레이어를 살리고 초기 시작 모션들 들어가기 전에 0.5초간 로딩바를 보여주는 형태로 LocalConnection의 문제점을 해결했다. 사실 해결이라기보다는 궁여지책이다.

W3C에서 권장하는 표준형은 document.getElementById("ID").style.display 이러한 형태로 접근하는 것이다.

3. 세번째 문제는 티스토리에 로그인한 상태에서 블로그에 접근했을 때는 오른쪽 상단에 티스토리 툴바가 보이게 된다.  테스트 과정에서 레이어의 index값을 아무리 올려도 상위에 있는 레이어보다 티스토리 툴바가 상위에 떠있는 것이다. 그래서 블로그 소스를 뒤져보니 상위에 뜨는 툴바의 index값이 무려 1000000라는 사실… 그래서 상위에 뜨는 레이어의 index 값을 1000001로 잡아서 해결했다.

4. 네번째는 문제라기 보다는 레이어를 올리는 과정에서 생겨난 부가적인 노동이다. 블로그에서 음악이 흘러나오도록 play를 시켜놓은 상태에서 infinite 페이지로 들어갔을 때는 끄고, play되고 있던 사용자라면 다시 나올 때 play를 시켜주는 것이다. 그리고 음악을 듣지 않고 있던 사용자라면 그대로 음악이 흘러나오지 않는 기능을 추가해야 했다. 그리고 블로그의 배경에서 랜덤으로 생겨나는 나비의 움직임이 infinite 페이지를 접근했을 때에 불필요하게 CPU의 낭비를 가져오고 있어서 infinite메뉴로 들어갔을 때는 나비들이 생성하지 않도록 interval을 clear시켜주고 다시 블로그로 나갔을 때는 생성하도록 설정해 놓았다.

Infinite메뉴를 추가하면서 가장 큰 문제는 자바스크립트에서 플래시로 통신하기가 어렵다는 것이 가장 큰 문제였던 것 같다. 일단 지금은 LocalConnection을 이용하여 플래시 간에 주거니 받거니 하고 있으니 나중에 알게 되면 수정해야 겠다.