Pagganap sa Pag-develop ng Mobile: ano ito, anong mga sukatan at kung paano pagbutihin

Bakit mabagal ang app?

Ang pagganap ng app ay direktang nauugnay sa jank — isang kapansin-pansing pagkaantala sa pagitan ng aksyon ng user at tugon ng UI. Pangunahing dahilan: pag-block ng pangunahing thread (mabibigat na operasyon sa UI thread), madalas na pag-redraw ng layout (overdraw), memory leaks (madalas na GC), hindi optimal na algorithm (O(n²) sa malaking data). Frame Rate (FPS) — bilang ng frame bawat segundo. Para sa komportableng karanasan, kailangan ang stable na 60 FPS (Android) o 120 FPS (iPhone Pro, iPad Pro). VSync ay nag-synchronize ng rendering sa refresh rate ng screen.

Nangyayari ang jank kapag ang pag-render ng isang frame ay lumampas sa 16.6 ms (para sa 60 FPS) o 8.3 ms (para sa 120 FPS). Ang pag-profile ng GPU (Profile GPU Rendering sa Android, Core Animation sa iOS) ay nagpapakita kung aling mga yugto ng rendering ang pinakamatagal. Pangunahing yugto: Layout (pag-aayos ng mga elemento), Draw (pag-drawing), Display (paglipat sa frame buffer). Ang pinakakaraniwang problema ay ang layout inflation sa XML, lalo na kapag gumagamit ng kumplikadong nested na ConstraintLayout.

Time-to-Interactive (TTI) — oras na kailangan ng app upang maging ganap na handa para sa interaksyon. Kasama sa TTI ang Cold Start, pag-load ng data at pagsisimula ng library. Inirerekomenda ng Google ang TTI na mas mababa sa 5 segundo, Apple — mas mababa sa 2 segundo para sa mga pangunahing screen. Lazy Loading — technique ng pagkaantala sa pag-load ng nilalaman at mga library, kritikal para sa pagpapabuti ng TTI. Sa IT Sectr, gumagamit kami ng tamad na pagsisimula bilang default sa lahat ng proyekto.

ANR at Crash

Ang ANR at Crash ay pangunahing kaaway ng pagganap ng mobile app. ANR (Application Not Responding) — dialog box sa Android na lilitaw kung ang pangunahing thread ay naka-block nang higit sa 5 segundo. Mga dahilan: sabay-sabay na network request sa UI thread, pagtatrabaho sa database nang walang coroutine, malaking bitmap decode nang walang downsampling, deadlock sa pangunahing thread. Ang ANR call stack ay nai-save sa /data/anr/traces.txt at nagbibigay-daan upang matukoy ang eksaktong lokasyon ng pag-block.

Crash — hindi inaasahang pagtatapos ng app. Sa Android — Exception (Java/Kotlin) o Signal (native code). Sa iOS — NSException o signal (EXC_BAD_ACCESS — pag-access sa libreng memorya). Mga Tool sa Pag-uulat ng Crash: Firebase Crashlytics, Sentry, BugSnag. Kinokolekta nila ang stacktrace, data ng device at mga hakbang sa pag-reproduce. Stack Overflow — pag-apaw ng call stack dahil sa walang katapusang recursion. OutOfMemoryError — kapag puno ang heap.

StrictMode — Android tool para sa pag-detect ng mga paglabag sa kaligtasan ng thread. Pinapayagan ang pag-set ng mga panuntunan: ThreadPolicy (pagbawal sa disk/network sa pangunahing thread), VmPolicy (detect ng Activity, SQLite, CloseGuard leaks). Ang StrictMode ay dapat na i-activate lamang sa debug build — sa release ay hindi dapat ito gumana. Sa iOS, ang katumbas ay Main Thread Checker (Xcode), na awtomatikong nakakatuklas ng mga UIKit call na wala sa pangunahing thread.

Pamamahala ng Memorya (GC, ARC, Retain Cycle)

Memory Leak

