「Flash Performance Tips Part 1」의 한국어 번역

Programming/ActionScript 3.0 2007. 11. 4. 20:15
「BIG SPACESHIP LABS / Flash Performance Tips Part I」 에서 Flash의 최적화에 대한 이야기를 하고 있어서 포스팅한다. 내용은 번역 과정에서 잘 못된 부분이 있을 수 있으므로 이해가 필요하다. Flash사이트를 최적화를 위해 부드럽게 재생시키려면 93%의 노력과6%의 지식과4%의 땀과2%정도의 butterscotch(버터를 넣은 캔디)가 필요합니다.(영화 「Charlie & the Chocolate Factory」의 대사로부터의 인용 했다고 합니다)
농담은 접어두고, 많은 사람들이Flash Player의 퍼포먼스에 고민을 하고 있지만 사이트를 부드럽게 재생시키기 위해서 당신이 할 수 있는 것이 있습니다. 부드러운 재생을 위해서 우리(BIG SPACESHIP스탭)이 매일 사용하고 있는 수법을 몇 개 소개하겠습니다.

마스크는 안된다
모든 마스크를 사용해서는 안된다는 것은 아닙니다. 마스크가 매우 도움이 되는 것은 이미 아시는 바지요. 그렇지만, 마스크는 재생 퍼포먼스를 떨어뜨리는 원인의 주범입니다. 어떤 대상을 마스크 했을 때 Flash player는 매 프레임 마다 무엇을 표시 하고 무엇을 숨기는지를 계산하고 있습니다. 마스크와 능숙하게 친해지려면 어떻게 하면 좋을까요? 거기에는 조금의 인내와 트릭인 층 구조(예를 들면 표시시키고 싶은 영역 사이즈로 구멍을 뚫은 상위 층을 올려놓고 그것을 아래의 층에 씌운다든가)를 사용하면 퍼포먼스 저하를 막으면서 같은 표시 결과를 얻을 수 있겠지요.

알파 채널 첨부PNG와 비디오에 대해
마스크와 같이 이것도 사용하지 않을 수 없을 때도 있지만 이 때도Flash Player는 알파 아래 부분의 표시 계산 처리를 강요당하고 있습니다. 경우에 따라서 우리는 절반 사이즈의 알파 비디오를 Flash위에서 확대해 사용하기도 합니다.
그리고 알파 첨부의 동영상에 대해입니다만 알파 비디오 대신에 연속된 번호의PNG를 사용하는 방법도 시험하는 가치가 있을 거라고 생각합니다. 대부분의 경우는 비디오 형식이 약간 퍼포먼스가 좋은 듯 하지만 그 때 마다 실험해 볼 가치는 있습니다.

frame rate
여러 가지 논의가 있습니다만 세상에 말하는 「매직 frame rate」같은 것은 없습니다. 우리는25, 30fps로 만들고 있습니다.(내가 알기로는) 그것이 베스트라고 생각하고 있습니다. 우리는 그 때마다 어느 쪽이 보다 좋은가를 테스트해서 결정을 하고 있습니다. 그렇지만 일반적으로 말하면 frame rate가 사이트의 재생 스피드가 저하하는 주된 원인은 되지 않을 것입니다. 아무튼 통상의 사용에서는30fps이상은 별로 추천하지 않습니다. 그렇게 아주 대단한 스피드로 렌더링 시켜도…

cacheAsBitmap 과 BitmapData
cacheAsBitmap을 이용한 벡터의 아이템의 rasterize화는 상황을 선택해 사용하도록 해야 한다. 분명히Flash는 심볼을draw하는 것은 한 번으로  끝납니다. 하지만 심볼을 확대 축소나 회전시킬 때는 결코cacheAsBitmap하지 말아야 한다. 이 때 Flash는 매프레임 마다 렌더링과 캡쳐를 반복하므로 처리가 빨라야할 어딘가가 늦어져 버립니다.
Da Vinci CodeNike Air 의 사이트에서 우리는 보이는 부분의 screen shot를 찍어 그것을 하나의 무비 클립에draw시켜서 screen shot을 애니메이션 시키는 처리를 하고 있습니다. 이것은 많은 엘리먼트를 개별적으로 움직이거나 하는 것보다도 상당히 빠릅니다.이 수법은 꽤 추천합니다.

