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, si vous travaillez sur des composants hautement optimisés, si vous interagissez directement avec le noyau ou si vous effectuez de grandes quantités de manipulation de fichiers, la transition d'Android vers la taille de page de 16 Ko peut ajouter des éléments à prendre en compte dans votre analyse des performances. Ce document met en évidence certaines façons dont la taille de la page 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 détecter ces problèmes, vous pouvez afficher /proc/maps, /proc/smaps (ou utiliser l'outil Android showmap, qui affiche clairement l'espace gaspillé) ou vérifier le strace de votre processus.
Détecter les problèmes d'espace 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 sont également alignées sur 16 Ko. 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'un fichier occupe. Pour afficher la
taille apparente d'un fichier, vous pouvez utiliser du -b <my file>, qui affiche 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 qu'il comporte des régions creuses. Lorsque la taille apparente est inférieure à la taille réelle, le fichier comporte probablement des métadonnées supplémentaires ou peut être divisé sur le disque. À l'aide de ces vérifications, vous pouvez analyser la taille réelle des fichiers sur le disque.