Instruments — apa itu, kemampuan Time Profiler dan Allocations

Apa itu Instruments?

Instruments — adalah sistem profiling dan pelacakan yang merupakan bagian dari Xcode dan didasarkan pada teknologi DTrace yang dikembangkan oleh Sun Microsystems. Instruments menggabungkan puluhan alat profiling (template) dalam satu antarmuka: cukup pilih template, jalankan aplikasi melalui Xcode, dan mulai mengumpulkan data.

Arsitektur Instruments dibangun pada model client-server: agen di perangkat mengumpulkan data dan mengirimkannya ke Mac melalui koneksi USB. Ini meminimalkan dampak profiler pada kinerja aplikasi — Instruments bekerja terutama di sisi host. Menurut WWDC 2022, overhead Time Profiler pada frekuensi sampling 1 ms kurang dari 3%.

Instruments mendukung template kustom — pengembang dapat menggabungkan beberapa alat dalam satu sesi profiling. Misalnya, menjalankan Time Profiler + Allocations + Leaks secara bersamaan dan melihat korelasi antara puncak CPU dan alokasi memori. Ini memberikan gambaran kinerja yang holistik, tidak tersedia dalam analisis terisolasi setiap komponen.

Template apa yang tersedia secara default

Xcode hadir dengan 16 template Instruments yang sudah terinstal: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace dan lainnya. Setiap template dioptimalkan untuk tugas tertentu dan telah dikonfigurasi sebelumnya dengan pengaturan pemicu dan filter yang tepat.

Time Profiler: analisis kinerja CPU

Time Profiler — adalah template Instruments yang paling sering digunakan. Ia bekerja berdasarkan sampling stack panggilan: setiap 1-10 milidetik sistem mencatat stack panggilan semua thread aplikasi. Setelah sesi dihentikan, Instruments menjumlahkan sampel dan menunjukkan metode serta fungsi mana yang memakan waktu paling banyak. Hasilnya disajikan sebagai Call Tree — pohon panggilan yang diurutkan berdasarkan Self Weight.

Metrik kunci Time Profiler — Self Weight (waktu yang dihabiskan langsung di metode, tidak termasuk panggilan metode anak). Justru Self Weight yang menunjukkan fungsi mana yang benar-benar membebani prosesor. Weight (total waktu dengan metode anak) bisa menipu: metode dengan Weight tinggi mungkin hanya memanggil metode lambat lainnya, sementara dirinya cepat.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler akan menunjukkan bahwa cellForItemAt memiliki Self Weight = 40%
    // di dalamnya decodeImage memakan 35% — ini adalah hambatan

    func collectionView(
        _ collectionView: UICollectionView,
        cellForItemAt indexPath: IndexPath
    ) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(
            withReuseIdentifier: "ImageCell",
            for: indexPath
        ) as! ImageCell
        // ❌ decodeImage — hambatan (Self Weight = 35%)
        cell.imageView.image = UIImage(contentsOfFile: imagePath)
        return cell
    }
}

Saat menganalisis Time Profiler, perhatikan metode yang dijalankan di com.apple.main-thread. Jika di thread utama Self Weight melebihi ambang batas 16 ms per frame — UI akan melambat. Solusi untuk masalah tersebut — pindahkan decoding gambar, perhitungan layout, dan pemrosesan data dari thread utama ke latar belakang melalui Grand Central Dispatch (GCD).

Cara membaca Call Tree di Time Profiler

Call Tree — adalah representasi hierarkis dari semua panggilan metode, diurutkan berdasarkan Self Weight. Metode terberat di Call Tree — baris pertama. Dengan membuka baris, Anda melihat metode anak mana yang dipanggil oleh metode ini dan berapa lama waktu yang mereka butuhkan. Cari metode di mana Self Weight (waktu sendiri) secara signifikan melebihi Weight (total waktu) — ini adalah tanda-tanda pemblokiran sinkron dan penantian.

Allocations: pelacakan memori real-time

Allocations — adalah alat untuk memantau semua alokasi memori aplikasi. Menunjukkan objek apa, dalam jumlah berapa, dan dengan ukuran total berapa yang dibuat pada setiap saat. Tidak seperti Memory Profiler di Android Studio, Allocations mendukung Heapshot — snapshot objek hidup dengan kemampuan membandingkan dua snapshot.

Antarmuka Allocations terdiri dari dua bagian utama: All Allocations (statistik kumulatif berdasarkan semua jenis objek) dan Call Trees (pohon panggilan dengan perincian berdasarkan metode yang membuat objek). Untuk mencari kebocoran, gunakan Heapshot Analysis: ambil snapshot sebelum menjalankan skenario, jalankan skenario, ambil snapshot setelahnya — dan bandingkan objek baru mana yang tersisa di memori.

Menurut Apple Developer Documentation, pola kebocoran paling umum yang terdeteksi melalui Allocations — pembuatan UIView dan CALayer yang berlebihan saat scrolling koleksi. Jika setiap scroll jumlah UIView hidup bertambah, sementara koleksi menggunakan ulang sel — di suatu tempat view tambahan dibuat tanpa membebaskan yang lama. Allocations menunjukkan stack panggilan yang tepat di mana view ini dibuat.

Heapshot Analysis: perbandingan snapshot memori

Heapshot — adalah snapshot objek hidup di Allocations. Ambil Heapshot sebelum menjalankan skenario, jalankan skenario, dan ambil Heapshot kedua. Perbedaan antara snapshot akan menunjukkan objek mana yang dibuat dan tidak dibebaskan. Hasil ideal — pertumbuhan hanya objek sementara (Autorelease pool). Untuk analisis yang akurat, gunakan kombinasi Allocations + Leaks dalam satu sesi. Allocations menunjukkan objek mana yang tidak dibebaskan, dan Leaks — mengapa (referensi kuat mana yang menahannya). Jalankan sesi ganda setiap kali ada kecurigaan kebocoran.