Ang memory leak — sitwasyon kung saan nananatili sa memorya ang isang bagay kahit hindi na ito ginagamit ng app. Ito ay direktang nagpapababa ng pagganap ng app. Sa Android, hindi maaaring kolektahin ng GC (Garbage Collection) ang isang bagay kung mayroong malakas na sanggunian dito. Mga karaniwang dahilan: static na sanggunian sa Activity, hindi nakanselang callback/observer, panloob na klase na may implicit na sanggunian sa panlabas na klase, Handler na may hindi nalinis na mensahe. LeakCanary — library para sa awtomatikong pag-detect ng leak.

Retain Cycle

ARC (Automatic Reference Counting) — modelo ng pamamahala ng memorya sa iOS. Ang bawat bagay ay may bilang ng sanggunian (retain count). Kapag ang bilang ay umabot sa zero, ang memorya ay pinalaya. Nagaganap ang Retain Cycle kapag ang dalawang bagay ay nagtataglay ng malakas na sanggunian sa bawat isa (A → B at B → A). Hindi kailanman i-zero ng ARC ang mga bilang. Solusyon: mahihinang (weak) o walang-ari (unowned) na sanggunian. Ang Weak ay awtomatikong nagiging nil kapag pinalaya ang bagay. Ang Unowned ay hindi nagiging ngunit ginagarantiyang buhay ang bagay.

GC vs ARC

GC (Garbage Collection) ay gumagana sa Android (Java/Kotlin). Ang GC ay pana-panahong humihinto sa pag-execute (Stop-the-World pause) upang mahanap at palayain ang mga bagay na hindi maaabot. GC Trigger: kapag ang heap ay napuno sa isang tiyak na porsyento. Ang ARC ay gumagana sa iOS (Swift/Objective-C) at walang mga pause — ang mga bilang ay ina-update nang atomiko sa bawat pagtatalaga. Ang ARC ay mas predictable, ngunit maaaring makaipon ng labis na retain/release na operasyon sa mataas na dalas ng pagtatalaga.

Mahinang Sanggunian (Weak Reference) at Malakas na Sanggunian (Strong Reference) — ang uri ng sanggunian ay tumutukoy kung maaaring palayain ng GC/ARC ang bagay. Strong Reference — ang bagay ay hindi kokolektahin habang umiiral ang sangguniang ito. Weak Reference — maaaring kolektahin ng GC/ARC ang bagay; ang mahinang sanggunian ay nagiging nil (sa Swift/Java WeakReference). Unowned Reference (Swift) — hindi nagiging nil kapag pinalaya; ang pag-access dito pagkatapos ng kamatayan ng bagay ay nagdudulot ng crash. Sa Android, ginagamit ang java.lang.ref.WeakReference para sa mahihinang sanggunian.

Halimbawa ng pag-detect ng leak sa Android gamit ang LeakCanary:

// Утечка: анонимный класс держит ссылку на Activity
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val handler = object : Handler(Looper.getMainLooper()) {
            override fun handleMessage(msg: Message) {
                // Используем `this@MainActivity`, сохраняя ссылку на Activity
                Log.d("TAG", "Handler received message")
            }
        }
        handler.sendEmptyMessageDelayed(0, 60000)
    }
}

// Исправление: статический Handler + WeakReference
class SafeHandler(activity: MainActivity) : Handler() {
    private val weakActivity =
        WeakReference(activity)

    override fun handleMessage(msg: Message) {
        weakActivity.get() ?: return
        Log.d("TAG", "Handler received message")
    }
}

Pag-profile (Instruments, Android Profiler)

Ang pag-profile ay ang proseso ng pagsukat ng pagganap ng app: CPU, memorya, network, pagkonsumo ng kuryente. Kung walang pag-profile, ang bulag na pag-optimize ay walang silbi — hindi mo malalaman kung aling bahagi ng code ang talagang mabagal.

Instruments (Xcode) — ang pinakamakapangyarihang tool para sa iOS. Ipinapakita ng Time Profiler kung aling mga function ang pinakamaraming kumokonsumo ng CPU. Sinusubaybayan ng Allocations ang paggawa at pagpapalaya ng bagay. Awtomatikong hinahanap ng Leaks ang retain cycles. Mga hakbang sa pag-profile: (1) ilunsad ang Instruments; (2) pumili ng template (Time Profiler para sa CPU); (3) patakbuhin ang problematikong senaryo; (4) suriin ang call stack — ang pinakamalawak na column ay ang pinaka"mainit" na function.

