لماذا يبدو تطبيق Android بطيئًا بعد كل تحديث

لماذا يبدو تطبيق Android بطيئًا بعد التحديث

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

والملف التعريفي الأساسي (baseline profile) هو الحل لذلك النصف من المشكلة. وهو تسجيل، يُجرى مرة واحدة على هاتف اختبار، لأجزاء التطبيق التي تستخدمها الشاشات الرئيسية، ويُشحن داخل التطبيق حتى يتمكن Google Play من تهيئتها عند تثبيت تحديث.

ما وجده مهندسنا على هاتف اختبار

لم يكن البطء شاشة ثقيلة واحدة، بل تكاليف صغيرة عدة تتزامن في اللحظات نفسها.

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

ما غيّرناه

أزلنا العمل المتكرر وأعطينا التطبيق خريطة لنفسه يرحل بها مع كل تحديث.

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

أين وصلنا، وما لا ندّعيه

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

ما يمكنك التحقق منه بنفسك

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

ما تفعله بعد ذلك

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