Les mythes d'optimisation Android les plus courants démystifiés

applications sur le Play Store, mais les scripts d'optimisation publiés sur les forums Android sont généralement bien intentionnés, il se trouve que le développeur peut être mal informé, ou simplement expérimenter divers réglages d'optimisation. Malheureusement, une sorte d'effet boule de neige a tendance à se produire, en particulier dans les scripts d'optimisation «tout-en-un». Une petite poignée de modifications peut en fait faire quelque chose , alors qu’une autre série de modifications dans un script peut ne rien faire du tout - pourtant, ces scripts sont transmis comme des balles magiques, sans véritable enquête sur ce qui fonctionne et ce qui ne fonctionne pas.

Ainsi, de nombreux scripts d'optimisation tout-en-un utilisent les mêmes méthodes, dont certaines sont complètement obsolètes ou nuisibles à long terme. En résumé, la majorité des scripts d'optimisation «tout-en-un» ne sont rien d'autre que des ajustements recommandés, sans idée claire du comment ou du pourquoi ces optimisations «fonctionnent - les utilisateurs flashent ensuite les scripts et affirment que leurs performances sont soudainement plus rapides. ( alors qu'en fait, c'est probablement le simple fait de redémarrer leur appareil qui a entraîné une augmentation des performances , car tout dans la RAM de l'appareil est nettoyé) .

Dans cet article exclusif Appuals, nous mettrons en évidence certaines des recommandations les plus courantes pour ' optimisation » Les performances d'Android, et s'il s'agit simplement d'un mythe ou d'une modification légitime des performances de l'appareil.



Échanger

En haut de la liste des mythes se trouve le swap Android - ce qui est assez absurde en termes d'être considéré comme une optimisation Android. L'objectif principal de Swaps est de créer et de connecter le fichier d'échange, ce qui libère de l'espace de stockage en mémoire. Cela semble raisonnable sur papier , mais c'est vraiment applicable à un serveur , qui n'a presque aucune interactivité.



Lorsque vous utilisez régulièrement le swap de votre téléphone Android, cela entraînera de graves retards dus au dépassement du cache. Imaginez, par exemple, si une application essaie d'afficher un graphique, qui est stocké dans le swap, qui doit maintenant recharger le disque après avoir libéré de l'espace en plaçant l'échange de données avec une autre application. C'est vraiment compliqué.



Certains amateurs d'optimisation peuvent dire que le swap n'a posé aucun problème, mais ce n'est pas le swap qui améliore les performances - c'est le mécanisme Android intégré lowmemorykiller , qui tueront régulièrement les processus hautement prioritaires qui ne sont pas utilisés. LMK a été conçu spécifiquement pour gérer les conditions de faible mémoire, est appelé à partir du kswapd processus, et tue généralement les processus de l'espace utilisateur. C'est différent de OOMkiller (tueur de mémoire insuffisante), mais c’est un sujet complètement différent.

Le fait est qu'un appareil avec, par exemple, 1 Go de RAM ne peut jamais atteindre les données de performances nécessaires dans un échange, et donc l'échange n'est absolument pas nécessaire sous Android. Sa mise en œuvre est simplement lourde de décalage et conduit à un dégradation en performance, plutôt que de l’optimiser.

zRAM - obsolète et plus efficace

zRAM est une méthode éprouvée et efficace d'optimisation des appareils, pour appareils plus anciens - pensez aux appareils basés sur KitKat qui ne fonctionnent qu'avec environ 512 Mo de RAM. Le fait que certaines personnes incluent encore des ajustements de zRAM dans les scripts d'optimisation, ou recommandent zRAM comme une sorte de réglage d'optimisation moderne, est un exemple de personnes qui ne suivent généralement pas les derniers protocoles opérationnels.



zRAM était destiné aux SoC multi-cœurs d'entrée de gamme, tels que les périphériques utilisant des chipsets MTK et 512 Mo de RAM. Des téléphones chinois très bon marché, en gros. Ce que zRAM fait essentiellement, c'est séparer le noyau via le flux de cryptage.

Lorsque zRAM est utilisé sur des appareils plus anciens avec noyau unique , même si zRAM est recommandé sur de tels appareils, de grandes quantités de retards ont tendance à apparaître. Cela se produit également avec la technologie KSM ( Fusion de la même page du noyau) qui combine des pages de mémoire identiques dans le but de libérer de l'espace. Ceci est en fait recommandé par Google, mais conduit à des retards plus importants sur les appareils plus anciens, car les threads de base constamment actifs fonctionnent en continu depuis la mémoire pour rechercher des pages en double. Fondamentalement, essayer d'exécuter le réglage d'optimisation ralentit encore davantage l'appareil, ironiquement.

Seeder - obsolète depuis Android 3.0

L'un des conseils d'optimisation les plus débattus parmi les développeurs Android est cèdre , et nous sommes sûrs que quelqu'un pourrait essayer de nous prouver le contraire sur ce sujet - mais nous devons d'abord examiner l'histoire du semoir.

Application Seeder pour Android

Oui, il existe un grand nombre de rapports qui déclarent de meilleures performances Android après l'installation sur appareils Android beaucoup plus anciens . Cependant, pour une raison quelconque, les gens pensent que cela signifie qu'il s'agit également d'une optimisation applicable pour appareils Android modernes , ce qui est absolument absurde. Le fait que le semoir soit toujours maintenu et offert en tant que « moderne' L'outil de réduction du décalage est un exemple de désinformation - bien que ce ne soit pas la faute du développeur de Seeder, car même leur page Play Store note que Seeder est moins efficace après Android 4.0+. Pourtant, pour une raison quelconque, Seeder apparaît toujours dans les discussions d'optimisation pour les systèmes Android modernes.

Ce que Seeder fait essentiellement pour Android 3.0 est de résoudre un bogue où l'exécution d'Android utiliserait activement le fichier / dev / random / pour acquérir l'entropie. Le tampon / dev / random / deviendrait instable et le système serait bloqué jusqu'à ce qu'il remplisse la quantité de données requise - pensez à de petites choses comme les différents capteurs et boutons de l'appareil Android.

L'auteur de Seeder a pris le démon Linux rngd , et compilé pour l'inastroil d'Android afin qu'il prenne des données aléatoires d'un chemin / dev / urandom beaucoup plus rapide et plus prévisible, et les fusionne dans dev / random / chaque seconde, sans permettre à / dev / random / de s'épuiser. Cela a abouti à un système Android qui n'a pas connu de manque d'entropie et qui a fonctionné beaucoup plus facilement.

Google a brisé ce bogue après Android 3.0, mais pour une raison quelconque, Seeder apparaît toujours sur 'Réglages recommandés' listes pour l'optimisation des performances Android. De plus, l'application Seeder a quelques analogues comme sEFix qui incluent la fonctionnalité de Seeder, que ce soit en utilisant le même rngd ou l'alternative avoir eu , ou même juste un lien symbolique entre / dev / urandom et / dev / random. Ceci est absolument inutile pour les systèmes Android modernes.

La raison pour laquelle c'est inutile est que les nouvelles versions d'Android utilisent / dev / random / dans trois composants principaux - libcrypto , pour le cryptage des connexions SSL, la génération de clés SSH, etc. WPA_supplication / hostapd qui génère des clés WEP / WPA, et enfin, une poignée de bibliothèques pour générer des ID lors de la création de systèmes de fichiers EXT2 / EXT3 / EXT4.

Donc quand Semoir ou des améliorations basées sur Seeder sont incluses dans les scripts d'optimisation Android modernes, ce qui finit par se produire est un dégradation dans les performances de l'appareil, car rngd réveillera constamment l'appareil et provoquera une augmentation de la fréquence du processeur, ce qui aura bien sûr un effet négatif sur la consommation de la batterie.

Odex

Le firmware d'origine sur les appareils Android est à peu près toujours odex. Cela signifie qu'à côté du package standard pour les applications Android au format APK, trouvé dans / system / app / et / system / priv-app /, sont des mêmes noms de fichiers avec l'extension .odex. Les fichiers odex contiennent des applications de bytecode optimisées qui sont déjà passées par la machine virtuelle du validateur et de l'optimiseur, puis enregistrées dans un fichier séparé utilisant quelque chose comme dexopt outil.