Leaks: pencarian kebocoran memori otomatis

Leaks — adalah alat khusus untuk mendeteksi kebocoran memori di aplikasi iOS dan macOS. Tidak seperti Allocations yang hanya menunjukkan alokasi, Leaks secara aktif memindai heap untuk mencari retain cycles — situasi di mana dua atau lebih objek saling menahan satu sama lain dengan referensi kuat.

Leaks bekerja bersama Cycles & Roots — visualisator graf retensi objek. Ketika kebocoran terdeteksi, Leaks menunjukkan semua objek dalam siklus, retain count mereka, dan field tepat di mana referensi diteruskan. Pengembang cukup melihat graf dan memahami referensi mana yang perlu diganti dengan weak.

Alat ini secara otomatis menyorot kebocoran dengan marker merah pada timeline. Leaks bekerja secara real-time: segera setelah sistem mendeteksi kebocoran, ia langsung memberi sinyal kepada pengembang. Ini memungkinkan memperbaiki masalah di tempat, tanpa menunggu dump dan analisis pasca-fakta.

Menurut WWDC 2022, Leaks mampu mendeteksi bahkan retain cycles kompleks bertingkat — misalnya, ketika tiga atau lebih objek membentuk rantai tertutup referensi kuat. Untuk diagnosis siklus semacam itu, graf Cycles & Roots sangat diperlukan: ia secara visual menunjukkan bagaimana objek saling menutup satu sama lain.

Cara membaca graf Cycles & Roots

Setiap node graf adalah objek, setiap panah — referensi kuat. Siklus — kontur tertutup dari panah. Warna node menunjukkan status: merah — objek bocor, hijau — akar (GC Root), abu-abu — objek perantara. Untuk memperbaiki kebocoran, temukan panah yang dapat dibuat weak tanpa melanggar logika — dan ganti tipe referensi di kode.

Energy Log: analisis konsumsi daya

Energy Log — adalah template Instruments untuk mengukur konsumsi daya aplikasi. Mengumpulkan data dari sensor hardware perangkat: beban CPU, status Wi-Fi dan jaringan seluler, penggunaan GPS, layar, dan Bluetooth. Energy Log menunjukkan operasi mana di aplikasi yang menyebabkan konsumsi baterai terbesar dan menempatkannya pada grafik konsumsi daya berdasarkan skala waktu.

Alat ini mengklasifikasikan operasi berdasarkan tingkat konsumsi daya: rendah (kerja normal prosesor), sedang (transmisi Wi-Fi), tinggi (GPS, jaringan seluler, GPU). Jika Energy Log menunjukkan indikator merah tingkat tinggi untuk waktu yang lama — aplikasi menguras baterai di latar belakang dan akan dihapus oleh pengguna.

Masalah umum yang terdeteksi oleh Energy Log: WakeLock tanpa batas waktu (aplikasi menjaga prosesor tetap aktif setelah menyelesaikan tugas), Location Updates dengan akurasi tinggi di latar belakang (setiap beberapa detik permintaan koordinat), anomali sesi jaringan (sering menghubungkan ulang ke server). Energy Log merekomendasikan mencatat setiap insiden tersebut dan menambahkan kondisi untuk menonaktifkan operasi boros daya.

Untuk menguji konsumsi daya, gunakan perangkat nyata dengan daya baterai — pada emulator, indikator konsumsi daya tidak akurat. Jalankan Energy Log bersama dengan pengujian UI untuk mengotomatiskan pemeriksaan konsumsi baterai di CI.

Cara menjalankan dan menginterpretasi hasil Instruments

Menjalankan Instruments dari Xcode dilakukan dengan dua cara: melalui menu Product → Profile (⌘I) atau dengan membuka Instruments sebagai aplikasi terpisah di Launchpad. Cara pertama lebih nyaman: Xcode secara otomatis membangun aplikasi dalam mode profiling dan menjalankannya di perangkat yang terhubung dengan template yang dipilih. Setelah sesi dihentikan, Instruments menyimpan tracing dalam file dengan ekstensi .trace.

Interpretasi hasil tergantung pada template. Untuk Time Profiler, lihat Call Tree yang diurutkan berdasarkan Self Weight — metode teratas adalah hambatan utama Anda. Untuk Allocations — lihat # Living setelah skenario siklik: jika jumlah objek meningkat, cari kebocoran. Untuk Leaks — lihat marker merah dan graf Cycles & Roots. Bandingkan hasil sebelum dan sesudah optimasi — ini satu-satunya cara untuk mengonfirmasi efektivitas perubahan.

// Baris perintah untuk Instruments di CI
// Integrasi Instruments ke dalam pipeline CI/CD
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Mengukur waktu scroll koleksi
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

Di CI, Instruments dapat dijalankan dari baris perintah melalui xcodebuild -showBuildSettings dan xcrun xctrace. Ini memungkinkan mengotomatiskan profiling di setiap commit dan tidak melewatkan regresi. Untuk analisis, gunakan perbandingan Baseline: jika metrik memburuk sebesar 5% dibandingkan commit sebelumnya — pipeline harus berhenti.

Kesalahan utama saat bekerja dengan Instruments: profiling di simulator bukan di perangkat nyata (data CPU dan GPU tidak akurat), mengumpulkan data tanpa skenario (hasil acak), mengabaikan Call Tree (hanya melihat grafik, bukan metode spesifik). Memperbaiki kesalahan ini memberikan 80% kualitas profiling.