본문 바로가기

Starling

Feathers 라이브러리에 대한 생각.



처음 Feathers 라이브러리가 나왔을 때 진짜 좋다고 생각했다.


거의 모든 컴포넌트가 이미 Starling 기반으로 구현되어 있으므로 

프로젝트에 필요한 컴포넌트를 굳이 따로 개발할 필요가 없겠다 싶었다.


하지만 현재 이 라이브러리를 사용하고 있지 않으며 앞으로도 사용할 일이 없을 것 같다.

이유는 아래와 같다.



1.

feathers 의 장점은 개발자가 필요한 특정 컴포넌트를 개발할 시간을 줄여준다는 것이다.

하지만 사용하려면 어느정도는 feathers 라이브러리에 대한 이해가 필요하며

만약 버그가 발생했을 때 이를 처리하려면 최소한의 이해정도로는 부족하다. 

커스텀이라도 시킬려면 당연히 속속히 알고 있어야 한다.

게다가 협업의 경우, 프로젝트에 투입된 모든 개발자가 모두 관련 지식을 습득해야 한다.

이를 위해 투자해야하는 시간은 직접 필요한 컴포넌트를 만들지 않아 획득한 여분의 시간을 상쇄하고도 남을 것이다.



2.

프로젝트에서 필요한 것은 feathers 가 제공해주는 모든 기능이 아니다. 

ScrollBar, List 를 직접 구현하기 싫어 feathers 를 사용하는 것은 배보다 간이 큰 경우다.

만약 이를 직접 개발한다면 아무리 꼼꼼하게 작업한다고 해도 하루를 넘지 않을 것이다.

직접 개발이 불가능하면 개발자로써 문제가 있는 것이다. 게다가 이 경우 디버깅 및 팀원간의 공유가 손쉽다.



3.

Starling 도 마찬가지지만

이런 공개된 라이브러리는 사용자가 사용하기 편하도록 하기 위해 너무 많은 것을 신경쓰고 있다.

이를 위해 희생되는 것이 너무 많다. 무겁다. flex 컴포넌트의 사용이 꺼려졌던 것과 비슷한 이유다.



4.

컴포넌트 각각의 단일 기능으로써의 모듈화보다는 라이브러리전체를 하나의 모듈로 보고 있다.

예를 들어 Feathers 의 TextArea 클래스는 이 클래스 하나만을 따로 때어내서 사용할 수 없다.

이 하나의 TextArea 클래스 사용을 위해 필연적으로

Scroller, FeathersControl 2개의 클래스,

IFocusDisplayObject, IFeathersControl, ILayoutDisplayObject, 3개의 인터페이스가 딸려와야 한다.

Radio 버튼을 사용하기 위해서 Radio 클래스가 필요한 것이 아니라 feathers 전체가 필요한 것이다.



5.

게다가 디자인 적용을 위해선 DisplayListWatcher 클래스를 상속한 theme 클래스를 만들고

무슨 CSS 정의하듯이 세팅해야 하는 작업이 필요하다.

게다가 여기서 사용할지 않을지도 모르는 feathers 에 포함된 모든 클래스들을 에 대한 설정을 관리하고 있다!

png 든 atf 든 스프라이트시트를 만들때도 각 요소를 신경써야 한다!

내가 원하는 모듈화된 컴포넌트 클래스는 이런것이 아니다.

모든 사전작업이 필요치 않고 그냥 필요한 순간에



이걸로 그냥 모든것이 끝나길 원한다.

반드시 외부 리소스에 의한 디자인이나 폰트의 적용이 필요하다면 동적으로 클래스의 공개된 api를 사용해



이러한 형태로 이루어지는게 이상적이지 않을까 하는 마음이 있다.



6.

위의 5개의 이유는 사실 어떻게든 헤쳐나갈 수 있을지도 모른다. 가장 큰 이유는 퍼포먼스이다.



10개의 List 가 담긴 PanelScreen 이다. 

정말 단순한 구조다. 어떠한 모션도 없다. 


근데 draw call 이 48 이다!!!!


정말 다른 모든 부분이 장점밖에 없다고 해도 이건  도저히 넘어갈 수 없는 문제이다!!!

아무리 텍스트필드가 포함되어 있다 하더라도 솔직히 이건 너무 했다;


타켓 디바이스가 막 갤럭시 노트3, 아이폰5s 밖에 없다면 모르겠다. ( 사실 그래도 이수준에 이정도면 문제가 심각하다 )

기본적인 순정 Starling 조차 느려서 커스텀하고 어떻게든 draw call 을 조금이나마 줄이고자 온갖 수단을 다써가는 판에;


실제로 모바일에서 느려지는 이유는 안의 로직이, 알고리즘이 어쩌고를 떠나서 반이상이 렌더링때문이다.

모든 것이 화면에 표시되어 게임이 진행되고 이펙트가 파바박 터져도

draw call 을 어떻게든 10이하로 만들 수 있지 않을까 노력하고 있는데 이건 멘붕 수준이다.


예전에 어느분이 air 로 작업중인 게임이 느리다고 해서 drawcall 을 물어봤더니 막 80~100 이라고 대답한적이 있다.

ㄷㄷㄷ... 20만 넘어가도 큰일났다!! 라는 생각이 드는데...

다른이유도 물론 있었겠지만 UI, HUD 에 feathers 를 사용한 것도 한 몫 하지 않았을까 생각한다.




결론.

퍼포먼스가 중요한 게임등과 같은 장르가 아니라 상대적으로 비중이 적은 앱이라면 ( 생활 util 앱 같은 ),

그리고 feathers 가 제공하는 요소들을 꽤 많이 필요로 하는 경우

이를 이용하면 개발 시간을 엄청나게 단축 시킬 수 있을 것 같긴 하다. 이는 분명히 장점이다.


타켓 플랫폼이 모바일이 아니라 pc라면 얻는 장점이 훨씬 클 것이다.


물론 아예 쳐다보지 말라는 것은 아니다.

RadionButton 과 RadioButtonGroup 기능을 구현하고 싶은데 feathers 에서는 어떤식으로 했을까?

스크롤기능과 끝에서 팅기는듯한 Elastic 기능은 다른사람은 나와다르게 어떻게 했을까?

나와는 다르게 이사람은 scale9 을 어떤방식으로 구현했을까? 

디바이스크기에 따른 리사이징 이슈는 어떤식으로 처리했을까? 같은

내부 알고리즘이나 로직, 각 클래스간의 구조등에선 배울점은 확실히 많다고 생각된다.


하지만 그게 아니라면 굳이 feathers 를 사용하지 않아도 되지 않을까 싶다.