본문으로 건너뛰기
黯羽轻扬매일 조금씩

Chrome DevTools-Timeline

무료2016-12-24#Tool#Chrome Timeline panel#Timeline面板怎么用#CSS动画调试工具#CSS动画性能调优

Timeline 도구를 사용하여 애니메이션 성능을 디버깅하는 방법은?

서문에

본문 첫 부분은 Chrome DevTools 문서에서 번역했습니다: How to Use the Timeline Tool

작년에도 이 작업을 했습니다. Chrome DevTools 참조. Chrome 버전과 문서는 지속적으로 업데이트 중이며, Timeline 패널 기능은 더 강력해졌고 레이아웃도 일부 변화했습니다

一.번역문

Chrome DevTools 의 Timeline 패널을 사용하여 애플리케이션 실행 시의 모든 활동을 기록·분석할 수 있으며, 애플리케이션의 성능 문제를 조사하는 데 사용할 수 있습니다

[caption id="attachment_1260" align="alignnone" width="625"]timeline-panel timeline-panel[/caption]

콘텐츠 개요

  • 타임라인 기록을 생성하여 페이지 로딩 후 또는 사용자 인터랙션 후에 발생하는 모든 이벤트 분석

  • 개요 페인에서 FPS, CPU, 네트워크 요청 표시

  • 플레임 차트 (flame chart) 의 각 이벤트 클릭하여 상세 정보 표시

  • 기록의 일부를 확대하여 분석 가능

Timeline 패널 개요

[caption id="attachment_1263" align="alignnone" width="938"]timeline-annotated timeline-annotated[/caption]

Timeline 패널은 위에서 아래로 순서대로:

  • 제어 옵션

기록 시작, 기록 정지, 기록 프로세스 중 어떤 정보를 캡처할지 설정

  • 개요

    페이지 성능의 고도 요약. 더 많은 내용은 아래

  • 플레임 차트

CPU 스택 트레이스의 시각화 표현

플레임 차트에는 3 개의 수직 점선이 표시될 수 있습니다. 파란선은 DOMContentLoaded 이벤트, 초록선은 첫 번째 그리기 시점, 빨간선은 load 이벤트를 나타냅니다

  • 상세 정보

이벤트를 선택하면, 최하단 상세 정보 페인에 해당 이벤트의 상세 정보가 표시됩니다. 이벤트가 선택되지 않았을 때는 선택된 시간 범위의 종합 정보가 표시됩니다

개요 페인

[caption id="attachment_1265" align="alignnone" width="954"]overview-annotated overview-annotated[/caption]

3 가지 유형의 그래프가 포함됩니다:

  • FPS

    초당 프레임 수. 초록색 바가 높을수록 FPS 가 높음. FPS 그래프 상단의 빨간 블록은 긴 프레임을 나타내며, 저크 (jank) 가 발생할 가능성이 있음

  • CPU

    CPU 리소스. 영역 차트 (area chart) 는 어떤 유형의 이벤트가 CPU 리소스를 소비했는지 표시

  • NET

    각 색상 바는 리소스를 나타내며, 바가 길수록 리소스 획득에 시간이 더 걸림. 각 바의 밝은 부분은 대기 시간 (리소스 요청부터 첫 번째 바이트를 얻을 때까지의 시간) 을 나타냄. 어두운 부분은 데이터 전송 시간 (첫 번째 바이트를 얻은 후 마지막 바이트를 얻을 때까지의 시간) 을 나타냄

    바의 색상 의미는 다음과 같음:

     HTML: 파랑
 Scripts: 노랑
 CSS: 보라
 Media: 초록
 기타 여러 리소스: 회색

기록 생성

Timeline 패널을 열고, 기록하고 싶은 페이지를 연 후, 페이지를 reload 합니다. Timeline 패널은 reload 프로세스를 자동으로 기록합니다

페이지 인터랙션을 기록하려면, 먼저 Timeline 패널을 연 후, 기록 버튼을 클릭하거나 단축키 Cmd+E(Mac) 또는 Ctrl+E(Windows/Linux) 를 누릅니다. 기록 버튼이 빨갛게 변하면 기록 중임을 나타냅니다. 페이지 인터랙션을 수행한 후, 다시 기록 버튼을 클릭하거나 키보드 단축키를 눌러 기록을 정지합니다

기록 종료 시, DevTools 는 어떤 부분이 가장 관심 있는 부분인지 추측하여 자동으로 해당 부분을 선택합니다

