jasu's blog

예전에 System.gc 내장 함수가 없었던 것으로 알고 있는데 업데이트 버전에서 생겨난 듯 하다. 기존에는 개발자가 강제로 CG를 실행시킬 수 없어서 완전한 메모리 테스트는 사실상 불가능 했다. 물론 강제로 많은 오브젝트를 생성하는 과정에서 일정한 메모리(FlashPlayer가 예상하는 적정 사용영역)을 벗어날 경우를 임의로 만들어서 확인할 수는 있었으나 이것 또한 어느 정도의 메모리 영역을 CG가 동작하는 시작점으로 보는가를 알 수 없기 때문에 어려움이 있었다.

System 클래스에서 지원하는 메소드에 gc가 있다. 이는 자바에서의 System.gc와 같이 이 함수를 실행하는 시점에서 강제로 CG가 동작하게 된다. 문제는 자바와 같이 플래시도 full gc를 할 경우 시스템 리소스 낭비가 예상된다는 것이다. System.gc 실행은 개발 테스트 과정에서 사용하되 작업물에서의 동적인 강제 실행은 피하는 것이 좋을 듯 싶으나 이는 이미 웹상에서는 System.gc가 작동하지 않는 듯 싶다. 경험상 flashPlayer9버전의 가비지콜렉터는 상당히 안정적이고 신뢰 할만 하다.

아래 예제로 만든 것을 보면 replay 버튼을 누름과 동시에 Event.ENTER_FRAME 이벤트가 등록된 sprite를 통해서 이벤트가 발생할 때마다 임의로 TextField를 생성과 소멸을 반복한다. 50개의 TextField가 생성되는 시점에서 Event.ENTER_FRAME가 등록된 sprite를 메모리해서 해제시킨다.

여기서 많은 개발자들이 Event.ENTER_FRAME 이벤트가 적용된 상태에서 removeEventListener로 이벤트를 해제하지 않고 sprite를 메모리 해제 시도를 했기 때문에 메모리에서 지워지지 않는다고 생각하는 듯 하다. 나도 예전에는 이 부분이 상당히 모호했다.  addEventListener로 강참조를 할 경우라도 역참조가 아닌 이상은 이벤트가 적용된 오브젝트가 메모리에서 해제하고 GC를 통해서 free memory가 되면 자동으로 등록되어 있는 이벤트도 발생하지 않는다.

여기서 혼돈했던 이유는 개발자가 강제로 가비지콜렉션을 실행하지 못하는 상황에서 sprite가 메모리에서 해제되지 않아서 이벤트가 계속 발생하는 것인지, gc가 동작하지 않아서 해제되지 않는 것인지 모호했기 때문이다.

아래의 예제에서 gc 동작버튼을 누르지 않더라도 일정한 시간이 지나면 flashplayer가 적당한 시점에서 gc를 가동하여 Event.ENTER_FRAME 이벤트가 등록된 sprite를 메모리에서 해제하면서 Event.ENTER_FRAME 이벤트도 발생하지 않게 된다. System.gc를 이러한 gc의 동작을 강제로 실행하므로써 개발자에게 즉시 free memory가 되었다는 것을 알려주므로 개발과정에서 요긴하게 사용될 듯싶다.

아래 swf상에서는 System.gc 함수가 실행되지 않는다. fla를 다운로드하여 로컬상에서 테스트 해보길 바란다.

필요 없는 오브젝트의 참조가 남아있으면 그 오브젝트가 사용하고 있는 메모리 영역을 사용할 수 없게 된다. 특히 복수가 참조하는 오브젝트에 대해서는 참조를 해제하는 것을 잊어버리게 되면 메모리의 낭비가 발생하므로 주의해야 한다.

이벤트 리스너를 등록하려면 이벤트의 타겟으로 되는 오브젝트와 이벤트 리스너를 가지는 오브젝트 사이에 참조를 할 수 있다. AS3에서는 아래와 같이 기술한다.

eventTarget.addEventLisener("eventType", eventHandler);

이 코드를 실행하면 eventTarget과 현재 스크립트가 포함된 this 사이에 참조가 만들어진다. 하지만 이것은 명시적인 참조의 추가가 아니기 때문에 참조의 삭제가 필요한 경우 간과할 수 있다.

아래는 이벤트 리스너 추가시에 참조의 취급 방법에 대한 내용이다.


참조의 방향
참조에는 방향성이 있다. 즉, 오브젝트간의 참조는 한 방향으로만 가능하다. 예를 들면 아래와 같은 코드가 있을 때,

var foo = new Foo();
foo.bar = this;
foo = null;

1행에서 만들어진 참조는 this -> new Foo() 방향으로 만들어진 참조이다. 2행에서 만들어진 참조는 1행과 반대로 new Foo() -> this 방향으로 만들어 진 참조다. 3행에서 1행의 참조를 삭제하게 되면 this -> new Foo()으로의 참조를 할 수 없다.

가비지컬렉터는 오브젝트 트리의 루트로부터 참조를 찾아 들어 간다. 우선 루트의 오브젝트를 찾아내고 다음에 그 오브젝트의 오브젝트를 찾아내는 동작을 반복하게 된다. 위 샘플을 실행했을 경우 this에 new Foo()로 만들어진 오브젝트를 찾아 낼 수 없다. 즉 2행째에 작성한 참조가 남아있다고 해도 3행을 실행하게 되면 메모리 문제는 해결될 수 있다.


오브젝트에 이벤트 리스너 추가
오브젝트에 이벤트 리스너를 추가할 경우에 참조 방향으로는 아래와 같다.

import flash.events.Event;
import flash.events.MouseEvent;
var foo = New Foo();
addChild(foo);
foo.addEventListener(MouseEvent.CLICK, clickHandler);

function clickHandler(evt:Event):void{
        trace(this);
}

위 코드에서 foo 오브젝트를 작성하고 그 오브젝트에 clickHandler라는 이벤트 리스너를 등록하였다. clickHandler 메소드는 스크립트가 작성된 this 오브젝트의 메소드가 된다.

이러한 경우 foo 오브젝트의 참조를 삭제할 때 이벤트 리스너도 삭제하지 않으면 메모리에 잔존하는 문제의 원인이 될 수 있다. 아래와 같이 오브젝트로부터 this에 이벤트 리스너를 설정할 경우도 같다.

parent.addEventListener("click", clickHandler);

약한 참조의 이용
약한 참조는 참조가 존재하고 있어도 가비지콜렉터에 의해서 참조로서 보이지 않는 참조이다. 이는 매우 편리하게 사용할 수 있는데 이벤트 리스너에 의해 생성되는 참조가 모두 약한 참조라면 참조의 방향을 신경 쓰지 않고 등록한 리스너를 방치해 두어도 문제가 되지 않기 때문이다. 이벤트 리스너를 등록할 때 약한 참조를 사용할지를 지정할 수 있다. addEventListener()의 5번째 인수를 true로 적용하면 약한 참조를 사용할 수 있다.

addEventListener("eventType", listenerHandler, false, 0, true);

3번째와 4번째 인수는 false와 0 값을 지정해 두면 대체적으로 문제가 없기 때문에 위와 같은 형태로 5번째 인수를 false와 true로 적용하여 강한 참조와 약한 참조를 사용할 수 있다.