ART: ano ito, execution environment at kung paano ito gumagana

Ano ang ART?

Android Runtime (ART) — ang execution environment na nagko-compile ng DEX bytecode sa native machine code bago patakbuhin. Hindi tulad ng Dalvik na gumamit ng Just-In-Time compilation habang tumatakbo, ang ART ay nagsasagawa ng Ahead-Of-Time (AOT) compilation sa pag-install ng APK. Ang pangunahing pagbabagong ito sa arkitektura ay nagdulot ng makabuluhang pagbilis ng mga app at pagbawas sa konsumo ng kuryente.

Unang lumitaw ang ART bilang experimental na opsyon sa Android 4.4 KitKat. Maaaring i-activate ito ng mga developer sa settings ng developer at subukan ang kanilang mga app. Sa Android 5.0 Lollipop, naging default execution environment ang ART, at ganap na inalis ang Dalvik sa platform. Sa paglabas ng Android 7.0 Nougat, nakatanggap ang ART ng hybrid compilation mode.

Kasaysayan ng pag-develop

Ang desisyong palitan ang Dalvik ng ART ay hindi biglaan. Nagsimula ang trabaho sa bagong environment noong 2012, nang mapagtanto ng Google ang mga limitasyon ng JIT approach. Mga pangunahing layunin: pabilisin ang pag-start ng app, bawasan ang load ng processor, at babaan ang konsumo ng kuryente. Ang pag-develop ay pinamunuan ng Android Runtime Group team, na dati nang nagtrabaho sa mga optimisasyon ng Dalvik.

Mga pagbabago sa arkitektura

Gumagamit ang ART ng parehong register architecture tulad ng Dalvik, ngunit may ganap na redesign na compiler. Sa halip na interpreter at JIT compiler, kasama sa ART ang AOT compiler na dex2oat, na nagko-convert ng mga DEX file sa ELF binary sa pag-install. Bilang resulta, ang app sa ART ay agad na tumatakbo nang may native performance, walang warm-up phase.

Arkitektura ng ART: mula Dalvik hanggang bagong environment

ART ay pinanatili ang mga pangunahing prinsipyo ng Dalvik: paghihiwalay ng app sa pamamagitan ng magkakahiwalay na proseso, register architecture, at suporta sa DEX format. Gayunpaman, ang internal implementation ay ganap na na-rewrite. Sa halip ng Dalvik interpreter, kasama sa ART ang tatlong execution mode: interpreter, JIT compiler, at AOT compiler dex2oat. Ang pagpili ng mode ay depende sa yugto ng lifecycle ng app.

Ang pangunahing bahagi ng ART — dex2oat (dalvik executable to optimized android translator). Ang tool na ito ay tumatakbo sa pag-install ng app (mula Android 7.0 — pati na rin sa background optimization). Binabasa ng dex2oat ang mga DEX file mula sa APK, nag-o-optimize ng bytecode, at gumagawa ng OAT file — isang ELF binary na may native code. Ang mga OAT file ay naka-imbak sa direktoryo /data/dalvik-cache/.

# Pagsusuri ng mga OAT file sa device
adb shell ls -la /data/dalvik-cache/arm64/

# Puwersahang recompilation ng app
adb shell cmd package compile -m speed com.example.app

Mga bahagi ng ART

Ang ART system ay binubuo ng ilang magkakaugnay na module. Ang compiler dex2oat ay responsable para sa pagbuo ng native code. Ang garbage collector (GC) ay namamahala sa pagpapalaya ng memorya. Ang interpreter ay nag-execute ng bihirang tinatawag na code nang walang compilation. Ang profiler ay sumusubaybay sa mga hot method para sa hybrid compilation. Ang bawat module ay maaaring gumana nang nakapag-iisa, na ginagawang flexible at scalable ang ART.

Hybrid compilation: JIT + AOT + profiling

