Android Profiler: ano ito, mga kakayahan ng CPU, Memory at Network

Ano ang Android Profiler?

Android Profiler — ay isang bahagi ng Android Studio na pumalit sa lumang Android Monitor at DDMS. Nagbibigay ito ng nagkakaisang interface para sa profiling ng lahat ng aspeto ng application: CPU Profiler para sa pagsusuri ng processor, Memory Profiler para sa pagtatrabaho sa memorya, Network Profiler para sa mga request sa network at Energy Profiler para sa pagkonsumo ng enerhiya. Ang data ay awtomatikong kinokolekta kapag inilunsad ang application sa pamamagitan ng Android Studio.

Ang profiler ay gumagana pareho sa emulator at sa pisikal na device na nakakonekta sa pamamagitan ng USB. Ayon sa datos ng Google I/O 2023, ang Android Profiler ay ginagamit sa mahigit 70% ng mga proyekto sa Android at itinuturing na karaniwang tool para sa diagnostic ng pagganap. Ang pangunahing bentahe kumpara sa mga panlabas na solusyon — zero integration: hindi kailangang magdagdag ng mga dependency sa build.gradle o baguhin ang code ng application.

Ang arkitektura ng Android Profiler ay binuo sa Perfetto — system tracer ng Android na kumokolekta ng data sa antas ng kernel at application. Tinitiyak ng Perfetto ang minimal na overhead (mas mababa sa 1% CPU) at sumusuporta sa pangmatagalang pag-record hanggang 30 minuto. Pinapayagan nito ang profiling hindi lamang ng mabilis na operasyon, kundi pati na rin ng mahabang senaryo — mga transisyon sa pagitan ng mga screen, background synchronization, pagkonsumo ng memorya sa loob ng isang oras na paggamit.

Anong data ang kinokolekta ng Android Profiler

Ang profiler ay kumokolekta ng apat na uri ng data: CPU — pag-load ng bawat core at thread, Memory — Java Heap, Native Heap, Stack, Graphics, Network — lahat ng papasok at papalabas na request, Energy — mga kategorya ng pagkonsumo ng enerhiya (Idle, Light, Medium, Heavy). Ang data ay naka-sync sa timeline — makikita mo nang sabay-sabay kung paano nakakaapekto ang pagbabago ng CPU sa memorya at pagkonsumo ng enerhiya.

CPU Profiler: pagsusuri ng processor at mga thread

CPU Profiler nagpapakita ng pag-load ng processor sa real-time sa timeline, hinati ayon sa mga thread ng application. Ang bawat thread ay kinakatawan ng may kulay na linya o lugar — kung mas malawak ang lugar, mas maraming oras ng processor ang ginagamit ng thread. Ang mga pulang lugar ay nangangahulugang trabaho ng application, asul — mga tawag sa system, kulay abo — paghihintay.

Para sa detalyadong pagsusuri, sinusuportahan ng CPU Profiler ang tatlong mode ng pag-record: Trace Java Methods (pagsubaybay sa lahat ng Java method), Trace C/C++ Functions (pagsubaybay sa native NDK function) at Sample Java Methods (pagsa-sample, inirerekomendang mode). Ang pagsa-sample ay nagbibigay ng pinakamaliit na overhead at angkop para sa araw-araw na profiling, habang ang buong pagsubaybay ay para sa paghahanap ng mga kumplikadong problema.

// Halimbawa: ang pagsusuri ng CPU Profiler ay magpapakita ng pamamaraang ito bilang bottleneck
class DataProcessor {
    suspend fun processLargeDataset(items: List<Item>): List<Result> {
        // Ipapakita ng CPU Profiler ang mataas na pag-load ng CPU sa inBackgroundThread
        return withContext(Dispatchers.Default) {
            items.map { it.computeHeavyTransformation() }
        }
    }
}

// Rekomendasyon pagkatapos ng profiling:
// Ang computeHeavyTransformation ay tumatagal ng 80% ng oras — i-cache ang resulta
class DataProcessorOptimized {
    private val cache = LruCache<String, Result>(100)

    suspend fun processLargeDataset(items: List<Item>): List<Result> {
        return withContext(Dispatchers.Default) {
            items.mapNotNull { cache.get(it.id) ?: it.computeHeavyTransformation().also { cache.put(it.id, it) } }
        }
    }
}

