أعلنت Google خلال أغسطس 2026 عن تغييرين مرتبطين يجب التعامل معهما كمشروع أداء واحد. يطبق Android 17 حدوداً للذاكرة على مستوى التطبيق، بدءاً من أجهزة Pixel، لحماية الجهاز من التطبيقات التي تستهلك ذاكرة مفرطة. وفي 26 أغسطس نشرت Google Play حدود جودة جديدة تقيس استخدام الذاكرة وتحسين كود DEX، ويبدأ تطبيقها في فبراير 2027.
هذه ليست مطالبة برفع targetSdkVersion فقط. حدود Android 17 المذكورة في صفحة تغييرات جميع التطبيقات تنطبق عند تشغيل التطبيق على Android 17 بغض النظر عن target SDK. أما متطلبات Play فتقيس الإصدارات التي تتوفر عنها بيانات وتستخدم نافذة متحركة من 28 يوماً. النتيجة العملية: قد ينجح البناء والمراجعة اليدوية، ثم يتباطأ التطبيق أو ينهيه النظام على جهاز حقيقي، وقد تتأثر لاحقاً رؤيته أو قدرته على النشر إذا تجاوز الحدود.
توثيق حدود ذاكرة Android 17 ومتطلبات الجودة التقنية في Google Play
ماذا يفعل Android عندما يتجاوز التطبيق ميزانيته؟
تشرح Google مساراً تدريجياً. عندما يصل التطبيق إلى الحد المخصص له، يدفع النظام بعض صفحاته إلى zRAM، وهي ذاكرة مضغوطة داخل RAM. هذا يؤخر الإنهاء، لكنه يضيف كلفة ضغط وفك ضغط على المعالج وقد يظهر على شكل تقطيع في الواجهة أو بطء. إذا استمر الاستهلاك في الارتفاع بعد عتبة zRAM، يمكن للنظام إنهاء العملية.
لا تشخص الحالة على أنها OOM تقليدية فقط. بعد الإنهاء، افحص ApplicationExitInfo.getDescription(). إذا طبق Memory Limiter الحد، يكون السبب REASON_OTHER ويتضمن الوصف النص MemoryLimiter:AnonSwap. ويمكن استخدام trigger-based profiling مع TRIGGER_TYPE_ANOMALY لالتقاط heap dump عند الوصول إلى الحد.
يوفر Android 17 أوامر اختبار صريحة على الأجهزة التي تطبق المحدد:
adb shell am memory-limiter status
adb shell am memory-limiter manual <pid> 512
adb shell am memory-limiter ignore <uid>الأمر اليدوي يستقبل الحد بالميغابايت. لا تجعل اختبار ignore جزءاً من نسخة الإنتاج ولا تستخدمه لإخفاء المشكلة. الغرض منه المقارنة والتشخيص، ثم يجب إعادة الوضع الافتراضي والتحقق من سلوك التطبيق تحت الضغط.
كيف تقيس Google Play السلوك السيئ؟
تضيف Android vitals مقياسين أساسيين: استخدام الذاكرة الديناميكية Anonymous RSS + Swap، واستخدام ذاكرة الصور Bitmap. يقيس الأول heap الخاص بـ Java أو Kotlin، والذاكرة الأصلية، وخرائط الذاكرة المجهولة، إضافة إلى الذاكرة المضغوطة أو المنقولة إلى zRAM. لا يضم ملفات الكود والأصول المخزنة على الجهاز.
تجمع Google العينات من مستخدمين وافقوا على المشاركة، ثم تعرضها مجمعة ومجهولة. التقييم يعتمد القيمة المئوية التسعين P90 حسب حالة التطبيق وفئة RAM. تستخدم Play آخر 28 يوماً، وتشمل بيانات مقياس الذاكرة Android 13 فما بعد، وعلى الهواتف والأجهزة اللوحية فقط.
للـ apps غير المصنفة ألعاباً، أمثلة حدود P90 المعلنة للذاكرة الديناميكية هي:
| RAM الفعلية | الواجهة الأمامية | خدمة يلاحظها المستخدم | الخلفية |
|---|---|---|---|
| 4 GB | 2 GB | 1 GB | 1 GB |
| 6 GB | 2.25 GB | 1.25 GB | 1.25 GB |
| 8 GB | 2.25 GB | 1.5 GB | 1.5 GB |
| 12 GB | 3.25 GB | 1.75 GB | 1.75 GB |
| 16 GB | 4.25 GB | 2 GB | 2 GB |
أما Bitmap memory فتكون عتبة السلوك السيئ أعلى من 200 MB في خدمة يلاحظها المستخدم أو الخلفية، وأعلى من 400 MB في الحالة cached. وجود شرطة في بعض خلايا الجدول الرسمي يعني أن Google لم تنشر عتبة لتلك الفئة، وليس أن الاستهلاك غير محدود.
كلفة الأعمال ليست في RAM وحدها
بدءاً من فبراير 2027، تقول Google إن التطبيقات والألعاب التي لا تحقق حدود الذاكرة وتحسين DEX قد تتأثر رؤيتها وقدرات النشر في Play. التفاصيل التشغيلية الإضافية ستصدر لاحقاً، لذلك لا يجوز الادعاء أن عقوبة محددة مطبقة اليوم. لكن الانتظار حتى يظهر التحذير يترك نافذة 28 يوماً بين الإصلاح وانعكاسه الكامل في القياس.
التطبيق الثقيل يكلف أيضاً قبل أي إجراء من المتجر: جلسات دعم بسبب الإغلاق، تقييمات سيئة، استهلاك بطارية، وأجهزة اختبار إضافية. وفي تطبيق تجارة أو خدمة، إنهاء العملية أثناء الدفع أو رفع ملف ليس خطأ أداء داخلياً فقط، بل فقدان تحويل وثقة.
أضف إلى ذلك شرط تحسين DEX. في فبراير 2027 يجب أن تحقق الرفعات ذات حجم DEX غير المهمل حداً أدنى 25% في كل من obfuscation وoptimization وshrinking. يطبق القياس على apps التي يتجاوز DEX فيها 10 MB، وعلى games التي تتجاوز 50 MB. يمكن استخدام R8 أو أداة shrinker أخرى، لكن يجب اختبار build الإصدار بعد التحسين لأن قواعد keep الخاطئة قد تزيل كوداً يعتمد على reflection أو serialization.
خطة تنفيذ خلال ستة أسابيع
1. أنشئ baseline من إصدار الإنتاج
سجل P50 وP90 للواجهة والخلفية حسب RAM tier وإصدار Android ونسخة التطبيق. اربط ذلك بمعدل ANR وcrash وزمن فتح الشاشات الثقيلة. لا تقارن debug build بإصدار Play، لأن أدوات التصحيح وغياب R8 تغير النتيجة.
2. اختبر التدفقات المكلفة
اختر تسجيل الدخول، feed طويل، التقاط الصور، تحريرها، الخريطة، الفيديو، الرفع، والخروج إلى الخلفية ثم العودة. نفذها على 4 و6 و8 GB إن أمكن، مع التكرار وتغيير الاتجاه واللغة. في React Native افصل JavaScript heap عن native allocations والصور، ولا تفترض أن شاشة بسيطة بصرياً تعني استهلاكاً منخفضاً.
3. عالج الملكية والاحتفاظ
ابحث عن Activity أو Context محتفظ به، listeners غير ملغاة، caches بلا سقف، صور decoded أكبر من حجم العرض، وقوائم تحمل كل الصفحات. طبق pagination وimage resizing وonTrimMemory، وأفرغ الموارد التي لا تحتاجها الخلفية. لا تجعل cache داخل الذاكرة نسخة ثانية كاملة من قاعدة البيانات.
4. فعّل تحسين الإصدار بأمان
شغّل minification وresource shrinking في build الإصدار، واستخدم proguard-android-optimize.txt، ثم راجع R8 Configuration Analyzer وقواعد keep الواسعة. احتفظ بملفات mapping لكل إصدار كي تبقى crash traces قابلة للقراءة. اختبر deep links والإشعارات وJSON وSDKs التي تستخدم reflection.
5. أضف بوابة CI ومرحلة إطلاق
ضع ميزانية ذاكرة للتدفقات الحرجة ولا تسمح بتراجع غير مفسر. ارفع إلى internal ثم closed track، واقرأ Android vitals حسب الإصدار قبل التوسع. أوقف rollout إذا ارتفع P90 أو ظهر MemoryLimiter:AnonSwap أو تراجعت crash-free sessions.
المخاطر وحدود التوافق والتوفر
- يبدأ Memory Limiter بأجهزة Pixel، وتقول Google إن مزيداً من المصنعين سيستخدمونه خلال العام التالي عبر أجهزة من 4 GB إلى أكثر من 16 GB. لا تفترض أن كل جهاز Android 17 يطبق الحد نفسه اليوم.
- الحدود مبنية على RAM الكلية وحالة العملية، وليست رقماً ثابتاً واحداً لكل الأجهزة.
- بيانات Play مجمعة من أجهزة مستخدمين مشاركين، لذلك قد يكون حجم العينة صغيراً لإصدار أو سوق محدود.
- المتطلبات المعلنة عالمية للهواتف والأجهزة اللوحية المنشورة على Google Play، وليست ميزة مقيدة بدولة. لكن وصول Android 17 والأجهزة التي تطبق المحدد يختلف حسب المصنع والطراز والسوق.
- العتبات والسياسات قد تتغير قبل فبراير 2027. سجل تاريخ كل قراءة وأعد مراجعة صفحة المتطلبات قبل الإطلاق.
توصية عملية
لا تبدأ بحملة تقليل عشوائي لكل allocation. ابدأ من P90 للتدفقات التي يستخدمها العملاء فعلاً، ثم اربط كل إصلاح بأثر مرئي: تقليل الإنهاء، سلاسة أفضل، أو استعادة أسرع. بالنسبة لتطبيق عربي، اختبر خطوط العربية، صور المحتوى، القوائم المعكوسة، وتبديل اللغة لأنها قد تكشف caches ومسارات rendering لا تظهر في اختبار إنجليزي واحد.
إذا كنت تخطط لإطلاق أو صيانة تطبيق Android، اجعل تقرير الذاكرة ونتيجة R8 جزءاً من تعريف الجاهزية مثل التوقيع وسياسة الخصوصية. فبراير 2027 هو موعد التنفيذ المعلن، لكن جمع baseline الصحيح يجب أن يبدأ الآن كي يبقى لديك وقت لإصلاح الكود ومشاهدة 28 يوماً من بيانات Play بعد الإصلاح.
المصادر وتاريخ المراجعة
- تغييرات Android 17 لجميع التطبيقات وحدود الذاكرة
- شرح Google للاستعداد لحدود الذاكرة الأوسع، 19 أغسطس 2026
- إعلان جودة التطبيقات وموعد التنفيذ، 26 أغسطس 2026
- الجداول الرسمية لمتطلبات Google Play التقنية
- تمت مراجعة الحالة والعتبات والنطاق والتواريخ في 29 أغسطس 2026.