Systrace — 개념 및 Android 시스템 트레이싱 도구

Systrace란

Systrace는 Android SDK의 명령줄 유틸리티로, 여러 커널 트레이싱(ftrace) 및 사용자 공간(atrace) 소스의 데이터를 단일 HTML 보고서로 캡처하고 병합합니다. 이 도구는 Android 4.1(Jelly Bean)에서 시스템 프로파일링을 위한 이전 traceview 유틸리티를 대체하기 위해 등장했으며 오랫동안 Android 플랫폼에서 표준 성능 진단 도구로 자리 잡았습니다.

Systrace 아키텍처

Systrace는 ftrace에 의존합니다 — Android 4.1부터 사용 가능한 Linux 커널 트레이싱 메커니즘입니다. Systrace가 시작되면 지정된 트레이스 카테고리를 활성화합니다: sched(작업 스케줄러), freq(CPU 주파수), idle(유휴 상태), workq(작업 큐), binder, gfx 등입니다. 데이터는 커널의 링 버퍼에 수집되고 중지 후 단일 trace.html 파일로 병합되어 모든 브라우저에서 열 수 있습니다.

Android Studio 맥락에서의 Systrace

Android Studio 3.1부터 Systrace는 CPU Profiler에 내장되어 있습니다. “Trace System Calls” 모드에서 프로파일러는 연결된 장치에서 Systrace를 실행하고 결과를 Android Studio 창에 직접 표시합니다. 이를 통해 기본적인 경우 명령줄 작업이 필요하지 않으며 모든 트레이스 카테고리, 필터링 및 대화형 타임라인이라는 완전한 기능을 유지합니다. 트레이싱 중 장치 성능 저하는 미미합니다. ftrace가 최소 오버헤드로 설계되었기 때문입니다.

Systrace 작동 방식

Systrace는 두 가지 데이터 수집 메커니즘을 사용합니다: 시스템 이벤트용 커널 수준의 ftrace와 Android 특정 태그용 사용자 공간의 atrace입니다. ftrace는 컨텍스트 스위치(sched_switch), CPU 주파수 변경(cpu_frequency), 인터럽트(irq_handler_entry) 및 기타 이벤트를 기록합니다. atrace는 Android 프레임워크의 태그 — 프레임 렌더링 시작 및 종료, SurfaceFlinger 호출 및 Binder 트랜잭션을 추가합니다.

Systrace의 프레임 렌더링 파이프라인

Systrace의 주요 기능은 각 프레임의 렌더링 파이프라인 시각화입니다: 애플리케이션 → BufferQueue → SurfaceFlinger → HWC(컴포저) → 디스플레이. 어떤 단계에서 지연이 발생하면 Systrace가 정확한 원인을 보여줍니다: 애플리케이션이 제시간에 버퍼를 준비하지 못함, SurfaceFlinger가 VSync를 기다리는 중, HWC가 레이어를 합성할 수 없음 등입니다. 타임라인의 프레임 수명 주기는 상태에 따라 색상으로 구분됩니다: 녹색(제시간), 노란색(지연), 빨간색(드롭). 이 시각화는 UI 성능 최적화를 위한 기본 도구입니다.

트레이스 카테고리

Systrace는 20개 이상의 트레이스 카테고리를 지원하며 각 카테고리는 관련 이벤트 집합을 포함합니다. 중요한 카테고리로는 gfx(그래픽 렌더링), input(입력 처리), view(View 시스템), webview(WebView), power(전력 소비), hal(하드웨어 추상화 계층)이 있습니다. 게임 프로파일링에는 AGI(Android GPU Inspector)를 통한 GPU 명령 세부 정보가 포함된 gfx 카테고리가 유용합니다.

Systrace의 주요 기능

Systrace는 다른 프로파일러에서는 사용할 수 없는 Android용 고유한 기능 세트를 제공합니다: 시스템 타임라인, 커널 수준 메트릭 및 자동 문제 감지입니다.

대화형 타임라인

Systrace HTML 리포트에는 각 레인이 하나의 프로세스 또는 스레드에 해당하는 다중 레벨 타임라인이 포함되어 있습니다. 시간 축을 확대/축소하고 이벤트를 클릭하여 세부 정보(기간, 시작 프로세스, 추가 인수)를 볼 수 있습니다. 색상 코딩은 빠른 탐색에 도움이 됩니다: 녹색 블록 — 프로세스 실행 중, 파란색 — 대기 중, 주황색 — 인터럽트, 흰색 — 유휴 상태.

알림 메시지

