Instruments — nedir, Time Profiler ve Allocations özellikleri

Instruments nedir?

Instruments — Xcode'un bir parçası olan ve Sun Microsystems tarafından geliştirilen DTrace teknolojisine dayanan bir profilleme ve izleme sistemidir. Instruments, düzinelerce profilleme aracını (şablonu) tek bir arayüzde birleştirir: sadece bir şablon seçin, uygulamayı Xcode üzerinden başlatın ve veri toplamaya başlayın.

Instruments'ın mimarisi istemci-sunucu modeline dayanır: cihazdaki bir aracı verileri toplar ve USB bağlantısı üzerinden Mac'e iletir. Bu, profilleyicinin uygulama performansı üzerindeki etkisini en aza indirir — Instruments esas olarak ana bilgisayar tarafında çalışır. WWDC 2022'ye göre, 1 ms örnekleme hızında Time Profiler'ın ek yükü %3'ten azdır.

Instruments özel şablonları destekler — geliştirici tek bir profilleme oturumunda birden fazla aracı birleştirebilir. Örneğin, Time Profiler + Allocations + Leaks'ı aynı anda başlatın ve CPU tepe noktaları ile bellek tahsisleri arasındaki korelasyonu görün. Bu, her bileşenin ayrı ayrı analiz edilmesiyle elde edilemeyen bütünsel bir performans resmi sağlar.

Varsayılan olarak hangi şablonlar mevcut

Xcode, 16 ön yüklü Instruments şablonuyla birlikte gelir: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace ve diğerleri. Her şablon belirli bir görev için optimize edilmiştir ve doğru tetikleyici ve filtre ayarlarıyla önceden yapılandırılmıştır.

Time Profiler: CPU performans analizi

Time Profiler — en çok kullanılan Instruments şablonudur. Çağrı yığını örneklemesine dayanarak çalışır: her 1-10 milisaniyede bir, sistem uygulamanın tüm iş parçacıklarının çağrı yığınını kaydeder. Oturumu durdurduktan sonra Instruments örnekleri toplar ve hangi yöntemlerin ve işlevlerin en fazla zamanı aldığını gösterir. Sonuç, Call Tree (Kendi Ağırlığına göre sıralanmış çağrı ağacı) olarak sunulur.

Time Profiler'ın temel metriği Self Weight'tir (alt yöntem çağrıları hariç, yöntemin içinde doğrudan harcanan süre). İşlemciyi gerçekten yükleyen işlevleri gösteren Self Weight'tir. Weight (alt yöntemlerle toplam süre) yanıltıcı olabilir: Yüksek Weight'e sahip bir yöntem, yalnızca başka bir yavaş yöntemi çağırıyor olabilir, kendisi hızlıdır.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler, cellForItemAt'in Self Weight = %40 olduğunu gösterecek
    // bunun içinde decodeImage %%35'ini kaplıyor — bu darboğaz

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

Time Profiler'ı analiz ederken com.apple.main-thread'te çalışan yöntemlere dikkat edin. Ana iş parçacığındaki Self Weight, kare başına 16 ms eşiğini aşarsa — UI yavaşlayacaktır. Bu sorunların çözümü, görüntü kod çözme, düzen hesaplamaları ve veri işlemeyi Grand Central Dispatch (GCD) kullanarak ana iş parçacığından arka plan iş parçacığına taşımaktır.

Time Profiler'da Call Tree nasıl okunur

Call Tree — Self Weight'e göre sıralanmış tüm yöntem çağrılarının hiyerarşik bir gösterimidir. Call Tree'deki en ağır yöntem ilk satırdır. Satırı genişleterek, bu yöntemin hangi alt yöntemleri çağırdığını ve ne kadar süre aldıklarını görürsünüz. Self Weight' (kendi süresi) Weight'ten (toplam süre) önemli ölçüde fazla olan yöntemleri arayın — bunlar senkron blokaj ve bekleme belirtileridir.

Allocations: gerçek zamanlı bellek izleme