Ang Android Profiler ay naka-integrate sa Android Studio (View → Tool Windows → Profiler). Ipinapakita ng CPU Profiler ang load ng bawat thread. Memory Profiler — heap dump at pagsubaybay sa alokasyon. Network Profiler — lahat ng HTTP request na may timing. Energy Profiler — pagkonsumo ng kuryente: WakeLock, Location, Network. Para sa detalyadong pagsubaybay, gamitin ang Systrace (Android 10+) o Perfetto — system tracing na may microsecond precision.

Pagsisimula ng App (Cold/Warm/Hot Start)

Ang pagsisimula ng app ay isa sa mga pangunahing tagapagpahiwatig ng pagganap. Ito ay nahahati sa tatlong uri: Cold Start — ang app ay magsisimula mula sa simula: nilikha ang proseso, Application.onCreate (Android) / AppDelegate.applicationDidFinishLaunching (iOS), pag-load ng klase, pagsisimula ng library. Warm Start — umiiral ang proseso, ngunit ang Activity/ViewController ay nawasak (hal., sa pag-ikot ng screen o pagbabalik mula sa memorya). Hot Start — ang Activity/ViewController ay nasa memorya, ang app ay ipinapakita lamang (paglipat mula sa ibang app).

Ang Cold Start ay ang pinakamahalagang sukatan. Sa Android kasama ang: (1) launch Activity — pag-load ng XML, pagsisimula ng View; (2) unang frame — oras hanggang sa unang pag-render. Inirerekomenda ng Google: launch Activity < 200 ms, unang frame < 500 ms, TTI < 5 segundo. Pag-optimize ng Cold Start: bawasan ang Application.onCreate (coroutine para sa tamad na pagsisimula), gamitin ang SplashScreen API (Android 12+), ipagpaliban ang pagsisimula ng library (WorkManager, DI), alisin ang hindi kinakailangang ContentProviders.

Sa iOS, kasama sa Cold Start: pag-load ng Mach-O binary, dyld (dynamic linker), pagsisimula ng Objective-C runtime, application delegate, unang controller. Chrome Custom Tabs (Android) at Universal Links (iOS) — mga teknolohiya para sa mabilis na pagbukas ng panlabas na nilalaman sa app nang walang buong Cold Start. Inirerekomenda na subukan ang Cold Start sa totoong mid-range na device.

Pag-optimize ng Sukat

Ang sukat ng app ay isang factor ng pagganap para sa pag-install at pag-update. Nakakaapekto ito sa conversion: bawat 10 MB ay nagpapababa ng conversion ng 1%. Inirerekomenda ng Google Play ang sukat ng APK na mas mababa sa 150 MB; App Store — mas mababa sa 200 MB (cellular network — 100 MB). Pangunahing paraan ng pag-optimize: compression ng imahe (WebP sa halip na PNG ay nakakatipid ng 25-35%), vectorization (VectorDrawable sa Android, SF Symbols sa iOS), pag-alis ng hindi nagamit na code (R8/ProGuard), pag-alis ng hindi nagamit na resources (lint → unused resources).

App Bundle (Android) — format ng publikasyon kung saan ang Google Play ay lumilikha ng naka-optimize na APK para sa bawat device. Binabawasan ng App Bundle ang laki ng pag-download ng 20-40%. Dynamic Delivery — mga module na dina-download on-demand (on-demand feature modules). Sa iOS, ang katumbas ay On-Demand Resources (ODR): mga resource na dina-download pagkatapos ng unang pagsisimula (level ng laro, video).

Lazy Loading — technique kung saan ang mga module at library ay hindi na-load sa pagsisimula, ngunit na-load kung kinakailangan. Split APK (Android) at App Slicing (iOS) — paghahati ng app sa architectural slots: arm64-v8a, x86_64. Pag-optimize ng Sukat ng App — isang patuloy na proseso: suriin ang komposisyon ng APK (Analyze APK sa Android Studio), alisin ang mga duplicate na icon, gumamit ng SVG sa halip na maraming densidad ng PNG. Sa IT Sectr, isinasama namin ang pagsusuri ng laki ng build sa CI/CD para sa bawat MR.