Ainsi, les fichiers odex sont destinés à décharger la machine virtuelle et à offrir un lancement accéléré de l'application odexed - à la baisse, les fichiers ODEX empêchent les modifications du micrologiciel et créent des problèmes avec les mises à jour, donc pour cette raison, de nombreuses ROM personnalisées comme LineageOS sont distribuées sans ODEX .

La génération de fichiers ODEX se fait de plusieurs façons, comme en utilisant Odexer Tool - le problème est que c'est purement un effet placebo. Lorsque le système Android moderne ne trouve pas de fichiers odex dans le répertoire / system, le système les crée en fait et les place dans le répertoire / system / dalvik-cache /. C'est exactement ce qui se passe lorsque, par exemple, vous flashez une nouvelle version d'Android et que cela donne le message «Occupé, optimisation des applications» pendant un moment.

Modifications de Lowmemorykiller

Le multitâche sous Android diffère des autres systèmes d'exploitation mobiles en ce sens qu'il est basé sur un modèle classique où les applications fonctionnent silencieusement en arrière-plan, et il n'y a aucune restriction sur le nombre d'applications en arrière-plan ( sauf si l'un d'entre eux est défini dans les options du développeur, mais cela est généralement recommandé) - de plus, la fonctionnalité de transition vers une exécution en arrière-plan n'est pas arrêtée, bien que le système se réserve le droit de tuer les applications en arrière-plan dans des situations de mémoire insuffisante ( voir où nous avons parlé de lowmemorykiller et out-of-memory killer plus haut dans ce guide) .

Pour revenir au lowmemorykiller mécanisme, Android peut continuer à fonctionner avec une quantité limitée de mémoire et un manque de partition de swap. L'utilisateur peut continuer à lancer des applications et basculer entre elles, et le système tuera silencieusement les applications d'arrière-plan inutilisées pour essayer de libérer de la mémoire pour les tâches actives.

Cela était très utile pour Android au début, bien que pour une raison quelconque, il soit devenu populaire sous la forme d'applications tueur de tâches, qui sont généralement plus nuisibles que bénéfiques. Les applications tueur de tâches se réveillent à des intervalles définis ou sont exécutées par l'utilisateur et semblent libérer de grandes quantités de RAM, ce qui est considéré comme un avantage - plus de RAM libre signifie un appareil plus rapide, non? Ce n’est cependant pas exactement le cas avec Android.

En fait, disposer d'une grande quantité de RAM libre peut en fait nuire aux performances et à la durée de vie de la batterie de votre appareil. Lorsque les applications sont stockées dans la RAM d'Android, il est beaucoup plus facile de les appeler, de les lancer, etc. Le système Android n'a pas besoin de consacrer beaucoup de ressources pour passer à l'application, car elle est déjà présente dans la mémoire.

