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, que vous travaillez sur des composants hautement optimisés, que vous interagissez directement avec le noyau ou que vous effectuez de nombreuses manipulations de fichiers, la transition d'Android vers la taille de page de 16 Ko peut ajouter des considérations à votre analyse des performances. Ce document met en évidence certains aspects de la taille de page qui modifient 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 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. L'affichage de /proc/maps, /proc/smaps (ou l'utilisation de l'outil Android showmap qui imprime l'espace gaspillé de manière attrayante) ou la vérification du strace de votre processus peuvent vous aider à les détecter.
Détecter les problèmes d'espace disque
Les appareils qui s'exécutent sur Android 15 ou version ultérieure disposent par défaut d'ELF alignés sur 16 ko, et de nombreuses applications sont également alignées sur 16 ko. Quel que soit le système, de nombreux fichiers ont un rembourrage 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 peu denses. Lorsque la taille apparente est inférieure à la taille réelle, le fichier contient probablement des métadonnées supplémentaires ou peut être divisé sur le disque. Grâce à ces vérifications, vous pouvez analyser la taille réelle des fichiers sur le disque.