溫馨提示:

  • 기록 프로세스를 가능한 한 짧게. 짧을수록 분석하기 쉬움

  • 불필요한 동작 회피. 기록 분석하려는 부분과 관계없는 외부 동작 (마우스 클릭, 네트워크 로딩 등) 회피. 예를 들어, 로그인 버튼 클릭 후 발생하는 이벤트를 기록하려면, 동시에 페이지를 스크롤하거나 이미지를 로딩하지 마십시오

  • 브라우저 캐시 비활성화. 네트워크 작업을 기록할 때는 DevTools 설정 패널 또는 네트워크 상황 (Network conditions) 옵션을 통해 브라우저 캐시를 비활성화하는 것이 최선

  • 플러그인 비활성화. Chrome 플러그인은 애플리케이션의 Timeline 기록에 영향을 줄 수 있음. 시크릿 모드 (incognito mode) 에서 Chrome 창을 열거나, 새로운 Chrome 사용자 프로필 (Chrome user profile) 을 생성하여 환경에 플러그인이 없음을 보장할 수 있음

기록 상세 정보 보기

[caption id="attachment_1269" align="alignnone" width="936"]details-pane details-pane[/caption]

플레임 차트에서 이벤트를 선택하면, 상세 정보 페인에 이벤트에 대한 추가 정보가 표시됩니다

Summary 등의 일부 탭은 모든 이벤트 유형에 있으며, 다른 일부 탭은 특정 이벤트 유형에만 있습니다. 기록 유형에 대한 상세 정보는 Timeline event reference 참조

기록 프로세스 중 스크린샷

[caption id="attachment_1270" align="alignnone" width="625"]timeline-filmstrip timeline-filmstrip[/caption]

Timeline 패널은 페이지 로딩 프로세스 중에 스크린샷을 촬영할 수 있으며, 이 특성은 영화 필름 스트립과 같습니다

기록 시작 전에, 제어 페인에서 Screenshots 체크박스를 체크하면, 스크린샷이 기록되며, 스크린샷은 개요 페인 하단에 표시됩니다

스크린샷 또는 개요 페인 위에 마우스를 호버하면, 해당 시점의 확대 스크린샷을 볼 수 있습니다. 마우스를 왼쪽에서 오른쪽으로 이동하여 애니메이션 효과를 시뮬레이션할 수 있습니다

JS 성능 분석

[caption id="attachment_1271" align="alignnone" width="625"]js-profile js-profile[/caption]

기록 시작 전에, JS Profile 체크박스를 체크하면 타임라인 기록 중 JS 호출 스택을 캡처할 수 있습니다. JS Profile 을 활성화하면, 플레임 차트에는 호출된 각 JS 함수가 표시됩니다

그리기 성능 분석

[caption id="attachment_1272" align="alignnone" width="625"]paint-profiler paint-profiler[/caption]

기록 시작 전에, Paint 체크박스를 체크하면 Paint 이벤트를 자세히 볼 수 있습니다. 그리기 성능 분석을 활성화하면, Paint 이벤트를 클릭할 때, 상세 정보 페인에 Paint Profiler 탭이 표시되어 더 세밀한 입자도의 이벤트 정보가 표시됩니다

렌더링 설정

[caption id="attachment_1273" align="alignnone" width="822"]rendering-settings rendering-settings[/caption]

메인 DevTools 메뉴를 열고 More tools > Rendering settings 를 선택하여 렌더링 설정을 수행합니다. 그리기 문제 디버깅에 도움이 될 수 있습니다. 렌더링 설정을 열면, Console 탭 옆에 탭이 표시됩니다 (없으면 esc 를 눌러 표시)

기록 찾기

[caption id="attachment_1274" align="alignnone" width="690"]find-toolbar find-toolbar[/caption]

이벤트를 볼 때, 한 유형의 이벤트에만 주목하고 싶을 수 있습니다. 예를 들어, 각 Parse HTML 이벤트의 상세 정보를 봐야 할 수 있습니다

Timeline 패널에서 Cmd+F(Mac) 또는 Ctrl+F(Windows/Linux) 를 눌러 찾기 도구 모음을 열고, 보고 싶은 이벤트 유형명 (예: Event) 을 입력합니다

도구 모음은 현재 선택된 시간 프레임에만 유효하며, 선택된 시간 프레임 밖의 모든 이벤트는 찾기 결과에 표시되지 않습니다

