الإجابة المختصرة: المستخدم لا يبلّغ عن انهيار التطبيق غالبًا؛ يعيد المحاولة مرة، ثم يحذف. ولهذا فإن غياب الشكاوى ليس دليل استقرار. والأسباب الثمانية الأشيع معروفة ومتكرّرة: قيمة فارغة غير متوقعة، وردّ خادم مختلف عن المتوقع، وذاكرة نفدت مع الصور، وعملية طويلة توقف الواجهة، وترقية بيانات محلية فاشلة، وإذن سُحب، ونسخة نظام أحدث، وجهاز أضعف مما اختُبر عليه. وأول خطوة ليست الإصلاح بل القياس: بلا أداة تجمع الأعطال، أنت تصلح ما تراه لا ما يحدث.
المؤشر الأول: معدل الانهيار
القياس الصحيح ليس «كم انهيارًا» بل كم جلسة خالية من الانهيار. لأن مستخدمًا واحدًا في حلقة انهيار قد ينتج مئات التقارير فيشوّه الصورة.
واقرأه مقسّمًا: لكل نسخة، ولكل نظام تشغيل، ولكل طراز جهاز. فالانهيار المركّز في نسخة واحدة أو جهاز واحد تشخيصه شبه جاهز.
وراقب الاتجاه بعد كل إصدار. الارتفاع المفاجئ بعد نشر نسخة يعني خللًا أُطلق للتو، وهذا سبب إضافي للإطلاق التدريجي الذي شرحناه في تحديثات التطبيق.
كيف تقرأ تقرير العطل؟
التقرير يبدو مخيفًا وهو ليس كذلك. اقرأه بهذا الترتيب:
1. عدد المتأثرين. عطل يصيب مستخدمًا واحدًا غير عطل يصيب ثلث القاعدة. رتّب حسب الأثر لا حسب التاريخ.
2. أين وقع؟ أول سطر يشير إلى كودك أنت (لا إلى مكتبة النظام) هو مكان البداية.
3. متى بدأ؟ هل ظهر مع نسخة معيّنة؟ إن كان كذلك، راجع ما تغيّر فيها.
4. من يتأثر؟ نظام تشغيل واحد؟ طراز معيّن؟ لغة معيّنة؟ الأنماط هنا تختصر ساعات.
5. ماذا كان يفعل المستخدم؟ الأدوات تسجّل مسار الخطوات قبل الانهيار — وهو أنفع جزء في التقرير كله.
والقاعدة: لا تبدأ بالسطر التقني، بل بالنمط. أغلب الأعطال تُحلّ بمعرفة «من ومتى» قبل «كيف».
السبب 1: قيمة فارغة غير متوقعة
الأشيع على الإطلاق: الكود يتوقع بيانات فيجدها غائبة. حساب بلا اسم، وطلب بلا عنوان، وصورة بلا رابط.
ومصدرها غالبًا: بيانات قديمة أُنشئت قبل إضافة حقل، أو ردّ خادم يحذف الحقل حين يكون فارغًا.
العلاج: لا تفترض وجود شيء. واعرض بديلًا مقبولًا بدل الانهيار — اسم افتراضي، أو صورة بديلة، أو رسالة واضحة.
السبب 2: ردّ الخادم ليس كما توقعت
التطبيق يتوقع رقمًا فيصل نص، أو يتوقع قائمة فتصل قيمة فارغة، أو يصل خطأ HTML بدل بيانات.
والحالة الأخبث: الخادم يعمل جيدًا لكن وسيطًا في الطريق يعيد صفحة خطأ، فيحاول التطبيق قراءتها كبيانات.
العلاج: تحقّق من شكل الرد قبل استخدامه، وتعامل مع كل حالة فشل بمسار واضح. وأي رد غير متوقع يُسجَّل لا يُتجاهل.
السبب 3: الذاكرة نفدت
شائع في التطبيقات التي تعرض صورًا كثيرة أو خرائط أو قوائم طويلة.
والعلامة المميزة: الانهيار يتركّز في الأجهزة الأقدم والأقل ذاكرة، ولا يظهر أبدًا على أجهزة الفريق.
العلاج: حمّل الصور بمقاسات العرض لا بمقاسها الأصلي، وحرّر ما خرج عن الشاشة، واستخدم قوائم تعيد استخدام العناصر. وهي الإصلاحات نفسها التي تخدم حجم التطبيق وسرعة الإقلاع.
السبب 4: عملية ثقيلة توقف الواجهة
قراءة ملف كبير أو معالجة بيانات في الخيط الرئيسي تجمّد الواجهة، ثم يُغلق النظام التطبيق قسرًا.
والمستخدم يسمّي هذا انهيارًا وإن كان تقنيًا شيئًا آخر — وهو محقّ من ناحيته.
العلاج: أخرج كل عملية ثقيلة من الخيط الرئيسي، وضع مؤشر تقدّم لما يطول.
السبب 5: ترقية بيانات محلية فاشلة
انهيار يصيب من يحدّث ولا يصيب من يثبّت التطبيق حديثًا. وهذا يربك الفرق كثيرًا لأن أجهزتهم نظيفة.
العلاج: اختبر التحديث من النسخة المنشورة فعلًا بعد استخدامها وتراكم بيانات فيها، لا من تثبيت جديد.
السبب 6: إذن سُحب أثناء التشغيل
المستخدم منح إذنًا ثم سحبه من الإعدادات، أو النظام سحبه تلقائيًا لعدم الاستخدام. والكود يفترض أن الإذن ما زال ممنوحًا فينهار عند أول محاولة.
العلاج: افحص الإذن قبل كل استخدام لا مرة واحدة عند البداية، وتعامل مع الغياب بمسار بديل كما فصّلنا في أذونات التطبيق.
السبب 7: نسخة نظام أحدث
التطبيق يعمل منذ سنة، ثم يبدأ بالانهيار عند شريحة من المستخدمين بلا أي تغيير من طرفك — لأن نظامهم تُرقّي.
العلاج: جرّب النسخ التجريبية من الأنظمة قبل إطلاقها العام، وراقب معدل الانهيار مقسّمًا حسب نسخة النظام بعد كل موسم ترقية.
السبب 8: حالات لم تُختبر
الشبكة تنقطع في منتصف عملية، أو يُغلق التطبيق أثناء رفع ملف، أو تُستدعى شاشة برابط خارجي بمعرّف غير موجود.
العلاج: اختبر الحالات القذرة عمدًا لا المسار السعيد وحده — وهذا جوهر اختبار تطبيقات الجوال المنهجي.
مثال: كيف حُلّ عطل يصيب المحدّثين فقط
لنمشِ في تشخيص واقعي يوضّح الترتيب كاملًا.
البلاغ: ارتفاع مفاجئ في الانهيارات بعد نشر إصدار جديد، والشكاوى تقول «التطبيق يغلق فور الفتح».
الخطوة الأولى — النمط: التقارير تُظهر أن كل المتأثرين على النسخة الجديدة، لكن ليس كل من على النسخة الجديدة متأثرًا. إذن ليس خللًا عامًا بل مرتبطًا بحالة معيّنة.
الخطوة الثانية — المقارنة: الفريق يثبّت النسخة الجديدة على جهاز نظيف فتعمل بلا مشكلة. هنا يظهر الخيط: المشكلة تخصّ من كان لديه التطبيق سابقًا.
الخطوة الثالثة — إعادة الإنتاج: يثبّتون النسخة القديمة، ويستخدمونها حتى تتراكم بيانات محلية، ثم يحدّثون — فينهار التطبيق فورًا. تم تأكيد السبب.
الخطوة الرابعة — الجذر: حقل أُضيف إلى بنية التخزين المحلي بلا خطوة ترقية، فالقراءة من قاعدة بيانات قديمة تفشل عند التهيئة.
الخطوة الخامسة — الإصلاح والوقاية: خطوة ترقية للبيانات، ومعالجة للفشل بحيث يبدأ التطبيق ببيانات نظيفة بدل الانهيار، وبند جديد ثابت في قائمة ما قبل الإصدار: اختبار التحديث من النسخة المنشورة.
والدرس: لولا سؤال «من يتأثر؟» قبل قراءة السطر التقني، لضاعت ساعات في مطاردة كود سليم.
جدول: العَرَض والتشخيص المرجّح
| ما تراه في التقارير | التشخيص المرجّح | |—|—| | انهيار في أجهزة قديمة فقط | نفاد ذاكرة | | انهيار لمن حدّث فقط | ترقية بيانات محلية | | انهيار مع نظام واحد | تغيّر في واجهات النظام | | انهيار عند شاشة واحدة | بيانات غير متوقعة من الخادم | | انهيار عشوائي بلا نمط | تزامن أو عملية في الخلفية | | ارتفاع مفاجئ بلا إصدار جديد | تغيير في الخادم أو خدمة خارجية | | انهيار عند الفتح فقط | خلل في التهيئة أو إذن سُحب |
الأعطال التي لا تُسمّى انهيارًا
التطبيق قد لا ينهار وهو مع ذلك معطّل تمامًا في نظر المستخدم. وهذه الحالات لا تظهر في تقارير الانهيار، فتبقى غير مرئية شهورًا:
التجميد. الواجهة لا تستجيب لكن التطبيق لم يُغلق. يسمّيه المستخدم «معلّق»، ويحذفه بالسرعة نفسها.
الشاشة البيضاء. التطبيق يفتح ويعرض فراغًا لأن البيانات لم تصل ولا توجد معالجة للفشل.
الحلقة المفرغة. المستخدم يضغط زرًا فيعود لنفس الشاشة، أو يُطلب منه تسجيل الدخول مرارًا بعد كل نجاح.
الفشل الصامت. يضغط «إرسال» فلا يحدث شيء — لا نجاح ولا خطأ. وهذا أسوأها لأنه يجعله يكرّر العملية، وقد ينتج طلبات مكرّرة.
العلاج المشترك: سجّل هذه الحالات كأخطاء حتى وإن عالجتها. كل رسالة خطأ يراها المستخدم يجب أن يقابلها حدث مسجّل في تحليلات التطبيق، وإلا فأنت تعالج ما لا تعرف حجمه.
ومؤشر مفيد: نسبة الجلسات التي انتهت بخطأ ظاهر للمستخدم. اقرأها بجانب معدل الانهيار؛ غالبًا ستجدها أعلى بكثير وأكثر تفسيرًا لهبوط الاحتفاظ.
سياسة عملية للتعامل
حدّد سقفًا للانهيار يُعدّ تجاوزه حالة طارئة، واتفق عليه مع الفريق مسبقًا.
رتّب حسب عدد المتأثرين لا حسب صعوبة الإصلاح.
أصلح الثلاثة الأوائل في كل إصدار كقاعدة ثابتة، حتى لا تتراكم القائمة.
سجّل الأخطاء المُلتقَطة أيضًا، لا الانهيارات فقط. الخطأ الذي عالجته برسالة للمستخدم ما زال مشكلة يجب أن تُعرَف.
واقرأ التقارير أسبوعيًا لا عند الأزمات. الأعطال الصامتة تتراكم بهدوء، وأول من يخبرك بها منحنى الاحتفاظ الهابط.
أسئلة شائعة
ما المعدل المقبول للانهيار؟
كلما اقتربت من خلوّ الجلسات من الانهيار كان أفضل، والمقارنة المفيدة مع نسختك السابقة. والقاعدة العملية: أي ارتفاع بعد إصدار جديد يُعامَل كطارئ حتى يُفهم سببه.
هل أعرض رسالة اعتذار بعد الانهيار؟
رسالة قصيرة عند إعادة الفتح تُشعر المستخدم بأنك تعرف وتهتم، مع خيار إرسال تقرير. لا تطلب منه شرحًا طويلًا؛ الأداة تجمع التفاصيل التقنية أصلًا.
هل التطبيقات الهجينة أكثر انهيارًا؟
ليست بالضرورة. الأسباب الثمانية أعلاه تصيب كل التقنيات، والفارق في جودة البناء والاختبار أكبر من الفارق في التقنية.
كيف أختبر حالات نفاد الذاكرة؟
على جهاز قديم فعلي مع فتح تطبيقات أخرى، وبتصفّح قوائم طويلة وصور كثيرة. ولا تعتمد على المحاكي وحده — سلوك الذاكرة فيه مختلف.
ماذا لو كان الانهيار في مكتبة خارجية؟
حدّثها أولًا، فكثير من الأعطال معروفة ومُصلحة في نسخة أحدث. وإن استمر، ابحث عن بلاغات مشابهة، وفكّر في بديل إن كانت المكتبة مهملة.
هل أرسل تقارير الأعطال لجهة خارجية؟
هذا ما تفعله أدوات التقارير، ويجب أن ينعكس في إعلان البيانات في المتجرين. واحرص ألا تحوي التقارير بيانات شخصية في نصوص السجل.
من يتابع الأعطال بعد انتهاء عقد التطوير؟
هذا سؤال يجب أن يُحسم في العقد نفسه لا بعد أول عطل. حدّد من يستقبل التنبيهات، وما زمن الاستجابة المتفق عليه، وما يُعدّ طارئًا — وهي بنود أساسية في صيانة التطبيق بعد الإطلاق.
كيف أعرف أن الإصلاح نجح؟
راقب عدد المتأثرين بالعطل في النسخة الجديدة تحديدًا. والعطل الذي يُغلق ثم يعود في نسخة لاحقة علامة على أن الإصلاح عالج العَرَض لا السبب.
كيف تمنع الانهيار قبل حدوثه؟
الوقاية أرخص بكثير من التشخيص بعد الإطلاق، وهذه ست عادات تصنع الفرق:
اختبر على الجهاز الأضعف الذي تدعمه. ليس على أحدث جهاز في الفريق. خصّص جهازًا قديمًا للاختبار وثبّت عليه كل إصدار.
افترض الفشل في كل نداء شبكة. كل طلب قد يفشل أو يتأخر أو يعود بشكل غير متوقع. اكتب مسار الفشل كما تكتب مسار النجاح.
تعامل مع الغياب لا مع الوجود فقط. كل حقل قد يكون فارغًا، وكل قائمة قد تكون خالية، وكل صورة قد لا تُحمَّل.
اختبر الحالات القذرة عمدًا. قطع الشبكة في المنتصف، وإغلاق التطبيق أثناء عملية، وضغط الزر مرتين بسرعة، وتدوير الشاشة أثناء التحميل.
راجع المكتبات الخارجية دوريًا. المكتبة المهملة منذ سنتين ستنكسر مع أول ترقية نظام كبيرة.
واجعل مراجعة الأعطال بندًا ثابتًا في اجتماع الفريق، لا نشاطًا يحدث عند الأزمة. عشر دقائق أسبوعيًا تمنع أسبوعًا من الإطفاء لاحقًا.
عطل واحد قد يفسّر كل شيء
قبل أن تعيد تصميم شاشة أو تضيف ميزة لرفع الاحتفاظ، افتح تقارير الأعطال واقرأ الأول في القائمة.
كثير من حالات «التطبيق لا ينمو» التي نُستدعى إليها تنتهي عند عطل واحد يصيب شريحة من الأجهزة، ولا أحد يعرف به لأن أصحابه حذفوا التطبيق بلا شكوى.
والقاعدة العملية: ابدأ بالأعطال قبل التحسينات — فإصلاح ما هو مكسور أرخص وأسرع أثرًا من إضافة ما هو جديد.
الخلاصة: الانهيار عطل يعرفه مستخدموك ولا تعرفه أنت — إلا إن قِسته. أداة تجمع التقارير، وقراءة أسبوعية، وترتيب حسب عدد المتأثرين، وإصلاح ثلاثة في كل إصدار: هذه العادة البسيطة تفصل بين تطبيق يستقر مع الوقت وآخر يتآكل بهدوء حتى تسأل نفسك لماذا انخفض الاحتفاظ. وهي جزء أصيل من طريقتنا في اختبار تطبيقات الجوال ومتابعتها بعد الإطلاق.