Les ajustements du script les rassemblent tous. Optimisation de la base de données

Mot de l'auteur :
Cet article a été écrit par moi, c'est-à-dire , avec l'utilisation de , qui ne prétend pas être universel et la découverte de « l'Amérique ». Il est plutôt destiné à la familiarisation et au partage d'expériences et de réflexions personnelles, et un peu à la science))))

Introduction:
Ces scripts d'ajustement pour init.d sont conçus pour améliorer les performances de Google Phone et le personnaliser en fonction de vos besoins.
Pour que les modifications fonctionnent, vous avez besoin de la prise en charge de init.d par le micrologiciel de votre appareil, ainsi que de .
Cependant, la prise en charge d'init.d peut être émulée à l'aide de programmes tels que ou en activant les éléments appropriés dans les programmes. De plus, mcTweaker implémente de nombreux ajustements pour votre appareil.
Permettez-moi de vous rappeler que BusyBox peut être installé dans un firmware personnalisé, et de nombreux ajustements ont déjà été implémentés !
Vous faites tout à vos risques et périls ! Pour les manipulations, vous avez besoin d'un accès root !

Informations générales:
Les scripts de réglage doivent être placés dans le chemin /system/etc/init.d/ :

Pour modifier/ajouter/supprimer des scripts, j'ai utilisé .
Si vous n'avez pas de dossier init.d, alors les scripts ne fonctionneront pas à 100 % !

Chaque fichier script commence par la ligne :

#!/system/bin/sh
Ensuite, insérez le code de réglage, par exemple : echo "500" >
écho "1000" >
Exemple de fichier de script

#!/system/bin/sh
echo "500" > /proc/sys/vm/dirty_expire_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_centisecs

Nous nommons le fichier de script de quelque manière que ce soit, mais pour que nous puissions nous-mêmes les reconnaître, par exemple, Batterie_tweak- réglage de la batterie.

Ajustements :
1) Ajustements de la vitesse de connexion Internet

echo "0" > /proc/sys/net/ipv4/tcp_timestamps ;
echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse ;
écho "1" > /proc/sys/net/ipv4/tcp_sack ;
echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle ;
echo "1" > /proc/sys/net/ipv4/tcp_window_scaling ;
echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes ;
echo "30" > /proc/sys/net/ipv4/tcp_keepalive_intvl ;
echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout ;
echo "404480" > /proc/sys/net/core/wmem_max ;
echo "404480" > /proc/sys/net/core/rmem_max ;
echo "256960" > /proc/sys/net/core/rmem_default ;
echo "256960" > /proc/sys/net/core/wmem_default ;
écho "4096, 16384, 404480" > /proc/sys/net/ipv4/tcp_wmem ;
écho "4096, 87380, 404480" > /proc/sys/net/ipv4/tcp_rmem ;

2) Ajustements pour la gestion de la mémoire des machines virtuelles

écho "4096" > /proc/sys/vm/min_free_kbytes
echo "0" > /proc/sys/vm/oom_kill_allocating_task ;
écho "0" > /proc/sys/vm/panic_on_oom ;
echo "0" > /proc/sys/vm/laptop_mode ;
echo "0" > /proc/sys/vm/swappiness
echo "50" > /proc/sys/vm/vfs_cache_pression
écho "90" > /proc/sys/vm/dirty_ratio
écho "70" > /proc/sys/vm/dirty_background_ratio

3) Ajustements du noyau

echo "8" > /proc/sys/vm/page-cluster ;
echo "64000" > /proc/sys/kernel/msgmni ;
echo "64000" > /proc/sys/kernel/msgmax ;
echo "10" > /proc/sys/fs/lease-break-time ;
echo "500, 512000, 64, 2048" > /proc/sys/kernel/sem ;

4) Augmentation de la durée de vie de la batterie

echo "500" > /proc/sys/vm/dirty_expire_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_centisecs

5) Ajustez la vitesse de lecture de la carte SD (augmentez le cache de la carte)

echo "2048" > /sys/devices/virtual/bdi/179:0/read_ahead_kb ;

6) Défragmentation des fichiers de base de données ?

pour moi dans \
`trouver /data -iname "*.db"`
faire\
sqlite3 $i "VIDE;";
fait

7) Désactivez les enregistreurs (aucun fichier journal ne sera écrit)

rm /dev/log/main

8) Nous configurons les seuils auxquels les applications seront déchargées en cas de mémoire insuffisante

echo "2048, 3072, 6144, 15360, 17920, 20480" > /sys/module/lowmemorykiller/parameters/minfree

9) Ajustements de la gestion du cache

LOOP=`ls -d /sys/block/loop*`;
RAM=`ls -d /sys/block/ram*`;
MMC=`ls -d /sys/block/mmc*`;
pour j dans $LOOP $RAM
faire
echo "0" > $j/queue/rotational ;
echo "2048" > $j/queue/read_ahead_kb ;
fait

10) Des ajustements du processeur ?

SAMPLING_RATE=$(busybox expr `cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency` \* 750/1000)
echo 95 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo $SAMPLING_RATE > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

11) Transférez le cache Dalvik vers la section cache pour soulager la section données

CACHESIZE=$(df -k /cache | tail -n1 | tr -s " " | cut -d " " -f2)
si [ $CACHESIZE -gt 80000 ]
alors
echo "Grand cache détecté, déplacement du cache Dalvik vers /cache"
si [! -d /cache/dalvik-cache ]
alors
occupébox rm -rf /cache/dalvik-cache /data/dalvik-cache
mkdir /cache/dalvik-cache /data/dalvik-cache
fi

Busybox chown 1000:1000 /cache/dalvik-cache
Busybox chmod 0771 /cache/dalvik-cache

# lier le montage Dalvik-cache pour que nous puissions toujours démarrer sans la carte SD
Busybox mount -o bind /cache/dalvik-cache /data/dalvik-cache
occupébox chown 1000:1000 /data/dalvik-cache
Busybox chmod 0771 /data/dalvik-cache
autre
echo "Petit cache détecté, le cache Dalvik restera sur /data"
fi

12) Suppression du cache, des fichiers tmp et autres déchets

