نحن فريق سلسلة أدوات 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)، يسمح ذلك للبائعين بتطبيق تقنيات التحسين نفسها على برامج تشغيل الأجهزة الخاصة بهم.
• تغطية أوسع للملفات الشخصية: من المحتمل جمع ملفات شخصية من نطاق أوسع من رحلات المستخدم الرئيسية (CUJ) لتحسينها.

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