Allocations — uygulamanın tüm bellek tahsislerini izlemek için bir araçtır. Hangi nesnelerin, hangi miktarda ve hangi toplam boyutla her an oluşturulduğunu gösterir. Android Studio'daki Memory Profiler'ın aksine Allocations, Heapshot'ı (iki anlık görüntüyü karşılaştırma özelliğine sahip canlı nesnelerin anlık görüntüsü) destekler.

Allocations'ın arayüzü iki ana bölümden oluşur: All Allocations (nesne türüne göre toplam istatistikler) ve Call Trees (nesneleri oluşturan yöntemlere göre çağrı ağacı). Sızıntıları bulmak için Heapshot Analysis kullanın: bir senaryoyu çalıştırmadan önce anlık görüntü alın, senaryoyu çalıştırın, sonra anlık görüntü alın — ve hangi yeni nesnelerin bellekte kaldığını karşılaştırın.

Apple Developer Documentation'ya göre, Allocations tarafından tespit edilen en yaygın sızıntı modeli, koleksiyon kaydırma sırasında UIView ve CALayer'in aşırı oluşturulmasıdır. Her kaydırmada canlı UIView sayısı artıyorsa, ancak koleksiyon hücreleri yeniden kullanıyorsa — bir yerde eski görünümleri serbest bırakmadan ek görünümler oluşturuluyordur. Allocations, bu görünümlerin oluşturulduğu tam çağrı yığınını gösterir.

Heapshot Analysis: bellek anlık görüntülerini karşılaştırma

Heapshot — Allocations'taki canlı nesnelerin anlık görüntüsüdür. Senaryoyu çalıştırmadan önce Heapshot alın, senaryoyu çalıştırın ve ikinci bir Heapshot alın. Anlık görüntüler arasındaki fark, oluşturulan ancak serbest bırakılmayan nesneleri gösterecektir. İdeal sonuç — yalnızca geçici nesnelerde (Autorelease pool) artış. Doğru analiz için tek bir oturumda Allocations + Leaks kombinasyonunu kullanın. Allocations hangi nesnelerin serbest bırakılmadığını, Leaks ise nedenini (hangi güçlü referansın onları tuttuğunu) gösterir. Sızıntıdan şüphelendiğinizde her zaman çift oturum başlatın.

Leaks: otomatik bellek sızıntısı arama

Leaks — iOS ve macOS uygulamalarında bellek sızıntılarını tespit etmek için özel bir araçtır. Yalnızca tahsisleri gösteren Allocations'ın aksine Leaks, retain cycle'ları (iki veya daha fazla nesnenin birbirini güçlü referanslarla tuttuğu durumlar) bulmak için heap'i aktif olarak tarar.

Leaks, Cycles & Roots (nesne tutma grafiği görselleştiricisi) ile birlikte çalışır. Bir sızıntı tespit edildiğinde, Leaks döngüdeki tüm nesneleri, retain count'larını ve referansların iletildiği tam alanları gösterir. Geliştiricinin sadece grafiğe bakıp hangi referansın weak ile değiştirilmesi gerektiğini anlaması yeterlidir.

Araç, zaman çizelgesinde sızıntıları kırmızı bir işaretçiyle otomatik olarak vurgular. Leaks gerçek zamanlı çalışır: sistem bir sızıntı tespit ettiği anda geliştiriciyi hemen uyarır. Bu, döküm ve sonrası analiz beklemeden sorunları “yerinde” düzeltmeye olanak tanır.

WWDC 2022'ye göre Leaks, karmaşık çok seviyeli retain cycle'ları bile tespit edebilir — örneğin, üç veya daha fazla nesnenin güçlü referanslardan oluşan kapalı bir zincir oluşturması. Bu tür döngüleri teşhis etmek için Cycles & Roots grafiği vazgeçilmezdir: nesnelerin birbirine nasıl kapandığını görsel olarak gösterir.

Cycles & Roots grafiği nasıl okunur