Pagkatapos ng pag-record, ipinapakita ng CPU Profiler ang Top-Down Tree — puno ng tawag na may oras ng pagpapatupad ng bawat method. Bigyang-pansin ang column na Self Time/Total: kung ang Self Time ng method ay higit sa 16 ms at tinatawag mula sa UI thread — ito ay garantisadong pagbaba ng frame. Solusyon — ilipat ang mabibigat na pagkalkula sa background thread sa pamamagitan ng Dispatchers.IO o Default.

Mga mode ng pagsubaybay sa CPU

Sample Java Methods — inirerekomendang mode para sa araw-araw na profiling na may 3–5% overhead. Trace Java Methods — buong pagsubaybay sa bawat tawag, overhead hanggang 15%, ginagamit para sa maiikling pag-record (5–10 segundo). Trace C/C++ Functions — pagsubaybay sa NDK code sa pamamagitan ng Linux Perf, kailangang-kailangan para sa pagsusuri ng mga laro at library sa C++. Magpalit ng mga mode depende sa uri ng problema.

Memory Profiler: pagtatrabaho sa memorya at paghahanap ng mga tagas

Memory Profiler sumusubaybay sa lahat ng kategorya ng memorya ng application: Java Heap (mga bagay ng JVM), Native Heap (mga alokasyon ng C/C++ sa pamamagitan ng JNI), Stack (mga stack ng thread) at Graphics (mga texture, GPU buffer). Ang pangunahing visualization — timeline graph ng pagkonsumo ng memorya, kung saan ang bawat kategorya ay ipinapakita sa sarili nitong kulay. Kung ang graph ay hindi bumababa pagkatapos ng garbage collection (GC) — maghinala ng tagas.

Para sa paghahanap ng mga tagas, gamitin ang function na Capture Heap Dump. Sa sandali ng dump, pinipigilan ng Android Profiler ang application ng ~100 ms at lumilikha ng HPROF file — kumpletong snapshot ng lahat ng buhay na bagay sa Java Heap. Pagkatapos buksan ang dump, maaari mong ayusin ang mga bagay ayon sa Retained Size (dami ng memorya na ilalabas kapag tinanggal ang bagay) at hanapin ang mga instance ng Activity, Fragment o Bitmap na dapat ay nawasak na.

Ayon sa datos ng Google I/O 2022, ang Memory Profiler kasama ng LeakCanary ay sumasaklaw sa 95% ng mga senaryo ng pagtuklas ng tagas ng memorya sa Android. Ang LeakCanary ay awtomatikong gumagana — natutukoy ang tagas sa background. Ang Memory Profiler ay kailangan para sa manu-manong pagsusuri: nakikita mo ang buong larawan ng mga alokasyon, hindi lamang ang mga tagas.

Paano i-interpret ang HPROF dump

Pagkatapos makuha ang dump, ayusin ang mga bagay ayon sa Retained Size — ito ang dami ng memorya na ilalabas kapag tinanggal ang bagay. Hanapin ang mga instance ng Activity, Fragment at Bitmap na may malaking Retained Size na hindi dapat nasa memorya. Pumunta sa tab na Reference Tree upang makita ang chain ng mga reference na humahawak sa bagay — kadalasan ito ay isang static na field ng singleton o hindi na-clear na callback. Mahalagang sukatan — Allocation rate (bilang ng mga alokasyon bawat segundo). Kung ang allocation rate ay lumampas sa 10,000 bagay/s, ang application ay gumugugol ng masyadong maraming oras sa paglikha at pagtanggal ng mga pansamantalang bagay, na nagpapabigat sa GC at nagdudulot ng micro-stutter. Sa kasong ito, gamitin ang tool na View Inspector at hanapin ang mga lugar na may madalas na paglikha ng bagay sa mga loop.

Network Profiler: pagsubaybay sa mga request sa network

Network Profiler nagpapakita ng lahat ng request sa network ng application sa real-time sa timeline. Ang bawat request ay ipinapakita bilang pahalang na bar — ang haba nito ay tumutugma sa oras ng pagpapatupad, ang kulay ay sa uri ng request (GET, POST, PUT, DELETE). Ang pag-scroll sa timeline ay nagbibigay-daan upang makita kung paano ipinamamahagi ang mga request sa oras at kung sila ay nagdodoble.

Sinusuportahan ang lahat ng sikat na library: OkHttp, Retrofit, Volley, Ktor. Para sa Ktor at OkHttp, ipinapakita ng profiler ang buong stack ng tawag kasama ang mga interceptor at converter. Para sa bawat request, available ang Request Headers at Response Headers, body ng tugon (hanggang 1 MB), code ng katayuan at tagal.

