نحن فريق سلسلة أدوات Android LLVM. من أهم أولوياتنا تحسين أداء Android من خلال تقنيات التحسين في نظام LLVM. نبحث باستمرار عن طرق لجعل Android أسرع وأكثر سلاسة وكفاءة. على الرغم من أنّ معظم أعمال التحسين التي نجريها تحدث في مساحة المستخدِم، تظل النواة هي قلب النظام. يسرّنا اليوم أن نشاركك كيف نقدّم ميزة التحسين التلقائي المستند إلى الملاحظات (AutoFDO) إلى نواة Android لتحقيق تحسينات كبيرة في الأداء للمستخدمين.

ما هي ميزة AutoFDO؟

أثناء إنشاء برنامج عادي، يتخذ المحوّل البرمجي آلاف القرارات الصغيرة، مثل ما إذا كان سيتم تضمين دالة وأيّ فرع من الفروع الشرطية من المرجّح أن يتم تنفيذه، استنادًا إلى تلميحات الرمز البرمجي الثابتة.على الرغم من أنّ هذه الإرشادات مفيدة، فإنّها لا تتنبأ دائمًا بدقة بتنفيذ الرمز البرمجي أثناء استخدام الهاتف في العالم الحقيقي.

تغيّر ميزة AutoFDO ذلك من خلال استخدام أنماط التنفيذ في العالم الحقيقي لتوجيه المحوّل البرمجي. تمثّل هذه الأنماط مسارات تنفيذ التعليمات الأكثر شيوعًا التي يتخذها الرمز البرمجي أثناء الاستخدام الفعلي، ويتم تسجيلها من خلال تتبُّع سجلّ التفرّعات في وحدة المعالجة المركزية. على الرغم من أنّه يمكن جمع هذه البيانات من أجهزة الأسطول، فإنّنا نركّبها في بيئة معملية للنواة باستخدام أحمال عمل تمثيلية، مثل تشغيل أهم 100 تطبيق شائع. نستخدم أداة تتبُّع الأداء المستندة إلى أخذ العيّنات لجمع هذه البيانات، وتحديد أجزاء الرمز البرمجي التي يتم استخدامها بشكل متكرر ("ساخنة") وأجزاء الرمز البرمجي التي لا يتم استخدامها بشكل متكرر ("باردة").عند إعادة إنشاء النواة باستخدام هذه الملفات الشخصية، يمكن للمحوّل البرمجي اتخاذ قرارات تحسين أكثر ذكاءً ومخصّصة لأحمال عمل Android الفعلية.

لفهم تأثير هذا التحسين، يُرجى الاطّلاع على الحقائق الرئيسية التالية:

• في Android، تمثّل النواة حوالي% 40 من وقت وحدة المعالجة المركزية.
• نستخدم حاليًا ميزة AutoFDO لتحسين الملفات التنفيذية والمكتبات الأصلية في مساحة المستخدِم، ما يحقّق تحسينًا بنسبة% 4 تقريبًا في وقت تشغيل التطبيق البارد وتقليل وقت التشغيل بنسبة% 1.

تحسينات الأداء في العالم الحقيقي

لقد حقّقنا تحسينات مذهلة في مقاييس Android الرئيسية من خلال الاستفادة من الملفات الشخصية من البيئات المعملية الخاضعة للرقابة. تم جمع هذه الملفات الشخصية باستخدام عملية الزحف إلى التطبيقات وتشغيلها، وتم قياسها على أجهزة Pixel التي تعمل بنواة 6.1 و6.6 و6.12.

في ما يلي التحسينات الأكثر وضوحًا. يمكنك الاطّلاع على تفاصيل الملفات الشخصية لميزة AutoFDO لإصدارات النواة هذه في مستودعات نواة Android المعنيّة لنواة android16-6.12 ونواة android15-6.6.

هذه ليست مجرد أرقام نظرية. إنّها تعني واجهة أكثر سرعة، وتبديلًا أسرع بين التطبيقات، وعمر بطارية أطول، وجهازًا أكثر استجابة بشكل عام للمستخدم النهائي.

طريقة العمل: مسار البيانات

تتضمّن استراتيجية النشر مسار بيانات متطوّرًا لضمان بقاء الملفات الشخصية ذات صلة واستقرار الأداء.

الخطوة 1: جمع الملفات الشخصية

على الرغم من أنّنا نعتمد على أسطول الاختبار الداخلي لإنشاء ملفات شخصية للثنائيات في مساحة المستخدِم، فقد انتقلنا إلى بيئة معملية خاضعة للرقابة لصورة النواة العامة (GKI). يسمح فصل عملية إنشاء الملفات الشخصية عن دورة إصدار الجهاز بإجراء تحديثات مرنة وفورية بغض النظر عن إصدارات النواة المنشورة. والأهم من ذلك، تؤكّد الاختبارات أنّ هذه البيانات المستندة إلى المعمل تحقّق تحسينات في الأداء مماثلة لتلك التي تحقّقها أساطيل الأجهزة في العالم الحقيقي.

• الأدوات والبيئة: نثبّت ذاكرة ROM على أجهزة الاختبار باستخدام أحدث صورة للنواة ونستخدم simpleperf لتسجيل عمليات تنفيذ التعليمات. تعتمد هذه العملية على إمكانات الأجهزة لتسجيل سجلّ التفرّعات، وتحديدًا استخدام  ARM Embedded Trace Extension (ETE) و ARM Trace Buffer Extension (TRBE) على أجهزة Pixel.
• أحمال العمل: ننشئ حمل عمل تمثيليًا باستخدام أهم 100 تطبيق شائع من مجموعة أدوات اختبار توافق تطبيقات Android (C-Suite). لجمع البيانات الأكثر دقة، نركّز على ما يلي:
  • تشغيل التطبيق: تحسين الأداء للحد من التأخيرات الأكثر وضوحًا للمستخدم
  • الزحف إلى التطبيقات المستند إلى الذكاء الاصطناعي: محاكاة تفاعلات المستخدم المتجاورة والمتطورة
  • المراقبة على مستوى النظام: تسجيل أنشطة التطبيق التي تعمل في المقدّمة، بالإضافة إلى أحمال العمل الأساسية في الخلفية وعمليات الاتصال بين العمليات
• التحقّق من الصحة: يُظهر حمل العمل المُركّب هذا تشابهًا بنسبة% 85 مع أنماط التنفيذ التي تم جمعها من أسطول الأجهزة الداخلي.
• البيانات المستهدَفة: من خلال تكرار هذه الاختبارات بشكل كافٍ، نسجّل أنماط تنفيذ عالية الدقة تمثّل بدقة تفاعل المستخدم في العالم الحقيقي مع التطبيقات الأكثر شيوعًا. علاوة على ذلك، يتيح لنا إطار العمل القابل للتوسيع هذا دمج أحمال العمل ومقاييس الأداء الإضافية بسلاسة لتوسيع نطاق التغطية.

الخطوة 2: معالجة الملفات الشخصية

نعالج بيانات التتبُّع الأولية بعد ذلك لضمان نظافتها وفعاليتها وجاهزيتها للمحوّل البرمجي.

• التجميع: نجمع البيانات من عمليات الاختبار المتعددة والأجهزة في عرض نظام واحد.
• التحويل: نحن نحوّل عمليات التتبُّع الأولية إلى تنسيق الملف الشخصي لميزة AutoFDO، ونزيل الرموز غير المرغوب فيها حسب الحاجة.
• اقتطاع الملف الشخصي: نقتطع الملفات الشخصية لإزالة بيانات الدوال "الباردة"، ما يسمح لها باستخدام التحسين العادي. يمنع ذلك حدوث تراجعات في الرمز البرمجي الذي نادرًا ما يتم استخدامه ويتجنّب الزيادات غير الضرورية في حجم الثنائيات.

الخطوة 3: اختبار الملفات الشخصية

قبل النشر، تخضع الملفات الشخصية لعملية تحقّق صارمة لضمان تحقيق تحسينات متّسقة في الأداء بدون أي مخاطر على الاستقرار.

• تحليل الملف الشخصي والثنائيات: نقارن بدقة محتوى الملف الشخصي الجديد (بما في ذلك الدوال الساخنة وعدد العيّنات وحجم الملف الشخصي) بالإصدارات السابقة. نستخدم أيضًا الملف الشخصي لإنشاء صورة نواة جديدة، ونحلّل البرامج الثنائية لضمان أنّ التغييرات في قسم النص تتّسق مع التوقعات.
• التحقّق من الأداء: نُجري معايير مستهدَفة على صورة النواة الجديدة. يؤكّد ذلك أنّها تحافظ على تحسينات الأداء التي تم تحديدها من خلال الخطوط الأساسية السابقة.

