هوس التشغيل البارد

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

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

هدفنا

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

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

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

ما الذي يفرضه ذلك

بلوغ هذا الرقم يضع حداً لكثير من الجدالات في وقت مبكر. لا يمكن إقامة علاقات شبكية خلال مرحلة الإطلاق. ويصعب الترويج لحزم أدوات التطوير (SDK) الخاصة بأطراف ثالثة — فمعظمها يولد عمليات تعمل في الخلفية قبل application(_:didFinishLaunching…) حتى النتائج. يتم تحميل ذاكرة التخزين المؤقت للصور بشكل مؤجل. وتُنفَّذ عمليات ترحيل قاعدة البيانات في قائمة انتظار في الخلفية، دون أن تعرقل أبدًا القائمة الرئيسية.

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

المفاضلات

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

الأخطاء التي ارتكبناها

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

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

لماذا يستحق الأمر العناء

الالتزام بالانضباط يؤتي ثماره. فعندما يصبح الإطلاق سريعًا، يصبح كل شيء آخر سريعًا أيضًا — لأن القواعد نفسها تنطبق في كل مكان.