Booster son android avec un tueur de tâches automatisé
Beaucoup (toutes ? ;-) de ROM que l'on trouve pour Android se prétendent plus rapides et plus stables. De toute celle que j'ai testé (une bonne dizaines), c'est tout de même la MoDaCo qui ment le moins. D'un point de vue fonctionnel, la couche applicative étant la même que la ROM HTC Hero d'origine, il n'y a guère de surprises. Tout fonctionne à l'identique (bluetooth, APN à 5Mp, etc.). Pour la stabilité c'est un peu la même chose puisque cette ROM tourne sous Android 1.5 pour lequel a été conçu et testé cette couche applicative. Enfin concernant les performances, elles sont sans aucun doute meilleur. Le mérite revenant en grande partie à l'utilisation du Teknologist Kernel, un noyau linux optimisé pour le Hero, qui active le CompCache. Mais malgré cela, il est possible d'obtenir encore mieux de cette petite bestiole.
Avant de démarrer
Pour ce qui suit, il vaut mieux que vous ayez déjà suivi ce tutoriel.
Compcache
gaston$adb shell cat system/init.d/ramzswap.sh/system/xbin/insmod /system/lib/modules/tun.ko/system/xbin/insmod /system/lib/modules/lzo_decompress.ko/system/xbin/insmod /system/lib/modules/lzo_compress.ko/system/xbin/insmod /system/lib/modules/xvmalloc.ko/system/xbin/insmod /system/lib/modules/ramzswap.ko disksize_kb=131072/system/xbin/swapon /dev/block/ramzswap0echo "10" > /proc/sys/vm/swappinessecho "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorcontenu de ramzswap.sh
Comme vous le voyez, mis à par le module tun qui n'a rien à voir, la mise en oeuvre de compcache implique les modules de compression/décompression lzo, xvmalloc, un gestionnaire de mémoire écrit pour compcache et bien sur ramzswap qui est le swap en mémoire compressé fixé ici (pour une MoDaCo 3.1) à 128mo. Ensuite il ne reste plus qu'à activer le swap de linux (swapon) sur le device créé par ramzswap et de modifier la valeur de swapiness pour en profiter.
A l'usage le système est en effet plus réactif, ce n'est pas une illusion. Mais malgré cela on ne peut s'empêcher de pense qu'il s'agit là d'une emplâtre sur une jambe de bois. Loin de moi l'idée de dénigrer ce très bon travail mais consommer du CPU pour compresser de la mémoire n'entraîne un gain de performance que si le temps passé à vider la mémoire inutilisé est inférieur au temps passé à compresser les pages de swap. C'est pragmatiquement le cas mais le gain reste faible et on ne peut s'empêcher de se dire qu'une meilleur gestion de la dite mémoire devrait être plus efficace. Et c'est en faisant des recherches dans ce sens que je suis tombé sur l'auto-taskkiller.Auto taskkiller
Il existe une multitude de tueurs de tâches sur le market Android et ils ont à peu prés tous les deux mêmes défauts : ils sont aveugles s'agissant des tâches systèmes et surtout, on doit les utiliser... Fort heureusement il existe une autre approche beaucoup plus intelligente directement intégré au noyau linux pour Androphone, le taskkiller interne. Son principe est de brider quelque peu le gros avantage d'android sur iphone, le multi-tache. En effet, a force de lancer des applications qui elles-mêmes lancent des processus, etc, etc, la mémoire se trouve vite saturée (et le CPU aussi au fond). Le principe du taskkiller est une heuristique pour déterminer quelle tâches ne sont plus utiles et de les détruire pour gagner de la mémoire. Cette fonctionnalité est gérée par un pilote spécifique à Android, LowMemoryKiller, réglable par un simple echo dans /sys/... permettant d'indiquer les contraintes de destruction de processus en fonction de la mémoire restante.
Le principe technique de ce consiste à associer à chaque processus lancé, un score appelé oomadj (pour out of memory adjustement) allant de -17 à +15. Plus le score est élevé, plus le processus est jugé inutile en cas de crise de mémoire. Le score en lui-même est réglé par Android selon les références suivantes :
SYSTEM_ADJ -16
CORE_SERVER_ADJ -12
FOREGROUND_APP_ADJ 0
VISIBLE_APP_ADJ 1
SECONDARY_SERVER_ADJ 2
HIDDEN_APP_MIN_ADJ 7
CONTENT_PROVIDER_ADJ 14
EMPTY_APP_ADJ 15
Comme on le voit, les applications critiques sont positionné avec un score négatif (-12), c'est typiquement le cas de la téléphonie. A -16 c'est le système lui-même qui tourne.
Au score 0 nous avons les applications en premier plan, celles donc qu'il n'est cool de tuer car l'utilisateur bosse dessus :-) Ensuite nous avons les applications visibles (1), celles avec interface mais en arrière plan (7), etc.
Le réglage du taskkiller va fonctionner en associant un score de processus "tuables", avec un niveau de mémoire minimum servant de déclencheur. La liste des scores tuables est lisible dans le fichier /sys/module/lowmemorykiller/parameters/adj :
$adb shell cat /sys/module/lowmemorykiller/parameters/adj0,1,2,7,14,15Liste des scores tuables
Nous retrouvons ici les scores donnés plus haut, et uniquement les positifs (non-système). Maintenant pour les limites de mémoire libre, c'est le fichier /sys/module/lowmemorykiller/parameters/minfree :
$adb shell cat /sys/module/lowmemorykiller/parameters/minfree1536,2048,4096,5120,5632,6144Liste des niveaux de mémoire libre
Ces valeurs sont exprimés en "pages de 4ko". Ainsi les applications de score 7 sont tuées dés que la mémoire libre tombe au dessous de 5120x4=20mo. Les processus visibles mais qui ne sont pas utilisé à un moment T (score 1) sont tuées à 2048*4=8mo, etc... Sachant cela il est possible d'injecter dans le kernel des valeurs un peu plus agressives, comme par exemple !
$adb shell echo "1024,2048,4096,8192,16384,32768" > /sys/module/lowmemorykiller/parameters/minfreeListe des niveaux de mémoire libre
Avec ces nouvelles valeurs nous avons une tuerie de processus qui débute dés que la mémoire libre passe en dessous des 128mo (4*32768) avec une libération des applications en avant plan à 4mo de libre. De quoi garder en permanence de la mémoire sous la pédale, et donc de la réactivité.
Maintenant ces valeurs sont les miennes et vous pouvez en tester d'autres.
Mise en oeuvre du tueur
Pour simplifier nous allons prendre comme base le script d'initialisation de compcache de la MoDaCo que nous allons joyeusement remplacer par nos valeurs pour lowmemorykiller. Pour cela nous allons récupérer ce script en local :
gaston$adb pull /system/init.d/ramzswap.sh ramzswap.sh12 KB/s (527 bytes in 0.042s)Liste des niveaux de mémoire libre
Ceci fait, avec votre éditeur préféré, vous allez modifier ce script pour mettre en commentaire les éléments de compcache et ajouter ceux du tueur
#/system/xbin/insmod /system/lib/modules/tun.ko # pas besoin de ce module pour moi
#/system/xbin/insmod /system/lib/modules/lzo_decompress.ko
#/system/xbin/insmod /system/lib/modules/lzo_compress.ko
#/system/xbin/insmod /system/lib/modules/xvmalloc.ko
#/system/xbin/insmod /system/lib/modules/ramzswap.ko disksize_kb=131072
#/system/xbin/swapon /dev/block/ramzswap0
#echo "10" > /proc/sys/vm/swappiness
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "1024,2048,4096,8192,16384,32768" > /sys/module/lowmemorykiller/parameters/minfreescripte ramzswap.sh
Voilà c'est tout. Vous pouvez maintenant ré-injecter le fichier dans le téléphone et redémarrer
# remontage de la partition système en écrituregaston$adb remount# injection du nouveau scriptgaston$adb push ramzswap.sh /system/init.d/ramzswap.sh12 KB/s (527 bytes in 0.042s)# redémarragegaston$adb shell rebootListe des niveaux de mémoire libre
Conclusion
Le taskkiller permet d'adresser le problème de la taille limité des androphones qui implique un travail trop intensif du garbage collector de la machine virtuel lorsqu'elle vient à manquer. Sur ce point, cette technique est à mon sens plus efficace que compcache. Maintenant s'agissant de la rapidité pour passer d'une application à l'autre, il est évident que compcache est plus adapté car taskkiller va vous obliger à relancer vos applications, avec donc un temps de démarrage supplémentaire. A vous de voir ce qui convient le mieux à votre usage.
Toujours est-il que si on avait un doute, Android est bien un petit GNU/Linux qu'il est possible de tweaker à loisir.