Mula Android 7.0 Nougat, gumagamit ang ART ng hybrid approach sa compilation, na pinagsasama ang mga bentahe ng JIT at AOT. Sa pag-install ng app, hindi na ginagawa ng ART ang buong AOT compilation — sa halip, ang app ay tumatakbo sa interpreted mode na may JIT compilation ng mga hot method. Binabawasan nito ang oras ng installation at ginagamit na espasyo.

Kahanay, gumagana ang background profiler. Nangongolekta ito ng statistics ng execution: aling mga method ang madalas na tinatawag, aling mga branch ng code ang na-execute, aling mga klase ang na-load. Pagkatapos makaipon ng sapat na data (karaniwan pagkatapos ng 2–3 pag-start ng app), pinapatakbo ng ART ang dex2oat sa background at nagko-compile lamang ng na-profile na hot method sa native code.

Mga mode ng compilation

ART ay sumusuporta sa ilang compilation mode na pinamamahalaan sa pamamagitan ng system_server. Ang "speed" mode ay nagko-compile ng lahat ng method sa AOT (maximum performance, mahabang installation). Ang "speed-profile" mode ay nagko-compile lamang ng na-profile na hot method (balanse ng bilis at laki). Ang "verify" mode ay nagbe-verify lamang ng bytecode nang walang compilation (minimal na espasyo, interpretasyon). Default na ginagamit ang speed-profile — optimal para sa karamihan ng mga app.

Profiler ng ART

Ang profiler ay nangongolekta ng data ng execution sa mga espesyal na .prof file. Ang bawat app ay nag-iimbak ng profile nito sa /data/misc/profiles/. Kapag naabot ang threshold (karaniwan 1000 samples), pinapatakbo ng profiler ang dex2oat para i-compile ang mga natukoy na hot method. Ang mga profile ay napananatili sa pagitan ng mga update ng app, na nagpapabilis ng re-optimization pagkatapos ng OTA system updates.

Garbage collection sa ART

Garbage collection sa ART ay lubos na napabuti kumpara sa Dalvik. Sa halip ng single-threaded Concurrent Mark and Sweep (CMS), gumagamit ang ART ng generational collector na may ilang optimisasyon: moving collector (pag-compact ng heap), large object space (hiwalay na imbakan ng malalaking bagay), at concurrent compaction (parallel compaction).

Ang tipikal na GC pause sa ART ay 2–3 ms kumpara sa 5–10 ms sa Dalvik. Ito ay naging posible dahil sa ilang mekanismo. Una, gumagamit ang ART ng read-barrier sa halip ng stop-the-world para sa concurrent phases. Pangalawa, ang generational collector ay nagpoproseso lamang ng batang generation ng mga bagay sa karamihan ng cycles, hindi naaapektuhan ang buong heap. Pangatlo, ang large object space (LOS) ay inilalaan nang hiwalay at hindi lumalahok sa normal na GC cycles.

// Pag-activate ng GC logs para sa debugging
System.logV("ART", "GC trigger: allocation failed");

// Puwersahang tawag ng GC (hindi inirerekomenda sa production)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

Mga memory leak sa panahon ng ART

Sa kabila ng pinabuting GC, ang memory leak ay nananatiling isang napapanahong problema. Ang sanhi na partikular sa ART — pag-load ng native libraries sa pamamagitan ng JNI nang walang tamang pagpapalaya. Kung ang native code ay nag-aalokasyon ng memorya sa pamamagitan ng malloc ngunit hindi tumatawag ng free, hindi mapapalaya ng ART ang memorya na ito — nasa labas ito ng managed heap. Ang tool na AddressSanitizer sa Android NDK ay tumutulong sa pagtuklas ng mga ganitong leak.

ART vs Dalvik: paghahambing na pagsusuri

ART at Dalvik — dalawang fundamentally magkaibang implementasyon ng parehong gawain: pag-execute ng Android apps. Ang mga pagkakaiba ay nakakaapekto sa lahat ng antas: mula compilation hanggang memory management. Sa ibaba ay isang paghahambing batay sa mga pangunahing parameter ng performance at compatibility.

