Runtime sa mobile development: ano ito, runtime system at paano ito gumagana

Ano ang Runtime sa mobile development?

Runtime (execution environment) ay ang infrastructure na tumitiyak sa pagpapatakbo ng program pagkatapos itong ilunsad. Sa konteksto ng mobile development, ang runtime ay kabilang ang class loader, memory allocator, garbage collector, method dispatcher, at exception handler. Kung walang layer na ito, hindi maipapatakbo ng operating system ang Dalvik bytecode o mga Objective-C na mensahe.

Ang mga mobile platform ay gumagamit ng iba't ibang implementasyon ng runtime. Android ay gumagamit ng ART (Android Runtime) na may hybrid AOT/JIT compilation. Ang iOS ay gumagamit ng Objective-C Runtime — isang dynamic na sistema na batay sa message passing at SEL identifiers. Parehong pamamaraan ay lumulutas ng isang problema: patakbuhin ang code ng developer sa isang partikular na device na may pinakamataas na pagganap.

Ayon sa Google I/O 2024, ang Android Runtime ay nagpoproseso ng higit sa 10 bilyong method bawat araw sa mga device sa buong mundo. Ang pagganap ng runtime ay direktang nakakaapekto sa bilis ng paglulunsad ng app, sa kinis ng mga animation, at sa pagkonsumo ng baterya. Bawat method call, bawat memory allocation, at bawat garbage collection cycle ay dumadaan sa runtime layer.

Runtime system: saan binubuo

Ang runtime system ay kabilang ang limang pangunahing komponente: class loader, memory manager, interpreter o compiler, method dispatcher, at security system. Bawat komponente ay gumaganap ng mahigpit na tinukoy na tungkulin sa proseso ng pagpapatakbo ng code.

Class loader at pagpapatunay

Kapag inilunsad ng gumagamit ang app, ang ClassLoader ay naglo-load ng mga DEX file (Android) o Mach-O binary file (iOS) sa working memory. Sa Android, ang yugtong ito ay kabilang ang pagpapatunay ng bytecode: sinusuri ng runtime na ang code ay walang mga hindi ligtas na instruction, hindi lalampas sa mga hangganan ng array, at gumagalang sa mga uri. Ang pagpapatunay ay isang kritikal na hakbang sa seguridad na pumipigil sa pagpapatakbo ng malisyosong code.

Memory manager at Garbage Collector

Memory Manager ay naglalaan at nagpapalaya ng memory para sa mga object. Sa Android, ang ART ay gumagamit ng concurrent garbage collector na may generational collection: ang mga batang object ay sinusuri nang mas madalas, ang mga matatanda — mas madalang. Ang Objective-C Runtime ay nag-aapply ng Automatic Reference Counting (ARC), kung saan ang compiler ay awtomatikong naglalagay ng retain/release calls.

Method dispatcher at virtual table

Method dispatcher ay tumutukoy kung aling implementasyon ng method ang tatawagin. Sa mga static na wika (Kotlin, Swift), ang pagpapadala ay ginagawa sa pamamagitan ng vtable — ang talahanayan ng mga virtual method. Sa mga dynamic na wika (Objective-C), ang mensahe ay dumadaan sa objc_msgSend, na naghahanap ng implementasyon sa class at sa mga superclass nito. Ang resulta ay naka-imbak sa method cache upang mapabilis ang mga paulit-ulit na tawag.

Paano gumagana ang ART sa Android

Android Runtime (ART) ay isang virtual machine na nagpapatakbo ng DEX bytecode ng mga Android app. Pinalitan ng ART ang Dalvik sa Android 5.0 Lollipop, na nag-alok ng AOT compilation: ang app ay kinokompile sa machine code isang beses sa panahon ng pag-install. Tinanggal nito ang overhead ng JIT compilation sa bawat paglulunsad.

Mula sa Android 7.0 Nougat, ang ART ay gumagamit ng hybrid approach. Sa pag-install, ang JIT compilation ay ginagawa lamang para sa madalas na ginagamit na method (hot methods), habang ang natitirang code ay ini-interpret. Ang background process (profile-guided optimization) ay nagsusuri kung aling method ang madalas na tinatawag at kinokompile ang mga ito AOT sa mga panahong hindi aktibo ang device. Binabawasan nito ang oras ng pag-install at kasabay nito ay nagbibigay ng mataas na pagganap.

