Instruments — ano ito, mga kakayahan ng Time Profiler at Allocations

Ano ang Instruments?

Instruments — ay isang sistema ng profiling at pagsubaybay na bahagi ng Xcode at batay sa teknolohiyang DTrace na binuo ng Sun Microsystems. Pinagsasama ng Instruments ang dose-dosenang mga tool sa profiling (template) sa iisang interface: pumili lamang ng template, patakbuhin ang aplikasyon sa pamamagitan ng Xcode at simulan ang pagkolekta ng datos.

Ang arkitektura ng Instruments ay binuo sa modelong client-server: isang agent sa device ang nangongolekta ng datos at ipinapadala ito sa Mac sa pamamagitan ng USB connection. Pinapaliit nito ang epekto ng profiler sa pagganap ng aplikasyon — ang Instruments ay pangunahing gumagana sa panig ng host. Ayon sa WWDC 2022, ang overhead ng Time Profiler sa sampling frequency na 1 ms ay mas mababa sa 3%.

Sinusuportahan ng Instruments ang custom na mga template — maaaring pagsamahin ng developer ang maraming tool sa isang profiling session. Halimbawa, sabay na patakbuhin ang Time Profiler + Allocations + Leaks at makita ang ugnayan sa pagitan ng CPU peaks at mga alokasyon ng memorya. Nagbibigay ito ng isang holistic na larawan ng pagganap na hindi makukuha sa hiwalay na pagsusuri ng bawat bahagi.

Anong mga template ang available bilang default

Ang Xcode ay may 16 na pre-install na template ng Instruments: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace at iba pa. Ang bawat template ay na-optimize para sa isang partikular na gawain at na-configure nang maaga gamit ang tamang mga setting ng trigger at filter.

Time Profiler: pagsusuri ng pagganap ng CPU

Time Profiler — ay ang pinakaginagamit na template ng Instruments. Gumagana ito batay sa sampling ng call stack: bawat 1-10 millisecond, itinatala ng system ang call stack ng lahat ng thread ng aplikasyon. Pagkatapos ihinto ang session, sinusuma ng Instruments ang mga sample at ipinapakita kung aling mga metodo at function ang kumuha ng pinakamaraming oras. Ang resulta ay ipinakita bilang Call Tree — isang puno ng mga tawag na na-sort ayon sa Self Weight.

Ang pangunahing metrik ng Time Profiler — Self Weight (oras na ginugol nang direkta sa metodo, hindi kasama ang mga tawag sa mga anak na metodo). Ang Self Weight mismo ang nagpapakita kung aling mga function ang tunay na nagpapabigat sa processor. Ang Weight (kabuuang oras kasama ang mga anak na metodo) ay maaaring mapanlinlang: ang isang metodo na may mataas na Weight ay maaaring tumawag lamang ng isa pang mabagal na metodo, habang ito mismo ay mabilis.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Ipapakita ng Time Profiler na ang cellForItemAt ay may Self Weight = 40%
    // sa loob nito ang decodeImage ay kumukuha ng 35% — ito ay isang bottleneck

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

Sa pag-aanalisa ng Time Profiler, bigyang-pansin ang mga metodo na isinasagawa sa com.apple.main-thread. Kung sa pangunahing thread ang Self Weight ay lumampas sa threshold na 16 ms bawat frame — ang UI ay babagal. Ang solusyon sa mga problemang ito — ilipat ang pag-decode ng mga imahe, pagkalkula ng layout at pagproseso ng datos mula sa pangunahing thread patungo sa background sa pamamagitan ng Grand Central Dispatch (GCD).

Paano basahin ang Call Tree sa Time Profiler

Call Tree — ay isang hierarchical na representasyon ng lahat ng tawag ng metodo, na na-sort ayon sa Self Weight. Ang pinakamabigat na metodo sa Call Tree — ang unang linya. Sa pagbukas ng linya, makikita mo kung aling mga anak na metodo ang tinawag ng metodong ito at kung gaano katagal ang kanilang inabot. Hanapin ang mga metodo kung saan ang Self Weight (sariling oras) ay malaki ang lampas sa Weight (kabuuang oras) — ito ay mga senyales ng sabay-sabay na pag-block at paghihintay.

Allocations: real-time na pagsubaybay ng memorya

Allocations — ay isang tool para sa pag-monitor ng lahat ng alokasyon ng memorya ng aplikasyon. Ipinapakita nito kung aling mga bagay, sa anong dami, at sa anong kabuuang sukat ang ginagawa sa bawat sandali. Hindi tulad ng Memory Profiler sa Android Studio, sinusuportahan ng Allocations ang Heapshot — isang snapshot ng mga buhay na bagay na may kakayahang maghambing ng dalawang snapshot.

Ang interface ng Allocations ay binubuo ng dalawang pangunahing seksyon: All Allocations (pinagsamang estadistika ayon sa lahat ng uri ng bagay) at Call Trees (puno ng tawag na may paghahati ayon sa mga metodo na gumagawa ng mga bagay). Para sa paghahanap ng mga tagas, gamitin ang Heapshot Analysis: kumuha ng snapshot bago isagawa ang scenario, isagawa ang scenario, kumuha ng snapshot pagkatapos — at ihambing kung aling mga bagong bagay ang nanatili sa memorya.

Ayon sa Apple Developer Documentation, ang pinakakaraniwang pattern ng tagas na natutuklasan sa pamamagitan ng Allocations — labis na paggawa ng UIView at CALayer habang nag-scroll ng mga koleksyon. Kung sa bawat scroll ang bilang ng mga buhay na UIView ay tumataas, habang ang koleksyon ay muling gumagamit ng mga cell — sa isang lugar ay gumagawa ng karagdagang mga view nang hindi binibitawan ang mga luma. Ipinapakita ng Allocations ang eksaktong call stack kung saan ginagawa ang mga view na ito.

Heapshot Analysis: paghahambing ng mga snapshot ng memorya

Heapshot — ay isang snapshot ng mga buhay na bagay sa Allocations. Kumuha ng Heapshot bago isagawa ang scenario, isagawa ang scenario at kumuha ng pangalawang Heapshot. Ang pagkakaiba sa pagitan ng mga snapshot ay magpapakita kung aling mga bagay ang ginawa at hindi pinalaya. Ang perpektong resulta — paglago lamang ng mga pansamantalang bagay (Autorelease pool). Para sa tumpak na pagsusuri, gamitin ang kumbinasyon ng Allocations + Leaks sa isang session. Ipinapakita ng Allocations kung aling mga bagay ang hindi pinapalaya, at Leaks — kung bakit (aling malakas na reference ang humahawak sa kanila). Patakbuhin ang dobleng session sa bawat hinala ng tagas.

Leaks: awtomatikong paghahanap ng mga tagas ng memorya

Leaks — ay isang specialized na tool para sa pag-detect ng mga tagas ng memorya sa mga aplikasyon sa iOS at macOS. Hindi tulad ng Allocations na nagpapakita lamang ng mga alokasyon, ang Leaks ay aktibong nag-scan ng heap sa paghahanap ng retain cycles — mga sitwasyon kung saan ang dalawa o higit pang mga bagay ay magkabilang humahawak sa isa't isa gamit ang malalakas na reference.

Gumagana ang Leaks kasama ang Cycles & Roots — isang visualizer ng object retention graph. Kapag may nakitang tagas, ipinapakita ng Leaks ang lahat ng bagay sa cycle, ang kanilang retain count at ang eksaktong mga field kung saan ipinapasa ang mga reference. Kailangan lamang tumingin ng developer sa graph at maunawaan kung aling reference ang kailangang palitan ng weak.

Awtomatikong naha-highlight ng tool ang mga tagas na may pulang marker sa timeline. Gumagana ang Leaks sa real-time: sa sandaling may nakitang tagas ang sistema, agad itong nag-sesenyas sa developer. Ito ay nagpapahintulot na ayusin ang mga problema sa lugar, nang hindi naghihintay ng dump at post-analysis.

Ayon sa WWDC 2022, ang Leaks ay kayang makakita kahit ang kumplikadong multi-level na retain cycles — halimbawa, kapag tatlo o higit pang mga bagay ang bumubuo ng isang saradong kadena ng malalakas na reference. Para sa diyagnosis ng naturang mga cycle, ang Cycles & Roots graph ay kailangang-kailangan: biswal nitong ipinapakita kung paano nagsasara ang mga bagay sa isa't isa.

Paano basahin ang Cycles & Roots graph

Bawat node ng graph ay isang bagay, bawat arrow — isang malakas na reference. Ang cycle — isang saradong contour ng mga arrow. Ang kulay ng node ay nagpapakita ng status: pula — tumatagas na bagay, berde — ugat (GC Root), kulay abo — intermediate na bagay. Upang ayusin ang tagas, hanapin ang arrow na maaaring gawing weak nang hindi lumalabag sa lohika — at palitan ang uri ng reference sa code.

Energy Log: pagsusuri ng pagkonsumo ng enerhiya

Energy Log — ay isang template ng Instruments para sa pagsukat ng pagkonsumo ng enerhiya ng aplikasyon. Nangongolekta ito ng datos mula sa hardware sensors ng device: CPU load, status ng Wi-Fi at cellular network, paggamit ng GPS, display at Bluetooth. Ipinapakita ng Energy Log kung aling mga operasyon sa aplikasyon ang nagdudulot ng pinakamalaking konsumo ng baterya at inilalagay ang mga ito sa graph ng konsumo ng enerhiya ayon sa scale ng oras.

Inuuri ng tool ang mga operasyon ayon sa antas ng konsumo ng enerhiya: mababa (normal na trabaho ng processor), katamtaman (Wi-Fi transmission), mataas (GPS, mobile network, GPU). Kung ang Energy Log ay nagpapakita ng mga pulang indikator ng mataas na antas sa mahabang panahon — ang aplikasyon ay nagda-drain ng baterya sa background at tatanggalin ng user.

Mga karaniwang problemang natutuklasan ng Energy Log: WakeLock na walang limitasyon sa oras (ang aplikasyon ay nagpapanatiling aktibo ng processor pagkatapos matapos ang gawain), Location Updates na may mataas na katumpakan sa background (bawat ilang segundo ay humihiling ng mga coordinate), mga anomalya ng network session(madalas na pagkonekta ulit sa server). Inirerekomenda ng Energy Log na itala ang bawat naturang insidente at magdagdag ng kondisyon para i-off ang operasyong malakas sa enerhiya.

Para sa pagsubok ng konsumo ng enerhiya, gumamit ng totoong device na may power ng baterya — sa emulator, ang mga indikator ng konsumo ng enerhiya ay hindi tama. Patakbuhin ang Energy Log kasama ang mga UI test para i-automate ang pagsusuri ng konsumo ng baterya sa CI.

Paano patakbuhin at bigyang-kahulugan ang mga resulta ng Instruments

Ang pagpapatakbo ng Instruments mula sa Xcode ay ginagawa sa dalawang paraan: sa pamamagitan ng menu na Product → Profile (⌘I) o sa pamamagitan ng pagbukas ng Instruments bilang isang hiwalay na aplikasyon sa Launchpad. Ang unang paraan ay mas maginhawa: awtomatikong binuo ng Xcode ang aplikasyon sa profiling mode at pinapatakbo ito sa nakakonektang device na may napiling template. Pagkatapos ihinto ang session, ini-save ng Instruments ang tracing sa isang file na may extension na .trace.

Ang interpretasyon ng mga resulta ay depende sa template. Para sa Time Profiler, tingnan ang Call Tree na na-sort ayon sa Self Weight — ang mga pinakamataas na metodo ay ang iyong mga pangunahing bottleneck. Para sa Allocations — tingnan ang # Living pagkatapos ng cyclic scenario: kung ang bilang ng mga bagay ay tumaas, maghanap ng tagas. Para sa Leaks — tingnan ang mga pulang marker at ang Cycles & Roots graph. Ihambing ang mga resulta bago at pagkatapos ng optimisasyon — ito ang tanging paraan upang kumpirmahin ang bisa ng mga pagbabago.

// Command line para sa Instruments sa CI
// Pagsasama ng Instruments sa CI/CD pipeline
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Pagsukat ng oras ng scroll ng koleksyon
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

Sa CI, ang Instruments ay maaaring patakbuhin mula sa command line sa pamamagitan ng xcodebuild -showBuildSettings at xcrun xctrace. Ito ay nagpapahintulot na i-automate ang profiling sa bawat commit at hindi makaligtaan ang regression. Para sa pagsusuri, gamitin ang Baseline comparison: kung ang metric ay lumala ng 5% kumpara sa nakaraang commit — ang pipeline ay dapat huminto.

Mga pangunahing pagkakamali sa pagtatrabaho sa Instruments: pag-profile sa simulator sa halip na sa device (hindi tama ang datos ng CPU at GPU), pagkolekta ng datos nang walang scenario (random ang mga resulta), pagbalewala sa Call Tree (pagtingin lamang sa graph, hindi sa mga tiyak na metodo). Ang pag-aayos ng mga pagkakamaling ito ay nagbibigay ng 80% ng kalidad ng profiling.