Systrace는 트레이스를 자동으로 분석하고 문제 영역을 나타내는 알림 메시지를 표시합니다. 예: “Buffer underrun — SurfaceFlinger가 VSync 전에 버퍼를 받지 못함” 또는 “Long Binder transaction — 스레드 Binder_1에서 42ms”. 각 알림에는 타임라인의 해당 섹션 링크와 수정 권장 사항이 포함됩니다. 이는 수동 분석 시간을 절약하고 수동 로깅 대신 Systrace를 사용하는 주된 이유 중 하나입니다.

Trace.beginSection 메서드

개발자는 Trace.beginSection 및 Trace.endSection API를 통해 Systrace 트레이스에 사용자 정의 태그를 추가할 수 있습니다. 이를 통해 시스템 타임라인에서 직접 중요한 코드 섹션의 실행을 추적할 수 있습니다 — 예를 들어 데이터 로딩 또는 레이아웃 계산의 시작과 끝을 표시할 수 있습니다. 태그는 애플리케이션 레인에 별도의 블록으로 나타나 시스템 이벤트와 함께 표시됩니다.

Systrace 실행 방법

Systrace 실행은 두 가지 방법으로 가능합니다: Android Studio CPU Profiler(“Trace System Calls” 모드)를 통해 또는 platform-tools 폴더의 systrace.py Python 스크립트를 사용하여 명령줄을 통해 실행합니다. 각 방법에는 고유한 사용 사례가 있습니다.

Android Studio를 통한 실행

장치를 연결하고 Profiler를 엽니다(View → Tool Windows → Profiler). 프로세스를 선택하고 CPU 탭으로 이동하여 “Trace System Calls” 모드를 선택하고 Record를 클릭합니다. 5–30초 후 Stop을 클릭합니다 — Android Studio가 장치에서 Systrace를 실행하고 완료를 기다린 후 결과를 로드합니다. 제한 사항: Profiler가 열려 있는 동안에만 녹화가 가능하므로 긴 시나리오나 자동화에는 불편합니다.

명령줄에서 실행

더 유연한 제어를 위해 systrace.py 스크립트를 사용합니다. 트레이스 카테고리, 기간 및 출력 파일 이름을 지정합니다. 예: 10초 동안 gfx, input 및 sched 데이터 캡처. 실행하려면 Python 2.7+와 USB 디버깅이 활성화된 연결 장치가 필요합니다. Android 12+에서는 Systrace가 Perfetto로 대체됩니다 — 명령은 동일하게 유지되지만 스크립트는 호출을 perfetto로 리디렉션합니다.

# systrace 기본 10초 실행
$ python systrace.py \
    --time=10 \
    -o trace.html \
    gfx input sched

# UI 분석을 위한 gfx 카테고리만
$ python systrace.py \
    --time=5 \
    -t gfx \
    -o ui_trace.html

코드에서 사용자 정의 태그 설정

코드가 Systrace 타임라인에 나타나도록 하려면 중요한 섹션을 Trace.beginSection / Trace.endSection으로 래핑합니다. beginSection과 endSection은 엄격히 쌍을 이루어야 합니다 — 그렇지 않으면 Systrace가 잘못된 타임라인을 표시합니다. Kotlin에서는 예외가 발생한 경우에도 섹션 종료를 보장하기 위해 인라인 확장을 사용하는 것이 편리합니다.

import android.os.Trace

fun traceSection(name: String, block: () -> Unit) {
    Trace.beginSection(name)
    try {
        block()
    } finally {
        Trace.endSection()
    }
}

// 코드에서 사용
traceSection("load_screen_data") {
    fetchData()
    updateUI()
}

Systrace HTML 리포트 읽기

Systrace 리포트는 Chrome, Edge 또는 Firefox에서 열 수 있는 자체 포함 HTML 파일입니다. 대화형 타임라인, 프로세스 선택 패널, 알림 메시지 목록 및 주요 메트릭(프레임 속도, CPU 사용량, Binder 트랜잭션)이 포함되어 있습니다. 리포트 구조를 이해하는 것은 효과적인 프로파일링을 위한 핵심 기술입니다.

타임라인 및 탐색

타임라인은 시간을 왼쪽에서 오른쪽으로 표시합니다. 각 프로세스와 스레드는 별도의 레인입니다. W/S 키는 확대/축소, A/D는 시간 이동입니다. 마우스로 영역을 선택하여 섹션을 확대합니다. VSync 라인은 프레임 경계를 표시합니다(60 FPS에서 16.6ms 간격). 두 VSync 라인 사이에 전체 렌더링 주기가 맞지 않으면 프레임이 드롭됩니다. SurfaceFlinger 레인에 주목하세요: 오랜 시간 동안 바쁘면(주황색 블록) 레이어 합성이 전체 렌더링을 느리게 하고 있는 것입니다.