Ang ART ay mayroon ding AOT compiler (dex2oat), na nagko-convert ng DEX file sa ELF binary file na may ARM64 machine code. Ang kompilasyon ay ginagawa sa tatlong antas ng optimisasyon: quicken (mabilis), optimize (katamtaman), at everything (kumpleto). Bilang default, inia-apply ng Android ang optimize, na nagbabalanse sa pagitan ng bilis ng kompilasyon at pagganap ng code.

class RuntimeExample {
    fun measureExecutionTime() {
        val start = System.nanoTime()
        // Pagtawag ng method na kinokompile ng ART
        processData()
        val end = System.nanoTime()
        println("Oras ng pagpapatakbo: ${end - start} ns")
    }
}

Sa halimbawa sa itaas, ang System.nanoTime() ay isang native method na ang tawag ay ipinapadala sa pamamagitan ng ART runtime sa Linux kernel. Ang ART ay nagko-convert ng Kotlin bytecode sa ARM64 instructions na pinapatakbo ng processor ng device. Ang prosesong ito ay nangyayari nang hindi nakikita ng developer, ngunit ang optimisasyon nito ay isang pangunahing gawain ng Android Platform team.

Profile-Guided Optimization (PGO)

Optimization na batay sa profile ay isang mekanismo ng ART na nangongolekta ng mga profile ng paggamit ng method. Ang file na profiles/.primary.prof ay naglalaman ng listahan ng hot methods na kinokompile AOT. Ayon sa Android Performance Team, pinapabilis ng PGO ang paglulunsad ng app ng 15–30% pagkatapos ng ilang araw ng paggamit, kapag ang profile ay naipon na.

Ang developer ay maaaring mag-activate ng baseline profiles sa kanyang Gradle project. Ito ay mga manual annotation na nagpapahiwatig sa ART kung aling method ang kokomplihen AOT kaagad pagkatapos ng pag-install. Ang baseline profiles ay nagpapaikli sa unang paglulunsad ng 40% nang hindi naghihintay ng background profiling.

Paano gumagana ang Objective-C Runtime sa iOS

Objective-C Runtime ay isang dynamic na library na tumitiyak sa pagpapatakbo ng Objective-C code sa iOS at macOS. Ang core nito ay ang objc_msgSend function, na nagpapatupad ng message passing: sa halip na direktang method call, ang object ay nagpapadala ng mensahe na may selector, at tinutukoy ng runtime kung aling implementasyon ang dapat patakbuhin.

Bawat Objective-C object ay naglalaman ng isa pointer sa class, at ang class ay may dispatch table (talahanayan ng pagpapadala) na nagmamapa ng mga selector (SEL) sa mga implementasyon (IMP). Kapag tinawag ang isang method, ang objc_msgSend ay dumadaan sa chain: class → superclass → NSObject, hanggang makahanap ng IMP. Kung hindi mahanap ang implementasyon, tinatawag ng runtime ang forwarding mechanism, na maaaring humarang sa mensahe o gumawa ng exception.

Ang Objective-C Runtime ay sumusuporta rin sa method swizzling — pagpapalit ng IMP para sa umiiral na selector sa panahon ng pagpapatakbo. Ito ay isang makapangyarihang mekanismo na ginagamit sa AOP libraries at monitoring tools, ngunit nangangailangan ng pag-iingat dahil sa epekto nito sa buong app.

@interface RuntimeDemo : NSObject
- (void)printClassInfo;
@end

@implementation RuntimeDemo
- (void)printClassInfo {
    // objc_getClass — function ng runtime
    Class cls = objc_getClass("RuntimeDemo");
    unsigned int count;
    Method *methods = class_copyMethodList(cls, &count);
    NSLog("Bilang ng mga method: %d", count);
}
@end

Ipinapakita ng code ang direktang pag-access sa Objective-C Runtime API: nakukuha ng objc_getClass ang object ng class sa pamamagitan ng pangalan, at kinukuha ng class_copyMethodList ang listahan ng lahat ng method. Ito ay reflection na kumikilos — pag-access sa metadata ng class sa panahon ng pagpapatakbo. Ang ganitong pamamaraan ay ginagamit sa XCTest para sa dynamic na pagpaparehistro ng mga test.

isa pointer at tagged pointers

isa pointer ay isang pointer sa class ng object, na naka-imbak sa unang 8 byte ng bawat object. Mula sa iOS 12, ipinakilala ng Apple ang isa-swizzling para sa optimisasyon: ang mga mas mababang bit ng isa ay nag-e-encode ng karagdagang impormasyon tungkol sa estado ng object. Ang tagged pointers ay isa pang optimisasyon, kung saan ang mga halaga hanggang 60 bit (NSNumber, NSDate) ay iniimbak nang direkta sa pointer, nang walang paglalaan ng object sa heap. Binabawasan nito ang kargamento ng memory manager ng 30%.