Ang pangunahing bentahe ng ART — pag-aalis ng JIT warm-up. Sa Dalvik, ang app ay maaaring bumagal sa unang 3–10 segundo habang nagko-compile ang JIT ng mga hot method. Sa ART, lahat ng method ay na-compile na sa native code (o iko-compile sa background). Ito ay lalong kapansin-pansin sa mga laro at app na may mabigat na UI: ang pagkakaiba sa fps ay maaaring umabot ng 15–20% pabor sa ART.

Compatibility

Lahat ng app na isinulat para sa Dalvik ay gumagana sa ART nang walang pagbabago. Ginagarantiyahan ng Google ang buong backward compatibility sa antas ng DEX bytecode. Exception — code na gumagamit ng Dalvik-specific internal API sa pamamagitan ng reflection: mga miyembro ng klase dalvik.system.DexFile na minarkahan ng @hide sa Android SDK. Ang naturang code ay dapat i-update upang gumamit ng public APIs.

Suporta sa Java 8 at desugaring

ART ang naging unang Android execution environment na may native na suporta sa Java 8 features. Mula Android 7.0, kasama sa ART ang desugaring — ang proseso ng pag-convert ng Java 8 constructs (lambda, method references, Stream API) sa katumbas na Java 7 code. Ito ay nagpapahintulot ng paggamit ng modern syntax nang walang pagkawala ng compatibility sa mas lumang device.

Ang desugaring ay ginagawa ng D8 compiler at gumagana tulad ng sumusunod. Ang source code na may lambda ay ginagawang synthetic method sa loob ng parehong klase, at ang lambda ay pinapalitan ng invoke-custom na tawag. Ang runtime ng ART ay sumusuporta sa invoke-custom instruction, na idinagdag lalo na para sa Java 8. Sa mga device na may Android 6.0 at mas mababa, ang lambdas ay dinedesugar sa anonymous classes.

// Java 8 lambda — desugaring sa ART
button.setOnClickListener(v -> handleClick(v));

// Pagkatapos ng desugaring (katumbas sa Java 7)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

Mga limitasyon ng desugaring

Hindi lahat ng Java 8 features ay sinusuportahan ng desugaring. Ang java.time API (petsa at oras) ay maa-access lamang sa pamamagitan ng desugar_jdk_libs — isang karagdagang library na idinadagdag sa build.gradle. Ang Stream API ay nangangailangan din ng desugar_jdk_libs. Ang java.util.function at Optional ay gumagana nang walang karagdagang dependencies. Ang buong suporta sa Java 8 ay available sa mga device na may Android 8.0 at mas bago nang walang desugaring.

Pag-optimize ng app para sa ART

Kahit na ang ART ay backward compatible, ang ilang optimization practices ay nagpapabuti ng performance partikular sa environment na ito. Ang pangunahing rekomendasyon — bawasan ang reflection. Ang ART ay nagko-compile ng mga method na nakikita sa compilation stage sa direktang tawag ng machine code. Ang Reflection ay pumipilit sa ART na gumawa ng karagdagang stubs, na nagpapabagal ng execution ng 10–15%.

Mula Android 9.0, lumitaw ang suporta para sa App Startup Optimization sa ART. Maaaring markahan ng developer ang mga initialization class sa manifest sa pamamagitan ng <initialization>, at pre-load ang mga ito ng ART sa pag-start ng app. Binabawasan nito ang oras ng pag-start ng 5–15% para sa mga app na may maraming plugin o library.

<!-- App Startup Optimization sa AndroidManifest.xml -->
<application>
    <profileable
        android:shell="true"
        android:enable="true" />
</application>

Pagsukat ng performance

Para sa pagsukat ng performance sa ART, gamitin ang systrace at perfetto. Ang Systrace ay nagpapakita ng oras ng compilation ng dex2oat, frequency ng GC, at bilis ng pag-render ng frame. Ang Perfetto ay nagbibigay ng mas detalyadong impormasyon: distribution ng thread, oras ng JNI transitions, pag-load ng native libraries. Pag-start: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm.