Google Play يشدد قواعد تطبيقات أندرويد في 2027 بحدود جديدة للذاكرة

تستعد Google لرفع سقف الجودة التقنية للتطبيقات والألعاب المنشورة عبر Google Play. واعتبارًا من فبراير 2027، ستقيس المنصة مجموعة من مؤشرات «السلوك السيئ» المرتبطة باستهلاك الذاكرة وتحسين الكود، وقد تفرض على التطبيقات التي تتجاوز الحدود تقليل الظهور في المتجر أو تقييد إمكانات النشر، من دون أن يعني ذلك حذفها تلقائيًا من Google Play.

وتأتي خطوة منفصلة في أبريل 2027: إذ سيتعين على التطبيقات التي تتيح تسجيل الدخول دعم ميزة Zero-Tap Sign-In أثناء نقل البيانات إلى جهاز جديد، بالاعتماد على نظام Restore Credentials في أندرويد. أما الألعاب فهي معفاة حاليًا من هذا الشرط الخاص بترحيل بيانات تسجيل الدخول. 17

ما الذي ستقيسه Google Play؟

تركز السياسة الجديدة على ثلاثة مجالات قد تؤدي إلى بطء التطبيقات أو تعطلها أو زيادة استهلاك موارد الجهاز:

1. استهلاك الذاكرة الديناميكية

ستقيس Google حجم الذاكرة المقيمة المجهولة التي يستخدمها التطبيق، أو Anonymous RSS، إلى جانب الذاكرة المضغوطة في قسم التبديل Swap. ويعني ذلك التركيز على الذاكرة الخاصة التي يستهلكها التطبيق أثناء التشغيل، بدل احتساب كل ملفات الكود أو الأصول المخزنة على الجهاز باعتبارها ذاكرة تطبيق.

وبالنسبة إلى الألعاب، تتدرج حدود الذاكرة الديناميكية في الواجهة الأمامية وفق سعة RAM في الجهاز. ويتراوح النطاق المعلن بين 2.25 غيغابايت للأجهزة المزودة بذاكرة RAM سعتها 4 غيغابايت و5 غيغابايت للأجهزة التي تملك 16 غيغابايت من RAM. وبدل تطبيق حد موحد على جميع الهواتف والأجهزة اللوحية، ستقيّم Google Play الأداء بحسب فئات قدرات الأجهزة.

2. ذاكرة الصور النقطية Bitmap

ستُفحص ذاكرة الصور النقطية في حالات تشغيل التطبيق في الواجهة، وعمله في الخلفية، ووجوده في الذاكرة المؤقتة. وتبلغ الحدود:

• 200 ميغابايت عندما يكون التطبيق في الواجهة أو في الخلفية.
• 400 ميغابايت عندما يكون التطبيق في حالة التخزين المؤقت.

والهدف هو منع بقاء الأصول المرئية في ذاكرة النظام دون حاجة، خصوصًا عندما لا تكون ظاهرة للمستخدم أو مطلوبة فورًا.

3. تحسين كود DEX

ستحتاج الألعاب التي يتجاوز كود DEX لديها 50 ميغابايت إلى تحقيق تغطية لا تقل عن 25% من حزمة التطبيق App Bundle عبر تصغير الكود وتحسينه وتمويهه. ويمكن للمطورين استخدام أدوات مثل R8 أو أي أداة أخرى لتقليص الكود غير الضروري وتحسين كفاءة الحزمة التي تصل إلى المستخدم.

كيف ستُطبَّق القواعد؟

لن تعتمد Google Play على جلسة واحدة سيئة بشكل استثنائي للحكم على التطبيق. بل ستستخدم مقياس المئين التسعين P90 من البيانات المجمعة خلال فترة متحركة مدتها 28 يومًا. وعمليًا، تستهدف السياسة مشكلات الأداء المستمرة التي تظهر لدى المستخدمين الحقيقيين، لا أسوأ قراءة منفردة على جهاز واحد.

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

ومن المحتمل أيضًا أن تتغير الحدود مع جمع Google مزيدًا من البيانات وتحسين فهمها لاختلافات الأداء بين أنواع الأجهزة والتطبيقات. لذلك من الأفضل التعامل مع الأرقام المنشورة باعتبارها خط أساس للمراقبة المستمرة، لا شهادة نجاح تُحصل مرة واحدة.

مهلة منفصلة لتسجيل الدخول بلا نقرات

تتعلق القاعدة الثانية بجانب مختلف من تجربة أندرويد: الانتقال إلى هاتف أو جهاز جديد. فمنذ أبريل 2027، ستحتاج التطبيقات التي تستخدم حسابات المستخدمين إلى دعم Zero-Tap Sign-In، بحيث تستعيد حالة تسجيل الدخول تلقائيًا أثناء نقل المستخدم من جهاز أندرويد إلى آخر، عبر واجهة Restore Credentials API.

وتعمل Restore Credentials من خلال Credential Manager، وهي مصممة لإعادة تسجيل المستخدم في التطبيق بصمت عند استعادته على جهاز جديد. كما يمكنها العمل بصورة مستقلة عن وسيلة المصادقة الأساسية للتطبيق، سواء كانت كلمة مرور أو مفتاح مرور Passkey أو تسجيل دخول موحدًا عبر مزود خارجي. 1719

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

ما علاقة ذلك بنظام Android 17؟

تكمل قواعد Google Play الجديدة ضوابط الذاكرة في Android 17 ولا تستبدلها. فقد أضاف Android 17 حدودًا للذاكرة تختلف بحسب إجمالي RAM في الجهاز، وبدأ تطبيقها على أجهزة Pixel، بينما تتوقع Google أن تعتمدها شركات أخرى تدريجيًا على أجهزة تتراوح سعة ذاكرتها بين 4 غيغابايت وأكثر من 16 غيغابايت.

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

وهنا يكمن الفرق الأساسي: يحدد Android 17 ما قد يحدث للتطبيق أثناء تشغيله على جهاز بعينه، بينما تحدد قواعد Google Play الجديدة ما إذا كان التطبيق سيحافظ على مستوى الظهور الطبيعي وإمكانات النشر في المتجر.

ماذا ينبغي للمطورين أن يفعلوا الآن؟

ينبغي للمطورين، خصوصًا أصحاب التطبيقات والألعاب الكبيرة، البدء بالخطوات التالية:

1. تدقيق استخدام Anonymous RSS وCompressed Swap خلال جلسات التشغيل في الواجهة والخلفية.
2. تتبع ذاكرة الصور النقطية بصورة منفصلة عن استخدام الذاكرة العامة، بما في ذلك حالات التخزين المؤقت.
3. فحص حجم كود DEX وقياس نسبة تغطية App Bundle الناتجة عن التصغير والتحسين والتمويه.
4. اختبار التطبيق على عدة فئات من سعة RAM، بدل الاعتماد على الأجهزة مرتفعة المواصفات فقط.
5. متابعة أدوات التشخيص المقبلة في Play Console ومؤشرات Android Vitals.
6. مراجعة مسار المصادقة في التطبيق والتخطيط لدعم Restore Credentials قبل أبريل 2027.

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