سلسلة تحسين أداء iOS 07｜عملية تقارب السبب الجذري لاستكشاف أخطاء أداء iOS وإصلاحها

عند القيام باستكشاف أخطاء أداء نظام التشغيل iOS وإصلاحها، فإن الشيء الأكثر إزعاجًا هو أن المشهد غالبًا ما يكون فوضويًا من البداية.

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

بعد القيام بهذا النوع من العمل عدة مرات، أكبر شعور لدي هو: **تبدأ عملية استكشاف أخطاء الأداء وإصلاحها بمشكلات التقارب، يليها تحليل البيانات. **

إذا لم يتم حل المشكلة أولاً، فكلما زاد عدد الأدوات التي تفتحها، أصبح من الأسهل أن تضل نفسك. لأن كل مؤشر تراه يبدو أنه يحتوي على معلومات، ولكن كل المعلومات ليست كافية لتكوين استنتاج.

المقالة التالية لا تتحدث عن “كيفية استكشاف الأخطاء وإصلاحها نظريًا”، ولكنها تكتب وفقًا للإيقاع الذي سيحدث في المشروع الحقيقي: كيف انتقلت مشكلة سقوط الإطار في تدفق معلومات الصفحة الرئيسية من “الشعور بالتوقف قليلاً” خطوة بخطوة إلى النقطة التي يمكن إصلاحها يدويًا؟

أكمل المشهد أولاً، وإلا فسيتم فقدان كل التحليلات اللاحقة.

كان الوصف الأولي لهذه المشكلة عاديًا جدًا:

• الصفحة الرئيسية لا تنزلق بسلاسة
• بعض النماذج أكثر وضوحا
• يبدو الإصدار الأخير أكثر ثباتًا.

يبدو هذا الوصف وكأنه معلومات، ولكن في الواقع يكاد يكون من المستحيل استخدامه مباشرة لاستكشاف الأخطاء وإصلاحها. لأنه مختلط بثلاث طبقات من الأشياء على الأقل:

*نطاق الصفحات غير واضح *نوع الظاهرة غير واضح *شروط الظهور مرة أخرى غير واضحة

أخيرًا تم اختصار الوصف الذي بدأ العمل بالفعل إلى هذا:

iPhone 13 Pro، iOS 18، تسجيل الدخول إلى الحساب A، البدء البارد للدخول إلى تدفق توصيات الصفحة الرئيسية، انتقل إلى علامة التبويب “متابعة” بعد تحميل الشاشة الأولى، ثم قم بالتبديل مرة أخرى إلى تدفق التوصيات، اسحب لأعلى 4 شاشات متتالية، واستمر في إسقاط الإطارات بدءًا من الشاشة الثالثة. تحدث المشكلة بشكل أساسي في الترتيب المختلط للرسومات والنصوص والترتيب المختلط لبطاقات الفيديو.

لا تكمن أهمية هذا المقطع في أنه مكتوب كحالة اختبار، بل في أنه يزيل الكثير من الغموض في وقت واحد:

*إنها بطاقة التدفق الموصى بها على الصفحة الرئيسية

• يكون الأمر أكثر وضوحًا في المرة الثانية التي تدخل فيها
• يتم التمرير وإسقاط الإطارات *المنطقة التي تختلط فيها الصور والنصوص أكثر وضوحًا.

غالبًا ما تبدأ البداية الحقيقية للتحقيق بهذا “تحديد النطاق”. وبدون هذه الخطوة، فإن كل “التحليلات” اللاحقة قد تكون مجرد مطاردة لمخيلة الفرد.

لا تتعجل في إلقاء نظرة على الأدوات أولاً، وحدد أولاً ما إذا كان هذا تجميدًا عرضيًا أم انخفاضًا مستمرًا في معدل الإطارات.

الكلمات الأربع “لا تنزلق بسلاسة” قد تتوافق في الواقع مع مشاكل مختلفة تمامًا.

أول شيء فعلته تلك المرة هو تسجيل الشاشة وتحريكها عدة مرات لتوصيف الظاهرة.

في النهاية، يعد هذا معدل إطارات منخفضًا نموذجيًا للغاية:

