أخبار المنتجات

تحسين أداء Android: لمحة عن ميزة AutoFDO للنواة

مدّة القراءة: 4 دقائق
عرض الملف الشخصي لـ "تشارلز مونغر"
Yabin Cui مهندس برمجيات

نحن فريق سلسلة أدوات 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.

boosting_2.png

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

طريقة العمل: المسار

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

boosting_3.png

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

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

  • الأدوات والبيئة: نثبّت أحدث نسخة من صورة النواة على الأجهزة الاختبارية ونستخدم 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، نضمن تحسين أساس نظام التشغيل ليتناسب مع طريقة استخدامك لجهازك يوميًا.

من كتابة:
متابعة القراءة