alpha보다 visible로 하는 편이 좋아

alpha = 0과 visible = false는 실은 전혀 별개입니다. alpha는 대상이 되는 클립의 투명도를 결정하는 것입니다. Visible는 FlashPlayer위에서 실제로 그 클립을 표시 할까, 하지 않을까를 결정하는 것입니다. 만약, 무언가를 비 표시로 설정하고 싶으면 visible프롭퍼티를 사용하도록 합시다.

onEnterFrame 과 setInterval
이러한 처리를 사용했을 때는 각각 onEnterFrame = null;이나 clearInterval(myInterval); 하고, 메모리로부터 클리어 해 두도록 합시다.그것을 하지 않는 채 방치하는 것은 전화의 통화 후에 수화기를 올린 채로 떠나는 것입니다.

수학 연산은 사전에 미리 해둡시다.
표시 직전의 단계에서 싸인 웨이브(※ -1~1를 취하는 파형)을 연산하고 있지 않습니까? 그것은 매회 같은 싸인 커브는 아닙니까? 그럴 때는 수치를 배열 안에 하드 코드 해 둡시다. 사전에 수학 연산을 해 두는 것으로, 직전에 복잡한 처리를 하지 않는 것이 좋습니다. 나는 트윈 시키고 싶을 때에 사전에 배열에 모든 트윈치를 배열에 넣어두고 nextFrame()으로 매 프레임 마다 이동시킨 적도 있습니다.

무음 사운드
우리도 마지막 수단으로서 사용하고 있습니다만 기억해 두는 가치가 있는 수법이라고 생각합니다. 타임 라인상의 독립된 층에 무음의 사운드 파일을 「스트리밍 재생•루프」로 설정해 놓아두면 FlashPlayer는 사운드에 동기 시키려고 하고 자동적으로 프레임을 솎아내 조정해 줍니다.

//////////////////////////////////////////////////////////////////////////////////

위 내용은 「BIG SPACESHIP LABS / Flash Performance Tips Part I」의 내용이다. 이 밖에서 작업자 입장에서 FlashPlayer를 웃을 수 있게 해주는 방법은 여러 가지가 있을 듯 싶다. 현재 생각나는 몇 가지만 추가하고 그 이후 자신이 알고 있는 방법이 있으면 코멘트로 소통했으면 좋겠다.

1.    위에서 visible = false; 로 하는 것은 화면상의 표시 오브젝트에서 제외 되지만 그 안에서 연산하고 있는 처리는 그래도 FlashPlayer의 몫이다. 따라서 visible = false를 적용한 오브젝트 안에서 이루어지는 연산도 멈춰 주는 것이 바람직하다.

2.    for(var i:int=0;i<m_arr.length;i++) 와 같이 for문의 비교연산에서 직접 m_arr.length 값을 취득하는 것 보다 상위에 var l_intLen:int = m_arr.length; 변수를 미리 정의하여 사용하는 것 이 좋다. 이는 for문이 비교연산을 처리할 때 매번 m_arr 배열의 개수를 취득하기 위해서 연산처리를 시도하기 때문이다.

3.    _mcParent._mcChild1._mcChild2; 와 같은 참조를 여러 번 사용할 때는 상위에 var _mcChild2:MovieClip = _mcParent._mcChild1._mcChild2; 변수를 미리 선언하여 _mcChild2를 사용하는 것이 좋다. 이는 .연산자를 통해서 매번 depth 탐색이 이루어 지기 때문이다.