Grafiğin her düğümü bir nesnedir, her ok güçlü bir referanstır. Döngü, okların kapalı bir halkasıdır. Düğümün rengi durumu gösterir: kırmızı — sızdıran nesne, yeşil — kök (GC Root), gri — ara nesne. Sızıntıyı düzeltmek için, mantığı bozmadan weak yapılabilecek bir ok bulun — ve kodda referans türünü değiştirin.

Energy Log: enerji tüketimi analizi

Energy Log — uygulamanın enerji tüketimini ölçmek için bir Instruments şablonudur. Cihazın donanım sensörlerinden (CPU yükü, Wi-Fi ve hücresel radyo durumu, GPS kullanımı, ekran ve Bluetooth) veri toplar. Energy Log, uygulamadaki hangi işlemlerin en fazla pil tüketimine neden olduğunu gösterir ve bunları bir zaman ölçeğinde enerji tüketimi grafiğine bindirir.

Araç, işlemleri enerji tüketim seviyesine göre sınıflandırır: düşük (normal işlemci çalışması), orta (Wi-Fi iletimi), yüksek (GPS, mobil ağ, GPU). Energy Log uzun süre boyunca yüksek seviyede kırmızı göstergeler gösteriyorsa — uygulama arka planda pili tüketiyordur ve kullanıcı tarafından kaldırılacaktır.

Energy Log tarafından tespit edilen tipik sorunlar: Zaman sınırı olmayan WakeLock (uygulama görev tamamlandıktan sonra işlemciyi aktif tutar), arka planda yüksek hassasiyetli Location Updates (her birkaç saniyede bir koordinat isteği), ağ oturumu anormallikleri (sunucuya sık sık yeniden bağlanma). Energy Log, bu tür her olayı kaydetmeyi ve enerji yoğun işlemi kapatmak için bir koşul eklemeyi önerir.

Enerji tüketimini test etmek için pil gücüyle çalışan gerçek bir cihaz kullanın — öykünücüde enerji tüketimi göstergeleri doğru değildir. CI'da pil tüketimi kontrolünü otomatikleştirmek için Energy Log'u UI testleriyle birlikte çalıştırın.

Instruments nasıl başlatılır ve sonuçlar nasıl yorumlanır

Instruments'ı başlatma, Xcode'dan iki şekilde yapılır: Product → Profile (⌘I) menüsü aracılığıyla veya Launchpad'den ayrı bir uygulama olarak Instruments'ı açarak. İlk yöntem daha kullanışlıdır: Xcode, uygulamayı otomatik olarak profilleme modunda derler ve seçilen şablonla bağlı cihazda çalıştırır. Oturumu durdurduktan sonra Instruments, izlemeyi .trace uzantılı bir dosyaya kaydeder.

Sonuçların yorumlanması şablona bağlıdır. Time Profiler için Self Weight'e göre sıralanmış Call Tree'ye bakın — en üstteki yöntemler ana darboğazlarınızdır. Allocations için — döngüsel bir senaryodan sonra # Living'e bakın: nesne sayısı arttıysa sızıntı arayın. Leaks için — kırmızı işaretçilere ve Cycles & Roots grafiğine bakın. Optimizasyon öncesi ve sonrası sonuçları karşılaştırın — değişikliklerin etkinliğini onaylamanın tek yolu budur.

// CI'da Instruments için komut satırı
// Instruments'ın CI/CD pipeline'a entegrasyonu
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Koleksiyon kaydırma süresini ölçme
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

CI'da, xcodebuild -showBuildSettings ve xcrun xctrace aracılığıyla komut satırından Instruments çalıştırılabilir. Bu, her commit'te profillemeyi otomatikleştirmeyi ve gerilemeyi kaçırmamayı sağlar. Analiz için Baseline karşılaştırması kullanın: metrik önceki commit'e göre %5 kötüleştiyse — pipeline durmalıdır.

Instruments ile çalışırken ana hatalar: cihaz yerine simülatörde profilleme (CPU ve GPU verileri doğru değil), senaryo olmadan veri toplama (sonuçlar rastgele), Call Tree'yi yok sayma (belirli yöntemlere değil, yalnızca grafiğe bakma). Bu hataları düzeltmek, profilleme kalitesinin %80'ini sağlar.