• بمجرد الدخول إلى منطقة محتوى معينة، لن تعمل عدة شاشات متتالية بسلاسة.
• ثقيل خلال مرحلة التدحرج بأكملها
• الشعور الشخصي للمستخدم هو أن “هذا القسم لا يمكن أن ينزلق”

هذا التمييز مهم جدا.

لأن التأخير العرضي عادة ما يبدو أشبه بما يلي:

• وصل فك تشفير صورة معينة فجأة إلى الموضوع الرئيسي
• وقت تهيئة كائن كبير غير صحيح
• تمريرة تخطيط معينة تصبح ثقيلة في بعض الأحيان

والإطارات المنخفضة المستمرة تبدو أشبه بما يلي:

• القيام بأعمال متكررة في كل إطار
• بنية الخلية نفسها ثقيلة جدًا
• يتم ردم النتائج غير المتزامنة بشكل مستمر أثناء التمرير
• نطاق تحديث حالة القائمة كبير جدًا

إذا لم يتم فصل هذين النوعين من المشكلات في البداية، فسيتم إساءة تفسير أي بيانات لاحقًا بسهولة.

يجب كتابة مسار الاستنساخ، وإلا فلن يكون للكلمات “التي تم تغييرها” أي معنى.

أحد الأعراض الأكثر شيوعًا لمشاكل الأداء هو “لقد كان الأمر واضحًا الآن، ولكنه اختفى الآن.”

لذلك، في عملية استكشاف الأخطاء وإصلاحها، كانت الخطوة الأولى التي قمت بها غبية، ولكنها قيمة للغاية: كتابة مسار التكرار في خطوات ثابتة.

والذي تم ترتيبه في ذلك الوقت كان:

1. قم بإيقاف التطبيق والبدء من جديد
2. قم بتسجيل الدخول إلى الحساب أ
3. أدخل إلى تدفق توصيات الصفحة الرئيسية وانتظر حتى تصبح الشاشة الأولى مستقرة تمامًا.
4. قم بالتبديل إلى علامة التبويب “متابعة”.
5. عد إلى تدفق التوصيات
6. اسحب لأعلى 4 شاشات في تتابع سريع
7. راقب أداء معدل الإطارات وإشغال الخيط الرئيسي بدءًا من الشاشة الثالثة

تذكر أيضًا البيئة:

• نموذج المعدات
• إصدار النظام
• ظروف الشبكة
• مستوى البيانات
• ما إذا كان سيتم تشغيل مفتاح التصحيح

ولا تكمن أهمية ذلك في تسهيل إعادة إنتاج الآخرين فحسب، بل الأهم من ذلك، تسهيل التحقق اللاحق.

لأن الجملة الأكثر عديمة القيمة في تحسين الأداء هي:

أشعر بتحسن من ذي قبل.

لا يوجد مسار ثابت، وكلمة “شون” ليس لها أي قيمة تحليلية. قد يكون السبب فقط هو اختلاف البيانات، أو اختلاف الشبكة، أو أن الصفحة لا تنزلق إلى نفس الفقرة، أو حتى أن الإصبع لا ينزلق بسرعة كبيرة هذه المرة.

الجولة الأولى من الحكم لا تجد السبب الجذري، ولكنها تحدد فقط الرابط الذي تكمن فيه المشكلة.

عندما أبدأ بالتعامل مع هذا النوع من المشاكل لأول مرة أريد أن أسأل:

• أي سطر من التعليمات البرمجية بطيء؟
• ما هي الوظيفة الأكثر استهلاكا للوقت؟
• ما المكتبة هي المشكلة؟

ولكن في التحقيق الحقيقي، عادة ما يكون من السابق لأوانه طرح هذا السؤال.

ما فعلته أولاً تلك المرة هو التجزئة التقريبية للروابط:

هل هي مشكلة في البيانات أم مشكلة في العرض؟

تعتبر هذه الخطوة بالغة الأهمية، لأن الصفحة الرئيسية البطيئة يمكن أن تجعل الأشخاص يشككون بشكل غريزي في الواجهة.