4.    _mcParent[“_mcChild1”]와 같은 참조 보다는 _mcParent._mcChild1과 같은 참조가 빠르다. _mcParent[“_mcChild1”]와 같은 형태로 참조할 경우에는 해시테이블 탐색을 통해서 string의 값을 비교 연산을 하기 때문이다.

5.    onEnterFrame or Timer and Interval과 같은 빠른 속도로 처리되는 function 안에서는 특정 기능을 하기 위한 코드들을 외부 function을 호출하는 형태로 분리 하는 것 보다는 직접 function 안에 쓰는 것이 좋다.(이는 유지 보수와 재 사용상의 문제가 있을 수 있음)

6.    for문을 사용하여 연속된 연산처리를 수행하는 것 보다는 절차지향으로 라인으로 풀어 쓰는 것이 빠르다.(onEnterFrame이나 interval과 같은 function 안에서 for문을 사용하는 것은 치명적이다. 이럴 때는 라인에 풀어 쓰는 것이 좋다)

이 밖에도 많은 테스트들이 있었을 것으로 생각한다. 각자 가지고 있는 노하우가 있으면 댓글을 달아 주길 바란다.

    

설정

트랙백

댓글

  • 소다수 2007.11.05 08:41 ADDR 수정/삭제 답글

    늘 좋은글 잘 읽고 갑니다. ^^

  • cmr 2007.11.07 13:28 ADDR 수정/삭제 답글

    3.0 에 와서는 가비지 컬랙션에 대한 올바른 지식이 가장 필요한 것 같아요 ㅠㅠ

    • jasu 2007.11.07 21:52 신고 수정/삭제

      가끔 코드를 짜다보면 나는 말을 하는데 쓰레기통이 대답을 안해서 문제라는...

  • 이니셜Z 2007.11.08 00:35 ADDR 수정/삭제 답글

    (Cross Referencing)교차참조와 이벤트 핸들러의 정확한 참조 위임등
    순간적인 편리함을 위한 코딩보다 조금더 손이 가는 코딩을 지향한다면
    3.0의 GC는 정말 필요할때 작동을 하는거 같더군요.
    작업관리자 창의 메모리 그래프를 실시간으로 검사하여 확인 하는 것 보다는
    현제 브라우저나 플래시플레이어창에서 다른 응용프로그램 창으로 작업 활성화를
    변경했을때 주로 메모리를 반환 하더군요.
    플래시플레이어는 OS에서 수행되는 가비지 수집 프로세스에 의해 메모리를
    반환 하는 것 같내요.

    • jasu 2007.11.09 09:34 신고 수정/삭제

      작업 전환이 이루어 지지 않는 화면상에서 메모리가 언제 반환될지를 개발자 입장에서 결정할 수 있는 권한이 없다는 것이 아리송하게 만드는것 같네요 ^^

  • 동강 2007.11.10 04:50 ADDR 수정/삭제 답글

    와 ~ 좋은 참고가 되네요 . 잘 읽고 가요.ㅋ

    • jasu 2007.11.12 02:45 신고 수정/삭제

      네... 감사합니다. 추가할 사항이 있으면 남겨주세요...^^

  • 이드 2007.11.29 19:18 ADDR 수정/삭제 답글

    좋은글 감사합니다..좀 담아갈께요.

  • 지돌스타 2009.03.05 10:06 ADDR 수정/삭제 답글

    좋은 글 너무 잘봤습니다. ^^

  • 두리미 2009.04.29 11:38 신고 ADDR 수정/삭제 답글

    좋은 글 감사합니다. ^-^

  • 지돌스타 2010.03.03 12:33 ADDR 수정/삭제 답글

    cacheAsBitmap의 경우 move를 제외한 alpha,resize,rotation등 move외에 각종 transform에는 사용하지 말아야 한다는 군요. http://www.bytearray.org/?p=290
    alpha는 괜찮을 줄 알았는데... alpha가 변경될때마다 다시 캡쳐하는 방식이라 어쩔 수 없이 cpu연산이 들어가나 봅니다.