애니메이션 버벅거림 디버그
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
앱 개발자에게 가장 어려운 문제 중 하나는 매끄럽고 결함과 버벅거림이 없는 애니메이션을 보장하는 것입니다. 특히, 시스템에서 리소스를 많이 사용하는 백그라운드 작업도 실행 중인 경우 디버깅이 어렵습니다. 버벅거림이 앱이나 시스템으로 인해 발생하는지 쉽게 확인할 방법은 없습니다. 하지만 잘못된 동작의 가능한 원인을 식별하는 데 도움이 되는 프로파일러 도구가 있습니다.
ChromeOS에서 렌더링
게임과 같이 미세 조정된 앱은 일반적으로 이중 버퍼링을 사용하여 사용자 응답 시간을 가능한 한 짧게 유지합니다. 그런데도 성능을 저하시킬 수 있는 요소가 많습니다. 예를 들어 프레임을 렌더링하는 데 시간이 너무 오래 걸리면 렌더링된 결과가 다음 버퍼 스왑을 위해 준비되지 않으므로 이전 프레임이 반복됩니다.
그러면 렌더러가 다음 프레임 렌더링을 시작할 수 없으므로 더 많은 문제가 발생합니다. 이 시나리오는 Android 모바일 개발자에게 익숙합니다. 앱이 ChromeOS에서 실행되는 경우 컨텍스트가 훨씬 더 복잡합니다.
데스크톱에서 실행되는 앱은 화면의 디스플레이 프레임에 직접 렌더링되지 않습니다. 대신 데이터를 텍스처로 렌더링합니다. 일반적으로 그래픽을 텍스처로 렌더링하는 여러 앱이 있습니다. 시스템에서는 컴포지터로 모든 텍스처를 단일 데스크톱 이미지로 결합하여 화면의 뷰를 구성합니다.
컴포지터는 백그라운드에서 투명하게 작동합니다. 그러나, GPU 파이프라인을 최대한 활용하기 위해 한 프레임 시간 지연을 도입했습니다. 이상적인 환경에서는 필요하지 않을 수 있지만 시스템 성능 변동을 완화하고 비대칭 부하의 균형을 유지하는 데 도움이 됩니다.
OS가 매우 심하게 작동하면 GPU가 압착될 수 있습니다. 프레임이 렌더링되는 시간부터 화면에 표시되는 시점까지 지연이 발생할 수 있습니다. 하드웨어에 따라 시스템에서 4중 버퍼링을 사용하여 보완할 수 있습니다. 버퍼링이 심화되더라도 그래픽 파이프라인에 결함이 있을 수 있습니다.
ARC 그래픽 추적기
ChromeOS에는 버퍼가 시스템을 통해 침투하는 방식, 메모리 스왑이 발생하는 시점, CPU/GPU 사용량, 애플리케이션이 특정 시점에 실행하는 작업을 보여주는 프로파일링 도구가 있습니다(다음 이미지 참고).

프로파일러 설정
프로파일러를 사용하려면 M75 이상을 실행해야 합니다.
최상의 결과를 얻으려면 Intel 기기를 사용하세요.
프로파일러를 사용하기 전에 트레이스로 앱을 시드합니다.
trace를 포함할 위치의 코드에 Trace.traceCounter(Trace.TRACE_TAG_GRAPHICS, "Event", <number>);
를 추가합니다. 접두어 customTrace
로 시작하는 Event
를 사용합니다. 프리픽스는 트레이스 메시지에 표시되지 않습니다.
프로파일러를 설정하려면 다음 단계를 따르세요.
- 개발자 모드를 사용 설정합니다.
- Chrome 설정을 열고 ARC graphic buffers visualization tool(ARC 그래픽 버퍼 시각화 도구)를 사용 설정합니다.
chrome://arc-graphics-tracing
로 이동합니다.
프로파일러 실행
- 버벅거림 시 중지를 선택합니다.
- Android 앱을 실행합니다.
- Android 앱이 활성 상태이고 포커스가 있으면 Control+Shift+G를 누릅니다.
버벅거림이 발생하면 브라우저 창이 팝업됩니다.
W 및 S 키를 사용하여 타임라인을 확대/축소하고 축소합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Debug animation jank\n\nOne of the most difficult problems for app developers is\nensuring smooth, glitchless, and jank-free animation. This is especially hard to\ndebug when the system is also performing resource-intensive background\ntasks. There is no easy way to determine whether some jank is caused by your app or\nthe system. However, there is a profiler tool that can help you identify the\npossible source of the bad behavior.\n\nRender on ChromeOS\n------------------\n\nA fine-tuned app, like a game, usually uses double buffering to keep the user\nresponse time as low as possible. Still, there are many things that can degrade\nperformance. For example, if rendering a frame takes too long, the rendered\nresult is not ready for the next buffer swap, and consequently the previous\nframe repeats.\n\nThen, the renderer can't start rendering the next frame,\ncausing even more problems. This scenario is familiar to Android mobile\ndevelopers; when an app runs on ChromeOS, the context is even more complicated.\n\nAn app running on the desktop doesn't render directly to the screen's display\nframe. It renders its data into a texture instead. There are usually multiple\napps, each rendering its graphics into a texture. The system constructs the view\non the screen using a compositor to combine all the textures into a single\ndesktop image.\n\nThe compositor works transparently in the background. However, it introduces a\none-frame time delay to maximize the use of the GPU pipeline. In an ideal\nworld this might not be necessary, but it smooths system performance\nfluctuations and helps balance an asymmetrical load.\n\nWhen the OS is working very hard, the GPU might get squeezed. There can be a\ndelay from the time a frame renders to when it appears on the\nscreen. Depending on the hardware, the system might use quadruple buffering to\ncompensate. Even with deeper buffering, the graphic pipeline can still glitch.\n\nThe ARC graphics tracer\n-----------------------\n\nChromeOS has a profiling tool that shows how the buffers are percolating\nthrough the system, when memory swaps occur, how busy the CPU/GPU is, and what\nyour application is doing at a given time, shown in the following image:\n\n### Set up the profiler\n\nTo use the profiler, you must run M75 or later.\nFor best results, use an Intel device.\n\nBefore using the profiler, seed your app with traces.\nAdd `Trace.traceCounter(Trace.TRACE_TAG_GRAPHICS, \"Event\", \u003cnumber\u003e);` to your code\nwherever you'd like to include a trace. Use an `Event` that begins with\nthe prefix `customTrace`. The prefix doesn't appear in the trace message.\n\nTo set up the profiler, follow these steps:\n\n1. Turn on developer mode.\n2. Turn on Chrome settings and enable the **ARC graphic buffers visualization tool**.\n3. Navigate to `chrome://arc-graphics-tracing`.\n\n### Run the profiler\n\n1. Select **stop on jank**.\n2. Run the Android app.\n3. When the Android app is active and has focus, press \u003ckbd\u003eControl\u003c/kbd\u003e+\u003ckbd\u003eShift\u003c/kbd\u003e+\u003ckbd\u003eG\u003c/kbd\u003e.\n\nWhen some jank happens, a browser window pops up.\nUse the \u003ckbd\u003eW\u003c/kbd\u003e and \u003ckbd\u003eS\u003c/kbd\u003e keys to zoom and shrink the timeline."]]