Traceview: Android 트레이싱 및 프로파일링 도구란

Android에서 Traceview란

Traceview는 Android Studio에 내장된 그래픽 프로파일러로, Android 애플리케이션 메서드의 실행 트레이스를 타임라인 및 호출 테이블로 표시합니다. Android SDK의 일부이며 Android Studio 3.0부터 Android Profiler를 통해, 그리고 dmtracedump 명령줄 유틸리티를 통해 사용할 수 있습니다.

도구의 목적

Traceview의 주요 작업은 개발자가 가장 많은 CPU 시간을 소비하는 메서드를 찾도록 돕는 것입니다. 단순 로깅과 달리 Traceview는 각 메서드의 정확한 진입 및 종료 시간을 기록하고, Call Chart와 Top-Down 트리를 구축하여 성능 이상을 시각적으로 감지할 수 있게 합니다. 이 도구는 16ms 지연이 프레임 드롭을 유발하는 UI 스레드 프로파일링 시 특히 유용합니다.

역사와 발전

Traceview는 .trace 파일을 보기 위한 독립 실행형 유틸리티로 Android SDK 초기 버전에 처음 등장했습니다. Android Studio 3.0(2017) 출시와 함께 Android Profiler의 일부가 되어 실시간 CPU, 메모리 및 네트워크 타임라인과의 통합을 얻었습니다. Google I/O 2018에 따르면, Android Studio 팀은 프로파일러를 계속 개발하여 systrace 및 perfetto를 통한 네이티브 코드 지원을 추가하고 있습니다. 현재 Android Studio 버전에서 Traceview는 Perfetto 형식 위에서 작동하지만 기존 .trace 형식과의 하위 호환성을 유지합니다.

Traceview 작동 방식

Traceview는 Android Runtime(ART)의 System Tracing 메커니즘에서 데이터를 받습니다. 트레이싱을 활성화한 상태에서 애플리케이션을 실행하면, ART는 클래스 이름, 메서드 이름 및 스레드 ID를 포함하여 실행된 각 메서드의 시작 및 종료 타임스탬프를 기록합니다.

// 앱 코드에서 트레이스 시작
Debug.startMethodTracing("app_trace")

// 프로파일링할 주요 코드 구간
loadHeavyData()

// 트레이스 중지 — 파일이 기기에 저장됨
Debug.stopMethodTracing()

System Tracing은 ART 가상 머신 수준에서 작동하며 마이크로초 정밀도로 각 메서드 호출을 등록합니다. 애플리케이션 성능에 미치는 영향을 최소화하기 위해 데이터는 링 버퍼에 기록됩니다. 트레이싱이 중지되면 버퍼는 기기 내부 저장소의 .trace 파일로 플러시됩니다.

.trace 파일 형식

.trace 파일에는 형식 버전과 시작 시간이 포함된 헤더가 있으며, 그 뒤에 각 호출에 대한 레코드가 있습니다: 스레드 ID, 메서드 ID, 진입 타임스탬프, 종료 타임스탬프. Android Studio는 .trace 파일을 자동으로 로드하고 두 가지 주요 보기를 구축합니다: 시간순의 타임라인 패널과 호출 계층 구조의 프로필 패널입니다. 기본 최대 버퍼 크기는 8MB이지만, Debug.startMethodTracing(filename, maxSize)를 통해 늘릴 수 있습니다.

Traceview의 주요 기능

Traceview는 성능 분석에서 각각 특정 작업을 처리하는 여러 보완 데이터 보기를 제공합니다.

Call Chart (호출 차트)

Call Chart는 각 스레드가 별도 레인으로 표시되는 가로 타임라인입니다. 메서드는 색상이 지정된 직사각형으로 표시되며, 직사각형의 너비는 실행 시간에 비례하고 중첩은 호출 계층을 반영합니다. 메서드가 다른 메서드를 호출하면 하위 직사각형이 상위 직사각형 내에 그려집니다. 이 시각화를 통해 스레드를 차단한 작업을 즉시 식별할 수 있습니다.

Top-Down 및 Bottom-Up 트리

Top-Down 트리는 중첩된 모든 호출을 포함한 메서드의 실행 시간을 표시합니다 — Inclusive Time. 반면 Bottom-Up 트리는 특정 메서드를 호출한 상위 메서드를 보여줍니다 — 무거운 작업의 원인을 찾는 데 유용합니다. Inclusive Time과 Exclusive Time의 차이는 중요합니다: 메서드 자체는 빠르게 실행되지만 느린 하위 메서드를 호출할 수 있으며, 이는 Inclusive Time에서만 확인할 수 있습니다.

검색 및 필터링

Traceview는 메서드 이름, 패키지 또는 클래스로 검색을 지원합니다. 결과는 타임라인에서 강조 표시되며, 프로필 패널은 찾은 메서드에 대해서만 통계를 표시합니다. 스레드별 필터링도 가능하여 백그라운드 스레드를 숨기고 지연이 가장 중요한 메인(UI) 스레드에 집중할 수 있습니다.

데이터 내보내기

Traceview는 스프레드시트나 차트에서 추가 분석을 위해 트레이스를 CSV 형식으로 내보낼 수 있습니다. Android Studio에서는 타임라인의 선택한 부분을 이미지로 복사하여 버그 보고서나 문서에 삽입할 수도 있습니다. CI/CD의 경우 cmdline-tools 유틸리티를 통해 Perfetto 형식으로 내보낼 수 있습니다.

Android Studio에서 Traceview 사용 방법

프로파일링은 Traceview를 통해 두 가지 방법으로 가능합니다: 라이브 캡처가 포함된 Android Profiler를 통한 방법과 프로그래매틱 Debug API 호출을 통한 방법입니다. 첫 번째 방법은 임시 분석에 편리하고, 두 번째 방법은 재현 가능한 성능 테스트에 적합합니다.

Android Profiler를 통한 캡처

Android Studio에서 Profiler 탭(View → Tool Windows → Profiler)을 열고, 기기와 애플리케이션 프로세스를 선택합니다. CPU 세그먼트를 클릭한 다음 “Trace Java Methods” 모드를 선택하고 Record를 클릭합니다. 애플리케이션과 상호 작용한 후 Stop을 클릭하면 Traceview가 자동으로 기록된 트레이스를 엽니다. 기본 녹화 시간은 30초로 제한되지만, 프로파일러 설정에서 제한을 변경할 수 있습니다.

프로그래매틱 트레이싱 시작

특정 코드 섹션을 정확하게 프로파일링하려면 Debug.startMethodTracing 및 Debug.stopMethodTracing을 사용하세요. 파일은 context.getExternalFilesDir(null)이 반환하는 경로의 애플리케이션 외부 저장소에 저장됩니다. 완료 후 Android Studio Device Explorer를 통해 .trace 파일을 컴퓨터로 전송한 다음 Android Studio에서 File → Open을 통해 엽니다.

Debug.startMethodTracing(
    "heavy_computation",
    Debug.TRACE_COUNT_ALLOCS
)

processLargeDataset()

Debug.stopMethodTracing()

트레이싱 매개변수 구성

Debug.startMethodTracing은 파일 이름(확장자 제외), 최대 버퍼 크기(기본 8MB), 플래그의 세 가지 매개변수를 받습니다. TRACE_COUNT_ALLOCS 플래그는 객체 할당 카운팅을 추가합니다 — 메모리 누수 찾기에 유용합니다. Traceview는 네이티브 코드 프로파일링에 적합하지 않습니다 — SimplePerf 또는 Perfetto를 사용하세요. 긴 테스트(30초 초과)의 경우 maxSize 매개변수를 통해 버퍼를 64–128MB로 늘리는 것이 좋습니다.

Traceview 타임라인 읽기

Traceview 타임라인은 두 개의 패널로 구성됩니다: 색상이 지정된 호출 직사각형이 있는 상단 타임라인 패널과 통계 테이블이 있는 하단 프로필 패널입니다. 타임라인 패널은 왼쪽에서 오른쪽으로 스레드 실행을 보여주며, 각 직사각형은 단일 메서드 호출입니다. 직사각형 색상은 메서드 유형별로 코딩됩니다: Android 시스템 호출(녹색), 애플리케이션 메서드(파란색), 라이브러리 호출(주황색).

프로필 패널 읽는 방법

프로필 패널에서 각 행은 Inclusive Time, Exclusive Time, Calls + Recur 및 CPU Time 열이 있는 메서드입니다. Inclusive Time(내림차순)으로 테이블을 정렬하여 총 시간이 가장 많이 소요된 메서드를 먼저 확인합니다. Inclusive Time이 높은 메서드의 Exclusive Time이 낮은 경우 — 문제는 하위 호출에 있으며 트리를 확장해야 합니다. 예를 들어, ListView.getView는 이미지 로딩 호출로 인해 Inclusive Time이 높을 수 있습니다.

