عبدالله سنكر يجاوب: كيف تتبّع أعطال تطبيقك بعد الإطلاق؟

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

وش تسوي أداة Crash Reporting بالضبط؟

هي مكتبة صغيرة تنضاف داخل التطبيق، وظيفتها تلتقط لحظة الانهيار وترسل تقريراً لخادم الأداة. التقرير فيه تتبّع المكدّس (stack trace)، يعني سلسلة الدوال اللي كان التطبيق داخلها لحظة الخطأ، ومعه موديل الجهاز وإصدار النظام وإصدار تطبيقك، وأحياناً «فتات الخبز» (breadcrumbs): آخر الخطوات اللي سواها المستخدم قبل الانهيار. والأداة تجمّع التقارير المتشابهة في مشكلة وحدة، فبدل ألف تقرير منفصل تشوف خطأً واحداً صار ألف مرة. من الأدوات المعروفة في هذا المجال Firebase Crashlytics و Sentry، وكلاهما يدعم Flutter.

وفيه إعدادات صغيرة يوم التركيب تفرق كثير بعدين. وسم كل تقرير بإصدار التطبيق ورقم البناء، عشان تعرف بالضبط أي نسخة فيها المشكلة. ووسم البيئة، عشان أعطال نسخة الاختبار ما تختلط بأعطال الإنتاج وتضخّم الأرقام. وفعّل الأداة في نسخة الإنتاج من أول إصدار، مو بعد ما تبدأ الشكاوى، لأن التقارير ما ترجع بأثر رجعي: اللي صار قبل التركيب ضاع.

وصلني تقرير، بس كله رموز ما تنفهم. ليش؟

لأن نسخة الإنتاج مضغوطة ومشوّشة. في Flutter لما تبني بخيار --obfuscate مع --split-debug-info، أسماء الدوال تتحول لرموز قصيرة، وهذا يصغّر التطبيق ويصعّب على غيرك قراءته. نفس الشي يصير مع R8 في أندرويد، ومع ملفات dSYM في آيفون. الحل إنك ترفع ملفات الرموز (symbols) لأداة التتبّع مع كل إصدار، فتترجم التقرير وترجّع أسماء الدوال وأرقام الأسطر. والخطأ الشائع: الفريق يرفعها يدوياً أول مرة، وبعدين ينساها، فتصير كل تقارير الإصدارات الجديدة غير مقروءة. مكان هذي الخطوة الطبيعي داخل مسار البناء الآلي، مو في ذاكرة أحد.

وش الفرق بين الانهيار والخطأ «غير القاتل»؟

الانهيار (crash) لما يقفل التطبيق بالكامل. الخطأ غير القاتل (non-fatal) لما يصير خلل يلتقطه الكود ويكمل التطبيق شغله، مثل طلب دفع رجع برفض غير متوقع، أو شاشة ما قدرت تحمّل بياناتها. هذا النوع ما يقفل التطبيق، لكنه يخرّب التجربة بصمت، وكثير من المستخدمين يحذفون التطبيق بسببه بدون ما يكتبون تقييماً. في Flutter تلتقط أخطاء الإطار عبر FlutterError.onError، والأخطاء غير المتزامنة اللي ما التقطها أحد عبر PlatformDispatcher.instance.onError، وترسل الاثنين للأداة. وفي أندرويد فيه فئة ثالثة تستاهل الانتباه: ANR، لما يعلّق التطبيق وما يستجيب لفترة، وتظهر في لوحة Google Play ضمن مؤشرات الجودة.

عندي مئات التقارير. من وين أبدأ؟

لا ترتّب حسب عدد المرات. خطأ صار خمسمية مرة عند مستخدم واحد عالق في حلقة، أقل أهمية من خطأ صار مرة وحدة عند مية مستخدم. هذا الترتيب اللي يمشي عليه:

• عدد المستخدمين المتأثرين، مو عدد الأحداث.
• مكان الخطأ في الرحلة: أي شي في التسجيل أو الدخول أو الدفع يتقدّم على شاشة الإعدادات.
• هل هو جديد في هذا الإصدار؟ الخطأ اللي ظهر مع آخر تحديث غالباً سببه تعديل معروف وقريب، وإصلاحه أسرع.
• نسبة المستخدمين بلا انهيار (crash-free users): المؤشر اللي تتابعه من إصدار لإصدار، وتلاحظ لو نزل فجأة.
• تركّز الخطأ في جهاز أو نظام معيّن: أحياناً المشكلة في إصدار أندرويد واحد أو موديل واحد، وهذا يختصر البحث كثير.

هل الأداة تجمع بيانات عن مستخدميني؟

نعم، ولازم تتعامل معها على هذا الأساس. التقرير ممكن يحمل معلومات شخصية لو الكود يطبع أشياء حساسة في السجلات، فلا تكتب في السجلات رمز دخول ولا رقم جوال. ولو احتجت تربط الخطأ بمستخدم، استخدم معرّفاً داخلياً لا يدل على شخصه، مو إيميله. وصرّح بهذي البيانات في ملصق الخصوصية في App Store وقسم أمان البيانات في Google Play. وفي تطبيق مبني على مبدأ صفر بيانات مثل «مَثابة»، اللي ما فيه تتبّع ولا تحليلات، إضافة أداة خارجية تتعارض مع وعد التطبيق نفسه. البديل في هذي الحالة التقارير اللي توفرها المتاجر: نافذة الأعطال في Xcode من المستخدمين اللي وافقوا على مشاركة بيانات التشخيص، ومؤشرات Android Vitals في لوحة Google Play.

وصلني عطل جديد. وش الخطوات؟

اقرأ التقرير وفتات الخبز، وحاول تكرر الخطأ على جهاز أو محاكي بنفس الظروف. إذا تكرر، أصلحه واكتب اختباراً يمسك الحالة نفسها عشان ما ترجع. ثم انشر الإصلاح بإصدار تدريجي: Google Play يسمح بنشر مرحلي لنسبة من المستخدمين، و App Store فيه الإصدار المرحلي للتحديثات، فلو طلع الإصلاح نفسه فيه مشكلة توقفه قبل ما يعم. وبعد النشر تابع المشكلة في الأداة: هل اختفت من الإصدار الجديد؟ ولا تنسى تفعّل التنبيهات، عشان يوصلك إشعار لما تظهر مشكلة جديدة أو يقفز عدد مشكلة قديمة بعد تحديث.

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