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

Il existe de nombreux guides pédagogiques dédiés à l'amélioration des performances d'Android et des conseils d'optimisation généraux. Certains d'entre eux sont légitimes, et d'autres ne sont basés qu'en théorie, ou des méthodes opérationnelles obsolètes dans le système Android, ou sont tout simplement absurdes. Cela inclut des recommandations sur l’échange, les valeurs ajoutées à build.prop et les modifications de variables dans le noyau Linux.

Il existe même une tonne de «scripts d'optimisation», des zips compressibles tout-en-un qui promettent d'augmenter considérablement les performances, la durée de vie de la batterie, etc. Certaines des modifications peuvent effectivement fonctionner, mais la plupart ne sont qu'un effet placebo, ou pire, ont un impact négatif sur votre appareil.

Cela ne veut pas dire que les gens publient intentionnellement des scripts néfastes - il existe certainement de fausses applications payantes sur le Play Store, mais les scripts d'optimisation publiés sur les forums Android sont généralement bien intentionnés, il arrive que le développeur soit mal informé, ou simplement expérimenter différents 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 réalité 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 réglages recommandés, sans idée claire de savoir comment ou pourquoi ces optimisations «fonctionnent» - les utilisateurs flasquent ensuite les scripts et prétendent que leurs performances sont soudainement plus rapides. ( alors qu’il s’agissait très probablement du simple fait de redémarrer leur périphérique, ce qui a entraîné une augmentation des performances, car tout ce qui se trouvait dans la RAM de celui-ci était alors nettoyé) .

Dans cet article exclusif Appuals, nous soulignerons certaines des recommandations les plus courantes pour « optimiser» les performances d'Android, qu'il s'agisse simplement d'un mythe ou d'un ajustement légitime des performances de l'appareil.

Échanger

Au sommet de la liste des mythes se trouve l’échange d’Android, ce qui est assez absurde d’être considéré comme une optimisation pour Android. L'objectif principal des échanges est de créer et de connecter le fichier d'échange, ce qui permettra de libérer de l'espace de stockage en mémoire. Cela semble raisonnable sur le papier, mais il s’applique vraiment à un serveur, qui n’a presque aucune interactivité.

Lorsque vous utilisez régulièrement l’échange de votre téléphone Android, il se produit de graves décalages dus au fait que des éléments disparaissent de la mémoire cache. Imaginons, par exemple, si une application tente 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 le swap de données avec une autre application. C'est vraiment en désordre.

Certains passionnés d'optimisation peuvent affirmer que l'échange ne pose aucun problème, mais ne permet pas d'améliorer les performances. Il s'agit du mécanisme intégré lowmemorykiller d' Android, qui supprime régulièrement les processus saturés et hautement prioritaires qui ne sont pas utilisés. LMK a été spécialement conçu pour gérer les conditions de mémoire insuffisante. Il est appelé à partir du processus kswapd et tue généralement les processus d’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 doté, par exemple, de 1 Go de RAM ne peut jamais atteindre les données de performances nécessaires dans un échange. Un échange n'est donc absolument pas nécessaire dans Android. Sa mise en œuvre est simplement lourde de retard et conduit à une dégradation des performances, plutôt que de l'optimisation.

zRAM - obsolète et plus efficace

zRAM est une méthode éprouvée et efficace pour l'optimisation des appareils, pour les appareils plus anciens . Pensez aux appareils basés sur KitKat qui ne fonctionnent que sur environ 512 Mo de RAM. Le fait que certaines personnes incluent toujours des modifications zRAM dans les scripts d'optimisation, ou recommandent zRAM en tant que sorte d'optimisation moderne, est un exemple de personnes qui ne suivent généralement pas les derniers protocoles opérationnels.

La zRAM était destinée aux systèmes sur puce centrés pour les budgets d'entrée de gamme, tels que les dispositifs utilisant des jeux de puces MTK et 512 Mo de RAM. Téléphones chinois très bon marché, fondamentalement. En gros, zRAM sépare le noyau via le flux de cryptage.