Pour cette raison, les tueurs de tâches ne sont plus aussi populaires qu'ils l'étaient autrefois, bien que les novices d'Android aient toujours tendance à s'en remettre pour une raison quelconque ( manque d'informations, malheureusement) . Malheureusement, une nouvelle tendance a remplacé les tueurs de tâches, la tendance lowmemorykiller réglages du mécanisme. Ce serait par exemple MinFreeManager et l'idée principale est d'augmenter la surcharge de la RAM avant que le système ne commence à tuer les applications en arrière-plan.

Ainsi, par exemple, la RAM standard fonctionne aux frontières - 4, 8, 12, 24, 32 et 40 Mo, et lorsque l'espace de stockage libre de 40 Mo est rempli, l'une des applications en cache qui est chargée en mémoire mais pas en cours d'exécution sera résilié.

Donc, fondamentalement, Android aura toujours au moins 40 Mo de mémoire disponible, ce qui est suffisant pour accueillir une autre application avant lowmemorykiller commence son processus de nettoyage - ce qui signifie qu'Android fera toujours de son mieux pour utiliser la quantité maximale de RAM disponible sans interférer avec l'expérience utilisateur.

Malheureusement, ce que certains amateurs de homebrew ont recommandé, c'est que la valeur soit augmentée à, par exemple, 100 Mo avant que LMK entre en jeu. Désormais, l'utilisateur va réellement perdre RAM (100 - 40 = 60), donc au lieu d'utiliser cet espace pour stocker des applications back-end, le système conservera cette quantité de mémoire libre , sans aucun but.

Réglage LKM peut être utile pour les appareils beaucoup plus anciens avec 512 RAM, mais qui en possède plus? 2 Go est la «gamme budgétaire» moderne, même les périphériques de 4 Go de RAM sont considérés comme «milieu de gamme» ces jours-ci, les ajustements LMK sont donc vraiment obsolètes et inutiles.

Ajustements d'E / S

Dans de nombreux scripts d'optimisation pour Android, vous trouverez souvent des ajustements qui concernent le sous-système d'E / S. Par exemple, jetons un œil à la Coup de tonnerre! Script, qui contient ces lignes:

echo 0> $ i / queue / rotation; echo 1024> $ i / queue / nr_requests;

La première ligne donnera les instructions du planificateur d'E / S pour traiter un SSD, et la seconde augmentera la taille maximale des E / S de la file d'attente de 128 à 1024 - car la variable $ i contient un chemin vers l'arborescence des périphériques de bloc dans / sys, et le script s'exécute en boucle.

Ensuite, vous trouvez une ligne relative au planificateur CFQ:

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

Ceci est suivi par plus de lignes qui appartiennent à d'autres planificateurs, mais finalement, les deux premières commandes sont inutiles car:

Un noyau Linux moderne est capable de comprendre le type de support de stockage avec lequel il travaille par défaut.

Une longue file d'attente d'entrée-sortie ( comme 1024) est inutile sur un appareil Android moderne, en fait, cela n'a pas de sens même sur le bureau - c'est vraiment recommandé uniquement sur serveurs lourds . Votre téléphone n'est pas un serveur Linux robuste.

Pour un appareil Android, il n'y a pratiquement aucune application priorisée dans l'entrée-sortie et aucun pilote mécanique, donc le meilleur planificateur est la file d'attente noop / FIFO, donc ce type de planificateur ' tordre' ne fait rien de spécial ou de significatif pour le sous-système d'E / S. En fait, toutes ces commandes de liste multi-écrans sont mieux remplacées par un cycle simple:

pour i dans / sys / block / mmc *; do echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats terminé

Cela permettrait au planificateur noop pour tous les lecteurs de l'accumulation de statistiques d'E / S, ce qui devrait avoir un impact positif sur les performances, bien que très petit et presque complètement négligeable.

Un autre ajustement inutile d'E / S souvent trouvé dans les scripts de performance est l'augmentation des valeurs de lecture anticipée pour les cartes SD jusqu'à 2 Mo. Le mécanisme de lecture anticipée est destiné aux premières lectures de données à partir du support, avant que l'application ne demande l'accès à ces données. Donc, fondamentalement, le noyau essaiera de déterminer quelles données seront nécessaires à l'avenir, et les préchargera dans la RAM, ce qui devrait donc réduire le temps de retour. Cela semble bien sur le papier, mais l'algorithme de lecture anticipée est plus souvent faux , ce qui conduit à des opérations d'entrée-sortie totalement inutiles, sans parler d'une consommation élevée de RAM.

Des valeurs de lecture anticipée élevées comprises entre 1 et 8 Mo sont recommandées dans les matrices RAID, mais pour les appareils Android, il est préférable de laisser simplement la valeur par défaut de 128 Ko.

Ajustements du système de gestion de la mémoire virtuelle

Une autre technique 'd'optimisation' courante consiste à régler le sous-système de gestion de la mémoire virtuelle. Cela ne cible généralement que deux variables du noyau, vm.dirty_background_ratio et vm.dirty_ratio, qui servent à ajuster la taille du tampon pour stocker les données «sales». Sale les données sont généralement des données qui ont été écrites sur le disque, mais il y en a plus encore en mémoire et en attente d’écriture sur le disque.

Les valeurs de réglage typiques dans les distributions Linux et Androis du sous-système de gestion de VM seraient comme:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

Donc, ce que cela essaie de faire, c'est que lorsque le tampon de données sales représente 10% de la quantité totale de RAM, il se réveille pdflush flux et commence à écrire des données sur le disque - si l'opération d'enregistrement des données sur le disque sera trop intense , le tampon continuera de croître, et lorsqu'il atteindra 20% de la RAM disponible, le système passera à l'opération d'écriture suivante en mode synchrone - sans pré-tampon. Cela signifie que le travail d'écriture sur l'application de disque sera bloqué, jusqu'à ce que les données soient écrites sur le disque (AKA «lag»).

Ce que vous devez comprendre, c'est que même si la taille du tampon n'atteint pas 10% , le système lancera automatiquement pdflush après 30 secondes. Une combinaison de 10/20 est assez raisonnable, par exemple sur un appareil avec 1 Go de RAM, cela équivaudrait à 100/200 Mo de RAM, ce qui est plus que suffisant en termes d'enregistrements en rafale où la vitesse est souvent inférieure au record de vitesse dans le système NAND -mémoire ou carte SD, comme lors de l'installation d'applications ou de la copie de fichiers à partir d'un ordinateur.

Pour une raison quelconque, les scénaristes essaient de pousser cette valeur encore plus haut, à des taux absurdes. Par exemple, nous pouvons trouver dans le Xplix script d'optimisation un taux aussi élevé que 50/90.

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

Sur un appareil avec 1 Go de mémoire, cela définit la limite d'un tampon sale à 500/900 Mo, ce qui est complètement inutile pour un appareil Android, car cela ne fonctionnerait que sous enregistrement constant sur le disque - quelque chose qui ne se produit que sur un serveur Linux lourd.

Coup de tonnerre! Script utilise une valeur plus raisonnable, mais dans l'ensemble, cela n'a toujours pas de sens:

if ['$ mem' -lt 524288]; alors sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; alors sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; else sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; Fi;

Les deux premières commandes sont exécutées sur les smartphones avec 512 Mo de RAM, la seconde - avec 1 Go, et d'autres - avec plus de 1 Go. Mais en fait, il n'y a qu'une seule raison de modifier les paramètres par défaut - un appareil avec une mémoire interne ou une carte mémoire très lente. Dans ce cas, il est raisonnable de répartir 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, lorsqu'un système de surtension écrit des opérations, sans avoir à enregistrer de données sur le disque, le dernier ne passera pas en mode synchrone, ce qui permettra aux applications de réduire le décalage lors de l'enregistrement.

Modifications et réglages de performances inutiles supplémentaires

Il y a beaucoup plus d’optimisations qui ne font vraiment rien. La plupart d'entre eux n'ont tout simplement aucun effet, tandis que d'autres peuvent s'améliorer certains aspect de la performance, tout en dégradant l'appareil par d'autres moyens ( généralement, cela se résume à la performance par rapport à l'épuisement de la batterie) .

Voici quelques optimisations populaires supplémentaires qui peuvent être utiles ou non, selon le système et l'appareil Android.

  • Accélération - La petite accélération pour améliorer les performances et la sous-tension - économise un peu de batterie.
  • Optimisation de la base de données - En théorie, cela devrait donner une amélioration des performances de l'appareil, mais c'est douteux.
  • Zipalign - Ironiquement, malgré l'alignement du contenu de la fonctionnalité Android SDK intégré dans le fichier APK dans le magasin, vous pouvez trouver que beaucoup de logiciels ne sont pas transmis via zipalign.
  • Désactivez les services système inutiles, supprimez le système inutilisé et les applications tierces rarement utilisées. Fondamentalement, la désinstallation de bloatware.
  • Noyau personnalisé avec optimisations pour un périphérique spécifique (encore une fois, tous les noyaux ne sont pas aussi bons).
  • Planificateur d'E / S déjà décrit noop.
  • Algorithme de saturation TCP Westwood - Utilisé plus efficacement dans Android Cubic par défaut pour les réseaux sans fil, disponible dans les noyaux personnalisés.

Paramètres inutiles build.prop

LaraCraft304 du forum XDA Developers a mené une étude et a découvert qu'un nombre impressionnant de paramètres /system/build.prop qui sont recommandés pour une utilisation «experts» n'existent pas dans les sources AOSP et CyanogenMod. Voici la 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 debug.performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rodept ersist.sys.shutdown_rodept roAPOME
Mots clés Android Développement 12 minutes de lecture