병목 현상 식별

Real Time은 비정상적으로 높지만 CPU Time이 낮은 메서드를 찾으세요 — 이는 차단(I/O 대기, 네트워크 작업, 잠금 경합)을 나타냅니다. CPU Time이 높은 메서드는 알고리즘 최적화가 필요합니다. UI 스레드의 경우 각 메서드는 16ms 이내에 완료되어야 합니다 — 어떤 호출이 이 임계값을 초과하면 애플리케이션이 프레임을 드롭하고 사용자가 버벅거림을 경험합니다. Google 권장 사항에 따르면, UI 스레드의 프레임당 모든 호출의 총 시간은 8–10ms를 초과하지 않아야 하며, 시스템 작업을 위한 여유를 남겨둡니다.

Traceview vs Systrace: 도구 비교

Traceview와 Systrace는 모두 Android 트레이싱 도구이지만, 다른 작업을 해결하고 다른 프로파일링 단계에서 사용됩니다. 주요 차이점은 세부 수준입니다: Traceview는 Java/Kotlin 메서드 수준에서 작동하고, Systrace는 시스템 프로세스 수준(CPU, GPU, Binder, SurfaceFlinger)에서 작동합니다.

실제로 두 도구는 서로를 보완합니다: 먼저 Systrace가 어떤 시스템 구성 요소가 문제를 일으키는지(예: 빈번한 GC 또는 Binder 잠금) 식별하는 데 도움을 주고, 그런 다음 Traceview가 애플리케이션 내 특정 메서드를 심층 분석할 수 있게 합니다. Android Studio에서 두 도구는 Android Profiler에 통합되어 있으며, CPU Profiler가 자동으로 최적의 녹화 모드를 선택합니다. Android 12+ 기기에서 Systrace와 Traceview는 Perfetto 위에서 작동하여 모든 유형의 프로파일링에 통합된 데이터 형식을 제공합니다.

Traceview 코드 예제

효과적인 프로파일링은 단순히 트레이싱을 시작하는 것 이상이 필요합니다 — 캡처 지점을 올바르게 배치하고 결과를 해석해야 합니다. 아래는 두 가지 실용적인 예제입니다: RecyclerView 로딩 프로파일링과 성능 테스트에서 두 알고리즘 비교입니다.

RecyclerView 로딩 프로파일링

첫 번째 예제는 목록 스크롤 중 중요한 경로의 트레이싱입니다. RecyclerView는 각 표시 항목에 대해 onBindViewHolder를 호출하며, 이 메서드가 16ms 이상 걸리면 스크롤이 끊깁니다. onBindViewHolder 주변의 트레이싱은 그 내부의 어떤 특정 작업이 시간을 소비하는지 보여줍니다.

class MyAdapter : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        Debug.startMethodTracing("bind_card_$position")

        holder.bind(items[position])

        Debug.stopMethodTracing()
    }
}

두 알고리즘 비교

두 번째 예제는 두 구현의 A/B 속도 테스트입니다: Glide를 통한 이미지 로딩 대 수동 BitmapFactory입니다. 이 트레이스는 두 전략의 Inclusive Time을 객관적으로 비교하고 최적의 전략을 선택할 수 있게 합니다. 동일한 조건(백그라운드 부하, 온도)에서 워밍업된 기기(3–5사이클 후)에서 각 테스트를 실행하는 것이 중요합니다.

fun compareImageLoadingStrategies() {
    // 테스트 A: Glide
    Debug.startMethodTracing("glide_test")
    loadWithGlide()
    Debug.stopMethodTracing()

    // 테스트 B: BitmapFactory
    Debug.startMethodTracing("bitmap_test")
    loadWithBitmapFactory()
    Debug.stopMethodTracing()
}

실행 후 Android Studio에서 두 .trace 파일을 열고 프로필 패널에서 Inclusive Time을 비교합니다. Glide가 동일한 작업에 대해 3배 더 적은 Inclusive Time을 보여주면 — 이는 라이브러리를 선택할 객관적인 근거가 됩니다. Tony John(Glide 개발자, 2023)에 따르면, 라이브러리는 캐싱과 스레드 풀을 사용하여 반복 로드 시 최대 40%의 이득을 제공합니다.