لقد قمت أولاً بالتحقق المباشر للغاية: حاول إصلاح نتائج الشبكة قدر الإمكان، بحيث تأتي البيانات عند إدخال تدفق التوصية للمرة الثانية من النتائج الموجودة وليس من تغييرات الشبكة.

والنتيجة واضحة: لقد عادت البيانات، ولا يزال التمرير ثقيلًا وثابتًا.

يمكن لهذه الخطوة أن تقضي بشكل أساسي على مشكلة “توقف التمرير بسبب بطء الواجهة” من المشكلة الرئيسية.

ستؤثر الواجهة البطيئة على وقت الشاشة الأول، لكنها لا تفسر “بعد الدخول للمرة الثانية، يبدأ جزء معين من المحتوى في الحصول على إطارات منخفضة مستمرة”.

هل الموضوع الرئيسي مشغول أم أن العمل في الخلفية يستمر في العودة إلى الموضوع الرئيسي؟

الشيء التالي الذي يجب النظر إليه هو ما يفعله الخيط الرئيسي عندما تكون البطاقة عالقة.

الهدف من هذه الخطوة أيضًا هو تحديد شكل المشكلة أولاً:

• لا يزال الموضوع الرئيسي مشغولاً
• أو أن عمليات الاسترجاعات في الخلفية كثيفة جدًا، ويتم مقاطعة الخيط الرئيسي واحدًا تلو الآخر.

آخر شيء رأيته كان أكثر من السابق: لا يركز الموضوع الرئيسي دائمًا على مرحلة التمرير.

وهذا يدل على أن الاتجاه بدأ يتضح:

• التركيز ليس على الشبكة
• التركيز ليس على مهمة واحدة كبيرة
• التركيز أشبه برابط عرض القائمة نفسه ثقيل جدًا

هل هي نقطة استثناء واحدة أم حمل زائد على النظام؟

وهذا حكم أقدره في كل مرة.

إذا كانت وظيفة واحدة فقط تنفد أحيانًا لمدة 200 مللي ثانية، فمن السهل التعامل معها، ما عليك سوى التقاطها. ولكن لم يكن هذا هو الحال في ذلك الوقت.

الشيء المزعج الحقيقي في ذلك الوقت هو أنه لم يكن هناك أي سبب كان أمرًا شائنًا لدرجة أن تكون “قاتلًا حقيقيًا في لمحة واحدة”، ولكن تم تجميع الكثير من النفقات الصغيرة التي لم تكن مبالغ فيها معًا، وسقطت جميعًا في المسار الحرج للتمرير.

هذا النوع من المشاكل هو الأكثر إزعاجًا، لأنه لا يحتوي على مكدس واضح بشكل خاص مثل التعطل. يبدو الأمر كما لو أن النظام يخبرك أن كل قرار صغير “تمت كتابته بهذه الطريقة” في الماضي يتم الآن تحميله معًا.

لا يستحق الأمر سوى فتح الأدوات في هذه المرحلة، ويجب أن يتم ذلك مع الشك.

لم يعجبني أبدًا أسلوب “افتح جميع الأدوات أولاً ثم تحدث” لاستكشاف الأخطاء وإصلاحها. من السهل جدًا استخدام الأدوات كبدائل للتفكير.

قبل الدخول إلى Instruments في ذلك الوقت، كان لدي بالفعل عدة شكوك في ذهني:

الشبهة 1: رابط الصورة يضع العمل الذي لا ينبغي وضعه في فترة التدوير في فترة التدوير.

هذا هو المشتبه به الأكثر شيوعًا في سيناريوهات تدفق المعلومات.

خصوصا:

• حجم صورة الغلاف غير موحد
• ترتيب مختلط للرسومات والنصوص وبطاقات الفيديو
• إيقاع إعادة ملء الصورة غير مستقر
• قبل العرض، تتم أيضًا المعالجة مثل الزوايا الدائرية والظلال والقياس.

إذا كان كل هذا العمل يحدث بالفعل أثناء التمرير، فسيكون من الصعب تثبيت معدل الإطارات.

الشبهة 2: تم إعداد العرض التقديمي للخلية بعد فوات الأوان

تبدو العديد من القوائم “واضحة منطقيًا” في البداية، ولكن عندما تقوم بالتمرير فعليًا عبر المعدات، سيتم الكشف عن مشكلة قديمة:

