Traceview: що це, інструмент трасування та профілювання Android

Що таке Traceview в Android

Traceview — це графічний профайлер, вбудований в Android Studio, який відображає трейси виконання методів Android-застосунку у вигляді часової шкали та таблиці викликів. Він входить до складу Android SDK та доступний через Android Profiler починаючи з Android Studio 3.0, а також через утиліту командного рядка dmtracedump.

Призначення інструменту

Основне завдання Traceview — допомогти розробнику знайти ті методи, які витрачають найбільше часу CPU. На відміну від простого логування, Traceview записує точний час входу та виходу з кожного методу, будує Call Chart та Top-Down-дерево, що дозволяє візуально виявити аномалії продуктивності. Інструмент особливо корисний при профілюванні UI-потоку, де затримка в 16 мс призводить до пропуску кадру.

Історія та розвиток

Traceview з’явився ще в ранніх версіях Android SDK як самостійна утиліта для перегляду .trace-файлів. З виходом Android Studio 3.0 (2017) він став частиною Android Profiler, отримавши інтеграцію з живою часовою шкалою CPU, пам’яті та мережі. За даними Google I/O 2018, команда Android Studio продовжує розвивати профайлер, додаючи підтримку нативного коду через systrace та perfetto. В актуальних версіях Android Studio Traceview працює поверх формату Perfetto, але зберігає зворотну сумісність із класичним .trace.

Як працює Traceview

Traceview отримує дані від механізму System Tracing в Android Runtime (ART). Коли застосунок запускається з увімкненим трасуванням, ART записує в буфер timestamp початку та кінця кожного виконуваного методу, включаючи ім’я класу, ім’я методу та ID потоку.

// Запуск трассировки в коде приложения
Debug.startMethodTracing("app_trace")

// Критический участок кода для профилирования
loadHeavyData()

// Остановка трассировки — файл сохранён на устройство
Debug.stopMethodTracing()

System Tracing працює на рівні віртуальної машини ART та реєструє кожен виклик методу з точністю до мікросекунд. Дані записуються в кільцевий буфер, щоб мінімізувати вплив на продуктивність самого застосунку. Після зупинки трасування буфер скидається у файл .trace на внутрішньому сховищі пристрою.

Формат .trace файлу

Файл .trace містить заголовок з версією формату та часом старту, за яким слідують записи про кожен виклик: thread ID, method ID, timestamp входу та timestamp виходу. Android Studio автоматично завантажує .trace файл і будує два основних представлення: Timeline Panel для хронології та Profile Panel для ієрархії викликів. За замовчуванням максимальний розмір буфера — 8 МБ, але його можна збільшити через Debug.startMethodTracing(filename, maxSize).

Ключові можливості Traceview

Traceview надає кілька взаємодоповнюючих представлень даних, кожне з яких вирішує своє завдання при аналізі продуктивності.

Call Chart (граф викликів)

Call Chart — це горизонтальна часова шкала, де кожен потік відображається окремою доріжкою. Методи показані кольоровими прямокутниками: ширина прямокутника пропорційна часу виконання, а вкладеність відображає ієрархію викликів. Якщо метод викликав інший метод, дочірній прямокутник малюється всередині батьківського. Ця візуалізація дозволяє миттєво побачити, які операції заблокували потік.

Top-Down та Bottom-Up дерева

Top-Down дерево показує час виконання методу з урахуванням усіх його вкладених викликів — Inclusive Time. Bottom-Up дерево, навпаки, показує, які батьківські методи викликали даний метод — корисно для пошуку джерела важкої операції. Різниця між Inclusive та Exclusive Time критична: метод може сам працювати швидко, але викликати повільний дочірній метод, і це видно тільки в Inclusive Time.

Пошук і фільтрація

Traceview підтримує пошук за ім’ям методу, пакетом або класом. Результати підсвічуються на часовій шкалі, а в Profile Panel відображається статистика тільки за знайденими методами. Також доступна фільтрація за потоками — можна вимкнути відображення фонових потоків і зосередитися на головному (UI) потоці, де затримки найбільш критичні.

Експорт даних

Traceview дозволяє експортувати трейси у форматі CSV для подальшого аналізу в таблицях або побудови графіків. В Android Studio можна також скопіювати виділений фрагмент часової шкали як зображення — для вставки в баг-репорт або документацію. Для CI/CD доступний експорт у форматі Perfetto через утиліту cmdline-tools.

Як використовувати Traceview в Android Studio

Профілювання через Traceview доступне двома способами: через Android Profiler з живим захопленням та через програмний запуск Debug API. Перший спосіб зручний для ad-hoc аналізу, другий — для відтворюваних тестів продуктивності.

Захоплення через Android Profiler

В Android Studio відкрийте вкладку Profiler (View → Tool Windows → Profiler), виберіть пристрій і процес вашого застосунку. Натисніть на сегмент CPU, потім виберіть режим “Trace Java Methods” і натисніть Record. Після взаємодії із застосунком натисніть Stop — Traceview автоматично відкриє записаний трейс. Тривалість запису за замовчуванням обмежена 30 секундами, але ліміт можна змінити в налаштуваннях профайлера.

Програмний запуск трасування

Для точного профілювання конкретної ділянки коду використовуйте Debug.startMethodTracing та Debug.stopMethodTracing. Файл зберігається у зовнішнє сховище застосунку за шляхом, який повертає context.getExternalFilesDir(null). Після завершення перенесіть .trace файл на комп’ютер через Android Studio Device Explorer, потім відкрийте через File → Open в Android Studio.

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

processLargeDataset()

Debug.stopMethodTracing()

Налаштування параметрів трасування

Debug.startMethodTracing приймає три параметри: ім’я файлу (без розширення), максимальний розмір буфера (за замовчуванням 8 МБ) та прапорці. Прапорець TRACE_COUNT_ALLOCS додає підрахунок алокацій об’єктів — корисно для пошуку витоків пам’яті. Для профілювання нативного коду Traceview не підходить — використовуйте SimplePerf або Perfetto. Для тривалих тестів (понад 30 секунд) рекомендується збільшити буфер до 64–128 МБ через параметр maxSize.

Читання часової шкали Traceview

Часова шкала Traceview складається з двох панелей: верхня — Timeline Panel з кольоровими прямокутниками викликів, нижня — Profile Panel з таблицею статистики. Timeline Panel показує виконання потоків зліва направо, де кожен прямокутник — це один виклик методу. Колір прямокутника кодується за типом методу: системні виклики Android (зелений), прикладні методи (синій), виклики бібліотек (помаранчевий).

Як читати Profile Panel

В Profile Panel кожен рядок — це метод зі стовпцями Inclusive Time, Exclusive Time, Calls + Recur та CPU Time. Сортуйте таблицю за Inclusive Time (за спаданням), щоб першими побачити методи, які сумарно зайняли найбільше часу. Якщо метод з високим Inclusive Time має низький Exclusive Time — проблема в його дочірніх викликах, і потрібно розкрити дерево. Наприклад, ListView.getView може мати високий Inclusive Time через виклик завантаження зображення.

Виявлення вузьких місць

Шукайте методи з аномально високим Real Time при низькому CPU Time — це вказує на блокування (очікування I/O, мережева операція, lock contention). Методи з високим CPU Time потребують оптимізації алгоритму. Для UI-потоку критично, щоб кожен метод вкладався в 16 мс — якщо якийсь виклик перевищує цей поріг, застосунок пропускає кадр і користувач бачить джиттер. За рекомендаціями Google, сумарний час усіх викликів в UI-потоці на один кадр не повинен перевищувати 8–10 мс, залишаючи запас на системні операції.

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 для кожного видимого елемента, і якщо цей метод виконується довше 16 мс, прокручування стає смиканим. Трасування навколо 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()
}

Після запуску відкрийте обидва .trace файли в Android Studio та порівняйте Inclusive Time в Profile Panel. Якщо Glide показує 3x менший Inclusive Time при тій самій задачі — це об’єктивна підстава вибрати бібліотеку. За даними Тоні Джона (розробник Glide, 2023), бібліотека використовує кешування та пул потоків, що дає виграш до 40% на повторюваних завантаженнях.