التطبيق ينهار عند المستخدمين: كيف تجمع الدليل وتحدد مصدر الانهيار
العملاء يقولون إن التطبيق يُغلق فجأة، والمطور لا يستطيع تكرار المشكلة. هذا الدليل لصاحب التطبيق ومدير التقنية: كيف تجمع دليل الانهيار من مصادره، وتقرأ نمطه، وتصل إلى السبب، وتعرف أن الإصلاح نجح فعلًا.
حين يقول العملاء إن التطبيق ينهار، فالسؤال الأول ليس «ما الخطأ في الكود؟» بل «أين الدليل؟». الدليل في أربعة أماكن: أداة تقارير الأعطال داخل التطبيق، ولوحة Android vitals في Google Play، وتقارير Xcode وTestFlight، وسجلات الخادم في اللحظة نفسها. اجمع منها ثلاثة أشياء: أي إصدار من التطبيق بدأ فيه الانهيار، وعلى أي أجهزة وأنظمة يتركز، وما الخطوة التي سبقته. هذا النمط يشير عادة إلى أحد أسباب محدودة: الذاكرة، أو بيانات لم يتوقعها التطبيق، أو مكتبة، أو إذن مرفوض. ثم يُصلح السبب ويُنشر تدريجيًا، ويُقارن معدل الانهيار قبل الإصلاح وبعده.
التطبيق يعمل على جوالك وجوال فريقك، لكن تقييمات المتجر تقول «يُغلق فجأة»، والدعم يتلقى شكاوى لا يستطيع أحد تكرارها. المطور يطلب «خطوات إعادة الإنتاج»، والعميل لا يتذكر ما فعله. هذه الحلقة تستمر أسابيع إن لم يُجمع الدليل بطريقة منظمة. هذا الدليل لصاحب التطبيق ومدير التقنية: كيف تتأكد أن ما يحدث انهيار فعلًا، ومن أين تجمع الدليل، وكيف تقرأ نمطه، ومتى تعرف أن الإصلاح نجح.
هل هو انهيار فعلًا؟ فرّق بين أربعة أعراض
المستخدم يصف كل شيء بكلمة واحدة: «التطبيق ينهار». لكن خلف الوصف أعراض مختلفة، لكل منها مكان دليل مختلف. الخلط بينها يرسل المطور إلى المكان الخطأ.
| ما يراه المستخدم | ما يحدث غالبًا | أين الدليل |
|---|---|---|
| التطبيق يُغلق ويعود إلى الشاشة الرئيسية للجوال | انهيار (Crash): خطأ لم يُعالج في التطبيق أو في مكتبة | أداة تقارير الأعطال، وAndroid vitals، وXcode Organizer |
| الشاشة تتجمد ثم يعرض Android رسالة «التطبيق لا يستجيب» | تجمد (ANR): عمل ثقيل يوقف الواجهة | قسم ANR في Android vitals، وتقارير الأداة إن كانت تجمعها |
| التطبيق يبدأ من الصفر بعد العودة إليه من تطبيق آخر | النظام أغلقه في الخلفية لتوفير الذاكرة، وهو لم يحفظ حالته | غالبًا لا تقرير انهيار؛ يُثبت بإعادة الإنتاج على جهاز محدود الذاكرة |
| شاشة بيضاء أو دائرة تحميل لا تنتهي | ليس انهيارًا: خطأ من الخادم أو استجابة لم يتعامل معها التطبيق | سجلات الخادم ومراقبة واجهات الربط |
العرض الرابع تحديدًا يضيع وقتًا كثيرًا: يبحث الفريق في تقارير الانهيار فلا يجد شيئًا، لأن التطبيق لم ينهر. وإن كان التطبيق بطيئًا لا منهارًا، فالتشخيص مختلف ويبدأ من تحديد مصدر البطء بين الجوال والشبكة والخادم.
من أين تجمع دليل الانهيار؟
لا تعتمد على مصدر واحد. كل مصدر يرى جزءًا من الصورة، والتقاطع بينها هو ما يحدد السبب.
أداة تقارير الأعطال داخل التطبيق
أدوات مثل Firebase Crashlytics تسجل كل انهيار مع الجهاز والنظام والإصدار ومسار الكود. في تطبيقات Flutter لا تلتقط الأداة كل الأخطاء تلقائيًا؛ تشرح وثائق Crashlytics لـ Flutter أن أخطاء إطار العمل والأخطاء غير المتزامنة تحتاج إلى ربط صريح بالأداة. وإن كان الكود مشوشًا عند البناء (Obfuscation)، فيجب رفع ملفات الرموز لتصبح التقارير مقروءة. اسأل المطور: هل الأداة مفعلة في نسخة الإنتاج؟ وهل التقارير تعرض أسماء الدوال أم عناوين لا معنى لها؟
Android vitals في Google Play Console
تجمع Google بيانات الانهيار والتجمد من أجهزة المستخدمين دون أداة إضافية. والأهم أنها تؤثر على ظهور التطبيق: بحسب وثائق Android vitals، إذا تجاوز معدل الانهيار الذي يلاحظه المستخدمون 1.09% إجمالًا أو 8% على طراز جوال واحد، أو تجاوز معدل التجمد 0.47% إجمالًا أو 8% على طراز، فقد يقلل Google Play ظهور التطبيق أو يعرض تحذيرًا في صفحته. والحساب على متوسط 28 يومًا، فالتحسن بعد الإصلاح لا يظهر في يوم.
Xcode Organizer وTestFlight
بحسب وثائق Apple عن تقارير الانهيار، تجمع App Store وTestFlight تقارير الانهيار لكل إصدار مرفوع. نافذة الأعطال في Xcode تعرض تقارير المستخدمين الذين يشاركون بيانات التشخيص فقط، بينما مختبرو TestFlight يشاركونها تلقائيًا. ولتكون التقارير مقروءة، يجب تضمين معلومات الرموز عند رفع البناء.
سجلات الخادم وبلاغات المستخدمين
كثير من الانهيارات تبدأ من استجابة غير متوقعة من الخادم. قارن توقيت الانهيارات بسجل أخطاء الخادم في الدقائق نفسها. وبلاغ المستخدم، إن جُمع جيدًا، يعطي ما لا تعطيه الأدوات: ماذا كان يحاول أن يفعل.
نموذج بلاغ انهيار يجمعه فريق الدعم
«التطبيق ينهار» ليس بلاغًا. أعطِ فريق الدعم هذا النموذج، واجعله يملؤه مع كل شكوى، ولو في محادثة قصيرة مع العميل:
- الوقت التقريبي: اليوم والساعة، لمطابقته مع التقارير وسجلات الخادم.
- الحساب: رقم الجوال أو المعرف في النظام، لا اسم العميل فقط.
- الجهاز: الطراز، وإصدار النظام (iOS أو Android)، وتظهر في إعدادات الجوال.
- إصدار التطبيق: من صفحة «عن التطبيق» أو من المتجر. أضف رقم الإصدار في مكان ظاهر إن لم يكن موجودًا.
- الخطوة الأخيرة: ماذا ضغط قبل الإغلاق، وفي أي شاشة.
- التكرار: هل يحدث في كل مرة، أم أحيانًا، أم مرة واحدة.
- الظروف: شبكة ضعيفة، أو وضع توفير الطاقة، أو بعد العودة من تطبيق آخر كتطبيق البنك.
- لغة الجهاز وإعدادات التاريخ: عربي أم إنجليزي، والأرقام عربية أم لاتينية، والتقويم ميلادي أم هجري.
البند الأخير ليس تفصيلًا. في تطبيقات تخدم مستخدمين في المملكة، إعدادات اللغة والأرقام والتقويم تختلف من جهاز لآخر، وقد تكشف مسارًا لم يختبره الفريق على أجهزته.
اقرأ النمط قبل أن تقرأ الكود
التقرير الواحد قليل الفائدة. المفيد هو التجميع: أدوات الأعطال تجمع الانهيارات المتشابهة في مجموعة واحدة. اطلب من المطور لكل مجموعة كبيرة أربع إجابات:
- كم مستخدمًا تأثر؟ لا عدد الانهيارات، لأن مستخدمًا واحدًا قد ينهار عنده التطبيق عشرات المرات.
- منذ أي إصدار؟ إن بدأت المجموعة مع إصدار محدد، فالسبب غالبًا في ما تغير فيه: ميزة جديدة، أو مكتبة حُدّثت.
- على أي أجهزة وأنظمة؟ تركز على طراز أو إصدار نظام أو أجهزة محدودة الذاكرة يضيّق البحث كثيرًا.
- في أي شاشة أو خطوة؟ من مسار الكود في التقرير، ومن سجل الخطوات إن كانت الأداة تسجله.
ثم رتّب المجموعات بالأثر، لا بالترتيب الذي ظهرت به. هذه المصفوفة تساعدك على القرار:
انهيار عند الفتح أو في الدفع أو الدخول: إصلاح عاجل خارج جدول الإصدارات.
انهيار في الدفع على طراز واحد: أولوية عالية، لأن كل حالة تعني طلبًا ضائعًا.
انهيار في شاشة الإعدادات أو المشاركة: في أول إصدار إصلاح.
انهيار نادر على أجهزة قديمة: يُجدول مع الإصلاحات، ويُراقب إن زاد.
الأسباب الشائعة وما يدل على كل منها في التقارير
أغلب الانهيارات في تطبيقات الأعمال تعود إلى عدد محدود من الأسباب. النمط في التقارير يشير إلى السبب قبل قراءة الكود، ثم يُثبت بإعادة الإنتاج.
| السبب | النمط الذي يدل عليه | كيف يُثبت |
|---|---|---|
| نفاد الذاكرة | أجهزة محدودة الذاكرة، وشاشات فيها صور كثيرة أو كبيرة، أو رفع صور من الكاميرا | تشغيل المسار على جهاز من الفئة الأدنى المستهدفة، ومراقبة الذاكرة |
| بيانات لم يتوقعها التطبيق | حسابات محددة فقط، أو بعد تغيير في الخادم، وحقل فارغ أو قائمة فارغة في مسار الكود | فتح الحساب المتأثر في بيئة الاختبار، ومقارنة استجابة الخادم بما يتوقعه التطبيق |
| إعدادات اللغة والأرقام والتقويم | انهيار عند قراءة تاريخ أو رقم أو مبلغ، ويتركز على أجهزة بإعدادات إقليمية معينة | تغيير لغة جهاز الاختبار وأرقامه وتقويمه وتكرار الخطوة |
| مكتبة خارجية | بدأ مع إصدار حُدّثت فيه مكتبة، ومسار الكود داخل المكتبة لا داخل كود التطبيق | مراجعة سجل تغييرات المكتبة ومشكلاتها المعروفة، وتجربة الإصدار السابق منها |
| إذن مرفوض أو تغير سلوك النظام | يتركز على إصدار نظام جديد، أو بعد رفض المستخدم إذن الموقع أو الإشعارات أو الكاميرا | تكرار المسار مع رفض الإذن، وعلى إصدار النظام المتأثر |
| الانتقال بين التطبيقات | انهيار عند العودة من تطبيق البنك أو الكاميرا أو المتصفح | تفعيل خيار إغلاق الأنشطة في إعدادات المطور على Android وتكرار الانتقال |
| إعدادات البناء النهائي | يظهر في نسخة المتجر فقط ولا يظهر في نسخة المطور | اختبار النسخة الموقعة نفسها المرفوعة للمتجر، لا نسخة التطوير |
وإن تركز الانهيار على إصدار نظام جديد تحديدًا، فالأسباب والخطة تفصلها مقالة التطبيق لا يعمل على iOS الجديد.
مثال افتراضي للتوضيح مركز صيانة سيارات لديه تطبيق حجز على Android وiOS. بعد إصدار أضاف رفع صور السيارة، ارتفعت شكاوى الإغلاق. أظهرت أداة الأعطال مجموعة واحدة كبيرة: 90% منها على Android، ومعظمها على أجهزة اقتصادية، وكلها في شاشة رفع الصور، وبدأت مع الإصدار الجديد تحديدًا. النمط أشار إلى الذاكرة: التطبيق يحمّل الصور بدقتها الكاملة من الكاميرا قبل ضغطها. أُثبت السبب على جهاز اقتصادي، وأُصلح بتصغير الصور قبل تحميلها في الذاكرة، ونُشر الإصلاح تدريجيًا. بعد أسبوع اختفت المجموعة من تقارير الإصدار الجديد، بينما بقيت في الإصدار القديم عند من لم يحدّث.
الإصلاح والتحقق بعد النشر
الإصلاح لا ينتهي حين يقول المطور «أصلحته». ينتهي حين تثبت الأرقام أن المجموعة اختفت من الإصدار الجديد دون أن تظهر مشكلة أخرى.
- اختبار يمنع العودة: لكل انهيار يُصلح، حالة اختبار تكرر ظروفه، حتى لا يعود في إصدار لاحق.
- اختبار على الجهاز المماثل: على الطراز أو الفئة أو إصدار النظام الذي تركز عليه الانهيار، لا على جهاز المطور.
- نشر تدريجي: على نسبة من المستخدمين أولًا، مع قدرة على إيقاف الإطلاق فورًا إن ارتفعت الأعطال، كما يصف خط DevOps والنشر المستمر.
- مقارنة بالإصدار: معدل المستخدمين دون انهيار في الإصدار الجديد مقابل السابق، لا المعدل العام الذي يخلط الإصدارات.
- إغلاق البلاغات: إبلاغ العملاء الذين اشتكوا بأن الإصدار المصحح متاح، ومتابعة إن تكررت شكواهم.
إن كان الانهيار حرجًا وقديمًا منتشرًا بين المستخدمين، ففكر في آلية تطلب من أصحاب الإصدارات القديمة التحديث. الإصلاح لا يصل إلى من لا يحدّث، وتقاريرهم ستبقى تظهر في الأدوات وتؤثر على مؤشرات Android vitals.
أخطاء شائعة في تشخيص انهيار التطبيق
- البدء بتخمين السبب: «أكيد بسبب التحديث الأخير» ثم إصلاح شيء آخر. النمط أولًا، ثم الفرضية، ثم الإثبات.
- تطبيق بلا أداة تقارير أعطال: فيصبح كل تشخيص اعتمادًا على ذاكرة العملاء. تفعيلها يسبق أي إصلاح.
- تقارير غير مقروءة: ملفات الرموز لم تُرفع، فتظهر عناوين ذاكرة بدل أسماء الدوال.
- الاختبار على أحدث الأجهزة فقط: بينما الانهيار على أجهزة اقتصادية أو إصدارات أقدم يحملها جزء كبير من العملاء.
- الحكم على الإصلاح من المعدل العام: الذي يخلط الإصدار المصحح بالقديم، فيبدو أن الإصلاح لم ينجح أو نجح أكثر مما حدث.
- نشر الإصلاح للجميع دفعة واحدة: فإن كسر شيئًا آخر وصل الكسر إلى كل المستخدمين.
- معالجة كل انهيار كحادثة منفصلة: حين تتكرر الانهيارات في الأجزاء نفسها، فالمشكلة أعمق من أي إصلاح منفرد، وتحتاج إلى خطة تثبيت للتطبيق قبل أي ميزة جديدة.
ما تجهزه قبل التواصل وما تطلبه من المطور أو فريق الدعم
ما تجهزه
- بلاغات العملاء مجمعة بالنموذج أعلاه، ولو خمسة بلاغات مكتملة.
- صلاحية قراءة على أداة الأعطال وعلى Play Console وApp Store Connect.
- تاريخ بداية الشكاوى، وما نُشر قبله من إصدارات أو تغييرات في الخادم.
- تقييمات المتجر التي تذكر الإغلاق، بتواريخها.
- الوصول إلى الكود والخوادم بصلاحيات مراجعة، إن كان من سيشخص فريقًا جديدًا.
ما تطلبه من المطور أو فريق الدعم
- قائمة بمجموعات الانهيار الكبرى: عدد المتأثرين، وأول إصدار، والأجهزة، والشاشة.
- فرضية مكتوبة لكل مجموعة، وكيف أُثبتت بإعادة الإنتاج.
- الأولوية حسب الأثر، وموعد كل إصلاح.
- مقارنة معدل الانهيار بين الإصدار المصحح والسابق بعد النشر.
- اختبار لكل انهيار مُصلح يمنع عودته.
في صفحة إصلاح أخطاء التطبيق القائم نبدأ بجمع البلاغات والأعطال من كل المصادر، ونعيد إنتاج الانهيار على جهاز مماثل للطراز والإصدار المتأثرين، ونرتب الإصلاح حسب الأثر، ونراقب الأعطال بعد النشر ونقارن المعدلات قبل وبعد. وحين تتكرر الأعطال بعد الإصلاح، فالمراقبة المستمرة وتحديثات أنظمة التشغيل والمكتبات جزء من عقد الصيانة والدعم بمستوى خدمة مكتوب. وإن ترافقت الانهيارات مع تحذير من المتجر، فراجع أيضًا رفض التطبيق أو تعليقه في Google Play.
الخلاصة: الدليل أولًا، ثم السبب، ثم الأرقام بعد الإصلاح
انهيار التطبيق عند بعض المستخدمين يُشخص بالنمط لا بالتخمين: أي إصدار، وأي أجهزة، وأي خطوة. اجمع الدليل من أداة الأعطال وAndroid vitals وتقارير Apple وسجلات الخادم، ورتب المجموعات حسب أثرها، وأثبت كل سبب بإعادة الإنتاج، ثم انشر الإصلاح تدريجيًا وقارن الإصدارين. إن كان تطبيقك ينهار ولا تعرف من أين تبدأ، أرسل تفاصيل تطبيقك الحالي ووصف الانهيار، ونرد بالخطوة الأولى للتشخيص.
أسئلة شائعة
لأن جهازه غالبًا أحدث وذاكرته أكبر، وإعداداته غير إعدادات العميل، ويشغّل نسخة التطوير لا نسخة المتجر. الانهيار كثيرًا ما يرتبط بطراز أو إصدار نظام أو إعدادات لغة وتقويم أو حساب ببيانات معينة. لذلك يبدأ التشخيص من نمط التقارير، ثم يُعاد الإنتاج على جهاز وظروف مماثلة.
نعم. بحسب وثائق Android vitals، إذا تجاوز معدل الانهيار الذي يلاحظه المستخدمون 1.09% إجمالًا أو 8% على طراز واحد، فقد يقلل Google Play ظهور التطبيق أو يعرض تحذيرًا في صفحته. والحساب على متوسط 28 يومًا، فالتحسن بعد الإصلاح يظهر تدريجيًا.
ابدأ بما يتوفر دون أداة: Android vitals في Play Console، ونافذة الأعطال في Xcode للمستخدمين الذين يشاركون بيانات التشخيص، وسجلات الخادم. ثم اجعل تفعيل أداة تقارير الأعطال أول إصدار قادم، لأن كل تشخيص بعدها يصبح أسرع وأدق.
ليس دائمًا. قد يغلق النظام التطبيق في الخلفية لتوفير الذاكرة فيبدأ من الصفر عند العودة، وقد تكون الشاشة البيضاء خطأ من الخادم لا انهيارًا. التمييز بين الأعراض يوجه البحث إلى المكان الصحيح بدل البحث في تقارير انهيار لا وجود لها.
قارن معدل المستخدمين دون انهيار في الإصدار المصحح بالإصدار السابق، وتأكد أن مجموعة الانهيار اختفت من تقارير الإصدار الجديد. المعدل العام يخلط الإصدارات، لأن من لم يحدّث التطبيق سيبقى ينهار عنده، فلا تحكم به وحده.
خدمات وصفحات مرتبطة
اقرأ أيضًا
انهيارات لا تعرف مصدرها؟ ابدأ بتشخيص منظم
أرسل وصف الانهيار وما جمعته من بلاغات وتقارير، ونرد بخطة تشخيص تحدد مجموعات الانهيار وأولوياتها وطريقة إثبات كل سبب.