- تقوم جوجل بإدخال تحسينات AutoFDO الموجهة بالملف الشخصي مباشرة في نواة نظام Android لتقليل الحمل الزائد لوحدة المعالجة المركزية واستهلاك الطاقة.
- تُساعد أنماط التنفيذ الواقعية من أكثر 100 تطبيق استخدامًا المُترجم على تفضيل مسارات التعليمات البرمجية الساخنة وتقليل أولوية المسارات الباردة.
- تُظهر الاختبارات الأولية أوقات تشغيل أسرع بنسبة 2.1% تقريبًا وعمليات تشغيل أسرع بنسبة 4.3% تقريبًا للتطبيقات الباردة، مع مكاسب إضافية في كفاءة الخلفية.
- يتم طرح AutoFDO في فروع Android kernel LTS android16-6.12 و android15-6.6 ومن المخطط توسيعه ليشمل Android 17 وما بعده.
يتلقى نظام أندرويد سلسلة من التغييرات الهادئة والبسيطة التي تهدف إلى جعل الهواتف تبدو أسرع مع إطالة عمر البطارية قليلاًبدلاً من الميزات الجديدة البراقة، تركز جوجل على كيفية اتخاذ نواة نظام التشغيل للقرارات كل جزء من الألف من الثانية في الخفاء.
تتمحور هذه الجهود حول تقنية تسمى AutoFDO، وهي اختصار لـ تم تطبيق التحسين التلقائي الموجه بالتعليقات على نواة نظام أندرويدمن خلال إعادة تشكيل كيفية تجميع النواة بناءً على بيانات الاستخدام الحقيقية، تحاول جوجل تقليل العمل المهدر لوحدة المعالجة المركزية، وتقليل الحمل الزائد في الخلفية، ومنح الأجهزة الحالية دفعة متواضعة ولكن ملحوظة في الاستجابة.
ما يفعله AutoFDO فعليًا في نواة نظام Android
أثناء عملية البناء العادية، يتعين على المترجم أن يقوم بـ آلاف القرارات الصغيرة حول كيفية ترتيب وضبط التعليمات البرمجية. إنه يخمن الفروع المحتملة، والوظائف التي يجب تضمينها، وكيفية ترتيب التعليمات في الذاكرة وما إلى ذلك، استنادًا إلى حد كبير إلى التلميحات الثابتة والأساليب الاستدلالية العامة.
تكمن المشكلة في أن هذه التخمينات لا تتطابق دائمًا مع ما يحدث بالفعل عند استخدام هاتفك. ويمكن لنظام التشغيل، الذي يمكنه تفسير ذلك، حوالي 40% من إجمالي وقت وحدة المعالجة المركزية في نظام أندرويد، قد يقضي دورات على مسارات التعليمات البرمجية التي نادراً ما يتم استخدامها بينما لا يتم تحسين المسارات المستخدمة بشكل متكرر بالقدر الكافي.
يقوم AutoFDO بعكس هذا النهج عن طريق تزويد المُصرّف ملفات تعريف مبنية على أنماط تنفيذ حقيقيةبدلاً من الاعتماد بشكل أساسي على النظرية، يتم توجيه عملية البناء من خلال كيفية عمل الكود فعليًا على الأجهزة، مما يسمح بتشكيل ملف النواة الثنائي حول أحمال العمل اليومية.
بالنسبة للمستخدمين، لا يظهر هذا كإعداد جديد أو قائمة. بل يظهر بشكل خفي كـ استجابة أسرع قليلاً عند تشغيل التطبيقات أو إعادة تشغيل الهاتفوكذلك تقليل وقت وحدة المعالجة المركزية المُستهلك في القرارات التي تُتخذ في الخلفية والتي لا يراها المستخدمون بشكل مباشر.
من التخمينات الثابتة إلى ملفات تعريف التنفيذ في العالم الحقيقي
تقليديًا، اعتمدت عملية التحسين الموجهة بالملفات الشخصية على ملفات ثنائية مُجهزة بأدوات لجمع البيانات أثناء عمليات تشغيل خاصة. هذا الأسلوب فعال، ولكنه قد يكون تدخليًا وقد لا يعكس الأداء الفعلي. كيف يستخدم الناس هواتفهم فعلياً يومياً. يتبع AutoFDO مسارًا أخف وزنًا يعتمد على أخذ العينات.
تستخدم جوجل أداة تحليل العينات لالتقاط سجل تفرعات وحدة المعالجة المركزية ومسارات التعليمات أثناء تشغيل نظام أندرويد لأحمال عمل واقعيةتكشف هذه العينات عن أجزاء النواة "الساخنة" (التي يتم تنفيذها بشكل متكرر) وأجزاء "الباردة" (التي نادراً ما يتم لمسها)، دون الحاجة إلى إعادة بناء كل شيء باستخدام أدوات ثقيلة.
بالنسبة للنواة تحديدًا، يتم توليد البيانات في بيئة معملية. يقوم المهندسون بإعادة تشغيل أحمال عمل نموذجية تتضمن أكثر 100 تطبيق شيوعًا على نظام أندرويد من مجموعة اختبارات التوافق. تم تصميم هذا المزيج لمحاكاة الاستخدام الحقيقي: فتح التطبيقات وإغلاقها، والتبديل بينها، ومزامنة الخلفية، والتواصل بين العمليات.
بمجرد جمعها، تخضع الآثار الخام لعملية عملية التجميع والتنظيفيتم دمج البيانات من عمليات تشغيل متعددة وأجهزة مختلفة، وتحويلها إلى تنسيق ملف تعريف LLVM AutoFDO القياسي، ثم تصفيتها بحيث تبقى الرموز والوظائف ذات الصلة فقط. غالبًا ما تُحذف الوظائف غير المستخدمة بكثرة من ملف التعريف لكي تعود إلى أساليب المُصرّف التقليدية بدلًا من التأثير سلبًا على عملية التحسين.
يُوجّه هذا الملف التعريفي المُعدّ بعناية عملية بناء نواة جديدة. وبفضل المعلومات الدقيقة حول مسارات التعليمات البرمجية الأكثر أهمية، يستطيع المُصرّف تضمين الإجراءات الحرجة بشكل أكثر فعالية، وترتيب التعليمات البرمجية الأكثر استخدامًا لتكون مُلائمة لذاكرة التخزين المؤقت، وتقليل أهمية الفروع قليلة الاستخدام. والنتيجة هي نواة يتماشى بشكل أفضل مع أحمال العمل التي تواجهها هواتف أندرويد فعليًا.
إلى أي مدى يمكن أن يصبح نظام أندرويد أسرع وأكثر كفاءة؟
الأرقام الأولية من الاختبارات الداخلية لشركة جوجل متواضعة ولكنها ملموسة. مع تطبيق AutoFDO على النواة، يتحسن وقت تشغيل الجهاز بنسبة 2.1% تقريبًالن يحول ذلك الهاتف البطيء إلى صاروخ، ولكنه قد يقلل قليلاً من وقت الانتظار في كل مرة تقوم فيها بإعادة التشغيل.
تكون المكاسب أكثر وضوحًا عند فتح التطبيقات من حالة "باردة" - أي عندما لا تكون موجودة بالفعل في الذاكرة. في هذه الحالة، يُحسّن AutoFDO الأداء بنسبة تقارب 10%. انخفاض بنسبة 4.3% في أوقات الإطلاق البارد، وهو أمر مفيد بشكل خاص للتطبيقات الثقيلة التي تعتمد على المكونات الأصلية وخدمات النواة.
إلى جانب هذه المقاييس الواضحة، تشير جوجل أيضًا إلى تحسينات في المجالات التي أقل وضوحاً لكنها لا تزال مهمةيُسهم كل ذلك في تحسين سلاسة جدولة العمليات في الخلفية، وتقليل استهلاك وحدة المعالجة المركزية في مهام النواة الروتينية، وتحسين إدارة عمليات النظام بشكل عام. كل هذا يُعطي انطباعًا بأن الجهاز أكثر استجابة، حتى وإن كان من الصعب تحديد تغيير جذري واحد.
لأن النواة يمكن أن تستهلك نسبة كبيرة من إجمالي سعة وحدة المعالجة المركزية، فإن حتى المكاسب التي تبلغ نسبة مئوية من رقم واحد تُترجم إلى الموارد المُحررة التي يمكن استخدامها بواسطة التطبيقات وواجهة المستخدم الخاصة بالنظاموفي الوقت نفسه، فإن تقليل عمل وحدة المعالجة المركزية غير الضروري يساعد حتماً في كفاءة الطاقة، وبالتالي تشعر البطارية ببعض الراحة دون أي تغييرات في الأجهزة.
تحرص جوجل على تقديم هذه المزايا على أنها تدريجية. لا ينبغي للمستخدمين أن يتوقعوا تحولاً جذرياً، بل تحولاً تدريجياً. تحسين مستمر في تجربة استخدام نظام أندرويد وسلوكه بمرور الوقتوخاصة عندما تتراكم العديد من هذه التحسينات معًا عبر الإصدارات.
الحفاظ على الاستقرار مع تغيير طريقة بناء النواة
يتمثل أحد الشواغل المتكررة في أي عملية تحسين موجهة بالملف الشخصي في ما إذا كانت تنطوي على مخاطر مخالفة السلوك المتوقع أو إدخال أخطاء خفيةفي حالة AutoFDO، تؤكد جوجل أن هذه التقنية تعدل كيفية قيام المترجم بتحديد أولويات التعليمات البرمجية وترتيبها، وليس منطق النواة نفسها.
يُوصف هذا النهج بأنه "متحفظ بطبيعته". وهذا يعني أن الوظائف التي لا يتم تمثيلها بشكل جيد في بيانات الملف الشخصي عالية الدقة تُركت لاستراتيجيات التحسين القياسية بدلاً من إعادة تشكيلها بشكل جذري، تتصرف المسارات الباردة أو التي نادراً ما يتم تنفيذها كما لو كانت في عملية بناء تقليدية، مما يقلل من احتمالية حدوث تراجعات في سيناريوهات غامضة.
قبل قبول الملفات التعريفية، تخضع لعدة عمليات تدقيق. يقوم المهندسون بتحليل محتوى الملف التعريفي - الوظائف الأكثر استخدامًا، وعدد العينات، والحجم الإجمالي - ومقارنته بالإصدارات السابقة. ثم يتم إنشاء صورة نواة جديدة، و تُجرى اختبارات قياس الأداء لضمان اتساق مكاسب الأداء وأن زمن الاستجابة أو معدل نقل البيانات لا يتدهور بشكل غير متوقع في أحمال العمل الرئيسية.
ليست هذه المرة الأولى التي تستخدم فيها جوجل تقنية AutoFDO. فقد تم بالفعل نشر هذه التقنية على نطاق واسع لـ مكتبات أندرويد الأساسية، ومكونات نظام التشغيل ChromeOS، وحتى البنية التحتية للخادم الداخلي. تعمل تلك التجربة السابقة كشبكة أمان، مما يشير إلى أن أسلوب التحسين نفسه ناضج، حتى لو كان تطبيقه على نواة نظام Android جديدًا نسبيًا.
والنتيجة هي أن تكامل AutoFDO مع نواة النظام مصمم لـ الحفاظ على الاستقرار الوظيفي مع تحقيق كفاءة إضافيةبالنسبة للمستخدمين النهائيين، يهدف التغيير إلى أن يكون غير مرئي من حيث الموثوقية، ولكنه مفيد بهدوء من حيث الأداء.
كيفية تحديث الملفات الشخصية ونشرها بمرور الوقت
سيصبح ملف تعريف ثابت واحد قديماً بسرعة لأن يتطور نظام أندرويد والتطبيقات وأنماط الاستخدامللحفاظ على فعالية AutoFDO، تتعامل جوجل مع إنشاء الملفات الشخصية كعملية مستمرة بدلاً من كونها مهمة لمرة واحدة.
يتم إعادة إنشاء ملفات تعريف صورة النواة العامة (GKI). قبل كل إصدار جديد من نواة LTSيتم إعادة تشغيل أحمال العمل المحدثة بناءً على الإصدارات الحالية لأفضل 100 تطبيق، وإعادة أخذ عينات البيانات، وإعادة بناء الملفات الشخصية والتحقق من صحتها. تضمن هذه العملية المستمرة أن تتبع إصدارات النواة الأحدث كيفية استخدام الأشخاص لنظام أندرويد في ذلك الوقت.
ومن المثير للاهتمام أن جوجل تشير إلى أن تُظهر أحمال العمل المُولّدة في المختبر تشابهاً بنسبة 85% تقريباً. إلى أنماط التنفيذ الملتقطة من أساطيل الأجهزة الداخلية. يشير هذا المستوى من التداخل إلى أن النهج المُصنّع قريب بما يكفي من السلوك الواقعي ليكون مفيدًا في توجيه عملية التحسين، مع كونه في الوقت نفسه أسهل في التحكم والتحديث.
ولأن هذه الملفات التعريفية تتبع تنسيق LLVM AutoFDO القياسي، فإنها تتصل مباشرة بـ أدوات التحليل الحالية مثل llvm-profdataيمكن لفرق الهندسة فحص الوظائف الساخنة، والتعمق في أنماط الاستدعاء، والتحقق من أن جهد التحسين يُبذل حيثما يكون ذلك مهمًا بالفعل.
على مدار عدة دورات، تحوّل دورة التنميط وإعادة البناء المتكررة هذه AutoFDO إلى آلية ضبط مستمرة للنواةبدلاً من تعديل واحد محصور بإصدار واحد من نظام أندرويد.
AutoFDO عبر مجموعة أدوات Android
يعتمد التحول إلى AutoFDO في نواة النظام على عمل جارٍ في أماكن أخرى من بنية نظام أندرويد منذ فترة. دعم AutoFDO هو مدمج في نظام بناء Android المستخدم بواسطة AOSP، وخاصة بالنسبة للوحدات الأصلية التي تعتمد على تعريفات البناء على نمط المخطط.
بالنسبة للعديد من المكتبات والبرامج الثنائية الحساسة للأداء ضمن نظام أندرويد مفتوح المصدر (AOSP)، تم بالفعل جمع بيانات تعريفية من هواتف وأجهزة لوحية حقيقية. هذه تتوفر ملفات تعريف AutoFDO الجاهزة بجانب المصدر. ويمكن تفعيلها ببساطة عن طريق تبديل علامات البناء المقابلة، لذلك فإن مصنعي الأجهزة الذين يتابعون AOSP عن كثب يرثون التحسينات بأقل قدر من العمل الإضافي.
يستطيع إطار عمل تحليل الأداء في نظام أندرويد جمع البيانات عبر بنى معالجة مركزية متعددة، بما في ذلك x86، x86_64، ARM و ARM64طالما أن عبء العمل تمثيلي، يمكن أحيانًا تكييف ملف تعريف تم إنشاؤه على بنية واحدة مع بنية أخرى، مما يبسط عملية النشر عبر تشكيلات الأجهزة غير المتجانسة.
يُنصح المطورون الذين يحتاجون إلى تحسينات أكثر تخصيصًا - على سبيل المثال، عند إضافة مكوناتهم الأصلية أو تعديل المكونات الموجودة - بـ جمع البيانات التعريفية مباشرة من أجهزة التطوير أو الاختبارتساعد أدوات مثل simpleperf والأدوات المساعدة ذات الصلة في التقاط العينات اللازمة دون تعطيل التشغيل العادي بشكل كبير.
باختصار، لا يُعدّ AutoFDO مجرد حيلة في نواة النظام. بل يندرج ضمن استراتيجية أوسع حيث يتم إعادة تجميع أهم مكونات نظام أندرويد باستمرار بالاستعانة ببيانات الاستخدام الحقيقية.بدلاً من الاعتماد فقط على افتراضات ثابتة حول الأداء.
أين ومتى ستُطبّق هذه التحسينات الأساسية؟
تُقدّم جوجل أولاً إصدارات نواة تعمل بتقنية AutoFDO في فروع الدعم طويل الأمد (LTS) لنواة نظام التشغيل أندرويد، وتحديداً android16-6.12 و android15-6.6. تعمل هذه الفروع كأساس للعديد من الشركات المصنعة، التي تقوم بعد ذلك بإضافة تغييراتها الخاصة وتعديلاتها الخاصة بالأجهزة.
كما أوضحت الشركة خططًا لتوسيع استخدام AutoFDO ليشمل إصدارات GKI المستقبلية مثل android17-6.18مع شحن الأجهزة الجديدة بهذه النواة - ومع تلقي الهواتف الحالية تحديثات تتضمن قواعد LTS الأحدث - يجب أن يبدأ المزيد من المستخدمين في الاستفادة من السلوك المحسن.
وتتطلع جوجل إلى المستقبل، وتستكشف طرقًا لـ توسيع نطاق تغطية AutoFDO ليشمل ما هو أبعد من الملف الثنائي الرئيسي لنظام vmlinuxيشمل ذلك تطبيق تحسينات مُوجَّهة بالملفات التعريفية على وحدات GKI، وفي نهاية المطاف، على وحدات الموردين المبنية باستخدام حزمة تطوير برامج التشغيل. سيتيح هذا لشركاء الأجهزة تطبيق تقنيات التحليل نفسها على برامج التشغيل الخاصة بهم، مما ينشر الفوائد على نطاق أوسع في النظام البيئي.
تتمثل الرؤية طويلة المدى في أن عمليات البناء التي تعمل بتقنية AutoFDO ستؤثر على جزء متزايد من النواة ووحداتها. من كود الجدولة الأساسي إلى المكونات الخاصة بالجهازومع ازدياد هذا النطاق، قد يصبح التأثير التراكمي على الاستجابة والكفاءة أكثر وضوحًا، حتى لو كان كل تغيير فردي طفيفًا.
كل هذا يُشكل تحولاً هادئاً ولكنه هام في كيفية ضبط نظام أندرويد على أدنى المستويات. من خلال السماح لأنماط التنفيذ الواقعية بتوجيه المُترجم، تهدف جوجل إلى هواتف تبدو أسرع قليلاً، وتستهلك دورات معالجة أقل، وتجعل استخدام أفضل قليلاً لكل مللي أمبير ساعة من البطارية كل ذلك دون أن يضطر المستخدمون إلى تغيير الأجهزة أو البحث في الإعدادات.
