ART: چیست، محیط اجرا و چگونه کار می‌کند

ART چیست؟

Android Runtime (ART) — محیط اجرای برنامه‌ای است که بایت‌کد DEX را قبل از اجرا به کد ماشین بومی کامپایل می‌کند. بر خلاف Dalvik که از کامپایل Just-In-Time در حین اجرا استفاده می‌کرد، ART کامپایل Ahead-Of-Time (AOT) را هنگام نصب APK انجام می‌دهد. این تغییر اساسی معماری منجر به افزایش قابل توجه سرعت برنامه‌ها و کاهش مصرف انرژی شد.

ART اولین بار به عنوان یک گزینه آزمایشی در Android 4.4 KitKat ظاهر شد. توسعه‌دهندگان می‌توانستند آن را در تنظیمات توسعه‌دهندگان فعال کرده و برنامه‌های خود را آزمایش کنند. در Android 5.0 Lollipop، ART به محیط اجرای پیش‌فرض تبدیل شد و Dalvik به طور کامل از پلتفرم حذف شد. تا زمان انتشار Android 7.0 Nougat، ART حالت کامپایل هیبریدی را دریافت کرد.

تاریخچه توسعه

تصمیم برای جایگزینی Dalvik با ART ناگهانی نبود. کار بر روی محیط جدید در سال 2012 آغاز شد، زمانی که Google محدودیت‌های رویکرد JIT را تشخیص داد. اهداف اصلی: تسریع راه‌اندازی برنامه‌ها، کاهش بار پردازنده و کاهش مصرف انرژی. تیم Android Runtime Group که قبلاً روی بهینه‌سازی‌های Dalvik کار کرده بود، مسئولیت توسعه را بر عهده داشت.

تغییرات معماری

ART از همان معماری ثباتی Dalvik استفاده می‌کند، اما با کامپایلری کاملاً بازطراحی‌شده. به جای مفسر و کامپایلر JIT، ART شامل کامپایلر AOT dex2oat است که فایل‌های DEX را هنگام نصب به باینری‌های ELF تبدیل می‌کند. در نتیجه، برنامه در ART بلافاصله با عملکرد بومی و بدون فاز گرم‌شدن اجرا می‌شود.

معماری ART: از Dalvik تا محیط جدید

ART اصول کلیدی Dalvik را حفظ کرد: ایزوله‌سازی برنامه‌ها از طریق فرآیندهای جداگانه، معماری ثباتی و پشتیبانی از فرمت DEX. با این حال، پیاده‌سازی داخلی به طور کامل بازنویسی شد. به جای مفسر Dalvik، ART شامل سه حالت اجرایی است: مفسر، کامپایلر JIT و کامپایلر AOT dex2oat. انتخاب حالت به مرحله چرخه حیات برنامه بستگی دارد.

جزء کلیدی ART — dex2oat (dalvik executable to optimized android translator) است. این ابزار هنگام نصب برنامه (از Android 7.0 — همچنین هنگام بهینه‌سازی پس‌زمینه) اجرا می‌شود. dex2oat فایل‌های DEX را از APK می‌خواند، بایت‌کد را بهینه می‌کند و فایل OAT — یک باینری ELF با کد بومی تولید می‌کند. فایل‌های OAT در دایرکتوری /data/dalvik-cache/ ذخیره می‌شوند.

# بررسی فایل‌های OAT روی دستگاه
adb shell ls -la /data/dalvik-cache/arm64/

# کامپایل مجدد اجباری برنامه
adb shell cmd package compile -m speed com.example.app

اجزای ART

سیستم ART از چندین ماژول به هم مرتبط تشکیل شده است. کامپایلر dex2oat مسئول تولید کد بومی است. جمع‌آورنده زباله (GC) آزادسازی حافظه را مدیریت می‌کند. مفسر کدهای کم‌استفاده را بدون کامپایل اجرا می‌کند. پروفایلر متدهای داغ را برای کامپایل هیبریدی ردیابی می‌کند. هر ماژول می‌تواند مستقل کار کند که ART را انعطاف‌پذیر و مقیاس‌پذیر می‌کند.

کامپایل هیبریدی: JIT + AOT + پروفایل‌گیری

