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