Mga karaniwang problemang natutukoy ng Network Profiler: kawalan ng caching (parehong URL ay hinihiling sa bawat pagbubukas), dobleng request (dalawang component ang sabay na nag-load ng parehong data), sobrang laki ng tugon (server ay nagpapadala ng 5 MB kung kailan 50 KB lang ang kailangan). Tumutulong ang Network Profiler na makita ang mga ganitong problema sa literal na isang sulyap sa timeline.

Para sa pagtulad sa mabagal na network, gamitin ang Network Conditioning sa Android Studio — pinapayagan nitong limitahan ang bandwidth sa 3G/2G at magdagdag ng pagkaantala. Ito ay kritikal para sa pagsubok ng pag-uugali ng application sa masamang kondisyon ng network, lalo na para sa mga application na nagpapatakbo sa mga rehiyon na may hindi matatag na internet.

Energy Profiler: pagsusuri ng pagkonsumo ng enerhiya

Energy Profiler sinusuri ang epekto ng application sa charge ng baterya batay sa data ng Perfetto. Hindi sinusukat ng tool ang aktwal na pagkonsumo sa milliamps, ngunit inuuri ang bawat operasyon sa isa sa limang kategorya ng pagkonsumo ng enerhiya: Idle, Light, Medium, High at Overloaded. Ang timeline ng Energy Profiler ay naka-highlight ng kulay: berde (magaan na load), dilaw (katamtaman), pula (mataas).

Mga pangunahing dahilan ng paglitaw ng mga pulang zone: WakeLock (application ay pinapanatiling aktibo ang processor), Location GPS (patuloy na paghiling ng mga coordinate na may mataas na katumpakan), mga koneksyong Keep-Alive (madalas na pagpapalitan ng data sa server), malaking pagpapadala ng data (pagpapadala ng file, streaming). Eksaktong ipinapakita ng Energy Profiler kung aling operasyon at sa anong oras ang naging sanhi ng pagtaas ng pagkonsumo ng enerhiya.

Ayon sa Android Developers, ang isang tipikal na application ay hindi dapat gumugol ng higit sa 5% ng oras sa kategoryang High. Kung ang Energy Profiler ay nagpapakita ng mga pulang zone nang higit sa 10% ng oras ng profiling — ang application ay hindi makakapasa sa pagsusuri ayon sa pamantayan ng Battery Drain. Rekomendasyon — gamitin ang WorkManager para sa mga gawain sa background, limitahan ang mga request sa Location sa minimal na kinakailangang katumpakan at pagsama-samahin ang mga request sa network sa mga batch.

Paano gamitin ang Android Profiler: praktikal na gabay

Ang paglulunsad ng Android Profiler ay ginagawa sa isang click: sa Android Studio buksan ang View → Tool Windows → Profiler o i-double click ang icon ng Profiler sa kanang panel. Pagkatapos ilunsad ang application sa nakakonektang device, awtomatikong kumokonekta ang Android Studio sa proseso at magsisimulang mangolekta ng data. Sa timeline ay agad na lilitaw ang mga graph ng CPU, Memory, Network at Energy.

Para sa detalyadong pagsusuri, piliin ang nais na tab (CPU, Memory, Network o Energy) at simulan ang pag-record. Para sa CPU inirerekomenda ko ang mode na Sample Java Methods na may tagal ng pag-record na 30 segundo — ito ay sapat para sa isang tipikal na senaryo. Para sa Memory — heap dump pagkatapos isagawa ang senaryo (Capture Heap Dump). Para sa Network, awtomatikong nagsisimula ang pag-record, pindutin lamang ang Stop button pagkatapos ng senaryo.

Pagkatapos ihinto ang pag-record, i-export ang data: File → Save As ay nagse-save ng buong session sa isang .perf file. Ito ay maginhawa para sa paghahambing ng mga sukatan bago at pagkatapos ng pag-optimize. Lumikha ng baseline session sa unang matatag na bersyon at ihambing ang bawat bagong session dito — ito ang tanging paraan upang obhetibong suriin ang mga pagbabago sa pagganap.

Pag-automate ng profiling sa CI

Ang Android Profiler ay maaaring ilunsad mula sa command line sa pamamagitan ng Android Studio CLI at Firebase Test Lab. Sinusuportahan ng Firebase Test Lab ang profiling ng pagganap bilang bahagi ng UI tests: natatanggap mo ang mga sukatan ng CPU, Memory at Network kasama ang resulta ng pagsubok. I-configure ang pipeline upang kapag bumaba ang mga sukatan ng 10% kumpara sa baseline, ang CI pipeline ay mai-block hanggang sa masuri ng developer.