از Android 7.0 Nougat، ART از رویکرد هیبریدی برای کامپایل استفاده می‌کند که مزایای JIT و AOT را ترکیب می‌کند. هنگام نصب برنامه، ART دیگر کامپایل کامل AOT را انجام نمی‌دهد — در عوض، برنامه در حالت تفسیری با کامپایل JIT متدهای داغ اجرا می‌شود. این کار زمان نصب و فضای اشغال‌شده را کاهش می‌دهد.

به صورت موازی، پروفایلر پس‌زمینه (background profiler) کار می‌کند. آمار اجرا را جمع‌آوری می‌کند: کدام متدها بیشتر فراخوانی می‌شوند، کدام شاخه‌های کد اجرا می‌شوند، کدام کلاس‌ها بارگذاری می‌شوند. پس از جمع‌آوری داده‌های کافی (معمولاً پس از 2–3 بار اجرای برنامه)، ART dex2oat را در پس‌زمینه اجرا کرده و فقط متدهای داغ پروفایل‌شده را به کد بومی کامپایل می‌کند.

حالت‌های کامپایل

ART از چندین حالت کامپایل پشتیبانی می‌کند که از طریق system_server مدیریت می‌شوند. حالت "speed" همه متدها را به AOT کامپایل می‌کند (حداکثر عملکرد، نصب طولانی). حالت "speed-profile" فقط متدهای داغ پروفایل‌شده را کامپایل می‌کند (تعادل سرعت و اندازه). حالت "verify" فقط بایت‌کد را بدون کامپایل تأیید می‌کند (حداقل فضا، تفسیر). به طور پیش‌فرض از speed-profile استفاده می‌شود — optimum برای اکثر برنامه‌ها.

پروفایلر ART

پروفایلر داده‌های اجرا را در فایل‌های .prof مخصوص جمع‌آوری می‌کند. هر برنامه پروفایل خود را در /data/misc/profiles/ ذخیره می‌کند. پس از رسیدن به آستانه (معمولاً 1000 نمونه)، پروفایلر dex2oat را برای کامپایل متدهای داغ شناسایی‌شده اجرا می‌کند. پروفایل‌ها بین به‌روزرسانی‌های برنامه حفظ می‌شوند که بهینه‌سازی مجدد را پس از به‌روزرسانی‌های OTA سیستم تسریع می‌کند.

جمع‌آوری زباله در ART

جمع‌آوری زباله در ART در مقایسه با Dalvik به طور اساسی بهبود یافته است. به جای Concurrent Mark and Sweep (CMS) تک‌رشته‌ای، ART از جمع‌آورنده نسلی با چندین بهینه‌سازی استفاده می‌کند: moving collector (فشرده‌سازی heap)، large object space (ذخیره‌سازی جداگانه اشیاء بزرگ) و concurrent compaction (فشرده‌سازی موازی).

مکث معمول GC در ART 2–3 میلی‌ثانیه در مقابل 5–10 میلی‌ثانیه در Dalvik است. این امر به لطف چندین مکانیزم ممکن شده است. اولاً، ART به جای stop-the-world برای فازهای concurrent از read-barrier استفاده می‌کند. ثانیاً، جمع‌آورنده نسلی در بیشتر چرخه‌ها فقط نسل جوان اشیاء را پردازش می‌کند و کل heap را تحت تأثیر قرار نمی‌دهد. ثالثاً، large object space (LOS) به طور جداگانه تخصیص داده می‌شود و در چرخه‌های معمول GC شرکت نمی‌کند.

// فعال کردن لاگ‌های GC برای اشکال‌زدایی
System.logV("ART", "GC trigger: allocation failed");

// فراخوانی اجباری GC (در تولید توصیه نمی‌شود)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

نشت حافظه در عصر ART

علیرغم GC بهبودیافته، نشت حافظه همچنان یک مشکل رایج است. علت خاص ART — بارگذاری کتابخانه‌های بومی از طریق JNI بدون آزادسازی صحیح. اگر کد بومی حافظه را از طریق malloc تخصیص دهد اما free را فراخوانی نکند، ART نمی‌تواند این حافظه را آزاد کند — خارج از heap مدیریت‌شده قرار دارد. ابزار AddressSanitizer در Android NDK به شناسایی چنین نشت‌هایی کمک می‌کند.

ART در مقابل Dalvik: تحلیل مقایسه‌ای

ART و Dalvik دو پیاده‌سازی اساساً متفاوت از یک وظیفه هستند: اجرای برنامه‌های Android. تفاوت‌ها تمام سطوح را دربرمی‌گیرد: از کامپایل تا مدیریت حافظه. در زیر مقایسه‌ای بر اساس پارامترهای کلیدی عملکرد و سازگاری ارائه شده است.