위아래 화살표로 결과 내에서 시간순으로 이동할 수 있습니다. 따라서 첫 번째 결과는 선택된 시간枠에서 가장 이른 이벤트이고, 마지막 결과는 가장 늦은 이벤트입니다. 위아래 화살표를 클릭할 때마다, 새로운 이벤트가 선택되므로, 상세 정보 페인에서 그 상세 정보를 볼 수 있습니다. 위아래 화살표를 클릭하는 것은 플레임 차트의 이벤트를 클릭하는 것과 동일합니다

타임라인의 일부 확대

[caption id="attachment_1275" align="alignnone" width="625"]zoom zoom[/caption]

기록의 일부를 확대하여 더 쉽게 분석할 수 있습니다. 개요 페인을 사용하여 기록의 일부를 확대할 수 있으며, 확대 후, 플레임 차트는 자동으로 해당 부분에 맞춰 확대됩니다

타임라인의 일부를 확대하려면:

  • 개요 페인에서, 마우스로 타임라인의 일부를 드래그하여 선택

  • 자 영역의 회색 슬라이더 조정

일부를 선택한 후, WASD 로 선택 범위를 조정할 수 있습니다. W 와 S 는 확대 축소, A 와 D 는 좌우 이동

기록 내보내기 및 가져오기

[caption id="attachment_1276" align="alignnone" width="517"]save-open save-open[/caption]

개요 또는 플레임 차트 페인에서 오른쪽 클릭하여 저장 및 열기, 그리고 관련 옵션을 선택할 수 있습니다

二.애니메이션 성능 지표

프레임 레이트

가장 직관적인 것은 프레임 레이트 (단위는 FPS, 초당 프레임 수를 나타냄) 로, 30 이하는 인간의 눈이 명확히 저크를 느끼고, 60 이상은 눈으로 차이를 알 수 없으며, 30-60 은 기본적으로 매끄럽습니다

성능 목표는 애니메이션 프레임 레이트를 가능한 한 60FPS 에 가깝게 하는 것으로, 이렇게 하면 한 칸 한 칸 느낌이 없어집니다. 따라서 애니메이션 라이브러리는 일반적으로 이렇게 합니다:

/* rAF shim. Gist: https://gist.github.com/julianshapiro/9497513 */
var rAFShim = (function() {
    var timeLast = 0;

    return window.webkitRequestAnimationFrame || window.mozRequestAnimationFrame || function(callback) {
        var timeCurrent = (new Date()).getTime(),
                timeDelta;

        /* Dynamically set delay on a per-tick basis to match 60fps. */
        /* Technique by Erik Moller. MIT license: https://gist.github.com/paulirish/1579671 */
        timeDelta = Math.max(0, 16 - (timeCurrent - timeLast));
        timeLast = timeCurrent + timeDelta;

        return setTimeout(function() {
            callback(timeCurrent + timeDelta);
        }, timeDelta);
    };
})();

requestAnimationFrame 을 지원하는 경우 직접 사용하여, 브라우저가 실행 빈도를 결정하게 합니다 (일반적으로 초당 60 회 이상). 지원하지 않는 경우 폴백 방안은 setTimeout 입니다:

// 16 = 1000 / 60
timeDelta = Math.max(0, 16 - (timeCurrent - timeLast));

초당 60 회에 도달하려면, 실행 간격은 16ms 를 초과해서는 안 됩니다. 따라서 setTimeout 지연 시간은 일반적으로 16 - 함수 실행에 필요한 시간 입니다. 함수 실행 시간이 16ms 를 초과하는 경우, 지연은 0 입니다

프레임 레이트에는 많은 영향 요인이 있습니다. 예를 들어, 계산 집약적인 JS 작업이 대량의 CPU 시간을 점유하여 애니메이션 관련 JS 실행이 지연되거나, 레이아웃 변경으로 인한 빈번한 재그리기 Rendering/Painting 시간 소비 증가, 컴포지트 레이어가 너무 크거나 많아 Composite Layers 시간 소비 증가 및 GPU 그리기 압력 증가로 시간 소비가 길어지는 등

메모리

본래 애니메이션과 메모리는 직접적인 관계가 없지만, 하드웨어 가속으로 인해, 애니메이션 요소에 하드웨어 가속 적용->컴포지트 레이어 생성->메모리 소비 라는 관계가 생깁니다

CPU 와 GPU 는 메모리를 공유하지 않으므로, 컴포지트 레이어를 생성하려면 요소 렌더링 후 해당하는 비트맵 데이터를 패키징하여 GPU 에 전송해야 합니다. 이 데이터가 "애니메이션이 소비하는 메모리"입니다. 따라서 애니메이션 저크는, 자신이 만든 것일 수 있으며, 메모리도 애니메이션 성능 지표 중 하나입니다