알림 메시지 분석

리포트 왼쪽의 알림 패널에는 자동으로 감지된 문제가 포함되어 있습니다. 각 알림은 클릭 가능합니다 — 클릭하면 타임라인이 문제 지점으로 이동합니다. 가장 일반적인 알림: “Long Sync”(긴 스레드 동기화), “Scheduling Delay”(스케줄러 지연), “Buffer Overrun”(SurfaceFlinger 버퍼 오버플로). Scheduling Delay에 ~100ms 값이 표시되면 UI 스레드가 백그라운드 부하로 인해 CPU를 기다리고 있었음을 직접 나타냅니다 — 무거운 계산은 Worker Thread로 이동해야 합니다.

프레임 수명 주기 및 Jank

드롭된 프레임을 분석하려면 SurfaceFlinger 및 app.gfx 레인을 활성화합니다. 각 프레임은 사각형으로 표시됩니다: 녹색(≤16ms), 노란색(16–32ms), 빨간색(>32ms). 앱 레인에서 빨간색 사각형이 보이면 클릭합니다 — Systrace가 한도를 초과한 특정 메서드(또는 시스템 호출)를 표시합니다. Google(Android Performance Patterns, 2023)에 따르면 Jank 문제의 70%는 느린 onBindViewHolder 또는 빈번한 GC로 인해 발생합니다.

Systrace vs Perfetto: 새 형식으로 전환

Perfetto는 Systrace의 후속 제품으로, Google이 Android 9(Pie)에서 실험적 도구로 도입했으며 Android 12부터 기본 솔루션이 되었습니다. Perfetto는 최신 protobuf 데이터 형식을 사용하고 긴 세션(초 대신 시간)을 지원하며 트레이스 보기용 웹 UI를 갖추고 있습니다. 두 시스템의 주요 차이점을 살펴보겠습니다.

Perfetto로의 전환에도 불구하고 Systrace 기술은 여전히 유효합니다: Android 11 이하 장치에서는 기본적으로 사용되며 Perfetto는 Systrace 카테고리와의 하위 호환성을 유지합니다. Android Studio CPU Profiler에서는 새 장치에 Perfetto를 사용하고 이전 장치에는 Systrace를 사용합니다 — 사용자에게 투명합니다. CI/CD의 경우 형식을 Python 및 SQL을 통해 자동으로 처리할 수 있으므로 Perfetto가 권장됩니다.

Systrace 사용 예제

Systrace를 실질적으로 마스터하기 위해 두 가지 시나리오를 살펴보겠습니다: 스크롤 중 프레임 드롭 원인 찾기와 UI 스레드를 차단하는 빈번한 GC 진단입니다.

RecyclerView 스크롤 중 Jank 찾기

gfx 카테고리로 Systrace를 10초 동안 실행하고 앱에서 목록을 스크롤합니다. 리포트에서 빨간색 프레임이 있는 섹션을 찾습니다. 문제 프레임을 클릭하고 앱 레인을 확인합니다 — “inflateLayout” 또는 “onBindViewHolder” 블록이 16ms보다 넓으면 레이아웃 인플레이션 또는 데이터 바인딩에 문제가 있는 것입니다. 해결책: 레이아웃을 최적화하고(깊은 ViewGroup 감소, ViewStub), onAttachedToWindow와 함께 Glide로 이미지 로딩을 오프로드합니다.

GC 처리량 진단

freq 및 sched 카테고리의 Systrace를 사용하면 GC 주기가 UI 스레드를 얼마나 자주 선점하는지 확인할 수 있습니다. 타임라인에서 애플리케이션 레인을 찾습니다 — “Concurrent GC”라는 이름의 20–50ms 지속 주기 블록이 보이면 가비지 수집기가 너무 자주 실행되고 있는 것입니다. 자세한 분석을 위해 “dalvik” 카테고리를 추가합니다. 해결책: Bitmap을 ByteBuffer로 변환하고 빈번한 할당에 객체 풀(ObjectPool)을 사용하며 ART 인수를 통해 힙 단편화를 줄입니다.

# UI + GC 분석을 위한 카테고리로 실행
$ python systrace.py \
    --time=15 \
    -o gc_analysis.html \
    gfx sched dalvik freq

# 재현 가능한 테스트를 위한 30초 캡처
$ python systrace.py \
    --time=30 \
    --app=com.example.app \
    -o app_trace.html