مزیت اصلی ART — حذف گرم‌شدن JIT است. در Dalvik، برنامه می‌توانست 3–10 ثانیه اول کند کار کند تا JIT متدهای داغ را کامپایل کند. در ART، همه متدها از قبل به کد بومی کامپایل شده‌اند (یا در پس‌زمینه کامپایل خواهند شد). این امر به ویژه در بازی‌ها و برنامه‌های با UI سنگین قابل توجه است: تفاوت در fps می‌تواند به 15–20% به نفع ART برسد.

سازگاری

تمام برنامه‌های نوشته شده برای Dalvik روی ART بدون تغییر کار می‌کنند. Google سازگاری کامل معکوس را در سطح بایت‌کد DEX تضمین می‌کند. استثنا — کدی که از API داخلی مخصوص Dalvik از طریق بازتاب استفاده می‌کند: اعضای کلاس dalvik.system.DexFile که با @hide در Android SDK مشخص شده‌اند. چنین کدی باید برای استفاده از APIهای عمومی به‌روزرسانی شود.

پشتیبانی از Java 8 و desugaring

ART اولین محیط اجرای Android با پشتیبانی بومی از ویژگی‌های Java 8 شد. از Android 7.0، ART شامل desugaring — فرآیند تبدیل ساختارهای Java 8 (lambdas، method references، Stream API) به کد معادل Java 7 است. این امکان استفاده از نحو مدرن را بدون از دست دادن سازگاری با دستگاه‌های قدیمی فراهم می‌کند.

Desugaring توسط کامپایلر D8 انجام می‌شود و به صورت زیر کار می‌کند. کد منبع با lambda به یک متد مصنوعی در همان کلاس تبدیل می‌شود و lambda با فراخوانی invoke-custom جایگزین می‌شود. محیط ART از دستورالعمل invoke-custom که به طور ویژه برای Java 8 اضافه شده پشتیبانی می‌کند. در دستگاه‌های با Android 6.0 و پایین‌تر، lambdas به کلاس‌های ناشناس desugar می‌شوند.

// Lambda جاوا ۸ — desugaring در ART
button.setOnClickListener(v -> handleClick(v));

// پس از desugaring (معادل در جاوا ۷)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

محدودیت‌های desugaring

همه ویژگی‌های Java 8 توسط desugaring پشتیبانی نمی‌شوند. API java.time (تاریخ و زمان) فقط از طریق desugar_jdk_libs — کتابخانه اضافی که در build.gradle اضافه می‌شود — قابل دسترسی است. Stream API نیز به desugar_jdk_libs نیاز دارد. java.util.function و Optional بدون وابستگی‌های اضافی کار می‌کنند. پشتیبانی کامل از Java 8 در دستگاه‌های با Android 8.0 و بالاتر بدون desugaring در دسترس است.

بهینه‌سازی برنامه‌ها برای ART

اگرچه ART سازگار معکوس است، برخی روش‌های بهینه‌سازی عملکرد را دقیقاً در این محیط بهبود می‌بخشند. توصیه اصلی — به حداقل رساندن بازتاب (reflection) است. ART متدهایی را که در مرحله کامپایل قابل مشاهده هستند به فراخوانی مستقیم کد ماشین کامپایل می‌کند. بازتاب ART را مجبور به تولید stubهای اضافی می‌کند که اجرا را 10–15% کند می‌کند.

از Android 9.0، پشتیبانی از App Startup Optimization در ART ظاهر شد. توسعه‌دهنده می‌تواند کلاس‌های مقداردهی اولیه را در مانیفست از طریق <initialization> علامت‌گذاری کند و ART آن‌ها را هنگام راه‌اندازی برنامه پیش‌بارگذاری می‌کند. این کار زمان راه‌اندازی را برای برنامه‌های با تعداد زیادی پلاگین یا کتابخانه 5–15% کاهش می‌دهد.

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

بررسی عملکرد

برای اندازه‌گیری عملکرد روی ART از systrace و perfetto استفاده کنید. Systrace زمان کامپایل dex2oat، فرکانس GC و سرعت رندر فریم را نشان می‌دهد. Perfetto اطلاعات دقیق‌تری ارائه می‌دهد: توزیع رشته‌ها، زمان انتقال JNI، بارگذاری کتابخانه‌های بومی. اجرا: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm.