ART: ما هي، بيئة التشغيل وكيف تعمل

ما هي ART؟

Android Runtime (ART) هي بيئة تشغيل تطبيقات تقوم بترجمة رمز DEX الثنائي إلى كود آلة أصلي قبل التنفيذ. على عكس Dalvik، التي كانت تستخدم الترجمة في الوقت المناسب (JIT) أثناء التشغيل، تقوم ART بالترجمة المسبقة (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، التي كانت تعمل سابقًا على تحسينات Dalvik.

التغييرات المعمارية

تستخدم ART نفس الهندسة المعتمدة على السجلات مثل Dalvik، ولكن مع مترجم مُعاد تصميمه بالكامل. بدلاً من المفسر ومترجم JIT، تتضمن ART مترجم AOT dex2oat، الذي يحول ملفات DEX إلى ملفات ELF ثنائية أثناء التثبيت. ونتيجة لذلك، تبدأ التطبيقات على ART بأداء أصلي فوري، دون مرحلة تسخين.

هندسة ART: من Dalvik إلى البيئة الجديدة

ART حافظت على المبادئ الأساسية لـ Dalvik: عزل التطبيقات من خلال عمليات منفصلة، هندسة معتمدة على السجلات، ودعم تنسيق DEX. ومع ذلك، تمت إعادة كتابة التنفيذ الداخلي بالكامل. بدلاً من مفسر Dalvik، تتضمن ART ثلاثة أوضاع تنفيذ: مفسر، مترجم JIT، ومترجم AOT dex2oat. يعتمد اختيار الوضع على مرحلة دورة حياة التطبيق.

المكون الرئيسي لـ ART هو dex2oat (مترجم Android المحسن من Dalvik القابل للتنفيذ). يتم تشغيل هذه الأداة أثناء تثبيت التطبيق (منذ 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 للطرق النشطة. هذا يقلل من وقت التثبيت ومساحة التخزين.

يعمل ملف شخصي في الخلفية بالتوازي. يجمع إحصائيات التنفيذ: أي الطرق يتم استدعاؤها بشكل متكرر، أي فروع الكود يتم تنفيذها، أي الفئات يتم تحميلها. بعد تجميع بيانات كافية (عادةً بعد 2–3 عمليات تشغيل للتطبيق)، يقوم ART بتشغيل dex2oat في الخلفية ويترجم فقط الطرق النشطة المحددة إلى كود أصلي.

أوضاع الترجمة

ART تدعم عدة أوضاع ترجمة، تُدار عبر system_server. وضع “speed” يترجم جميع الطرق بـ AOT (أقصى أداء، تثبيت بطيء). وضع “speed-profile” يترجم فقط الطرق النشطة المحددة (توازن بين السرعة والحجم). وضع “verify” يتحقق فقط من الرمز الثنائي دون ترجمة (أقل مساحة، تفسير). افتراضيًا، يتم استخدام speed-profile — الأمثل لمعظم التطبيقات.

ملف تعريف ART

الملف الشخصي يجمع بيانات التنفيذ في ملفات .prof خاصة. يخزن كل تطبيق ملفه الشخصي في /data/misc/profiles/. عند الوصول إلى الحد الأدنى (عادةً 1000 عينة)، يقوم الملف الشخصي بتشغيل dex2oat لترجمة الطرق النشطة المحددة. يتم الاحتفاظ بالملفات الشخصية بين تحديثات التطبيق، مما يسرع إعادة التحسين بعد تحديثات OTA للنظام.

جمع القمامة في ART

جمع القمامة في ART تحسّن بشكل جذري مقارنة بـ Dalvik. بدلاً من Concurrent Mark and Sweep (CMS) أحادي الخيط، تستخدم ART مجمعًا أجياليًا مع عدة تحسينات: مجمع متحرك (ضغط الكومة)، مساحة الكائنات الكبيرة (تخزين منفصل للكائنات الكبيرة)، والضغط المتزامن (ضغط موازٍ).

فترة توقف GC النموذجية في ART هي 2–3 مللي ثانية مقارنة بـ 5–10 مللي ثانية في Dalvik. أصبح هذا ممكنًا بفضل عدة آليات. أولاً، تستخدم ART حاجز القراءة بدلاً من stop-the-world للمراحل المتزامنة. ثانيًا، يعالج المجمع الأجيالي فقط الجيل الشاب من الكائنات في معظم الدورات، دون لمس الكومة بأكملها. ثالثًا، يتم تخصيص مساحة الكائنات الكبيرة (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 تحرير هذه الذاكرة — فهي خارج الكومة المُدارة. تساعد أداة AddressSanitizer في Android NDK في تحديد هذه التسربات.

ART مقابل Dalvik: تحليل مقارن

ART و Dalvik هما تنفيذان مختلفان جوهريًا لنفس المهمة: تشغيل تطبيقات Android. تؤثر الاختلافات على جميع المستويات: من الترجمة إلى إدارة الذاكرة. فيما يلي مقارنة لمعايير الأداء والتوافق الرئيسية.

الميزة الرئيسية لـ ART هي إزالة تسخين JIT. على Dalvik، كان التطبيق قد يبطء في أول 3–10 ثوانٍ بينما يقوم JIT بترجمة الطرق النشطة. على ART، جميع الطرق مترجمة بالفعل إلى كود أصلي (أو ستُترجم في الخلفية). هذا ملحوظ بشكل خاص في الألعاب والتطبيقات ذات الواجهة الثقيلة: يمكن أن يصل فرق fps إلى 15–20% لصالح ART.

التوافق

جميع التطبيقات المكتوبة لـ Dalvik تعمل على ART بدون تغييرات. تضمن Google التوافق العكسي الكامل على مستوى رمز DEX الثنائي. الاستثناء هو الكود الذي يستخدم API داخلي خاص بـ Dalvik عبر الانعكاس: أعضاء فئة dalvik.system.DexFile المُعلمين بـ @hide في Android SDK. يجب تحديث هذا الكود لاستخدام API العامة.

دعم Java 8 وإزالة السكر

ART أصبحت أول بيئة تشغيل Android مع دعم أصلي لميزات Java 8. بدءًا من Android 7.0، تتضمن ART إزالة السكر — عملية تحويل بنيات Java 8 (lambdas، مراجع الطرق، Stream API) إلى كود Java 7 مكافئ. هذا يسمح باستخدام بناء جملة حديث دون فقدان التوافق مع الأجهزة القديمة.

يتم إزالة السكر بواسطة مترجم D8 ويعمل على النحو التالي. يتم تحويل الكود المصدري مع lambda إلى طريقة اصطناعية داخل نفس الفئة، ويتم استبدال lambda باستدعاء invoke-custom. يتضمن وقت تشغيل ART دعمًا لتعليمة invoke-custom، المضافة خصيصًا لـ Java 8. على الأجهزة التي تعمل بنظام Android 6.0 والإصدارات الأقدم، يتم تحويل lambdas إلى فئات مجهولة.

// Lambda Java 8 — إزالة السكر في ART
button.setOnClickListener(v -> handleClick(v));

// بعد إزالة السكر (ما يعادل Java 7)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

قيود إزالة السكر

ليست جميع ميزات Java 8 مدعومة بإزالة السكر. java.time API (التواريخ والوقت) متاحة فقط من خلال desugar_jdk_libs — مكتبة إضافية تُضاف في build.gradle. Stream API يتطلب أيضًا desugar_jdk_libs. java.util.function و Optional يعملان بدون تبعيات إضافية. الدعم الكامل لـ Java 8 متاح على الأجهزة التي تعمل بنظام Android 8.0 وما فوق بدون إزالة السكر.

تحسين التطبيقات لـ ART

على الرغم من أن ART متوافقة عكسيًا، إلا أن بعض ممارسات التحسين تحسن الأداء تحديدًا على هذه البيئة. التوصية الرئيسية هي تقليل الانعكاس. تقوم ART بترجمة الطرق المرئية في وقت الترجمة إلى استدعاءات كود آلة مباشرة. الانعكاس يجبر ART على توليد stubs إضافية، مما يبطئ التنفيذ بنسبة 10–15%.

بدءًا من Android 9.0، قدمت ART دعمًا لـ App Startup Optimization. يمكن للمطور وضع علامات على فئات التهيئة في البيان عبر <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.