بالنسبة إلى معظم مهام البرمجة، لا يكون حجم الصفحة ذا صلة. ومع ذلك، إذا كنت تخصص كميات كبيرة من الذاكرة أو تعمل على مكونات محسَّنة للغاية أو تتعامل مباشرةً مع النواة أو تُجري عمليات معالجة ملفات كبيرة، قد يؤدي انتقال Android إلى حجم صفحة بحجم 16 كيلوبايت إلى إضافة اعتبارات إلى تحليل الأداء. يُبرز هذا المستند بعض الطرق التي يغيّر بها حجم الصفحة ديناميكية الأداء.
رصد مشاكل الذاكرة
عند تخصيص ذاكرة باستخدام mmap، تأكَّد من ضبط وسيطة
تكون دائمًا مضاعِفًا لحجم الصفحة. إذا طلبت 4096 بايت على نظام حجم صفحته
16 كيلوبايت، تخصص النواة 16 KB، ما يؤدي إلى إهدار 12 KB من
المساحة. يمكن أن يساعد عرض /proc/maps أو /proc/smaps (أو استخدام أداة Android showmap
التي تُطبع المساحة المهدرة بشكل جيد) أو التحقّق من strace العملية
في رصد هذه الأخطاء.
رصد المشاكل المتعلّقة بمساحة القرص
تتضمّن الأجهزة التي تعمل بالإصدار 15 من نظام التشغيل Android والإصدارات الأحدث ملفات ELF مُحاذية بحجم 16 كيلوبايت بشكلٍ default، كما تتضمّن العديد من التطبيقات ملفات ELF مُحاذية بحجم 16 كيلوبايت أيضًا. بغض النظر عن
النظام، تم زيادة الحشو في العديد من الملفات. للاطّلاع على الحجم الفعلي على القرص،
يمكنك استخدام du <my file> لمعرفة عدد الكيلوبايت التي يشغلها الملف. للاطّلاع على
الحجم الظاهر لملف، يمكنك استخدام du -b <my file> الذي يعرض لك الحجم
بالبايت. عندما يكون الحجم الظاهر أكبر من الحجم الفعلي، يعني ذلك عادةً
أنّ الملف مضغوط أو يتضمّن مناطق متفرقة. عندما يكون الحجم الظاهر
أصغر من الحجم الفعلي، من المرجّح أن يحتوي الملف على بيانات وصفية إضافية أو قد يكون مقسّمًا
على القرص. باستخدام عمليات التحقّق هذه، يمكنك تحليل الحجم الفعلي للملفات على القرص.