التحديثات المستمرة

يحدث "انحراف" للرمز البرمجي بشكل طبيعي بمرور الوقت، لذا سيفقد الملف الشخصي الثابت فعاليته في النهاية. للحفاظ على أعلى مستوى من الأداء، نُشغّل مسار البيانات باستمرار لإجراء تحديثات منتظمة:

• إعادة التحميل المنتظمة: نعيد تحميل الملفات الشخصية في فروع الدعم طويل الأمد (LTS) لنواة Android قبل كل إصدار من GKI، ما يضمن أنّ كل عملية إنشاء تتضمّن أحدث بيانات الملف الشخصي.
• التوسيع المستقبلي: نقدّم حاليًا هذه التحديثات إلى الفرعَين android16-6.12 وandroid15-6.6 وسنوسّع نطاق الدعم ليشمل إصدارات GKI الأحدث، مثل android17-6.18 القادم.

ضمان الاستقرار

من الأسئلة الشائعة حول التحسين المستند إلى الملف الشخصي ما إذا كان يؤدي إلى مخاطر على الاستقرار. بما أنّ ميزة AutoFDO تؤثر بشكل أساسي في إرشادات المحوّل البرمجي، مثل تضمين الدوال وتنسيق الرمز البرمجي، بدلاً من تغيير منطق الرمز البرمجي المصدر، فإنّها تحافظ على سلامة وظائف النواة. لقد تم إثبات فعالية هذه التكنولوجيا على نطاق واسع، حيث إنّها تعمل كتحسين عادي لمكتبات نظام Android الأساسي وChromeOS والبنية الأساسية لخوادم Google لسنوات.

لضمان سلوك متّسق بشكل أكبر، نطبّق استراتيجية "متحفّظة تلقائيًا". يتم تحسين الدوال التي لم يتم تسجيلها في ملفاتنا الشخصية عالية الدقة باستخدام طرق المحوّل البرمجي العادية. يضمن ذلك أنّ الأجزاء "الباردة" أو التي نادرًا ما يتم تنفيذها من النواة تتصرف تمامًا كما تفعل في عملية إنشاء عادية، ما يمنع حدوث تراجعات في الأداء أو سلوكيات غير متوقعة في الحالات القصوى.

العمل للمستقبل

نحن بصدد نشر ميزة AutoFDO في الفرعَين android16-6.12 وandroid15-6.6. بالإضافة إلى عملية النشر الأولية هذه، نرى العديد من الطرق الواعدة لتعزيز التكنولوجيا بشكل أكبر:

• نطاق وصول أوسع: نتطلّع إلى تفعيل ملفات AutoFDO الشخصية على إصدارات أحدث من إصدار النواة GKI وأهداف إنشاء إضافية بخلاف الدعم aarch64 الحالي.
• تحسين وحدات GKI: يركّز التحسين حاليًا على ثنائي النواة الرئيسي (vmlinux). قد يؤدي توسيع نطاق ميزة AutoFDO ليشمل وحدات GKI إلى تحقيق تحسينات في الأداء لجزء أكبر من النظام الفرعي للنواة.
• دعم وحدات البائعين: يهمّنا أيضًا دعم ميزة AutoFDO لوحدات البائعين التي تم إنشاؤها باستخدام "حزمة تطوير برامج التشغيل" (DDK). بما أنّ الدعم متاح حاليًا في نظام الإنشاء (Kleaf) وأدوات إنشاء الملفات الشخصية (simpleperf)، يتيح ذلك للبائعين تطبيق تقنيات التحسين نفسها على برامج تشغيل الأجهزة الخاصة بهم.
• تغطية أوسع للملفات الشخصية: من المحتمل جمع الملفات الشخصية من نطاق أوسع من رحلات المستخدمين الأساسية (CUJs) لتحسينها.

من خلال تقديم ميزة AutoFDO إلى نواة Android، نضمن تحسين الأساس نفسه لنظام التشغيل بالطريقة التي تستخدم بها جهازك كل يوم.