يتم تنفيذ الكثير من أعمال إعداد العرض عندما تكون الخلية على وشك العرض.

على سبيل المثال:

• تجميع النص الغني
• قطع النسخ
• تنسيق الوقت
• حساب الارتفاع
• الحكم على حالة واجهة المستخدم
• تحضير الأجسام المدفونة

كل عنصر ليس كبيرًا بمفرده، ولكن بمجرد الضغط عليه جميعًا في المسار الحرج للتمرير، فإنه سينتقل من “مقبول” إلى “القائمة بأكملها ثقيلة”.

الشكوك 3: نطاق تحديث الحالة كبير جدًا

هذا الوضع شائع بشكل خاص في البنى التفاعلية.

ظاهريًا، يكون هذا مجرد تغيير في حالة البطاقة، ولكن ما يتم تشغيله فعليًا هو:

• إعادة مستوى القسم
• هناك الكثير من الاختلافات المحلية
• اقتران تقارير التعرض وتحديث واجهة المستخدم
• تعود عمليات الاسترجاعات التي يتم تحميلها مسبقًا بشكل متكرر إلى الموضوع الرئيسي

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

ما يضيق الاتجاه حقًا هو بضع جولات من التجارب الرخيصة.

في تلك المرة قمنا بتضييق نطاق المشكلة إلى بضع جولات من التجارب البسيطة جدًا.

التجربة الأولى: استبدال جميع الصور بصور نائبة

هذه التجربة بدائية للغاية، ولكنها مفيدة للغاية.

بمجرد استبدال الصورة، من الواضح أن التمرير قد عاد مرة أخرى. لا تشرح هذه الخطوة بشكل مباشر أن السبب الجذري هو “عدد كبير جدًا من الصور”، ولكنها كافية لتوضيح أن روابط الصور يجب أن تكون أحد الاتجاهات الرئيسية.

إذا واصلت السؤال في هذا الوقت، فلن يكون الجواب بـ “نعم” عامًا بل أكثر تحديدًا:

• ما إذا كان فك التشفير يقع على الخيط الرئيسي
• هل استراتيجية الحجم غير متناسقة؟
• هل يؤدي ردم الصورة إلى إعادة تخطيطها؟
• هل هناك الكثير من المعالجة الإضافية التي تتم قبل العرض؟

التجربة 2: جزء المعالجة المسبقة للنص الديناميكي للخلية

مع هذا التغيير، تم أيضًا تحسين التمرير بشكل ملحوظ.

وهذا يدل على أن الاتجاه الآخر صحيح أيضًا: لقد فات بالفعل إعداد القائمة قبل تقديمها، وهناك أكثر من مهمة أو اثنتين من هذه المهام.

بمعنى آخر، المشكلة هي أن رابط الصورة ورابط العرض مكرران معًا.

التجربة 3: إيقاف تشغيل إجراءات الحافة هذه مؤقتًا مثل التعرض والتحميل المسبق والتشغيل التلقائي

بعد هذه الجولة من التجارب، استمر معدل الإطارات في الاستقرار.

في هذه المرحلة، المشكلة واضحة بشكل أساسي: إن تدفق معلومات الصفحة الرئيسية هو الذي يحمل الكثير من أعمال “فقط افعلها” أثناء مرحلة التمرير.

عادة ما تبدو هذه المهام معقولة في حد ذاتها:

• الصور تحتاج إلى ردمها
• يجب الإبلاغ عن التعرض
• يجب أن يتم التحميل المسبق
• تحتاج بطاقة الفيديو إلى التسخين

ولكن عندما يحدثان معًا على المسار الحرج للتمرير، فإنهما يؤديان إلى إسقاط القائمة بأكملها.

ما يبدو عليه السبب الجذري الحقيقي في النهاية هو مجموعة من القرارات السيئة

عندما هبطت أخيرًا، ربما كانت المشكلة الحقيقية هي مزيج اللكمات:

• استراتيجية حجم الصورة ليست موحدة، مما يؤدي إلى تكاليف المعالجة قبل العرض
• تم فك تشفير بعض الصور بعد فوات الأوان
• تتم أعمال إعداد عرض الخلية في الموقع في الموضوع الرئيسي
• تكون عمليات الاسترجاعات الخاصة بالتعرض والتحميل المسبق كثيفة جدًا أثناء فترة التمرير
• قائمة تغييرات الحالة المحلية تؤدي إلى نطاق تحديث أكبر من المتوقع

هذا هو ما تبدو عليه العديد من مشكلات الأداء.

إنها ليست نهاية “تم العثور على السطر 357”، ولكن في النهاية، ستجد أن تصميم الطبقات المتعددة ليس مقيدًا بدرجة كافية، وفي النهاية سيتم تجميعها معًا في مرحلة التدحرج.

ولذلك، فإنني أكره بشكل متزايد الحجة القائلة بأنه “يجب أن تكون هناك وظيفة رئيسية لمشاكل الأداء”. بالطبع يحدث هذا في المشاريع الحقيقية، ولكن في أغلب الأحيان يكون “مجموعة من الأشكال السيئة التي تراكمت لفترة طويلة”.

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

بعد التعديل، لم يتم حل المشكلة مباشرة، ولكن تم إعادة اتخاذ مسار التكرار الأصلي.

نفس الجهاز، نفس الحساب، نفس طريقة التبديل، نفس الانزلاق إلى منطقة المحتوى، ثم انظر إلى:

• ما إذا كانت قطرات الإطار لا تزال تحدث بشكل ثابت؟
• هل ما زال الموضوع الرئيسي يركز على نفس الفترة الزمنية؟
• هل لا تزال سلوكيات إعادة ملء الصورة والحافة تتنافس مع التمرير للتنافس مع الموضوع الرئيسي؟

في هذه الخطوة، ألقيت أيضًا نظرة على الآثار الجانبية:

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

من الأخطاء التي يتم ارتكابها غالبًا في تحسين الأداء: إنهم يركزون فقط على “ما إذا كان المؤشر يبدو جيدًا”، لكنهم لا ينظرون إلى ما إذا كان قد حل محل مشاكل أخرى.

لكن في العمل الحقيقي، يكون التحسين دائمًا متعلقًا بالتبادل في التجربة الشاملة. التبادل المقبول يسمى تحسينًا، وتبادل المشكلات الأخرى لا يسمى تحسينًا.

من المرجح أن تتم كتابة هذا النوع من المقالات كأحاديث فارغة، ولكنه أيضًا المكان الأكثر واقعية لاستكشاف أخطاء الأداء وإصلاحها.

ستنتهي العديد من المقالات الموجزة بالكتابة:

• تحديد المشكلة أولا
• لوضع فرضية *للتحقق من النتائج

هذه الكلمات صحيحة بالتأكيد، لكنها يمكن أن تتحول بسهولة إلى هراء صحيح.

الفرق في التجربة الحقيقية ليس ما إذا كنت تستطيع قول هذه الكلمات، ولكن ما إذا كنت قد مررت باللحظات التالية:

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

بمجرد قيامك بهذه الأشياء عدة مرات، ستفهم بطبيعة الحال شيئًا واحدًا:

**القيمة الحقيقية لاستكشاف أخطاء الأداء وإصلاحها هي “هل يمكنني تحويل مشهد فوضوي إلى رابط عملي؟” **لا يمكن القيام بذلك، فكلما زاد عدد الأدوات، زادت الفوضى. من خلال القيام بذلك، يمكنك الاقتراب أكثر فأكثر من السبب الجذري للعديد من المشكلات دون المرور عبر جميع المخططات.

عندما أنظر إلى مشكلات الأداء الآن، فإن أكثر ما يهمني هو ما إذا كان بإمكاننا جعل الفريق يتفق على ما يلي في أقرب وقت ممكن:

نحن الآن نحقق في نفس المشكلة، ونعرف بالفعل الرابط الذي تقع عليه بشكل رئيسي.

وطالما تم إثبات ذلك، فإن الإصلاحات اللاحقة عادة لا تكون مربكة للغاية. الشيء الصعب حقًا هو تجميع المشكلة دائمًا في شكل يمكن التعامل معه.