#supprimer le cache, tmp et les fichiers inutilisés
rm -f /cache/*.apk
rm -f /cache/*.tmp
rm -f /data/dalvik-cache/*.apk
rm -f /data/dalvik-cache/*.tmp

si [ -e /data/system/userbehavior.db ]
alors
rm -f /data/system/userbehavior.db
fi

si [ -d /data/system/usagestats ]
alors
chmod 400 /données/système/usagestats
fi

si [ -d /data/system/appusagestats ]
alors
chmod 400 /data/system/appusagestats
fi

#supprimer le journal principal
si [ -e /dev/log/main ]
alors
rm -f /dev/log/main
fi

13) Changer la priorité des processus - uniquement les processus standard. Il est conseillé de vérifier les noms des processus sur votre appareil avant utilisation. Conçu pour augmenter le bon fonctionnement de l'appareil et rendre la réponse plus agréable)

renice -20 "pidof com.android.phone"
renice -19 "pidof com.android.inputmethod.latin"
renice -19 "pidof com.swype.android.inputmethod"
renice -17 "pidof com.android.systemui"
renice -9 "pidof com.android.settings"
renice -9 "pidof com.android.vending"
renice -6 "pidof com.sec.android.app.camera"
renice -6 "pidof com.sec.android.app.fm"
renice -6 "pidof com.google.android.apps.maps"
renice -4 "pidof com.google.android.apps.googlevoice"
renice -3 "pidof android.process.media"

p.s. Je le répète, toutes les manipulations avec votre appareil reposent sur votre conscience ! Lorsque vous utilisez des programmes de réglage comme mcTweaker, supprimez vos scripts utilisateur pour éviter les situations désagréables et faites toujours une sauvegarde !
p.p.s. L'article sera mis à jour avec de nouvelles informations dès que possible ! Posez des questions dans les commentaires !

Fichier joint n°1 :

Attention! Vous n'êtes pas autorisé à afficher le texte masqué.

La part du lion des paramètres du système Android cachés aux yeux de l'utilisateur est stockée dans un seul fichier appelé build.prop. Modifier correctement les paramètres permettra de donner une seconde vie au gadget : améliorer l'autonomie et les performances, optimiser l'interface. Dans l'article, nous montrerons comment éditer facilement build.prop et donnerons des exemples de modifications utiles, ainsi que celles qui errent d'article en article sur différentes ressources, mais qui ne fonctionnent en fait pas.

Le fichier build.prop fonctionne comme suit : au démarrage du smartphone, le contenu y est lu, ce qui affecte d'une manière ou d'une autre la logique du code du système d'exploitation. Parmi ces paramètres cachés à l’utilisateur, il y en a à la fois des paramètres profondément systémiques qu’il est préférable de laisser intacts et d’autres qui peuvent être modifiés sans douleur. Par exemple, en ajoutant quelques lignes à build.prop, vous pouvez accélérer le chargement du gadget, supprimer le délai d'un appel entrant ou activer la rotation automatique de l'affichage sur l'écran de verrouillage. Nous allons maintenant vous expliquer comment procéder.

Tout ce dont vous avez besoin pour apporter des modifications est un éditeur de fichier texte et des droits de superutilisateur. Vous pouvez découvrir comment obtenir un accès root sur notre forum dans la rubrique Firmware Android dans la rubrique dédiée à votre smartphone ou tablette. Pour apporter des modifications directes au fichier, vous pouvez utiliser un éditeur de texte classique. Pour ce faire, vous devrez rechercher indépendamment le fichier le long du chemin /system/build.prop. Mais il est beaucoup plus pratique d'apporter des modifications à l'aide d'un programme spécialisé, par exemple : Éditeur BuildProp.

Avant de commencer à expérimenter, vous devez faire une copie de sauvegarde du fichier. BuildProp Editor enregistre automatiquement une sauvegarde de l'original la première fois que vous le lancez. Si vous décidez d'utiliser un éditeur de texte classique, n'oubliez pas d'en faire une copie manuellement. Si quelque chose ne va pas soudainement, il vous suffira de remplacer le build.prop « endommagé » par une copie de sauvegarde pour tout remettre à sa place.

Accélérez le chargement. Les smartphones modernes mettent souvent plus de temps à démarrer que les PC classiques. En bricolant un peu les paramètres de build.prop, vous pouvez facilement augmenter la vitesse de chargement du gadget d'une fois et demie à deux ! Les paramètres suivants vous aideront à cela :

debug.sf.nobootanimation=1

ro.config.hw_quickpoweron=true

Après avoir effectué ces paramètres, le mode d'arrêt du gadget sera modifié et l'animation de démarrage du développeur du micrologiciel sera également désactivée. Par conséquent, lorsque vous démarrez votre smartphone, vous ne verrez rien à l’écran pendant un certain temps. Il ne faut pas avoir peur de cela : c'est grâce à la désactivation des animations inutiles que le smartphone de test a commencé à démarrer en seulement 30 secondes au lieu des 50 secondes précédentes.

Accélération du travail de mémoire. Par défaut, Android enregistre de nombreuses actions dans un fichier spécial, mais les développeurs n'en ont besoin que pour déboguer les applications. Ce journal ne sera pas utile aux utilisateurs ordinaires et il vaut donc la peine de le désactiver en ajoutant la ligne à build.prop

logcat.live=désactiver

La désactivation du journal réduira le nombre d'opérations sur le disque, ce qui aura un effet positif sur les performances de la mémoire interne du smartphone. Certes, la différence ne sera perceptible que sur les gadgets dotés de types de mémoire lents : dans notre cas, la vitesse d'écriture séquentielle a augmenté de 2 Mo/s.

Accélération du réseau. Ce réglage augmente la taille des tampons TCP, ce qui contribuera à augmenter la vitesse d'une connexion Internet lente, en particulier lors de l'utilisation de réseaux mobiles. Eh bien, l'enregistrement des serveurs DNS de Google vous permet dans certains cas de réduire le temps de ping.

net.tcp.buffersize.default=4096,87380,256960,4096, 16384,256960

net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960

net.rmnet0.dns1=8.8.8.8

net.rmnet0.dns2=8.8.4.4

net.dns1=8.8.8.8

net.dns2=8.8.4.4

Pour nous, la différence s'est avérée perceptible, mais il ne faut pas oublier que la plus grande influence La vitesse est affectée par la charge en constante évolution des stations de base.

Taux de transfert de données avec paramètres standard

Vitesse de transfert de données après la modification de build.prop

Malheureusement, les miracles ne se produisent pas - une double augmentation de l'autonomie ne peut être obtenue avec des ajustements. Mais il est tout à fait possible d’ajouter 30 à 60 minutes supplémentaires à la durée de fonctionnement du gadget.

Augmentez les intervalles d'analyse Wi-Fi. Par défaut, Android analyse les réseaux Wi-Fi environnants toutes les 20 à 90 secondes. De plus, il le fait même lorsque le Wi-Fi est désactivé, mais la recherche de réseaux en arrière-plan est autorisée à augmenter la précision de la détermination de l'emplacement. Pour étendre cet intervalle, vous devez ajouter la ligne au fichier build.prop :

wifi.supplicant_scan_interval=200

Ici, le nombre 200 est l'intervalle d'analyse du réseau en secondes.

Économisez la batterie sur LineageOS. Un petit ajustement qui permet une gestion plus efficace du mode veille lors de l'utilisation de CyanogenMod ou LineageOS sur des smartphones équipés de chipsets Qualcomm :

pm.sleep_mode=1

Vous pouvez trouver des ajustements encore plus utiles sur le forum 4PDA.

En plus des ajustements réellement fonctionnels présentés dans cet article et dans le fil de discussion, de nombreux éléments ont été largement diffusés sur Internet, mais n'ont en réalité aucun effet sur le fonctionnement du système. Une étude correspondante a été réalisée par l'un des utilisateurs de la ressource xda. Il a analysé le code source d'AOSP et de CyanogenMod et a découvert que de nombreux ajustements populaires n'étaient tout simplement pas mentionnés dans le code source d'Android. Parmi eux, il existe une variété de disques.

Ajustements qui n'économisent pas la batterie :

ro.ril.disable.power.collapse

ro.mot.eri.losalert.delay

ro.config.hw_fast_dormancy

ro.config.hw_power_ saving

Ajustements qui n'accélèrent pas le travail :

windowsmgr.max_events_per_sec

persist.cust.tel.eons

ro.max.fling_velocity

ro.min.fling_velocity
débogage.performance.tuning

vidéo.accelerate.hw

D'autres ajustements inutiles. Ils sont conçus pour désactiver la vérification du bytecode Dalvik et interdire le déchargement du lanceur de la RAM. Autrefois, ils fonctionnaient vraiment, mais ne sont absolument pas pertinents pour les versions modernes d'Android en raison de changements dans l'architecture interne du système d'exploitation :

dalvik.vm.verify-bytecode

Et quelques autres ajustements qui ne fonctionnent tout simplement pas :

ro.media.dec.jpeg.memcap

ro.config.nocheckin

profiler.force_disable_ulog

profileur.force_disable_err_rpt

persist.sys.shutdown.mode

ro.kernel.checkjni

Il est intéressant de noter que même si certaines de ces entrées étaient utiles pour les anciennes versions d'Android, certaines n'ont jamais fonctionné du tout, constituant une sorte de placebo. Et pourquoi une telle illusion massive est apparue en premier lieu, il est désormais impossible de le découvrir. Cependant, créer de telles entrées dans build.prop n'aggravera pas le fonctionnement du smartphone - toutes les entrées invalides seront simplement ignorées.

Même si de nombreux ajustements recommandés sur les forums et divers sites Web ne fonctionnent pas du tout, le fichier build.prop reste une bonne opportunité pour améliorer l'interface et les performances de votre smartphone. Alors obtenez les droits de superutilisateur, sauvegardez vos paramètres et n'hésitez pas à expérimenter !

Sont si adorables pour tous les amateurs d’Android. Que peuvent-ils faire ? Il rend votre téléphone extra ordinaire et booste votre smartphone en modifiant ses fonctionnalités internes qui sont par défaut par le système d'exploitation de l'entreprise. Si vous en avez déjà essayé , je suis sûr que vous connaissez déjà l'importance des meilleurs réglages Build.prop et de leurs fonctionnalités auxquelles vous pouvez accéder après les avoir appliqués sur votre appareil. Build Prop Tweaks peut être appliqué sur n’importe quel Android fonctionnant sur Jellybean, Kitkat, Lollipop ou Marshmallow.

Pour les amateurs d'Android, nous partageons les meilleurs ajustements d'accessoires de construction pour Android. Android est le meilleur plate-forme pour tester de nouveaux Tweaks & Tricks géniaux. Si vous êtes accro à Android, vous aimerez peut-être aussi le concevoir avec différents lanceurs et tous et construire des accessoires sont les la chose la plus folle pour toi.

L'accès root est la principale condition requise pour faire quoi que ce soit sous root sur votre smartphone Android. Nous pouvons l'utiliser sur notre mobile Rooted pour améliorer ses performances et sa recherche. L'enracinement déverrouille complètement notre téléphone Android et nous pouvons modifier tout ce que nous souhaitons dans nos fonctionnalités Android. Vous pouvez le faire et également après avoir rooté votre appareil.

De nombreux maîtres Android adorent tester différents réglages géniaux sur leur smartphone. Ils installent et testent différents styles sur leurs appareils Android pour changer son apparence. Ils aiment également tester différents réglages de Build.prop sur leurs téléphones Android.

Donc, si vous aimez également installer différents types de réglages sur votre smartphone, vous êtes au bon endroit. Ici, je vais partager Créez des ajustements d'accessoires pour JellyBean, Kitkat, Lollipop et Marshmallow Smartphones version Android pour améliorer les performances de votre appareil Android. Ce sont les derniers nouveaux ajustements des accessoires de construction grâce auxquels vous pouvez modifier de nombreuses fonctionnalités internes de votre appareil Android et améliorer les performances de votre appareil Android. Mais toi doit avoir besoin rootez d’abord votre appareil Android pour installer ces réglages sur votre mobile. Voyons dans la liste ci-dessous.

Doit vérifier : - | |

Build.prop est un fichier de notre appareil Android qui est stocké dans /system/path de nos appareils Android. Il stocke toutes les spécifications, fonctionnalités et paramètres de notre mobile Android. Il s’agit d’un fichier très important de notre appareil Android, sans ce fichier, notre appareil Android ne peut pas fonctionner, même votre mobile Android ne peut pas démarrer sans ce fichier. Ce fichier est invisible, c'est pourquoi nous n'avons jamais vu ce fichier sur notre mobile. Mais nous pouvons trouver ce fichier après avoir rooté notre appareil Android. Et nous pouvons également modifier ses paramètres pour peaufiner notre téléphone Android. Root est indispensable pour cela, car notre système d'exploitation Android ne peut pas accorder l'autorisation de toucher à ses fonctions internes, nous devons donc rooter notre appareil pour accorder l'autorisation à l'appareil Android.

Vous pouvez également ajouter quelques modifications supplémentaires sur votre appareil Android à partir du fichier Build.prop. Donc, dans cet article, je vais partager quelques ajustements de Build.prop pour les téléphones JellyBean, Kitkat, Lollipop, Marhsmallow Android afin d'améliorer les performances de votre appareil. J'ai également décrit les étapes à suivre pour ajouter des ajustements Build.prop sur Android au bas de cet article.

Doit lire: -

(La valeur par défaut est 240. N'oubliez pas d'installer un marché corrigé après l'avoir modifié.)

(Si le SMS/MMS n'a pas pu être envoyé, il réessaye après 2 secondes au lieu de 5 secondes)

(Peut être instable – mieux vaut l'activer)

Ce sont quelques-uns des meilleurs ajustements d’accessoires de construction pour les appareils Android. Je pense avoir couvert pour vous tous les ajustements catégorisés de build.prop. Si j'ai raté quelque chose, n'hésitez pas à commenter ci-dessous. Sur Internet uniquement, ce sont les ajustements les plus populaires avec lesquels je me suis amusé, c'est pourquoi je n'ai partagé que celui-ci.

Contrairement à iOS, Téléphone Windows et quelques autres OS mobiles, originaux Code Android est ouvert, afin que les passionnés puissent modifier le système comme ils le souhaitent et regrouper leurs modifications sous la forme de micrologiciels distribués gratuitement, tels que CyanogenMod, Paranoid Android et OmniROM. Un tel firmware contient un grand nombre de modifications utiles, mais tout le monde n'est pas prêt à prendre des risques en les installant. Heureusement, il existe un moyen d'obtenir tous les avantages de la personnalisation sur n'importe quel firmware d'origine.

Il n'y a pas si longtemps, nous avons découvert que le système Xposed existait pour Android - un ensemble de bibliothèques et d'applications qui, travaillant ensemble, permettent aux applications tierces d'intercepter les appels vers n'importe quelle classe Java Android et de les remplacer par les leurs. En termes simples, un analogue de Cydia Substrate pour iOS, avec lequel l'utilisateur peut modifier le comportement et l'apparence d'Android.

Xposed lui-même ne fournit que des outils d'interception, tandis que travail en cours se produit dans des applications spéciales appelées modules. Actuellement, il existe déjà plusieurs centaines de modules de ce type, et la gamme de leurs fonctions s'étend de petites choses telles que l'affichage de la photo d'un abonné lors d'un appel en plein écran et l'émulation des fonctionnalités d'autres firmwares, jusqu'aux moteurs de thèmes et modules multifonctionnels « pour toutes les occasions ». ». Presque toutes les fonctions de n'importe quel micrologiciel tiers peuvent aujourd'hui être obtenues à l'aide de modules Xposed sur un micrologiciel d'origine standard.

La plupart des modules ne dépendent en aucune façon de la marque ou du modèle de l'appareil et peuvent fonctionner sur n'importe quel Android à partir de la version 4.0. La seule limitation sérieuse est la nécessité d'obtenir les droits root, mais aujourd'hui, cette procédure est accessible même à un novice complet grâce à la disponibilité d'applications spéciales pour le root.

Xposed se compose de deux composants principaux : une version modifiée du binaire /system/bin/app_process, qui sous Android est responsable du lancement de la machine virtuelle Dalvik, et un ensemble de classes Java XposedBridge.jar, qui contient du code qui peut intercepter les appels à toutes les classes Java et leur émettre d'autres classes.

L'essence de la méthode. Le programme d'installation de Xposed remplace le app_process standard par le sien. Lors du chargement, le système d'exploitation démarre la machine virtuelle à l'aide d'un app_process usurpé, qui charge automatiquement XposedBridge.jar. Au cours de son exécution, le système crée une machine virtuelle pour chaque application Java qu'il exécute, y compris l'interface graphique et de nombreux composants du système, de sorte que les classes XposedBridge se retrouvent dans chacune d'entre elles.

Une fois installé, le module Xposed s'enregistre dans XposedBridge en tant que gestionnaire de certaines classes Java de ces applications, ce qui lui donne la possibilité de les remplacer par les siennes. En d'autres termes, les modules Xposed ne modifient pas le système, mais remplacent ses composants par des « faux », donc après avoir désactivé le module ou l'intégralité de Xposed, le système reviendra automatiquement à son état d'origine.

L'installation et la configuration de Xposed sont assez simples. À la base, il s'agit d'un package APK classique qui
après le lancement, il déploie tous les composants nécessaires pour que le système Xposed fonctionne dans le système. Vous pouvez obtenir le package lui-même sur le site officiel (goo.gl/61rOz7). À propos, il existe également un référentiel de modules, mais vous n'avez pas besoin de télécharger les modules manuellement, car tout peut être fait à l'aide de l'application elle-même.

Après avoir téléchargé et installé le package, allez dans la section « Framework » et cliquez sur le bouton « Installer/Mettre à jour », puis cliquez sur « Redémarrage rapide"afin que le système récupère les composants Xposed installés au prochain démarrage. Dans la plupart des cas, cela se produira
de quoi préparer Android à l'installation des modules. Si nous parlons d'un smartphone avec une partition /system (S-ON) verrouillée, la méthode d'installation devra être modifiée en « Depuis le mode de récupération » dans le menu « Mode d'installation du framework ». Dans ce cas, après avoir appuyé sur
bouton « Installer/Mettre à jour », le système redémarrera et l'archive avec les composants Xposed sera automatiquement flashée à l'aide de la console de récupération.

Après le redémarrage, exécutez à nouveau le programme d'installation de Xposed et accédez à la section « Télécharger ». Tous les modules disponibles dans le référentiel sont affichés ici, ainsi que les mises à jour de Xposed lui-même. Pour installer le module, sélectionnez simplement celui dont vous avez besoin et cliquez sur le bouton « Télécharger » à côté de la dernière version. Pour activer le module, rendez-vous dans la rubrique « Modules », cochez la case à côté de ce que vous avez installé et redémarrez votre smartphone.

Essayons d'installer l'un des modules. La barre d'état teintée en est un bon exemple. Nous le trouvons, l'installons, l'activons dans la section « Modules » de l'installateur Xposed et redémarrons le smartphone. Après le téléchargement, nous essayons de lancer différentes applications. L'effet qui devrait être immédiatement perceptible est la barre d'état, qui change désormais de couleur en fonction de la palette de couleurs de l'application elle-même (un peu comme dans iOS 7). C'est tout, nous avons modifié le comportement du composant système sans installer de firmware personnalisé ni de modifications flashées
récupération!


Ensuite, je parlerai des modules Xposed les plus intéressants, inhabituels et utiles, mais je vais d'abord vous avertir de plusieurs nuances que vous devez connaître avant de commencer à les installer.

Premièrement, il existe principalement deux types de modules : ceux qui font simplement leur travail et ne brillent nulle part, et ceux qui peuvent être personnalisés. Les modules du premier type peuvent modifier l'apparence ou le comportement du système, mais ils ne peuvent pas être personnalisés ; soit ils sont actifs dans les paramètres Xposed, soit ils sont désactivés (un exemple d'un tel module est Masterkey Multi-fix). Les modules du deuxième type ne s'affichent généralement pas non plus, mais créent une icône dans le menu de l'application qui permet d'accéder aux paramètres du module. Avec leur aide, vous pouvez activer certaines fonctions du module et modifier son comportement (il existe de nombreux exemples de tels modules : App Settings, GravityBox et bien d'autres).


Deuxièmement, tous les modules ne sont pas compatibles avec toutes les versions d'Android. Certains d'entre eux sont conçus pour fonctionner avec certains types de firmware d'origine (par exemple, avec le firmware de Samsung ou HTC) et peuvent se comporter de manière imprévisible sur d'autres firmware (bien qu'ils ne bloquent pas le smartphone, bien sûr). D'autres sont conçus pour fonctionner uniquement avec une version spécifique d'Android. Par exemple, le référentiel dispose de deux modules GravityBox, dont l'un est conçu pour fonctionner dans Jelly Bean (Android 4.1-4.3), l'autre dans KitKat (4.4). Afin de ne pas attraper de problèmes, ce point doit également être pris en compte. Il faut également faire attention aux tablettes basées sur Android 4.0-4.1, elles utilisent une interface incompatible avec le téléphone et de nombreux modules ne fonctionnent pas.

Le firmware personnalisé est une autre histoire. Habituellement, aucun problème ne se pose avec eux, mais des choses amusantes se produisent. Par exemple, après avoir installé GravityBox dans OmniROM, vous recevrez deux indicateurs de batterie. Cela se produit parce que ce firmware utilise son propre mécanisme d'affichage de l'indicateur de batterie incompatible, dont GravityBox ne sait rien. Heureusement, le problème est facilement résolu en désactivant l'indicateur soit dans les paramètres du firmware lui-même, soit dans GravityBox (il ne restera qu'un seul indicateur).

Troisièmement, un module peut être non seulement un package séparé, mais faire partie d'une application Android standard. Si vous installez l'application Greenify depuis le Play Store sur votre smartphone, un module correspondant apparaîtra dans Xposed. Dans le cas de cette application, cela est facultatif et est nécessaire pour mieux contrôler la veille de l’application. De nombreuses autres applications utilisent également Xposed pour étendre leurs fonctionnalités : BubbleUPnP pour diffuser un flux audio depuis n'importe quel lecteur, Cool Tool pour afficher diverses données dans la barre d'état, etc.
Passons aux modules. Ma liste des meilleurs comprend plus de vingt modules pour tous les goûts et toutes les couleurs. Les voici :

GravityBox est l'un des modules Xposed les plus connus et les plus populaires. Il n'a pas d'objectif spécifique et hautement spécialisé, mais constitue un ensemble d'un grand nombre de modifications différentes visant principalement à modifier l'apparence du système.

Le module est capable de personnaliser la barre d'état, de modifier l'ensemble et l'emplacement des vignettes dans le rideau, de modifier le comportement des boutons de navigation ou de les désactiver complètement, d'étendre le menu de redémarrage (à la manière d'un firmware personnalisé), d'inclure le l'implémentation de PIE de Paranoid Android (analogue à LMT Launcher), vous permet d'utiliser des filtres d'écran, de modifier le comportement des boutons matériels, le comportement des LED de notification et de chargement, et bien plus encore.

En fait, GravityBox est une collection des meilleures fonctionnalités de ROM tierces avec lesquelles vous pouvez changer votre Android. Toutes les fonctions peuvent être affinées, mais contrairement au custom firmware, la configuration se fait à l'aide d'un menu spécial et peu pratique, accessible via l'icône GravityBox dans le menu de l'application. En plus de GravityBox, dans le référentiel
Vous pouvez également trouver d'autres « modules combinateurs », tels que Wanam et Xblast Tools, mais leurs fonctionnalités sont inférieures.

Un autre module très populaire et utile. Conçu pour changer d'apparence
et le comportement des applications individuelles. Inclut des fonctionnalités telles que la possibilité de modifier la valeur DPI (vous permet d'augmenter ou de diminuer la taille des contrôles
applications), modification de la taille de la police, langue de l'application. Vous permet de forcer le mode plein écran pour n'importe quelle application ou de bloquer la suppression de l'écran, de forcer l'orientation paysage ou portrait (utile pour les applications qui ne peuvent fonctionner que dans un seul mode, comme un numéroteur), et bien d'autres. L'un des fonctionnalités intéressantes- possibilité d'afficher l'application en haut de l'écran de verrouillage.

De plus, le module dispose de son propre mécanisme de révocation des autorisations d'application, fonctionnant indépendamment du système AppOps, qui apparaît comme une fonctionnalité cachée.
sous Android 4.3. Avec son aide, vous pouvez, par exemple, interdire à une certaine application de surfer sur Internet ou d'envoyer des SMS. Très pratique lorsqu'il s'agit de publicités ennuyeuses ou de logiciels suspects.

Un module intéressant qui imite une partie des fonctionnalités du système de notification Halo du firmware Paranoid Android. Le module vous permet de lancer des applications sélectionnées dans une fenêtre flottante dont la taille et la transparence peuvent être modifiées à votre guise. Par défaut, il ne s'affiche en aucun cas, et pour pouvoir ouvrir l'application dans une fenêtre flottante, vous devrez l'ajouter à « Liste blanche» dans le menu « Propriétés » des paramètres du module. Après avoir redémarré l'application, elle s'ouvrira dans une fenêtre séparée.

L'utilité réelle du module n'est pas si grande, mais il est bien adapté pour exécuter des applications qui exécutent une fonction simple et n'ont en principe pas besoin de tout l'écran (par exemple, Wifi ADB). Vous devez également garder à l’esprit que toutes les applications ne se sentent pas à l’aise avec les changements constants de taille d’écran (c’est ainsi qu’une fenêtre flottante est émulée) et peuvent se comporter de manière inappropriée.

Une autre implémentation du mode multi-fenêtre, cette fois à partir du firmware OmniROM. Contrairement au module décrit ci-dessus, il ne crée pas de fenêtre séparée pour l'application, mais divise l'écran en deux parties, qui affichent l'interface des différentes applications. Ceci est très similaire à la fonctionnalité du micrologiciel intégré de Samsung, mais s'applique à n'importe quelle application, pas seulement à un ensemble limité. applications standards micrologiciel.

Fonctionne immédiatement après l'installation et le redémarrage ; une application lancée depuis le bureau s'ouvrira en mode plein écran, mais si au moment du lancement l'écran est déjà occupé par une autre application, il sera divisé en deux. Présente les mêmes problèmes de compatibilité que XHaloFloatingWindow, mais est beaucoup plus utile en soi. Ne prend pas en charge les fonctionnalités propriétaires de Samsung, telles que le glisser-déposer entre les applications. À propos, pour le moment, le mode multi-fenêtre a été supprimé d'OmniROM (en raison de plantages de certaines applications), vous pouvez donc utiliser ce module en remplacement.

Ce module remplit une fonction simple : il interdit aux applications individuelles de démarrer automatiquement au stade du démarrage du système d'exploitation. Le fait est que par défaut, Android ne vous permet pas de réguler le démarrage des applications, comme cela peut être fait dans n'importe quel système d'exploitation de bureau. Une application disposant de l'autorisation android.permission.RECEIVE_BOOT_COMPLETED sera automatiquement lancée par le système au démarrage, et rien ne peut être fait à ce sujet.

Si cela ne vous semble pas être un problème, je vous recommande d'exécuter n'importe quel gestionnaire de processus (en tant qu'option de suppression de tâches) sur un système nouvellement chargé. Vous y verrez un téléphone, une application d'échange et de SMS, ainsi qu'un tas d'applications tierces. BootManager vous permet de résoudre ce problème en sélectionnant uniquement le logiciel réellement nécessaire immédiatement après le démarrage de votre smartphone.

Oui, je sais qu'il existe déjà des applications sur le marché pour résoudre ce problème, mais BootManager s'en distingue avantageusement en ce sens qu'il fonctionne au niveau le plus bas du système et bloque le chargement des applications correctement et rapidement.

Un de mes modules préférés. Remplace la plaque par le curseur de volume, qui
Paradise apparaît lorsque vous appuyez sur les boutons de volume et recouvre les informations à l'écran avec un mince curseur qui apparaît en haut de la barre d'état et disparaît rapidement. De plus, il comprend un ensemble d'options pour modifier le comportement du module, parmi lesquelles vous pouvez trouver deux des plus importantes : la désactivation du réglage automatique du volume des notifications ainsi que la modification du volume de la sonnerie et la désactivation du "bip" gênant lorsque vous appuyez sur les boutons de volume.

L’inconvénient du module est qu’il est payant. Par défaut, une version d'essai de deux semaines est installée et pour acheter la version complète, vous devrez payer un dollar. À propos, pour accéder aux autres curseurs de volume (volume des médias et de l'alarme), vous devez dérouler juste en dessous de la barre d'état pendant que cette dernière affiche le curseur principal.

Trois modules permettant de modifier le comportement et l'apparence des messages qui apparaissent à l'écran lors de certains événements (message toast).

Burnt Toast ajoute au message une icône de l'application qui l'a appelé (avec possibilité de personnalisation). Jelly Toast remplace le style de messagerie défectueux de KitKat (avec des coins arrondis et des bordures larges) par le design simple et épuré de Jelly Bean.

EnhancedToast combine les fonctions des deux modules précédents et vous permet de bloquer les messages des applications sélectionnées (la plupart d'entre elles sont vraiment inutiles), y compris la possibilité de filtrer par expression rationnelle (seuls les messages qui correspondent au modèle seront affichés). En prime supplémentaire, le support Tasker est fourni, avec lequel vous pouvez configurer le contrôle automatique des fonctions du module.

Le deuxième module de ma liste personnelle des plus utiles (après StatusbarVolume). Fait une chose simple : développe automatiquement les liens raccourcis avant de les ouvrir dans l'application. Pourquoi est-ce nécessaire alors que n’importe quel navigateur les déploiera lui-même ? Ensuite, le lien menant, par exemple, à youtube.com, play.google.com ou facebook.com, dans la situation standard, s'ouvre non pas dans le navigateur, mais dans l'application correspondante, ce qui est correct et très pratique.

Cependant, si le lien est raccourci, le système ne pourra pas comprendre à qui le donner et l'enverra au navigateur par défaut, qui apparaîtra à l'écran, développera le lien et le donnera ensuite seulement au client ( et c'est dans meilleur scénario, au pire, il s'ouvrira à l'intérieur de lui-même).

CrappaLinks résout ce problème en interceptant les intentions contenant un lien vers une ressource HTTP et en l'étendant automatiquement si nécessaire. Le compromis est un certain ralentissement lors de l'ouverture des liens, mais cela reste plus rapide que le lancement d'un navigateur. En général, un module indispensable pour tous ceux qui utilisent souvent Twitter ou d'autres réseaux sociaux.

Bloqueur d'appels assez standard, la différence par rapport aux autres implémentations est qu'il fonctionne au niveau le plus bas du système d'exploitation, où les informations sont transférées du démon rild au numéroteur. En conséquence, le composeur intégré ne sera même pas au courant de l'appel. D'autres applications similaires fonctionnent au niveau de l'utilisateur et, en substance, raccrochent simplement immédiatement après un appel, après avoir coupé le son ; Pour cette raison, vous pouvez rencontrer de nombreux problèmes, tels que l'écran qui s'allume pendant une courte période, la sonnerie pendant une courte période et l'apparition d'icônes d'appel manqué. Certaines fonctionnalités ne sont disponibles qu'après l'achat d'une clé : blocage des appels sortants, blocage des appels provenant de numéros privés et masqués.

Un simple pare-feu qui vous permet de désactiver le transfert de données pour des applications individuelles en fonction du type de réseau. En fait, il s'agit d'un analogue de DroidWall avec une implémentation plus correcte : il ne dépend pas d'iptables, qui n'est pas présent dans de nombreux firmwares d'origine, il est activé avant même que les principaux composants du système d'exploitation ne commencent à se charger, ce qui exclut les fuites ( DroidWall démarre une fois le système d'exploitation complètement chargé), les règles sont toujours actives, plutôt que d'être réaffectées lorsque la connexion réseau change.

Malheureusement, il n'est pas possible de parler en détail de tous les modules intéressants dans un seul article, je vais donc lister le reste des modules intéressants avec une brève description de chaque module.

Sense 5/6 Toolbox - un ensemble de réglages et de hacks pour le firmware d'origine de HTC.
HTC One Tweaker - ajustements et hacks pour HTC One.
MotoGuide - une collection de réglages et de hacks pour Moto X.
Chrome Nouvel onglet - Permet à Chrome d'ouvrir toujours de nouveaux liens dans un nouvel onglet.
Phab7 - vous permet de basculer entre les modes téléphone et tablette.
Ok Google pour les lanceurs tiers - ajoute reconnaissance automatique voix dans des lanceurs tiers.
Master Key multi-fix - ferme le fameux bug de Master Key.
NetworkSpeedIndicator - ajoute un indicateur de vitesse de transfert de données à la barre d'état.
CpuTemp in Statusbar - affiche la température du processeur dans la barre d'état.
Holo Themer - vous permet de basculer entre les thèmes d'application clairs et sombres à la volée.
YouTube AdAway - bloque les publicités dans l'application YouTube.
Autoriser Youtube en plein écran avec HDMI - active le mode véritablement plein écran lors de l'affichage des images du lecteur YouTube via HDMI.
AppOpsXposed - donne accès à la fonction AppOps (voir ci-dessus).
Complete Action Plus - vous permet de personnaliser les boîtes de dialogue de sélection de fichiers et d'applications.
DitheredHoloBackground - rend l'arrière-plan des applications vraiment noir, sans dégradé (utile pour les écrans AMOLED).
DoubleTapToSleep - met le smartphone en veille après avoir appuyé deux fois sur la barre d'état.
Composant de traduction Xposed étendu - traduit automatiquement le micrologiciel MIUI en russe.
Masquer les applications Xposed - vous permet de masquer les applications dans le menu du lanceur standard.
Instagram Downloader - vous permet de télécharger des photos depuis Instagram.
Vine Downloader - vous permet de télécharger des vidéos depuis Vine.
Support LG PIE - prise en charge de la fonction PIE pour le firmware de LG.
Utilisateurs multiples pour téléphone - active le mode plusieurs utilisateurs sur votre smartphone.
neXus navbarz - vous permet de modifier l'apparence et le comportement des boutons de navigation du logiciel.
ScreenOffAnimation - un ensemble d'animations hors écran.
UnbelovedHosts - vous permet d'utiliser le vôtre propres versions/etc/hosts sans changer le fichier principal (pour bloquer les publicités).
Xposed Full Screen Call Picture - affiche la photo de l'appelant en plein écran (sans recadrage en bas).
Paramètres Xposed GEL - personnalisateur pour Google Now Launcher.

En parcourant les forums et diverses sortes Sur les sites dédiés à Android, on tombe constamment sur des astuces pour augmenter les performances d'un smartphone. Certains recommandent d'activer le swap, d'autres recommandent d'ajouter des valeurs spéciales à build.prop et d'autres encore recommandent de modifier les variables du noyau Linux. Vous pouvez trouver un grand nombre de recettes de ce type dans différentes versions, à la fois sur XDA et sur w3bsit3-dns.com. Mais fonctionnent-ils vraiment ?

Ayant utilisé une variété de systèmes * nix au cours des dix dernières années, j'ai toujours été étonné de voir avec quelle persistance certains utilisateurs de smartphones apparemment instruits tentent de faire connaître au public leurs idées sur la façon de configurer de manière optimale Android et le noyau Linux sous-jacent. Et ce serait bien si l'affaire se limitait à un réglage facile du sous-système de gestion de la mémoire virtuelle ou à l'inclusion d'options expérimentales. Non, on nous demande généralement d'utiliser de longs scripts qui modifient littéralement toutes les variables du noyau, remontent les systèmes de fichiers avec diverses options étranges, activent le swap, activent divers démons système et effectuent des milliards d'autres opérations différentes.

Non, eh bien, vous pouvez bien sûr supposer que le noyau Linux, Android et le firmware propriétaire pour smartphones sont développés par des idiots illettrés, dont le travail doit être radicalement refait, mais dans la pratique, pour une raison quelconque, il s'avère que le réglage le plus célèbre les outils publiés sur XDA ne sont rien de plus qu'un méli-mélo d'un grand nombre de recommandations disparates, inventées par quelqu'un d'inconnu et dont on ne sait pas pourquoi. L'absurdité de la situation est que dans ces outils, vous pouvez trouver des lignes copiées inchangées à partir de scripts pour augmenter les performances d'un serveur Linux dans des conditions de charge élevée (je ne plaisante pas, regardez le contenu du fameux script ThunderBolt !).

En général, la situation est plus que confuse. Tout le monde conseille tout, personne ne conseille rien, et ceux qui comprennent quelque chose s'assoient et, buvant du thé, se moquent de la farce qui se passe. Mais essayons de mettre de l'ordre dans tout ce désordre.

Commençons par le swap - l'idée la plus absurde à laquelle on puisse penser pour une utilisation dans les smartphones. Son but est de créer et de connecter un fichier d'échange, ce qui libérera de l'espace utile dans la RAM. L'idée en elle-même est bien sûr bonne, mais seulement s'il s'agit d'un serveur qui n'a aucun problème d'interactivité. Sur un smartphone, un fichier d'échange régulièrement utilisé entraînera des décalages non illusoires résultant de manques de cache - imaginez ce qui se passera si une application tente d'afficher une de ses icônes et qu'elle se retrouve dans un échange qu'il faudra charger à nouveau du disque, après avoir d'abord libéré de l'espace en plaçant les données d'une autre application dans un swap. Horreur.

Certains utilisateurs peuvent affirmer qu'en fait, après avoir activé le swap, aucun problème ne se pose, mais pour cela, nous devons remercier le mécanisme lowmemorykiller, qui tue régulièrement les applications particulièrement surchargées et inutilisées depuis longtemps. Grâce à cela, un appareil doté de 1 Go de mémoire n'aura peut-être jamais besoin de vider les données dans le swap. C'est aussi la raison pour laquelle, contrairement à un bureau Linux, le swap n'est pas nécessaire sur Android.

Verdict : une idée très stupide, dont la mise en œuvre se heurte à de sérieux retards.

Le swap est en effet très lent, et même sur un ordinateur de bureau, son existence est souvent injustifiée, mais que se passe-t-il si vous trompez le système ? Créons un disque virtuel directement dans la RAM avec une fonction de compression de données intégrée, connectons-le en tant que swap - et le tour est joué. La fonction de compression des données est assez bon marché, même pour les processeurs mobiles modernes, nous pouvons donc augmenter la taille de la RAM sans pratiquement aucune perte de performances.

L'idée est si bonne que même Google recommande d'utiliser la zRAM pour les appareils basés sur KitKat si la capacité de la RAM ne dépasse pas 512 Mo. Le seul problème est que la méthode ne fonctionne que pour les appareils modernes de pointe, c'est-à-dire les appareils basés sur des processeurs budgétaires multicœurs de certains MTK et 512 Mo de RAM. Dans ce cas, le flux de chiffrement peut être déplacé vers un noyau distinct sans se soucier du tout des performances.

Sur les appareils obsolètes dotés d'un seul cœur, pour lesquels les « gourous du forum » recommandent d'utiliser cette technologie, nous aurons à nouveau des décalages, et en quantité assez importante. Il en va d'ailleurs de même pour la technologie KSM (Kernel SamePage Merging), qui permet de fusionner des pages mémoire identiques, libérant ainsi de l'espace. Il est également recommandé par Google, mais sur les appareils plus anciens, cela entraîne des décalages encore plus importants, ce qui est tout à fait logique, compte tenu du fil nucléaire constamment actif, qui parcourt continuellement la mémoire à la recherche de pages en double (y a-t-il vraiment autant de ces doublons ? ).

Verdict : Dépend de l'appareil, ralentit le système dans la plupart des cas.

À une certaine époque, cette application faisait beaucoup de bruit et donnait naissance à de nombreux analogues. Un grand nombre de messages sont apparus sur Internet concernant l'augmentation prétendument phénoménale des performances du smartphone après son installation. Les constructeurs de micrologiciels personnalisés locaux ont commencé à l'inclure dans leurs versions, et l'auteur a été déclaré sauveur. Et tout cela malgré le fait que Seeder n'a effectué aucun hack sale, mais a simplement corrigé un stupide bug Android.

En bref, le bug était que certains composants de haut niveau du runtime Android utilisaient activement le fichier /dev/random pour obtenir l'entropie/sel. À un moment donné, le tampon /dev/random était vide et le système était bloqué jusqu'à ce qu'il soit rempli de la quantité de données requise. Et comme elle était remplie de ce qui provenait des différents capteurs, boutons et capteurs du smartphone, cette procédure prenait tellement de temps que l'utilisateur a eu le temps de s'apercevoir du décalage.

Pour résoudre ce problème, l'auteur de Seeder a pris le démon Linux rngd, l'a compilé pour Android et l'a configuré pour extraire des données aléatoires du fichier /dev/urandom, beaucoup plus rapide (mais aussi beaucoup plus prévisible), et les transférer dans /dev/random tous les deuxièmement, sans laisser cette dernière s’épuiser. En conséquence, le système n’a jamais manqué d’entropie et a fonctionné silencieusement.

Ce bug a été corrigé par Google dans Android 3.0, et il semblerait que nous n'ayons pas besoin de nous souvenir de Seeder. Mais le fait est que l’application a été activement développée depuis lors et qu’elle est encore aujourd’hui recommandée par de nombreux « experts ». De plus, l'application a plusieurs analogues (par exemple, sEFix), et de nombreux créateurs de scripts/outils d'accélération incluent toujours des fonctionnalités similaires dans leurs créations. Parfois c'est le même rngd, parfois c'est le démon haveged, parfois c'est juste un lien symbolique de /dev/urandom vers /dev/random.

Tous ceux qui l'ont essayé rivalisent sur l'efficacité de la solution, cependant, selon Ricardo Cerqueira de Cyanogen, versions modernes Android /dev/random n'est utilisé que par trois composants : libcrypto (pour chiffrer les connexions SSL, générer des clés SSH, etc.), wpa_supplicant/hostapd (pour générer des clés WEP/WPA) et plusieurs bibliothèques pour générer des identifiants aléatoires lors de la création de systèmes de fichiers ext2. /3/4.

L'efficacité de l'application dans Android moderne, à son avis, n'est pas du tout liée à la reconstitution du pool /dev/random, mais au fait que rngd réveille constamment l'appareil et l'oblige à augmenter la fréquence du processeur, ce qui a un effet positif sur les performances et impact négatif sur la batterie.

Verdict : placebo.

Le firmware d'origine pour smartphones est toujours classifié. Cela signifie qu'en plus des packages d'applications Android standard au format APK, les répertoires /system/app/ et /system/priv-app/ (commençant par KitKat) contiennent également des fichiers du même nom avec l'extension odex. Ils contiennent le bytecode d'application dit optimisé, qui a déjà traversé le vérificateur et l'optimiseur de machine virtuelle et écrit dans un fichier séparé (cela se fait à l'aide de l'utilitaire dexopt).

Le but d'existence des fichiers odex est de soulager la charge sur la machine virtuelle et ainsi d'accélérer le lancement des applications (stock). D'un autre côté, les fichiers odex interfèrent avec les modifications du firmware et créent des problèmes de mise à jour, et pour cette raison de nombreuses ROM personnalisées (y compris CyanogenMod) sont distribuées sans eux. Vous pouvez renvoyer (plus précisément, générer) des fichiers odex de différentes manières, notamment en utilisant des utilitaires/scripts simples comme Odexer Tool. Ils sont faciles à utiliser et de nombreux « experts » recommandent de le faire.

Le seul problème est qu’il s’agit d’un pur placebo. S'il ne trouve pas de fichiers odex dans le répertoire /system, le système lui-même les créera au prochain démarrage et les placera dans le répertoire /system/dalvik-cache/. C'est exactement ce qu'elle fait lorsque, lors du chargement d'un nouveau firmware, le message « Optimisation de l'application en cours... » apparaît à l'écran. Cela fonctionne d'ailleurs également pour les applications du marché. Mais au stade de l'installation du logiciel.

Verdict : placebo.

La mise en œuvre du multitâche dans Android est très différente des autres systèmes d'exploitation mobiles et repose sur modèle classique. Les applications peuvent s'exécuter silencieusement en arrière-plan, il n'y a aucune restriction quant à leur nombre dans le système et la fonctionnalité n'est pas réduite lors du passage à l'exécution en arrière-plan. Tout est comme sur le bureau, à un détail près : le système a parfaitement le droit de tuer n'importe quelle application en arrière-plan si la RAM est insuffisante ou (à commencer par KitKat) si l'application est excessivement gourmande en ressources.

Ce mécanisme, appelé lowmemorykiller, a été inventé pour que, tout en conservant les fonctionnalités d'un système d'exploitation multitâche à part entière, Android puisse vivre normalement dans des conditions de mémoire limitée et de partition d'échange manquante. L'utilisateur peut lancer n'importe quelle application en toute sécurité et basculer rapidement entre elles, et le système lui-même se chargera de mettre fin aux applications qui n'ont pas été utilisées depuis longtemps et de garantir qu'il y a toujours de la mémoire libre dans l'appareil.

Dans les premières années d'Android, le but de ce mécanisme n'était pas clair pour de nombreux utilisateurs, c'est pourquoi les soi-disant tueurs de tâches sont devenus populaires - des applications qui se réveillaient de temps en temps et terminaient toutes les applications en arrière-plan. Bénéficier en dans ce cas il y avait une grande quantité de RAM libre, ce qui était perçu comme un plus, même si, bien sûr, cela ne présentait aucun avantage. Mais il y avait de nombreux inconvénients sous la forme d'une commutation plus longue entre les applications, d'une consommation accrue de la batterie et de problèmes de réveil du propriétaire le matin (le réveil a également été tué).

Au fil du temps, les principes du multitâche ont été compris et les task killers ont été progressivement abandonnés. Cependant, ils ont été rapidement remplacés par une autre tendance : le réglage du mécanisme lowmemorykiller lui-même (par exemple, à l'aide de l'application MinFreeManager). L'idée principale de la méthode est d'augmenter les limites de remplissage de la RAM, après quoi le système commencera à tuer les applications en arrière-plan. Une sorte de méthode « à la fois pour nous et pour vous », qui permet de libérer de la mémoire avec des moyens standards, sans violer les idées du multitâche Android.

Mais à quoi cela conduit-il finalement ? Disons valeurs standards les limites de mémoire sont de 4, 8, 12, 24, 32 et 40 Mo, c'est-à-dire que lorsque la mémoire libre atteint 40 Mo, l'une des applications mises en cache sera supprimée (chargée en mémoire, mais non exécutée, il s'agit d'une optimisation Android) , en 32 - Fournisseur de contenu, qui n'a pas de clients, 24 - une des applications d'arrière-plan rarement utilisées, puis les processus du service d'application (par exemple, le service de lecteur de musique), visibles sur l'écran de l'application et celui en cours sont consommés application en cours d'exécution. La différence entre les deux derniers est que « actuelle » est l'application avec laquelle l'utilisateur travaille actuellement, et « visible » est quelque chose qui, par exemple, a une notification dans la barre d'état ou affiche des informations en haut de l'écran.

En général, tout cela signifie que le smartphone disposera toujours de 40 Mo de mémoire libre, ce qui est suffisant pour accueillir une application supplémentaire, après quoi le thread LKM se réveillera et commencera à nettoyer la mémoire. Tout va bien, tout le monde est content. Le système utilise la mémoire au maximum. Imaginons maintenant ce qui se passerait si l'utilisateur suivait les conseils d'un « expert » local et augmentait ces valeurs afin que ces dernières soient, disons, 100 Mo (généralement seulement trois augmentations). dernières valeurs). Dans ce cas, une chose simple se produira : l'utilisateur perdra 100 – 40 = 60 Mo de mémoire de l'appareil. Au lieu d'utiliser cet espace pour stocker des applications en arrière-plan, ce qui est utile car cela réduit le temps de commutation et la durée de vie de la batterie, le système le laissera libre sans raison apparente.

Pour être juste, il faut dire que le réglage LKM peut être utile pour les appareils avec une très petite quantité de mémoire (moins de 512) et Android 4.X embarqué ou pour augmenter temporairement les seuils. Certains développeurs de réglages recommandent directement d'utiliser des paramètres « agressifs » uniquement lors de l'exécution de logiciels lourds comme des jeux haut de gamme, et de rester sur les paramètres standard le reste du temps. Cela a du sens en fait.

Verdict : mieux vaut ne pas toucher.

Dans les scripts publiés sur les forums, vous pouvez souvent trouver des modifications du sous-système d'entrée/sortie. Par exemple, dans le même script ThunderBolt ! il y a les lignes suivantes :

Echo 0 > $i/queue/rotational ; echo 1024 > $i/queue/nr_requests ;

Le premier indique au planificateur d'E/S qu'il s'agit d'un disque SSD, le second augmente la taille maximale de la file d'attente d'E/S de 128 à 1024 (la variable $i dans les commandes contient le chemin d'accès à l'arborescence des périphériques de bloc dans /sys, par exemple /sys/block/ mmcblk0/, le script les parcourt en boucle). Plus loin dans le texte, vous trouverez les lignes suivantes liées au planificateur CFQ :

Écho 1 > $i/queue/iosched/back_seek_penalty ; echo 1 > $i/queue/iosched/low_latency ; echo 1 > $i/queue/iosched/slice_idle;

Ce qui suit sont quelques lignes supplémentaires liées à d'autres planificateurs (en passant, faites attention aux points-virgules complètement inutiles à la fin des commandes). Qu'est-ce qui ne va pas avec toutes ces lignes ? Les deux premières commandes n'ont aucun sens pour deux raisons :

Les trois derniers n'ont aucun sens pour la simple raison que pour un smartphone, où il n'y a en fait aucune division des applications en priorités d'E/S et aucun lecteur mécanique, le meilleur planificateur est noop, c'est-à-dire une simple file d'attente FIFO - quel que soit celui qui a accédé à la mémoire. obtient d'abord l'accès. Et ce planificateur n'a pas de paramètres particuliers. Il est donc préférable de remplacer toutes ces listes de commandes multi-écrans par une simple boucle :

Pour moi dans /sys/block/mmc* ; faire echo noop > $i/queue/scheduler echo 0 > $i/queue/iostats terminé

En plus d'activer le planificateur noop, il désactive l'accumulation de statistiques d'E/S pour tous les lecteurs, ce qui devrait également avoir un effet positif sur les performances (bien que ce ne soit qu'une goutte d'eau dans l'océan et qu'il soit totalement imperceptible).

Un autre ajustement que l'on retrouve souvent dans les scripts d'optimisation des performances consiste à augmenter la valeur de lecture anticipée de la carte mémoire à 2 Mo. Le mécanisme de lecture anticipée est conçu pour lire de manière proactive les données du support de stockage avant qu'une application ne demande l'accès à ces données. Si le noyau constate que quelqu'un lit des données sur le support pendant une longue période, il essaie de déterminer de quelles données l'application aura besoin à l'avenir et de les charger à l'avance dans la RAM, réduisant ainsi le temps nécessaire pour les restituer.

Cela semble cool, mais comme le montre la pratique, l'algorithme de lecture anticipée commet très souvent des erreurs, ce qui entraîne des opérations d'E/S inutiles et une consommation de RAM. Des valeurs de lecture anticipée élevées (1 à 8 Mo) sont recommandées pour une utilisation sur les matrices RAID, tandis que sur un ordinateur de bureau ou un smartphone, il est préférable de tout laisser tel quel, c'est-à-dire 128 Ko.

Verdict : vous n’avez besoin de rien d’autre que noop.

Outre le sous-système d'E/S, il est également courant de régler le sous-système de gestion de la mémoire virtuelle. Souvent, seules deux variables du noyau sont modifiées : vm.dirty_background_ratio et vm.dirty_ratio, qui permettent d'ajuster la taille des tampons pour stocker les données dites sales, c'est-à-dire les données qui ont été écrites sur le disque par l'application, mais qui sont toujours dans la RAM et attendez qu'ils soient écrits sur le disque.

Les valeurs standard de ces variables dans les distributions de bureau Linux et Android sont approximativement les suivantes :

* vm.dirty_background_ratio = 10 * vm.dirty_ratio = 20

Cela signifie que lorsque la taille du tampon de données « sales » atteint 10 % de la quantité totale de RAM, le thread nucléaire pdflush se réveillera et commencera à écrire des données sur le disque. Si les opérations d'écriture de données sur le disque sont trop intensives et, même malgré le travail de pdflush, le tampon continue de croître, alors lorsqu'il atteint 20 % du volume RAM, le système basculera toutes les opérations d'écriture ultérieures en mode synchrone ( sans mise en mémoire tampon préalable) et le travail de ceux qui écrivent sur le disque les applications seront bloqués jusqu'à ce que les données soient écrites sur le disque (dans la terminologie Android, cela s'appelle le décalage).

Il est important de comprendre que, même si la taille du tampon n'a pas atteint 10 %, le système lancera d'une manière ou d'une autre le flux pdflush après 30 secondes. Que nous apporte cette connaissance ? En fait, rien que nous puissions utiliser à nos propres fins. La combinaison 10/20% est tout à fait raisonnable et, par exemple, sur un smartphone avec 1 Go de mémoire cela fait environ 100/200 Mo de mémoire, ce qui est largement suffisant dans des conditions de rares rafales d'écriture dont la vitesse est souvent inférieure à la vitesse d'écriture sur la mémoire NAND du système ou sur la carte SD (lors de l'installation d'un logiciel ou de la copie de fichiers à partir d'un ordinateur). Mais les créateurs de scripts d’optimisation ne sont bien sûr pas d’accord avec cela.

Par exemple, dans le script Xplix, vous pouvez trouver des lignes comme celle-ci (dans l'original, elles sont beaucoup plus longues en raison du contrôle de la quantité de RAM et de l'utilisation de BusyBox) :

Sysctl -w vm.dirty_background_ratio=50 sysctl -w vm.dirty_ratio=90

Ces commandes s'appliquent aux appareils dotés de 1 Go de mémoire, c'est-à-dire qu'elles fixent les limites du tampon sale à (environ) 500/900 Mo. Tel valeurs élevées absolument inutile pour un smartphone, puisqu'ils ne fonctionnent que dans des conditions d'enregistrement intensif et constant sur le disque, c'est-à-dire encore une fois pour un serveur très chargé. Dans une situation avec un smartphone, ils ne seront pas meilleurs que les standards. D'ailleurs, dans le script ThunderBolt ! Des valeurs beaucoup plus raisonnables (et proches de la norme) sont utilisées, mais je doute que l'utilisateur remarquera une différence par rapport à leur utilisation :

Si [ "$mem" -lt 524288 ]; alors sysctl -w vm.dirty_background_ratio=15; sysctl -w vm.dirty_ratio=30; elif [ "$mem" -lt 1049776 ]; puis sysctl -w vm.dirty_background_ratio=10; sysctl -w vm.dirty_ratio=20; sinon sysctl -w vm.dirty_background_ratio=5; sysctl -w vm.dirty_ratio=10; fi;

Les deux premières commandes sont exécutées sur des smartphones dotés de 512 Mo de RAM, la seconde - avec 1 Go et la troisième - avec plus de 1 Go. Mais en fait, il n'y a qu'une seule raison de modifier les valeurs standard : un appareil avec une mémoire interne et/ou une carte mémoire très lente (bonjour aux Chinois). Dans ce cas, il est raisonnable de séparer les valeurs des variables, c'est-à-dire de faire quelque chose comme ceci :

Sysctl -w vm.dirty_background_ratio=10 sysctl -w vm.dirty_ratio=60

Ensuite, lors de rafales soudaines d'opérations d'écriture, le système, n'ayant pas le temps d'écrire des données sur le disque, ne passera en mode synchrone qu'à la dernière minute, ce qui réduira les retards des applications lors de l'écriture.

Verdict : mieux vaut ne pas toucher.

Il existe un grand nombre d'optimisations plus petites, notamment le « réglage » de la pile réseau, la modification des variables du noyau Linux et Android (build.prop), mais 90 % d'entre elles n'ont aucun effet sur les performances réelles de l'appareil, et le reste 10 % améliorent certains aspects du comportement au détriment d’autres, ou augmentent si peu la productivité que vous ne le remarquerez même pas. De ce qui fonctionne réellement, on peut noter ce qui suit :

• Overclocking Un peu d'overclocking peut améliorer les performances, et une sous-tension peut prolonger la durée de vie de la batterie.
• Optimisation de la base de données. Je doute sérieusement que cela entraîne une augmentation notable de la vitesse, mais la théorie nous dit que cela devrait fonctionner.
• Alignez la fermeture éclair. C'est drôle, mais malgré la fonction d'alignement du contenu dans les fichiers APK intégrée au SDK Android, vous pouvez trouver sur le marché une grande quantité de logiciels qui ne sont pas passés par zipalign.
• Désactivation des services système inutiles, suppression du système inutilisé et des applications tierces rarement utilisées (j'en ai déjà parlé dans l'un des articles précédents).
• Noyau personnalisé avec optimisations pour un périphérique spécifique (encore une fois, tous les noyaux ne sont pas aussi bons).
• Le planificateur d'E/S noop déjà décrit.
• Algorithme de saturation Westwood+ TCP. Il est prouvé qu'il est beaucoup plus efficace sur les réseaux sans fil que le Cubic par défaut d'Android. Disponible dans les noyaux personnalisés.

LaraCraft304 des forums des développeurs XDA a mené des recherches et a découvert qu'un nombre impressionnant de paramètres /system/build.prop que les « experts » recommandent d'utiliser n'existent pas du tout dans texte source AOSP et CyanogenMod. Voici leur liste :

• ro.ril.disable.power.collapse
• ro.mot.eri.losalert.delay
• ro.config.hw_fast_dormancy
• ro.config.hw_power_ saving
• windowsmgr.max_events_per_sec
• persist.cust.tel.eons
• ro.max.fling_velocity
• ro.min.fling_velocity
• ro.kernel.checkjni
• dalvik.vm.verify-bytecode
• débogage.performance.tuning
• vidéo.accelerate.hw
• ro.media.dec.jpeg.memcap
• ro.config.nocheckin
• profiler.force_disable_ulog
• profileur.force_disable_err_rpt
• ersist.sys.shutdown.mode
• ro.HOME_APP_ADJ

Script pour optimiser les bases de données de paramètres du système et des applications. Naturellement, root et BusyBox sont nécessaires pour fonctionner.

#!/system/bin/sh
pour moi dans \
`busybox find /data -iname "*.db"` ;
faire\
/system/xbin/sqlite3 $i 'VIDE;';
/system/xbin/sqlite3 $i 'REINDEX;';
fait;