사용자 인터페이스(UI) 성능 테스트를 수행하면 앱이 기능적인 요건에 부합할 뿐만 아니라 사용자가 앱과 부드럽고 매끈하게 상호작용하며 초당 60 프레임의 일관된 속도로(왜 60fps일까요?) 생략되거나 지연된 프레임, 또는 전문 용어로 jank(프레임이 넘어가는 현상)가 없이 실행되게 보장할 수 있습니다. 이 문서에서는 UI 성능을 측정하는 데 사용할 수 있는 몇 가지 도구를 설명하고, 테스트 방법에 UI 성능 측정법을 통합하는 데 쓰이는 접근법을 보여드립니다.
성능을 개선하려면 우선 시스템의 성능을 측정할 수 있는 능력부터 갖추고, 그 다음에 파이프라인의 여러 부분에서 나올 수 있는 다양한 문제를 진단하고 식별해야 합니다.
dumpsys는 Android 도구의 일종으로 기기에서 실행되면서 시스템 서비스의 상태에 대한 흥미로운 정보를 덤프하는 역할을 합니다. gfxinfo 명령을 dumpsys에 전달하면 기록 단계 중에 발생하는 애니메이션 프레임과 관련된 성능 정보가 담긴 logcat으로 출력을 제공합니다.
> adb shell dumpsys gfxinfo <PACKAGE_NAME>
이 명령은 프레임 타이밍 데이터의 서로 다른 변형을 여러 개 작성할 수 있습니다.
M 미리 보기에서 이 명령은 프레임 데이터의 집계된 분석을 logcat으로 출력합니다. 이는 프로세스의 전 수명을 통틀어 수집한 것입니다. 예를 들면 다음과 같습니다.
Stats since: 752958278148ns Total frames rendered: 82189 Janky frames: 35335 (42.99%) 90th percentile: 34ms 95th percentile: 42ms 99th percentile: 69ms Number Missed Vsync: 4706 Number High input latency: 142 Number Slow UI thread: 17270 Number Slow bitmap uploads: 1542 Number Slow draw: 23342
이와 같은 높은 레벨의 통계는 레벨이 높을 때 앱의 렌더링 성능을 나타내며, 이외에도 여러 프레임에 걸친 앱의 안정성을 나타내기도 합니다.
M 미리 보기에서는 gfxinfo에 사용할 수 있는 새 명령어를 도입했습니다. 바로 framestats로, 이는 최근 프레임으로부터 극히 상세한 프레임 타이밍 정보를 제공하여 문제를 더욱 정확하게 추적하고 디버그할 수 있습니다.
>adb shell dumpsys gfxinfo <PACKAGE_NAME> framestats
이 명령은 프레임 타이밍 정보를 나노초 타임스탬프로 출력하며, 그 출처는 앱이 만든 마지막 120개의 프레임입니다. 아래는 adb dumpsys gfxinfo <PACKAGE_NAME> framestats에서 가져온 원시 출력을 예로 나타낸 것입니다.
0,49762224585003,49762241251670,9223372036854775807,0,49762257627204,49762257646058,49762257969704,49762258002100,49762265541631,49762273951162,49762300914808,49762303675954, 0,49762445152142,49762445152142,9223372036854775807,0,49762446678818,49762446705589,49762447268818,49762447388037,49762453551527,49762457134131,49762474889027,49762476150120, 0,49762462118845,49762462118845,9223372036854775807,0,49762462595381,49762462619287,49762462919964,49762462968454,49762476194547,49762476483454,49762480214964,49762480911527, 0,49762479085548,49762479085548,9223372036854775807,0,49762480066370,49762480099339,49762481013089,49762481085850,49762482232152,49762482478350,49762485657620,49762486116683,
이 출력의 각 줄은 앱이 만든 프레임을 나타냅니다. 각 줄에는 정해진 숫자의 열이 있으며 이 열은 프레임 제작 파이프라인의 각 단계에서 소요한 시간을 나타냅니다. 다음 섹션에서는 각 열이 무엇을 나타내는지 등, 이 형식에 대해 좀 더 자세히 다뤄보겠습니다.
데이터 블록은 CSV 형식으로 출력되기 때문에 이를 개발자가 선택한 스프레드시트 도구에 붙여넣거나 수집해서 스크립트로 구문 분석하기 등의 작업이 매우 단도직입적입니다. 다음 표는 출력 데이터 열의 형식을 설명한 것입니다. 타임스탬프는 모두 나노초 단위입니다.
이 데이터는 여러 가지 방법으로 사용할 수 있습니다. 한 가지 단순하면서도 유용한 시각화는 프레임 시간의 분배(FRAME_COMPLETED - INTENDED_VSYNC)를 여러 가지 대기 시간 버킷에서 표시한 히스토그램을 예로 들 수 있습니다. 아래 그림을 참조하십시오. 이 그래프를 보면 한 눈에 대부분의 프레임이 아주 양호했다는 것을 알아볼 수 있습니다. 대부분 16ms 최종 기한(빨간색으로 표시)보다 한참 아래에 있지만, 최종 기한을 크게 넘어선 프레임도 몇 개 있습니다. 이 히스토그램에서 시간 경과에 따른 변화를 살펴보면 대규모 이동이나 새 이상값이 생성되는 것을 확인할 수 있습니다. 이외에도 데이터 내의 수많은 타임스탬프를 근거로 입력 대기 시간, 레이아웃에서 보낸 시간 또는 여타 비슷한 흥미로운 메트릭도 그래프로 표현할 수 있습니다.
프로필 GPU 렌더링이 개발자 옵션에서 adb 셸의 dumpsys gfxinfo로 설정된 경우, adb shell dumpsys gfxinfo 명령이 가장 최근의 120개 프레임에 대한 타이밍 정보를 출력하되, 몇 개의 서로 다른 카테고리로 나누어 탭으로 구분된 값을 담아 표현합니다.
이 데이터를 사용하면 드로잉 파이프라인의 어떤 부분이 레벨이 높을 때 느려지는지 나타내는 데 유용합니다.
위의 framestats와 마찬가지로, 이것을 개발자가 선택한 스프레드시트 도구에 붙여넣거나 수집해서 스크립트로 구문 분석하는 작업은 매우 단도직입적입니다. 다음 그래프는 앱이 생성한 수많은 프레임이 어디에서 시간을 보내는지 분석한 내용을 표시한 것입니다.
Gfxinfo를 실행한 결과, 그 출력을 복사하여 이를 스프레드시트 애플리케이션에 붙여넣은 다음 데이터를 누적 가로 막대형 그래프로 나타내는 것입니다.
각 세로 막대는 애니메이션 한 프레임을 나타냅니다. 그 막대의 높이가 해당 애니메이션 프레임을 계산하는 데 걸린 밀리초 수를 나타냅니다. 막대에서 색이 지정된 각 세그먼트는 렌더링 파이프라인의 각기 다른 단계를 나타내므로, 개발자는 이것을 보고 애플리케이션의 어떤 부분이 병목 현상을 유발하고 있는지 확인할 수 있습니다. 렌더링 파이프라인을 잘 이해하고 이에 맞게 최적화하는 법에 대한 자세한 내용은 무효화 레이아웃 및 성능 비디오를 참조하십시오.
Framestats와 단순한 프레임 타이밍은 양쪽 모두 아주 짧은 시간 범위 동안 데이터를 수집합니다. 렌더링 약 2초에 상당하는 시간입니다. 이 시간 범위를 정확하게 제어하려면(예: 데이터를 특정 애니메이션에 제한), 카운터를 모두 초기화한 다음 수집한 통계를 집계하면 됩니다.
>adb shell dumpsys gfxinfo <PACKAGE_NAME> reset
이 방법은 명령 자체를 덤프하는 방법과 함께 써서 정기적인 간격을 두고 수집과 초기화를 반복하여 계속해서 2초 미만의 프레임 창을 캡처하도록 하는 데 쓰일 수도 있습니다.
성능이 저하된 것을 알아내는 것은 문제를 추적하고 애플리케이션의 건강 상태를 높은 수준으로 유지 관리하는 데 좋은 첫 단계입니다. 그러나 dumpsys는 문제의 존재 여부와 상대적인 심각도만 식별하는 데 그치지 않습니다. 각 성능 문제의 제각기 다른 원인을 진단하고 이를 해결하기 위해 적절한 방법을 찾아야 하는 것은 변하지 않습니다. 이를 위해, systrace 도구를 사용하는 것을 적극적으로 추천합니다.
Android의 렌더링 파이프라인의 작동 원리나 여기에서 마주칠 수 있는 보편적인 문제와 그 해결 방법에 대한 자세한 정보를 원하시면, 다음 리소스 중 몇 가지를 유용하게 쓸 수 있습니다.
UI 성능 테스트에 대한 한 가지 관점은 그저 인간 테스터가 대상 앱에서 일련의 사용자 작업을 수행하도록 하는 것입니다. 그러면서 육안으로 jank가 있는지 살펴보든가, 아니면 오랜 시간을 들여 도구 중심적인 관점으로 jank를 찾아내는 것입니다. 하지만 이와 같은 수동식 방법은 위험 투성이입니다. 프레임 속도 변화를 인지하는 사람의 능력에는 개인차가 극명하고, 시간도 오래 걸릴 뿐더러 지루하고 오류가 발생할 가능성이 높습니다.
보다 효율적인 접근 방식은 자동화된 UI 테스트로부터 가져온 주요 성능 메트릭을 기록하고 분석하는 것입니다. Android M 개발자 미리 보기에는 새로운 로깅 기능이 포함되어 있어 애플리케이션 애니메이션의 jank의 양과 심각도를 판별하기 쉽고, 이를 사용해 현재 성능을 판단하고 앞으로의 성능 목표를 추적하기 위해 철저한 프로세스를 구축할 수도 있습니다.
이 글에서는 그러한 데이터를 사용하여 성능 테스트를 자동화하는 데 권장되는 방안을 찬찬히 알려드립니다.
이것은 주로 두 가지 주요 작업으로 나뉘어 있습니다. 첫째로 무엇을 테스트할지, 어떻게 테스트할지를 확인합니다. 그런 다음 두 번째로 자동화된 테스트 환경을 설정하고 유지 관리하는 것입니다.
자동화된 테스트를 시작하기 전에 우선 몇 가지 수준 높은 결정을 내려야 합니다. 그래야 테스트 공간과 스스로에게 필요한 부분을 제대로 숙지할 수 있습니다.
성능이 불량한 것이 사용자에게 가장 눈에 띄는 것은 애니메이션이 원활히 작동하지 않을 때라는 점을 명심하십시오. 따라서, 테스트할 UI 작업 유형을 식별할 때에는 사용자가 가장 많이 접하게 되는 애니메이션이나 사용자 환경에 가장 중요한 것에 주안점을 두면 유용합니다. 예를 들어 다음은 이처럼 식별하는 데 유용하게 쓰일 수 있는 몇 가지 보편적인 시나리오입니다.
팀 구성원인 엔지니어, 디자이너와 제품 관리자와 협력하여 이와 같이 테스트 대상 범위에 넣어야 하는 주요 제품 애니메이션의 우선 순위를 지정하십시오.
레벨이 높을 때에는 특정한 성능 목표를 알아내고 테스트 작성에 집중하며, 그에 관한 데이터를 수집하는 것이 매우 중요할 수 있습니다. 예를 들면 다음과 같습니다.
이 모든 경우, 애플리케이션의 여러 버전에 걸쳐 성능을 나타내주는 사용 기록 추적을 수행하는 것이 좋습니다.
애플리케이션의 성능은 어느 기기에서 실행되는지에 따라 여러 가지로 달라집니다. 메모리 용량이 적고 GPU 파워가 딸리거나 CPU 칩 속도가 느린 기기도 있습니다. 이는 즉 한 가지 하드웨어 세트에서는 잘 작동하는 애니메이션이 다른 곳에서는 그렇지 않을 수도 있다는 뜻입니다. 더 나쁜 경우로는 파이프라인의 서로 다른 부분에서 병목 현상이 일어나는 결과를 초래할 수도 있습니다. 따라서, 사용자가 볼 수도 있는 이러한 변형을 감안하기 위해 테스트를 실행할 기기를 여러 가지로 선택하는 것이 중요합니다. 최신 고사양 기기, 저사양 기기, 태블릿 등 양쪽 측면을 모두 고려하십시오. CPU 성능, RAM, 화면 밀도, 크기 등의 변형을 잘 살피십시오. 고사양 기기를 통과하는 테스트가 저사양 기기에서는 실패할 수도 있습니다.
UI Automator와 Espresso 등의 도구 스위트는 개발자의 애플리케이션을 통과하는 사용자의 동작을 자동화하는 데 도움이 되도록 구축된 것입니다. 이들은 단순한 프레임워크로, 사용자와 기기의 상호작용을 흉내 냅니다. 이러한 프레임워크를 사용하려면, 사실상 개발자가 나름의 고유한 스크립트를 생성해야 합니다. 이는 일련의 사용자-동작을 통해 실행되고, 이를 기기 자체에서 재생합니다.
이렇게 자동화된 테스트를 여러 가지로 조합하여 dumpsys gfxinfo와 함께 사용하면 재현 가능한 시스템을 재빨리 만들어내 테스트를 실행하고 해당 조건 하에서 성능 정보를 측정할 수 있습니다.
UI 테스트를 실행할 수 있게 되고, 한 번의 테스트로부터 데이터를 수집할 파이프라인을 갖추게 되면 다음으로 중요한 단계는 해당 테스트를 여러 번, 여러 기기에 걸쳐 실행하고 그 결과 도출된 성능 데이터를 집계하여 개발 팀이 한층 더 상세하게 분석할 수 있게 해주는 프레임워크를 채택하는 것입니다.
UI 테스트 프레임워크(예: UI Automator)는 대상 기기/에뮬레이터에서 직접 실행된다는 점에 주목할 만한 가치가 있습니다. 반면 dumpsys gfxinfo에 의해 완료되는 성능 수집 정보는 호스트 머신이 구동하여 ADB를 통해 명령을 전송합니다. 이러한 각각의 항목 자동화를 연결하는 데 도움을 주기 위해 MonkeyRunner 프레임워크가 개발되었습니다. 이것은 호스트 머신에서 실행되는 스크립팅 시스템으로, 일련의 연결된 기기에 명령을 발행하기도 하고 이들로부터 데이터를 수신할 수도 있습니다.
UI 성능 테스트를 제대로 자동화하기 위해 최소한의 수준으로 일련의 스크립트를 구축하는 경우, 다음과 같은 작업을 수행하기 위해 monkeyRunner를 활용할 수 있어야 합니다.
문제의 패턴이나 성능 저하를 확인했으면, 다음 단계는 해결 방법을 알아내어 적용합니다. 자동화된 테스트 프레임워크가 프레임에 대해 정확한 타이밍 분석을 유지하는 경우, 최근의 의심스러운 코드/레이아웃 변경 내용을 꼼꼼히 훑어보거나(성능 저하의 경우) 수동 조사로 전환했을 때 시스템의 어느 부분을 분석할지 범위를 좁히는 데 도움이 될 수 있습니다. 수동 조사의 경우, systrace부터 시작하는 것이 좋습니다. 이렇게 하면 렌더링 파이프라인의 모든 단계, 시스템에 있는 모든 스레드와 코어는 물론 개발자가 정의한 사용자 지정 이벤트 마커 일체에 대해 정확한 타이밍 정보를 나타내주기 때문입니다.
렌더링 성능에서 타이밍을 가져와 이를 측정하는 데 수반되는 몇 가지 어려움을 알아두는 것이 중요합니다. 이와 같은 숫자는 본래 결정적인 것이 아니고 시스템 상태, 이용 가능한 메모리 용량, 열 제한 및 개발자가 사는 지역에 태양 플레어가 마지막으로 영향을 미친 시점 등에 따라 변동폭이 큽니다. 요점은 같은 테스트를 두 번 실행하면서 서로 근사치이지만 완전히 똑같지는 않은, 약간 다른 숫자를 얻어내는 데 있습니다.
이런 식으로 데이터를 제대로 수집하고 프로파일링한다는 것은 같은 테스트를 여러 번 거듭 실행하면서 얻어지는 결과를 평균 또는 중간값(너무 복잡해지니 이것을 '배치(batch)'라고 부르기로 합시다)으로 누적한다는 것을 뜻합니다. 이렇게 하면 테스트 성과를 대략적으로 어림잡을 수 있으면서 정확한 타이밍은 없어도 됩니다.
이러한 배치를 코드 변경 사이사이에 사용하여 그러한 변경 내용이 성능에 미치는 상대적인 영향을 알아볼 수도 있습니다. 변경 전 배치의 평균 프레임 속도가 변경 후 배치에서보다 빠른 경우, 해당 변경에 대해 전반적으로 좋은 WRT 성능을 성취했다는 뜻입니다.
이는 즉 개발자가 수행하는 자동화된 UI 테스트는 모두 이 개념을 감안해야 한다는 뜻이기도 하고, 테스트 중에 일어나는 모든 변칙적인 부분 또한 감안해야 한다는 뜻입니다. 예를 들어 애플리케이션 성능이 일종의 기기 문제(본인의 애플리케이션에서 기인한 것이 아님) 때문에 갑자기 뚝 떨어지는 경우라면 해당 배치를 다시 실행하여 조금 덜 혼란스러운 타이밍을 얻어야 할 수도 있습니다.
그렇다면 측정값이 의의를 지니려면 테스트를 몇 번이나 수행하는 것이 좋습니까? 최소한 10번은 해야 합니다. 실행 횟수가 50이나 100처럼 커질수록 더욱 정확한 경과를 도출할 수 있습니다(물론, 이제는 정확도와 시간을 맞바꿔야 하는 셈입니다).