تطبيقك بطيء ويعلّق؟ دليل صاحب المشروع لفهم أداء التطبيق وقياسه

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

أربعة أشياء يحسها المستخدم كـ«بطء»

• زمن الفتح: كم ثانية من الضغط على الأيقونة لين يقدر يستخدم التطبيق.
• التقطيع (Jank): السحب في القوائم مو ناعم، والحركات تتقطع.
• انتظار البيانات: الشاشة فاضية أو فيها دائرة تدور بينما الطلب رايح للخادم.
• استهلاك الموارد: البطارية تنزل، الجوال يسخن، والتطبيق حجمه يأكل المساحة.

كل واحد من هذي له سبب مختلف وحل مختلف. عشان كذا «سرّعوا التطبيق» طلب ما يفيد المبرمج؛ حدّد وش بالضبط اللي بطيء.

زمن الفتح: لا تحمّل الدنيا قبل أول شاشة

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

التقطيع: غالباً مشكلة في طريقة بناء الشاشة

في Flutter المحرّك نفسه سريع، ومحرّك الرسم Impeller صار الافتراضي على الآيفون والأندرويد الحديث وحل كثير من مشاكل التقطيع القديمة. لكن الكود يقدر يخرّب هذا: قوائم تبني كل العناصر مرة وحدة بدل ما تبني الظاهر فقط، صور بدقة ضخمة تُعرض بحجم صغير، أو شاشة كاملة تُعاد بناؤها لأن رقماً صغيراً في الزاوية تغيّر. أداة Flutter DevTools تكشف هذي المشاكل بالضبط، والمبرمج المحترف يفتحها قبل ما يخمّن.

انتظار البيانات: خلّ الانتظار يبان أقصر

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

حجم التطبيق: كل ميغابايت له ثمن

المستخدم اللي مساحته ممتلئة يشوف حجم التطبيق في المتجر ويقرر. أسباب التضخم المعتادة: خطوط كاملة بكل الأوزان وهو يستخدم وزنين، صور وأيقونات PNG بدل SVG أو WebP، مكتبات ضخمة لميزة صغيرة، وفيديوهات ترحيبية داخل التطبيق. أمر flutter build مع خيار تحليل الحجم يعطي خريطة واضحة وش اللي ماخذ المساحة.

أسئلة تطرحها على المبرمج

• على أي جهاز قديم أو متوسط جرّبت التطبيق؟
• هل اختبرت بوضع Profile أو Release، مو Debug؟ (وضع التطوير أبطأ بطبيعته ولا يعكس الحقيقة)
• وش أثقل شاشة في التطبيق ووش السبب؟
• هل عندنا أداة تسجّل الأعطال والبطء من أجهزة المستخدمين الحقيقية، مثل Firebase Crashlytics و Performance Monitoring؟

البطارية والسخونة: البطء اللي ما يُرى

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

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