شركة Grab تقلِّل أخطاء ANR بنسبة% 32 وتحسِّن وقت بدء التشغيل بنسبة% 35 باستخدام أداة R8 وتحسين الأداء المستند إلى الملف الشخصي

‫Grab هو التطبيق الشامل الرائد في جنوب شرق آسيا، ويقدّم خدمات التوصيل والتنقّل والخدمات المالية لملايين المستخدمين في ثمانية بلدان من خلال تطبيق واحد. ومع قاعدة رموز برمجية عمرها 10 سنوات تحتوي على أكثر من 10 ملايين سطر من الرموز البرمجية ومئات المكتبات التابعة لجهات خارجية  تم إنشاؤها باستخدام إعدادات Bazel وGradle المختلطة، واجه فريق Grab ثلاثة تحديات متزايدة: ارتفاع معدلات أخطاء "التطبيق لا يستجيب" (ANR)، وحجم التطبيق الذي استمر في النمو مع إضافة التطبيق الشامل لخدمات جديدة، ووقت بدء التشغيل الذي كان يزداد ببطء عامًا بعد عام.  من خلال تفعيل تحسين R8، وتحسين قواعد الاحتفاظ بالبيانات، وتنفيذ "الملفات الشخصية للمرجع" و"الملفات الشخصية لبدء التشغيل"، تمكّن تطبيق Grab من خفض نسبة أخطاء ANR التي لاحظها المستخدمون بمقدار %32، وتقليل حجم تنزيل التطبيق بنسبة %30 تقريبًا، وتحسين وقت بدء التشغيل بمقدار %35.

القضاء على الارتفاعات المفاجئة في أخطاء ANR بعد الإصدار لتوفير تجربة مستخدم أكثر سلاسة

قبل تحسين عملية إنشاء التطبيق، واجهت شركة Grab تأخيرات في التشغيل على البارد وارتفاعًا في أخطاء "التطبيق لا يستجيب" (ANR) بعد التحديثات الجديدة مباشرةً، ويرجع ذلك في الأساس إلى عبء قراءة العديد من ملفات DEX أثناء إعداد التطبيق. 

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

يقول "نغوين فان مينه"، كبير مهندسي البرمجيات في فريق Passenger App Core في Grab: "كنا نواجه باستمرار ارتفاعات في نسبة أخطاء ANR مع كل إصدار أسبوعي للتطبيق". 

للتخلص من أخطاء ANR وتحسين أوقات بدء التشغيل، نفّذت شركة Grab تحسينات R8 و"الملفات الشخصية للمرجع" و"الملفات الشخصية لبدء التشغيل". أدّى التحسين المستند إلى الملف الشخصي إلى جانب مُحسِّن R8 إلى تحسين فوري بنسبة% 12 في وقت التشغيل على البارد من R8 و% 15 إضافية من "الملفات الشخصية للمرجع"، ما حقّق وقت بدء تشغيل أسرع بنسبة% 27 وقضى بشكل فعّال على الارتفاعات المفاجئة في أخطاء ANR بعد الإصدار.

نفّذت Grab عملية تحسين التطبيق هذه على ثلاث مراحل استراتيجية: تفعيل تحسين R8 في وضع التوافق، والانتقال إلى وضع R8 الكامل، ثم تحسين قواعد الاحتفاظ بالبيانات باستخدام أداة تحليل الإعدادات وإضافة إدارة التكامل المستمر/النشر المستمر.

المرحلة الأولى: تفعيل ميزة "تحسين R8"  (تم طرحها في 2025)

في هذه المرحلة الأولى، تخلّت شركة Grab عن ملف Proguard التلقائي القديم واستخدمت ملف proguard-android-optimize.txt الذي يتيح تحسينات R8.  وبما أنّ قاعدة الرموز البرمجية تعود إلى أكثر من عقد من الزمن وتحتوي على أكثر من 10 ملايين سطر من الرموز البرمجية، تطلّب تفعيل المحسِّن معالجة الإعدادات القديمة واستخدام الانعكاس.

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

المرحلة 2: الوضع الكامل لـ R8 ونقل البيانات (سيتم طرحه في 2026)

تم إطلاق هذه المرحلة بعد تسعة أشهر من الطرح الأوّل، وتم نقل التطبيق إلى وضع R8 الكامل، ما أتاح إجراء المزيد من التحسينات. على الرغم من أنّ المكتبات العادية، مثل Retrofit وFirebase وJetpack Compose، عملت بسلاسة مع R8 باستخدام قواعدها المضمّنة، تم نقل بقية قاعدة الرموز البرمجية الضخمة من خلال حلّ مسارات برمجية معيّنة تعتمد بشكل كبير على الانعكاس:

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

في النهاية، حقّق "الوضع الكامل" في R8 تحسينات هائلة ومتراكمة، بما في ذلك تقليل حجم تنزيل التطبيق بنسبة% 14 إضافية، وتحسين وقت بدء التشغيل بنسبة% 10 إضافية، وانخفاض آخر بنسبة% 10 في أخطاء ANR التي لاحظها المستخدمون. بعد نقل البيانات إلى "الوضع الكامل" في R8، حقّقت قاعدة الرموز البرمجية في Grab نتائج تحسين R8 التالية: 

• نتيجة التحسين: %72
• نتيجة تقليص الرموز البرمجية: %73
• نتيجة إخفاء مفاتيح فك التشفير: %79.6

