famo.us 코드 분석글은 정확한 글이 아니라 공부하면서 정리한 글이라 정확하지 않고 개인적인 의견들이 난무합니다. 정리하는 용도이니 추후 정리가 완료되면 좀 더 정확한 내용을 올릴 예정이니 나중에 정리된 글을 보세요.



매주 화요일날 만나서 관심있는 자바스크립트 라이브러리를 분석하는 스터디를 진행 중인데 난 famo.us을 한다. 예전에 facebook에 paper을 웹으로 만들면서 화제가 됬고 최근데 2000만불을 펀딩 받은 것으로 유명하다. 

회사얘기는 대충하고 일단 이 친구들이 말하는게 다양한 폰에서 고퀄의 애니메이션을 보장해준다고 하길래 모바일웹을 개발해 본 입장에서 이게 가능할까라는 생각이 들어서 시작한다.

이번에는 프로젝트의 환경은 어떤지 찾아보고 몇 가지 문서를 보고 구조를 파악했다.


환경

빌드하는 도구가 있을 것 같지만, package.json에는 lint랑 jscs만 한다. 머징한 파일이 있는 것으로 보아 내부적으로 관리하는 것 같다. 컨트리뷰트 과정을 확인해보니 테스트 코드에 대한 내용이 없는데 내부적으로는 어떨지 모르겠다. 그리고 requirejs로 의존성 관리를 한다.


실행

기본적으로 실행하기 위해 몇 가지가 필요하다.

1. famous code : 내가 찾아볼 파일

2. polyfill code : 일부 polyfill들

3. css : 기본 스타일이나 크게 많지 않고 일부다.


구조

이번 내용은 주로 [링크]을 보고 정리한 내용. 

famous는 자체적으로 브라우저와 같은 Render Tree의 형식을 가지고 있다. 그래서 60fps를 가능하게 만들어준다.(왜 그런지는 끝에) famous는 JS로만 개발가능하게 만든 라이브러리로 sencha와 비슷한 컨셉

먼저, Context를 만듬. 브라우저로 따지면 root라고 생각하면 됨.

var context = Engine.createContext();
context.add(surface);

브라우저의 RenderObect와 같이 다수의 node을 가진다.

node의 종류는 Renderables, Modifiers가 있다.

Renderables은 실제 화면에 그려주는 역할을 하는 node로 ContainerSurface, ImageSurface, InputSurface, CanvasSurface, VideoSurface가 있다. 걍 엘리먼트라고 생각하면 된다. 여기서는 surface가 렌더링 되는 최소의 단위고 직접 컨트롤하기 보다는 surface를 통해하기를 말한다.

Modifiers는 움직이는 역할이다. Renderables은 정적인 컨텐츠고 실제로 움직일 때는 Modifiers을 사용한다.

var context = Engine.createContext(); var chain = context.add(modifier); chain.add(surface); var modifier = new Modifier({ transform : Transform.translate(100,200) });


그리고 각 노드들은 트리 형식의 구조를 만들 수 있고 add메서드을 통해 Tree을 만든다.

Chaining Nodes : 
  context                    var context = Engine.createContext();
     │
 modifier1                   context.add(modifier1)
     │                              .add(modifier2)
 modifier2                          .add(surface);
     │
  surface

Branching Nodes : 
      context                var context = Engine.createContext();
   ┌─────┴─────┐
modifier    surface2         context.add(modifier).add(surface1); // left branch
   │
surface1                     context.add(surface2);               // right branch

Views라는 개념이 있는데 이건 그냥 일반적으로 얘기하는 UI컴포넌트의 형식이라고 생각하면 된다. Render Tree에 추가하고 이벤트를 받거나 전달하고 파라메터, 상태를 지정가능. 여기서는 shadow dom과 같은 컨셉이라고 얘기한다. 아마도 직접 돔을 컨트롤하지 않고 View을 컨트롤하기 때문에 그런듯.

정리하면, Surfaces는 컨텐츠, Modifiers는 layout, 구조는 add메서도로 연결.



 Render Tree와 DOM을 비교한 표.

보면 알겠지만, famo.us는 html을 사용하는게 아니라 모두 famo.us객체를 사용한다. 

얻는 장점은 모든지 컨트롤 가능하다. 즉, 돔을 직접 수정한다면 생기는 문제점을 famo.us는 requestAnimationFrame에서 batch로 돌려 개선할 수 있다.

물론 단점은 생각보다 협업하기가 까다롭고, 모든걸 famo.us을 믿고 가야 하기 때문에 쉽지 않은 방법이다.


일단, 여기까지 본 결과 성능이 좋은 이유는 famo.us는 직접 DOM을 컨트롤하지 않고 Render Object을 만들어 컨트롤하기 때문에 requestAnimationFrame으로 batch를 하기 때문이 아닐까 생각하고 있다. 좀 더 살펴보는걸로.


https://famo.us/guides/render-tree


Posted by 전용우
,