سلسلة تحسين أداء iOS 05｜ممارسات فعالة لتحسين بدء تشغيل iOS

يعد تحسين بدء التشغيل موضوعًا يمكن تحويله بسهولة إلى “مجموعة من الأجزاء والأجزاء”.

يتذكر الناس عادة العديد من التجارب:

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

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

المفتاح الحقيقي لتحسين بدء التشغيل هو سؤال بسيط للغاية:

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

1. السبب الجذري لبدء التشغيل البطيء هو عادةً أن المسار الحرج يصبح أكثر بدانة.

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

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

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

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

2. قم أولاً بالتمييز بين البداية الباردة والبداية الساخنة و"الوقت المتاح" الذي يدركه المستخدمون حقًا.

إذا لم يتم تمييز هذه الطبقة بوضوح، فسيتم تحيز التحسين اللاحق بسهولة.

لأن “بدء التشغيل البطيء” الذي ذكره المستخدمون قد يشير إلى أشياء مختلفة:

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

هذه تتوافق في الواقع مع مراحل مختلفة من البطء.

من وجهة نظر هندسية، على الأقل يجب أن نميز:

• البداية الباردة: العملية من الصفر
• البداية الدافئة: تم استئناف العملية في الذاكرة
• اللحظة التي يكون فيها المستخدم متاحًا بالفعل: اللحظة الزمنية التي يستطيع فيها المستخدم الرؤية وبدء التفاعل

لبدء التحسين، عليك أن تعرف بالضبط أين تضيع الوقت.

3. الخطوة الأولى الأكثر أهمية هي تقسيم العمل إلى طبقات في مرحلة بدء التشغيل.

عادةً ما أقوم بتقسيم العمل في مرحلة البدء إلى ثلاث فئات:

1. يجب إكماله قبل ظهور الشاشة الأولى

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

• هيكل الواجهة الأساسي
• تهيئة التبعية الأساسية
• حالة المستخدم الرئيسية التي يجب معرفتها مباشرة بعد بدء التشغيل

2. يتم الانتهاء منه في أقرب وقت ممكن بعد ظهور الشاشة الأولى

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

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

3. يمكن تأخيره أو تأخيره

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

• التحضير لنقاط دفن معينة
• لا يؤثر على تنظيف ذاكرة التخزين المؤقت للصفحة الحالية
• إحماء موارد الصفحة الثانوية

هذه الخطوة أكثر قيمة من أي خدعة ذات نقطة واحدة لأنها تؤدي مباشرة إلى رؤية: وتبين أن الكثير من البطء يرجع إلى “أنه لا ينبغي لنا أن نفعل ذلك الآن”.

4. السبب وراء عدم وجود فوائد للعديد من تحسينات بدء التشغيل هو أنها تكتب التعليمات البرمجية المحلية بشكل أسرع فقط ولكنها لا تغير المسار الحرج.

هذا سوء فهم شائع جدًا.

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

لذا، للحكم على ما إذا كان تحسين الشركة الناشئة يستحق القيام به، فإن ما أنظر إليه غالبًا هو:

• هل العمل على المسار الحرج؟
• هل يمكن إخراجها من المسار الحرج؟
• هل هو شيء يجب على المستخدمين الاعتماد عليه حاليًا؟

وهذا أكثر أهمية من مجرد مشاهدة الوظيفة وهي تستغرق وقتًا.

5. غالبًا ما يؤدي تحميل محتوى الصفحة الرئيسية إلى إبطاء تجربة بدء التشغيل

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

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

• تم تقديم الهيكل العظمي للصفحة الرئيسية
• ولكن عليك الانتظار حتى تعود الطلبات المتعددة قبل أن تصبح “متاحة بالفعل”
• بعض الوحدات تنتظر بعضها البعض
• لم يتم تحميل ذاكرة التخزين المؤقت المحلية أولاً

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

لذلك، غالبًا ما يرتبط تحسين بدء التشغيل بإستراتيجية الشاشة الأولى:

• ما هي الوحدات التي يجب أن تظهر في وقت واحد
• ما هي الوحدات التي يمكن استخدامها كشاشات هيكلية؟
• ما المحتوى الذي يمكنه عرض النتائج المخزنة مؤقتًا أولاً؟

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

6. حكم أقرب إلى القتال الفعلي: ما هو بطيء حاليًا هو “التهيئة” أو “تجميع الشاشة الأولى”

وكثيرا ما يختلط الأمران.

التهيئة البطيئة

السؤال أكثر حيادية:

-SDK

• خدمات عالمية
• قراءة التكوين
• حقن التبعية

تجميع الشاشة الأولى بطيء

السؤال أكثر حيادية:

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

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

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

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

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

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