자원절약병…
개인 framework 를 작업중인데... 아무래도 수전노병에 걸린 것 같다.
왠만한 그래픽스를 addChild 를 안쓰고 몽땅 BitmapData 나 Graphics 로 처리하려고 하는 병에 어지간해서 자원들을 new 없이 pooling 시키거나 gc 걸리게 하는 것에 극도로 예민한 병에 걸린것 같다.
텍스트 처리 마저 자꾸 Bitmap 에 찍어버릴라는 짓을 하게 되어서 framework 설계에 상당한 부하가 걸리고 있다.
하지만... 대충 체크해보니깐 cpu 도 memory 도 별 차이 안남... ㅡ ㄴ ㅡ;;;
대책없이 아끼는 것도 좋지 않다는 깨달음에 도달하게 되었다. 코딱지 만큼 아낄라고 작업량을 두세배로 늘리는건 바보같은 짓인 것 같다고나 할까... (불편해지면서 까지 flash 로 만들 필요가 뭐 있나... 차라리 C 로 만들고 말지...)
일의 경중을 나눠서 정말 성능 딸려서 당췌 못쓸 지경이다 싶은 부분에 쓸 방법들과 큰 타격이 없기 때문에 좀 편하게 작업하는게 좋겠다 싶은 부분에 쓸 방법들을 분리해서 만들어야 겠다는 생각이 든다. 다만... gc 를 불러들일 수 있도록 자원을 해제시키는 구간은 좀 더 신경쓰고...
성능고려에 이것저것 지금껏 겪었던 많은 문제점들을 해결하기 위한 구조들을 새롭게 만들다보니 점점 flash 스러운 사용법에서 좀 멀어지는 듯도 싶다. 대신 성능이나 작업편의성은 올라가긴 하는 것 같고... 플래시의 기본적인 방식이 좀 뭐랄까... 그닥 좋지는 않은 방식인 것 같다...
polygonal ds
요새 새로운 framework 을 만들기 이전에 polygonal ds 를 만져보고 있는 중이다. Array2, Array3, Queue, Iterator 구조 등... "이걸 왜 모르고 삽질했었지?" 라는 생각이 들 정도로 깔끔하게 논리를 정리해주는 라이브러리 인 것 같다.
API 문서는 있는데, 막상 뭘 어쩌라는 것인지 예제 같은 것들은 없어서 instance 하나 만들고 메서드들을 하나 하나 호출해보면서 무슨 기능을 하는지 파악하고 있다. polygonal 홈페이지에 있는 data structure 내용들도 참고로 해서 보고 있고...
대충 이거 잡고 몇 시간째인데 Array2 나 Queue, Iterator 부분들을 하나 하나 살펴보면서... 그간 맨땅에 헤딩하듯이 만들었던 많은 작업물들이 (슬픔과 함께) 떠올랐다. 자료구조 라는 것을 알면, 이렇게 깔끔하게 만들 수 있구나... 싶은 생각이 든달까? 짧은 시간이지만 굉장히 많은 것을 깨닫게 되는 것 같다.
그냥... 이런걸 보다보면 "과연 내가 개발자인가?" 라는 생각이 문득 들때도 있다.
프로그래머의 정의가 무엇일까? ActionScript 를 사용해서 개발을 하고는 있지만, 아무리 생각해도 내가 프로그래머 라는 생각은 잘 안든다. 오히려 옛날부터 해왔던 만화를 그리는듯한 "어떤 내용을 만드는데" 그냥 프로그래밍 언어를 사용하는 것 뿐이라는 느낌?
"프로그래머 다운" 프로그래머 라면 자료구조에 능통하고, 어떠한 사고체계를 구조적으로 잘 풀어내는 능력을 가진 사람이 아닐까도 싶다. 내가 하는 일들이 Graphics 와 Animation 등을 사용해서 그냥 서비스를 코드로 그려내는 것 뿐이라면... 과연 내가 프로그래머 일까? 라는 의아함도 든다.
뭐... 다들 ActionScript 사용하는 사람이니깐 프로그래머라고 불러주긴 하는 것 같은데... 그냥 난 서비스 제작자... 퍼블리셔? 뭐 그런것에 속하는게 아닐까하는 생각이 든다. 단지... 그 작업에 프로그래밍 언어를 사용하는 사람일 뿐이지...
뭐 자괴 하는 것은 아니다. 단지, 이렇게 자료구조에 대한 내용들이나 여러가지 "왠지 진짜같은" 프로그래머들의 흔적을 보다보면 "난 저 부류는 아니구나..." 싶은 생각이 드는 것 뿐... 내가 가진 힘 이라는 것은 오히려 만화, 애니메이션, 인테리어, 광고 기획 등을 거치면서 쌓은 내용에 대한 파악이라고 생각하고 있으니깐... (그리고, 그런 직업들을 멀쩡하게 거친 이후, 프로그래밍 코드를 다루게 된 희안한 인간이라는 희소성?)
그간 flowchart 나 uml 의 외계도형들을 보면서 이해가 안되었던 것들이 그럭저럭 ActionScript 다룰줄 아는 인간이라 그런지, polygonal ds 코드로는 이해가 잘 되어가는 것 같다. 이 기반을 바탕으로 자료구조에 대한 개념을 좀 더 잡는다면 지금보다 좀 더 괜찮은 작업들을 할 수 있지 않을까도 싶다...
ux 를 바탕으로 한 서비스 라는 것이 참 어렵다는 생각이 든다. 현상의 논리적 구조를 이렇게 분석해 낼줄도 알아야 하고, Graphics 를 위한 여러가지 수학, 물리적 지식들도 있어야 하고, 또... 그런것들을 실제 서비스에 적용하기 위해 실제 서비스에 대한 개념 역시 있어야 하며, 드러운 룩을 가지고 있는 것은 사람들이 싫어하기 때문에 미학에 대한 개념도 있어야 하며, 거기에 더해 ActionScript 와 같이 한 언어와 그 플랫폼에 대한 여러가지 기반지식들도 있어야 하고...
시대가 많이 변하며 Flash 도태론이 막 대두되고 있는 마당에 다음 시대를 준비하기 위해서는 지금껏 해왔던 ActionScript 위주의 파고들기 보다는, 좀 더 본질적인 이런 자료구조에 대한 이해나 그래픽스에 대한 처리능력, 미적, 논리적 서비스를 위한 예전에 했던 일들을 지금의 일에 좀 더 밀접하게 접목시키는 등의 응용적인 것 보다는 본질적인 것에 대한 공부가 필요한게 아닐까 싶기도 하다... Flash 는 사라질 수 있겠지만, 내가 사라질 순 없잖아... 그 어떤 개발플랫폼 이던지간에 변하지 않을 본질적인 것을 좀 더 자세히 아는 인간이 되어야겠지...
ModuleBase
기존에 컴포넌트 같은 것들을 만들고 addChild 를 시키면서 사용하는 것은 꽤나 귀찮은 문제들이었다. stage 의 감지도 그렇고, 애니메이션이 끝날때를 잡아내서 활성화 시켜주는 문제도 그렇고, pooling 을 시키기도 애매하고...
이래저래 컴포넌트들을 만들다가 이번에 역발상으로 parent 가 addChild 시키는 컨트롤이 아니라, 아싸리 child 에 parent 를 던져줘서 등록시키는 방식으로 모듈 기반을 바꿔줘봤다.
public class ModuleBase extends Sprite
{
private var _running : Boolean;
private var _constructed : Boolean;
public function construct(config : Object = null) : Boolean
{
if (_constructed) return false;
// 자원 생성
_constructed = true;
return true;
}
public function deconstruct() : Boolean
{
if (!_constructed) return false;
// 자원 파괴
_constructed = false;
return true;
}
public function setting(data : Object = null, config : Object = null) : void
{
// 상태 설정
// 이미 작동 중일 경우엔 변경되는 애니메이션을 뿌려준다.
if (_running) refresh();
}
public function register(parent : DisplayObjectContainer = null, index:int = -1) : Boolean
{
if (_running) return false;
_running = true;
// 작동을 시작시킴
// 이벤트 등록
return true;
}
public function deregister() : Boolean
{
if (!_running) return false;
_running = false;
// 작동을 중단시킴
// 이벤트 삭제
return true;
}
protected function refresh() : void
{
// 재설정 되는 애니메이션
}
protected function appear() : void
{
// 등장하는 애니메이션
}
protected function disappear() : void
{
// 퇴장 하는 애니메이션
}
public function get running() : Boolean
{
return _running;
}
public function get constructed() : Boolean
{
return _constructed;
}
}
대충 이래저래 고민을 하다보니 위와 같은 구조가 되어버렸다. 아직 다듬을 만한 구석이 많긴 하지만, 이번 작업동안에는 이 구조를 베이스로 해서 여러 구성요소들을 개발중이다.
대충 이 기반을 상속받은 컴포넌트들을 만드는데
var module:Module = new Module();
// 모듈의 구성요소들을 생성해준다.
module.construct();
// 모듈의 데이터 부분을 셋팅해준다.
module.setting({name:"xxx", age:17});
// 모듈을 서비스에 등록시켜서 작동시킨다.
// parent 인 this 를 던져주고, addChildAt 을 사용할 경우 -1 이외의 값을 넣어준다.
module.register(this, 10);
// 모듈을 등록해제 시켜준다.
module.deregister();
// 모듈의 구성요소들을 지워준다.
module.deconstruct();
위와 같은 식으로 진행이 되게된다.
pooling 의 경우는 pool 에서 construct 까지 시켜준 다음에 pool 에서 꺼내서 setting 과 register, deregister 를 반복시켜주는 구간이 확실해져서 좀 더 간단해진 느낌이 든다.
그리고, 대충... register 나 deregister 명령에 따라 지가 알아서 애니메이션 이후에 parent 에서 addChild, removeChild 작동을 해결하기 때문에, 애니메이션을 모듈화 시키는데 좀 더 편리한 것 같다. 그리고, 애니메이션에 의한 모듈들간에 순차적 등장이 필요한 경우에도 릴레이 방식으로 register 명령을 내려주면 되니... 뭐... 대충 예전에 addChild 방식으로 할 때 보다는 좀 더 논리적으로 개발을 할 수가 있게 된 것 같다.
이번 프로젝트 까지만 사용을 하고, 이번에 드러난 문제점들을 수정해서 앞으로 내가 만들 모든 작업물의 베이스로 삼아볼까 생각중이다.
Textile 파서…
ActionScript 로 Textile 파서를 만들다가, flash 등 여러가지 언어에서 사용하기엔 좀 무리가 많아서 (기본적으로 html 을 랩핑하는 형식의 언어이기 때문에...) 관두고 stutter 라는 새로운 위키 언어를 만들고 있었는데, 해외에서 오는 리퍼러의 상당수가 ActionScript Textile parser 로 오고 있다.
음... 그냥 만들던걸 다시 재개해서 올려야 할까나...
상당히 많이들 필요로 하는 것 같다. 근데... Textile 을 html string 으로 전환시켜주는 것은 문제가 아닌데... 이걸 뭐에다 쓰려는 것인지는 잘 모르겠네... ㅡ ㄴ ㅡ;;; flash 를 통해 Textile 을 표현해주려는 것이라면 Textile 자체가 flash 의 displayobject 로 전환되기엔 상당히 복잡한 편이고 (css 룰 까지 정해줘야 하니깐...) 그냥 flash 를 통해서 html string 을 뽑아내려 하는 것이라면 그냥 javascript 로 된 textile 파서가 이미 존재하는데...
