نحن فريق سلسلة أدوات 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، نضمن تحسين الأساس المتين لنظام التشغيل بالطريقة التي تستخدم بها جهازك كل يوم.