애니메이션에 대응하면, 컴포지트 레이어 수 와 컴포지트 레이어 크기 가 됩니다. 컴포지트 레이어가 많고 클수록, 비트맵 데이터는 커지고, 소비 메모리도 커집니다

三.애니메이션 성능 디버깅 방법

프레임 레이트와 메모리 두 방면에 대해, 몇 가지 디버깅 방법이 있습니다:

###1.무엇이 가장 시간을 소비하는가

Timeline 도구를 사용하여 비교적 저크를 느끼는 부분을 기록하고, FPS 란에 빨간 바가 있는 부분을 선택하고, 최하단 상세 정보 페인의 Summary 를 보고, 원 그래프에서 가장 시간을 소비하는 것을 찾습니다. 예를 들어:

Range: 294ms - 1.17s
Total: 878.74?ms
29.1?ms Loading
197.0?ms Scripting
43.0?ms Rendering
4.4?ms Painting
116.3?ms Other
489.0?ms Idle

JS 가 가장 시간을 소비하는 경우, Event Log 탭을 클릭하고, 시간 소비순으로 정렬하고, 처음 몇 항목을展開하여, 구체적인 JS 파일을 특정하고, 시간 소비 원인을 분석하고, 최적화 방안을 검토합니다

Rendering 이 가장 시간을 소비하는 경우, HTML 구조를 간소화하고, 불필요한 요소를 제거하고, 레이아웃을 간소화하며, reflow 를 줄이는 것을 검토해야 합니다. Painting 의 경우, 컴포지트 레이어에 주목해야 하며, 컴포지트 레이어가 너무 많거나 크지는 않은지, 여분의·보이지 않는 컴포지트 레이어를 제거하는 것을 검토하고, 애니메이션 요소의 z-index 를 늘려, 암묵적으로 컴포지트 레이어를 생성하는 것을 회피합니다

P.S. 먼저 시크릿 모드를 활성화한 후, Timeline 으로 기록하는 것을 권장합니다.否则, 각종 플러그인의 JS 가 원인 특정의 방해가 됩니다 (원 그래프가 부정확해짐)

###2.무엇이 가장 메모리를 소비하는가

기록 시간枠의 메모리 그래프를 관찰하고, 피크 부분을 선택하고, Event Log 탭에서 관련 이벤트를 찾고, 이벤트와 관련된 JS 를 검토합니다

하지만, 일반적으로 JS 의 영향은 컴포지트 레이어의 영향보다 훨씬 작으므로, 직접 컴포지트 레이어의 상황을 확인할 수 있습니다: 개요 페인에서 FPS 에 빨간 바가 있는 시간 구간을 드래그하여 선택하고, 상세 정보 페인의 Layers 탭을 표시하고, document 하의 각 레이어를展開하고, 몇 가지 사항에 주목합니다:

  • 컴포지트 레이어의 수는 예상대로인가, 나타나서는 안 되는 레이어는 없는가?

  • 레이어를 클릭하면, 그 크기와 메모리 소비 및 해당 레이어의 생성 원인을 볼 수 있으며, 메모리 소비가 너무 크지는 않은지 확인

대サイズの 컴포지트 레이어는 매우 메모리를 소비합니다. 예를 들어, 375x667 의 레이어는 1.5MB 의 메모리를 소비합니다. 이러한 대사이즈 레이어가 많은 경우, 대량의 메모리를 점유하고, 메모리가逼迫하면 확실히 저크합니다

31x31 의 소사이즈 버튼도 16KB 가 필요합니다. 따라서, 대사이즈 애니메이션 요소에 주목할 뿐만 아니라, 컴포지트 레이어의 수도 중요한 요인입니다. 예를 들어, 거품, 연기 등 대량의 소요소로 구현해야 하는 애니메이션은, 효과 다운그레이드 또는 요소 수 감소를 검토하고, 의사 요소 및 border, outline, box-shadow 등의 속성을 사용하여 복잡한 HTML 구조를 간소화합니다

P.S. 컴포지트 레이어를 줄이고, 메모리 소비를 낮추는 더 많은 방법에 대해서는, [CSS 애니메이션과 GPU-성능 최적화 기법](/articles/css 动画与 gpu/#articleHeader10) 참조

참고 자료

댓글

아직 댓글이 없습니다

댓글 작성