وقدّمت هذه النتائج ملاحظات حول إعدادات R8 والحاجة إلى تحسين قواعد الاحتفاظ بالبيانات لزيادة تحسين R8 إلى أقصى حد. 

المرحلة 3: تحسين قواعد الاحتفاظ بالبيانات 

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

من خلال الاستناد إلى أساس "الوضع الكامل" في R8 وتقليص قواعد الاحتفاظ القديمة بشكل منهجي، يحقّق تطبيق Grab تحسينات كبيرة في جميع الأبعاد الأساسية الثلاثة التي يقيّمها المحلّل:

• نتيجة التحسين: ترتفع من% 72 إلى %78.2
• نتيجة تقليص الرموز البرمجية: تزداد من% 73 إلى %79.1
• نتيجة إخفاء مفاتيح فك التشفير: تزداد من% 79.6 إلى %81.7

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

النتائج

في ما يلي التحسينات الرئيسية في الأداء بعد طرح أداة تحسين R8:

التحديات الفنية 

أدى تفعيل أداة تحسين R8 في قاعدة الرموز البرمجية التي تعود إلى عقد من الزمن في Grab إلى ظهور عقبات فنية رئيسية على نطاق واسع:

• الاختبار: أدّى عقد من التفكير المتراكم إلى إنشاء حالات حدّية في ظل التحسين الكامل. بما أنّ إجراء اختبار شامل على ملايين أسطر الرموز البرمجية كان مستحيلاً، اتّبع الفريق نهجًا تدريجيًا ذا أولوية عالية، حيث ركّز الاختبار على نسبة استخدام رموز الصفحة التي تغطيها قواعد الاحتفاظ التي يتم تضييق نطاقها، وعمل على تحسين هذه القواعد بشكل متكرر لاستهداف الفئات أو الطرق أو الحقول المحدّدة المطلوبة للانعكاس فقط من أجل تحقيق أقصى استفادة من تحسينات R8.
• وقت استجابة عملية الإنشاء والبنية المختلطة: يعني نظام الإنشاء المختلط في Grab (أداة Bazel لتصحيح الأخطاء وأداة Gradle لإصدارات R8) أنّ تغييرات R8 التجريبية تطلّبت ما يصل إلى ساعتَين في عملية CI عن بُعد. لسدّ فجوة الملاحظات، قامت Grab بمواءمة إصدارات تأكيد الجودة اليومية لتتطابق مع سلوك R8 في مرحلة الإنتاج، وأتمتت عملية جمع عناصر إصدارات CI الرئيسية، مثل mapping.txt وconfiguration.txt، لتبسيط عملية التحقيق.
• دورات تصحيح الأخطاء البطيئة: شكّل تتبُّع الأسباب الأساسية في مئات الفئات المحسّنة عبئًا ثقيلاً على فريق صغير. حلّت Grab هذه المشكلة من خلال برمجة عمليات تحميل ملفات الربط إلى Firebase Crashlytics عبر Gradle وتجميع عمليات إزالة التشويش في Play Console، ما أتاح حلّ الرموز بشكل فوري ودقيق لمشاكل وقت التشغيل

تأثير الرمز البرمجي على المدى الطويل باستخدام R8

بالإضافة إلى تحسين الأداء الفوري، حقّق تفعيل مُحسِّن R8 ميزة هيكلية دائمة لقاعدة الرموز البرمجية الضخمة في Grab. في شركة Grab، استخدم الفريق أداة app-sizer المفتوحة المصدر لقياس تأثير أداة R8، ولاحظ أنّها خفّضت بشكل دائم حجم التنزيل لكل سطر من الرموز البرمجية في التطبيق.

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

ملاحظة: المنهجية: مساهمة Kotlin/Java في حجم تنزيل التطبيق (جهاز تمثيلي)، مقسومة على أسطر الرموز البرمجية (LOC) في Kotlin للإصدار العلني (cloc؛ مجموعات رموز المصدر الرئيسية فقط؛ باستثناء وحدات الاختبار والمحاكاة والنماذج).

إدارة قواعد Keep والضوابط

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

الشكل 1: لوحة بيانات CI لتتبُّع نتائج تقليص حجم الرمز البرمجي وتحسينه وإخفائه باستخدام R8 بمرور الوقت في إصدارات Grab  لرصد أي تراجعات في الأداء بشكل استباقي ومنعها في جميع الإصدارات.

الخاتمة 

في مواجهة تحديات قاعدة الرموز البرمجية الضخمة والمتطورة، تعامل فريق Pax App Core في Grab بشكل استباقي مع زيادة أوقات بدء التشغيل وارتفاع الأداء بعد الإصدار من خلال تنفيذ "الملفات الشخصية للمرجع" وتحسين إعدادات R8 باستمرار. تمكّن الفريق من تقليل أخطاء ANR التي لاحظها المستخدمون بنسبة %32.5 تقريبًا، وخفض حجم تنزيل التطبيق بنسبة %30.3 تقريبًا، وتحسين وقت التشغيل على البارد بنسبة %35 تقريبًا، مع تحسين كفاءة توسيع قاعدة الرموز البرمجية بشكل أساسي.

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

للبدء ومعرفة المزيد عن R8، يُرجى الانتقال إلى - d.android.com/r8.