JIT at AOT compilation: paghahambing ng mga pamamaraan

JIT (Just-In-Time) at AOT (Ahead-Of-Time) ay dalawang pamamaraan ng pagkokompile ng bytecode sa machine code. Ang JIT ay nagkokompile ng code sa panahon ng pagpapatakbo ng app, sinusuri ang mga hot spot at ino-optimize ang mga ito nang on-the-fly. Ang AOT ay kinokompile ang buong code nang maaga — sa pag-install ng app o sa bahagi ng developer.

Ang hybrid approach ng ART (Android 7+) ay itinuturing na optimal: ginagamit ng app ang interpreter para sa mga bihirang tinatawag na method, JIT para sa hot methods, at AOT para sa mga method mula sa profile-guided optimization. Ang iOS, sa kabilang banda, ay gumagamit ng mahigpit na AOT sa pamamagitan ng LLVM: ang Swift at Objective-C ay kinokompile sa machine code sa yugto ng build sa Xcode.

Ayon sa Apple Developer Documentation, 2024, ang Swift runtime ay nagdaragdag ng humigit-kumulang 15 MB sa laki ng app. Ang Flutter ay gumagamit ng sarili nitong Dart VM, kung saan gumagana ang JIT compilation sa debug mode para sa hot reload, at ang AOT — sa release mode para sa pinakamataas na pagganap. Ang React Native ay gumagamit ng Hermes — isang JavaScript engine na may AOT compilation na binabawasan ang oras ng paglulunsad ng 50%.

ARM64 Runtime at machine code

ARM64 Runtime ay ang antas kung saan nakikipag-ugnayan ang machine code sa processor ng device. Karamihan sa mga modernong mobile device ay gumagana sa ARM64 (aarch64) processors. Isinasalin ng runtime ang bytecode o native calls sa ARM64 instructions na pinapatakbo ng CPU.

Ang mga pangunahing ARM64 register na ginagamit ng runtime: x0–x7 (mga parameter ng function), x8 (indirect result), x30 (return address), sp (stack pointer), fp (frame pointer). Gumagawa ang ART ng code na sumusunod sa ARM64 Procedure Call Standard: lahat ng method call ay dumadaan sa protocol na tinukoy ng architecture ng processor.

Ang pag-unawa sa ARM64 ABI ay mahalaga sa optimisasyon ng pagganap: ang inline-caching, branch prediction, at alignment ng code sa memory ay direktang nakakaapekto sa bilis ng paggana ng runtime. Ipinapakita ng mga profiling tool (Android Studio Profiler, Instruments) kung aling bahagi ng code ang gumugugol ng pinakamaraming oras sa runtime — ang optimisasyon mismo ng mga bahaging iyon ang nagbibigay ng pinakamalaking pagtaas.

// Halimbawa ng ARM64 assembly na ginagawa ng ART
// Pagtawag ng method na may dalawang parameter

mov    x0, x23            // self (this)
mov    x1, x24            // param1
mov    x2, x25            // param2
bl     methodEntryPoint   // pagtawag sa pamamagitan ng runtime
str    x0, [sp, #8]      // pag-save ng resulta

Sa halimbawang ito, ang ARM64 instructions na mov ay naglilipat ng mga argumento sa mga register x0–x2, tinatawag ng bl ang entry point ng method, at iniimbak ng str ang return value. Gumagawa ang runtime ng ganitong mga instruction para sa bawat method call, ino-optimize ang sequence sa pamamagitan ng devirtualization at inlining.

Epekto ng runtime sa pagganap

Runtime overhead ay ang hindi maiiwasang halaga ng dynamic dispatch. Bawat method call sa pamamagitan ng runtime ay nangangailangan: paghahanap ng implementasyon sa dispatch table, pagpapatunay ng mga uri, pagtawag sa IMP, at pagbabalik ng resulta. Ipinapakita ng mga pagsukat na ang runtime ay nagdaragdag ng 10–50 ns bawat call sa Objective-C at 5–20 ns sa ART.

Upang mabawasan ang overhead, ginagamit ng mga developer ang monomorphic inlining (ART) at method caching (Objective-C). Ang Kotlin/Native at Swift ay kinokompile nang direkta sa ARM64, na ganap na tinatanggal ang runtime layer, ngunit nawawala ang mga dynamic na kakayahan — reflection, swizzling, dynamic na paglo-load ng mga class.