Pour la plupart des tâches de programmation, la taille de la page n'est pas pertinente. Toutefois, si vous allouez de grandes quantités de mémoire, travaillez sur des composants hautement optimisés, interagissez directement avec le noyau ou effectuez de grandes quantités de manipulation de fichiers, la transition d'Android vers la taille de page de 16 Ko pourrait ajouter des considérations à votre analyse des performances. Ce document met en évidence certaines façons dont la taille des pages modifie la dynamique des performances.
Détecter les problèmes de mémoire
Lorsque vous allouez de la mémoire avec mmap, assurez-vous de toujours transmettre un argument qui est un multiple de la taille de la page. Si vous demandez 4096 octets sur un système avec une taille de page de 16 Ko, le noyau alloue 16 KB, ce qui gaspille 12 KB d'espace. Pour les détecter, vous pouvez afficher /proc/maps, /proc/smaps (ou utiliser l'outil Android showmap qui affiche clairement l'espace perdu) ou vérifier le strace de votre processus.
Détecter les problèmes d'espace sur le disque
Les appareils lancés sur Android 15 et versions ultérieures sont alignés sur 16 Ko par défaut, et de nombreuses applications le sont également. Quel que soit le système, de nombreux fichiers ont un remplissage accru. Pour afficher la taille réelle sur le disque, vous pouvez utiliser du <my file> pour voir le nombre de kilo-octets qu'occupe un fichier. Pour afficher la taille apparente d'un fichier, vous pouvez utiliser du -b <my file>, qui indique la taille en octets. Lorsque la taille apparente est supérieure à la taille réelle, cela signifie généralement que le fichier est compressé ou comporte des régions éparses. Lorsque la taille apparente est inférieure à la taille réelle, il est probable que le fichier contienne des métadonnées supplémentaires ou qu'il soit divisé sur le disque. Ces vérifications vous permettent d'analyser la taille réelle des fichiers sur le disque.