Lorsque zRAM est utilisé sur des appareils plus anciens avec un seul cœur, même si zRAM est recommandé sur de tels appareils, de grandes quantités de décalage tendent à apparaître. Cela se produit également avec la technologie KSM ( fusion de pages identiques au 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 décalages plus importants sur les appareils plus anciens, car les core actifs constamment actifs exécutent en permanence la mémoire pour rechercher les pages en double. Essentiellement, essayer d'exécuter le réglage d'optimisation ralentit le périphérique encore plus, ironiquement.

Seeder - périmé depuis Android 3.0

Un des conseils d'optimisation les plus controversés parmi les développeurs Android est le semoir, et nous sommes certains que quelqu'un pourrait essayer de prouver que nous avons tort sur ce sujet - mais nous devons d'abord examiner l'historique de Seeder.

Oui, de nombreux rapports déclarent de meilleures performances Android après l'installation sur des appareils Android beaucoup plus anciens . Cependant, pour une raison quelconque, les gens croient que cela signifie également qu'il s'agit d'une optimisation applicable aux appareils Android modernes, ce qui est absolument absurde. Le fait que Seeder soit toujours maintenu et proposé comme un outil « moderne» 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 indique que Seeder est moins efficace après Android 4.0+. Pourtant, pour une raison quelconque, Seeder apparaît toujours dans les discussions sur l'optimisation des systèmes Android modernes.

En gros, ce que fait Seeder pour Android 3.0, c’est résoudre un bogue dans lequel le moteur d’exécution Android utiliserait activement le fichier / dev / random / pour acquérir une entropie. Le / dev / random / buffer deviendrait instable et le système serait bloqué tant qu'il ne contiendrait pas la quantité de données requise - pensez à de petites choses comme les divers capteurs et boutons de l'appareil Android.

L'auteur de Seeder a pris Linux-demon rngd et l'a compilé pour l'inastro 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 en dev / random / chaque seconde, sans autoriser / dev / random / devenir épuisé. Cela a abouti à un système Android qui ne manquait pas d'entropie et qui fonctionnait beaucoup mieux.

Google a écrasé ce bogue après Android 3.0 et pourtant, pour une raison quelconque, Seeder apparaît toujours sur les listes de «réglages recommandés» pour l'optimisation des performances Android. En outre, l’application Seeder a quelques analogues, comme sEFix, qui incluent les fonctionnalités de Seeder, qu’ils utilisent le même rngd ou l’alternative, ou même un simple lien symbolique entre / dev / urandom et / dev / random. Ceci est absolument inutile pour les systèmes Android modernes.

Cela ne sert à rien, car 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 bibliothèques pour générer l’ID lors de la création de systèmes de fichiers EXT2 / EXT3 / EXT4.

Ainsi, lorsque des améliorations basées sur Seeder ou basées sur Seeder sont incluses dans les scripts d'optimisation Android modernes, il en résulte une dégradation des performances de l'appareil, car rngd éveille constamment l'appareil et entraîne une augmentation de la fréquence du processeur, ce qui bien sûr a un impact négatif sur la consommation de la batterie. .

Odex

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

Les fichiers odex sont donc conçus pour décharger la machine virtuelle et offrent un lancement accéléré de l'application odexed. En revanche, les fichiers ODEX empêchent les modifications du micrologiciel et créent des problèmes de mises à jour. C'est pourquoi de nombreuses ROM personnalisées telles que LineageOS sont distribuées sans ODEX .

La génération de fichiers ODEX s'effectue de différentes manières, comme avec Odexer Tool. Le problème est qu’il s’agit uniquement d’un effet placebo. Lorsque le système Android moderne ne trouve pas les fichiers odex dans le répertoire / system, le système les crée 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 le message «Occupé, optimisation des applications» apparaît pendant un moment.

Lowmemorykiller tweaks

Le multitâche dans Android diffère des autres systèmes d’exploitation mobiles en ce sens qu’il est basé sur un modèle classique dans lequel les applications fonctionnent en arrière-plan, sans restriction quant au nombre d’applications en arrière-plan (à moins qu’une autre ne soit définie dans Options de développeur, mais c généralement déconseillé) - de plus, la fonctionnalité de transition vers une exécution en arrière-plan n’est pas interrompue, bien que le système se réserve le droit de supprimer les applications en arrière-plan dans les situations de mémoire insuffisante ( voir où nous avons parlé plus tôt de cette mémoire, de la mémoire faible et de la mémoire insuffisante. guide) .

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

Cela a été très utile pour Android dans les premiers jours, bien que pour une raison quelconque, il soit devenu populaire sous la forme d'applications «Task Killer», qui sont généralement plus nuisibles que bénéfiques. Les applications qui tuent les tâches se réveillent à 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 positif - plus de RAM disponible signifie un périphérique plus rapide, n'est-ce pas? Ce n'est pas exactement le cas avec Android, cependant.

En fait, disposer d'une grande quantité de mémoire RAM libre peut nuire aux performances et à l'autonomie de votre appareil. Lorsque les applications sont stockées dans la mémoire 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 au basculement vers l'application, car il est déjà dans la mémoire.

Pour cette raison, les tueurs de tâches ne sont plus aussi populaires qu’auparavant, même si les novices sous Android ont encore tendance à s’en remettre à eux pour une raison quelconque ( manque d’informations, malheureusement) . Malheureusement, une nouvelle tendance a remplacé les destructeurs de tâches, la tendance à la mise au point de mécanismes à faibles inhibiteurs de la mémoire . Ce serait par exemple l'application MinFreeManager, et l'idée principale est d'augmenter la charge de mémoire vive avant que le système ne commence à supprimer les applications en arrière-plan.

Ainsi, par exemple, la RAM standard fonctionne aux frontières - 4, 8, 12, 24, 32 et 40 Mo. Lorsque l’espace de stockage disponible de 40 Mo est saturé, l’une des applications en cache est chargée en mémoire mais ne s'exécute pas. sera terminé.

Donc, fondamentalement, Android aura toujours au moins 40 Mo de mémoire disponible, ce qui est suffisant pour accueillir une application supplémentaire avant que lowmemorykiller ne commence son processus de nettoyage - ce qui signifie qu'Android fera toujours de son mieux pour utiliser le maximum de RAM disponible sans interférer avec les ressources. expérience utilisateur.

Malheureusement, ce que certains amateurs de homebrew ont commencé à recommander est que la valeur soit augmentée à, par exemple, 100 Mo avant que LMK n'intervienne. Maintenant, l'utilisateur perdra réellement de la mémoire vive (100 - 40 = 60). Au lieu d'utiliser cet espace pour stocker Dans les applications finales, le système gardera cette quantité de mémoire libre, sans aucun but.

Le réglage LKM peut être utile pour les appareils beaucoup plus anciens avec 512 RAM, mais à qui appartient-il désormais? 2 Go est la "gamme de budget" moderne, même les périphériques de 4 Go de RAM sont considérés comme "de milieu de gamme" de nos jours, de sorte que les réglages LMK sont vraiment obsolètes et inutiles.

I / O tweaks

Dans de nombreux scripts d'optimisation pour Android, vous trouverez souvent des réglages qui concernent le sous-système d'E / S. Par exemple, jetons un coup d'oeil au ThunderBolt! 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 augmente la taille maximale de l’E / S de la file d’attente de 128 à 1024, car la variable $ i contient un chemin vers l’arborescence des périphériques en mode bloc. / sys et le script s'exécute en boucle.

Ensuite, vous trouvez une ligne liée 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; 

Viennent ensuite d'autres lignes appartenant à d'autres planificateurs, mais les deux premières commandes sont finalement 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’entrées-sorties ( telle que 1024) est inutile sur un appareil Android moderne. En fait, elle n’a aucun sens, même sur un ordinateur de bureau - elle n’est vraiment recommandée que sur des serveurs à usage intensif . Votre téléphone n’est pas un serveur Linux très puissant.

Pour un appareil Android, il n'y a pratiquement aucune application priorisée dans l'entrée-sortie et pas de pilote mécanique. Le meilleur outil de planification est donc la file d'attente noop / FIFO. Ce type de planificateur ne fait donc rien de spécial ni de significatif pour l'utilisateur. Sous-système I / O. En fait, il est préférable de remplacer toutes ces commandes de liste multi-écrans par un simple cycle:

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

Cela permettrait au programmateur noop de tous les disques de l’accumulation de statistiques d’E / S, ce qui devrait avoir un impact positif sur les performances, bien que très minime et presque totalement négligeable.

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

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

Modification 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 concerne généralement que deux variables du noyau, vm.dirty_background_ratio et vm.dirty_ratio, qui permettent d'ajuster la taille de la mémoire tampon pour le stockage de données «modifiées». Les données sales sont généralement des données écrites sur le disque, mais il en reste encore en mémoire et en attente d'écriture sur le disque.

Les valeurs typiques de réglage dans les distributions Linux et Androis dans le sous-système de gestion de la machine virtuelle seraient les suivantes:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Donc, cela tente de faire en sorte que lorsque le tampon de données altéré représente 10% de la quantité totale de RAM, il réveille le flux pdflush et commence à écrire des données sur le disque - si l'opération d'enregistrement de données sur le disque est trop intense, la mémoire 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 de la mémoire tampon n'atteint pas 10%, le système lancera automatiquement pdflush au bout de 30 secondes. Une combinaison de 10/20 est assez raisonnable, par exemple sur un périphérique avec 1 Go de RAM, cela équivaut à 100/200 Mo de RAM, ce qui est amplement suffisant en termes d'enregistrements en rafale où la vitesse est souvent inférieure à celle du système NAND. -mémoire ou carte SD, par exemple 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 vitesses absurdes. Par exemple, nous pouvons trouver dans le script d' optimisation Xplix un taux aussi élevé que 50/90.

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

Sur un appareil disposant de 1 Go de mémoire, cela limite la mémoire tampon sale à 500/900 Mo, ce qui est totalement inutile pour un appareil Android, car il ne fonctionnerait que sous un enregistrement constant sur le disque - ce qui ne se produit que très souvent. Serveur Linux.

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

 if ["$ 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 disposant de 512 Mo de RAM, la seconde avec 1 Go et d’autres avec plus de 1 Go. Mais en réalité, il n’ya qu’une seule raison de modifier les paramètres par défaut: un périphérique doté d’une mémoire interne ou d’une carte mémoire très lente. Dans ce cas, il est raisonnable d’étaler 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, quand un système surtension écrit des opérations, sans avoir à enregistrer de données sur le disque, la dernière ne passera pas en mode synchrone, ce qui permettra aux applications de réduire les délais lors de l’enregistrement.

Compléments inutiles et réglages de performances

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 améliorer certains aspects des performances, tout en dégradant l’appareil de différentes manières (en général, il s’agit de la performance par rapport à la perte de batterie) .

Voici quelques optimisations populaires supplémentaires qui peuvent être utiles ou non, selon le système et le périphérique Android.

• Accélération - La petite accélération pour améliorer les performances et la sous-résolution - é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 des fonctionnalités du SDK Android intégré dans le fichier APK du magasin, vous pouvez constater que de nombreux logiciels ne sont pas transmis via zipalign.
• Désactivez les services système inutiles en supprimant les applications système inutilisées et les applications tierces rarement utilisées. Fondamentalement, désinstaller bloatware.
• Noyau personnalisé avec optimisations pour un périphérique spécifique (encore une fois, tous les noyaux ne sont pas aussi bons).
• Déjà décrit le planificateur d'E / S 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 révélé qu’un nombre impressionnant de paramètres /system/build.prop 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. kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelerate.hw ro.media.dec.empap.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt