سلسلة تحسين أداء iOS 01｜أهداف ونطاق تحسين أداء iOS

عند ذكر موضوع تحسين الأداء، يكون رد الفعل الأول عادة:

• التأتأة أم لا
• لا يسقط الإطار
• هل هو سريع للبدء؟

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

في نفس المنتج، قد تظهر مشاكل الأداء على النحو التالي:

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

لذا فإن السؤال الأول الذي يحتاج تحسين الأداء للإجابة عليه هو:

ما هو نوع البطء “البطيء” الذي نتحدث عنه الآن؟

1. تحسين الأداء هو تحسين جودة التشغيل بشكل عام.

يمكن على الأقل تقسيم مشكلات أداء iOS الحقيقية إلى الفئات التالية:

• وقت بدء التشغيل
• تجميد الصفحة وسقوط الإطار
• استخدام الذاكرة وإعادة تدويرها
• الطاقة والحرارة
• كفاءة استخدام الشبكة والموارد

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

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

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

إذا لم تقم بتصنيف المشكلة أولاً، فمن السهل أن يظهر الانشغال الزائف لاحقًا: لقد فتحت الكثير من الأدوات ونظرت إلى الكثير من المؤشرات، لكنني لم أقترب أبدًا من المشكلة الأساسية.

2. الأداء الذي يدركه المستخدم وأداء فهرس النظام ليسا نفس الشيء، ولكن كلاهما مهم

يمكن تقسيم مشكلات الأداء تقريبًا إلى منظورين:

1. مشكلات الأداء التي يدركها المستخدم

يمكن للمستخدمين الشعور به مباشرة، مثل:

• تعطلت الصفحة عند فتحها.
• قائمة قطرات الإطار المنزلق
• نتائج البحث تظهر ببطء شديد
• عند فتح التطبيق تبقى الشاشة فارغة لفترة طويلة

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

2. مشكلات أداء المؤشر

قد لا يتمكن المستخدمون من وصفها بشكل واضح، لكنها ستظهر تدريجياً على النحو التالي:

• حمى
• استهلاك الطاقة
• كثيرا ما يقتل في الخلفية
• تبقى الذاكرة في مستوى عالٍ لفترة طويلة

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

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

3. العديد مما يسمى بـ “تحسينات الأداء” هي في الأساس مشكلات حدودية هندسية.

هذه هي النقطة الأكثر الاستهانة.

تم أخيرًا التحقيق في العديد من مشكلات الأداء، وكانت المشكلة الحقيقية تكمن في فقدان السيطرة على المستوى الهندسي:

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

وهذا يعني أن تحسين الأداء غالباً ما يكون بمثابة “سداد الديون الهيكلية”.

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

4. سوء التقدير الأكثر شيوعًا في تحسين الأداء: إرجاع كل البطء إلى “العرض” أو “الجهاز”

من المواقف الشائعة أنه عندما ترى بطاقة، فإنك تفكر أولاً في:

• هل المعدات قديمة جداً؟
• هل هناك الكثير من الرسوم المتحركة؟
• هل لأن SwiftUI نفسها ليست جيدة؟

بالطبع هذا ممكن، لكن المواقف الأكثر شيوعًا في المشاريع الحقيقية هي:

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

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

لذا فإن تحسين الأداء هو الإجابة أولاً:

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

5. تحسين الأداء عبارة عن مجموعة من “قدرات تصنيف المشكلات”

من المواقف الشائعة أنه عندما تفكر في تحسين الأداء، فسوف تبحث عن:

• نصائح لتحسين بدء التشغيل
• قائمة نصائح التحسين
• نصائح للتخزين المؤقت للصور

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

عادة ما تكون نقطة البداية الأكثر عملية هي:

1. المشكلة هي بدء التشغيل أو التأخر أو الذاكرة أو استهلاك الطاقة.
2. هل هذه المشكلة من نوع إدراك المستخدم أم من نوع المؤشر؟
3. هل يتركز على صفحة معينة أم في التطبيق بأكمله؟
4. هل يتكرر باستمرار أم أنه يظهر بشكل متقطع في مسارات معينة؟

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

6. غالبًا ما يعود تحسين الأداء إلى “المسؤولية والحدود”

لأن مشكلات الأداء تخبرنا بشكل أساسي بما يلي: في مرحلة ما، يتولى النظام قدرًا كبيرًا من العمل لا ينبغي له القيام به.

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

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

أجبرت هذه الأسئلة في النهاية على إعادة الإجابة:

• من يجب أن يقوم بهذه المهمة؟
• متى يجب أن يتم ذلك؟
• هل يجب أن يتم ذلك في كل مرة؟
• هل يمكن تأجيلها أو تقسيمها أو تخزينها مؤقتًا؟

لذلك، غالبًا ما يتضمن تحسين الأداء “إعادة تنظيم توزيع عمل النظام”.

7. الخلاصة: ما يحتاج حقًا إلى تحسين في تحسين الأداء هو عدم التوازن بين تجربة المستخدم وموارد النظام.

ولكي أختصر الأمر أقول:

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

لذا فإن الخطوة الأولى دائمًا هي التمييز بين نوع المشكلة:

• أين البطء؟
• ما هو المهم؟
• أين يتم صرفها؟
• سيحدث هذا في هذا الوقت

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