Tl;dr
C'est possible avec Root, vous pouvez modifier oom_adj
pour empêcher les applications d'être tuées, pour forcer l'application cible à rester en mémoire en la "verrouillant" ou pour modifier certains paramètres responsables de la mort des applications en cas de manque de mémoire.
Fond d'écran : Gestion de la RAM sous Android
Android utilise une manière différente de gérer les processus. Au lieu de tuer chaque processus après la fin de son activité, les processus sont conservés jusqu'à ce que le système ait besoin de plus de mémoire. L'idée est de donner des améliorations de vitesse si vous recommencez cette activité. Mais comment/quand Android tue-t-il un processus s'il a besoin de plus de mémoire et quel processus tuer en premier ?
Ceci est géré par le pilote LMK (Low Memory Killer) d'Android. Vous savez peut-être déjà que chaque application/processus d'Android se voit attribuer une oom_adj
qui indique la probabilité qu'il soit tué lorsque lorsqu'une situation d'absence de mémoire (OOM) se produit. Plus sa valeur est élevée, plus la plus la probabilité qu'il soit tué est élevée. La plage valide est -17
à +15
. (si dans le -17
signifie qu'il ne sera pas tué). D'après ça, il y a six groupes (groupes OOM), dans lesquels les applications/processus sont classés sont catégorisés :
- Application de premier plan
- Application visible
- Serveur secondaire
- Application cachée
- Fournisseur de contenu
- Application vide
En gros, on pourrait les décrire comme suit :
FOREGROUND_APP
: C'est le processus qui exécute l'application de premier plan actuelle courante. Nous préférons vraiment ne pas le tuer !
VISIBLE_APP
: Il s'agit d'un processus n'hébergeant que des activités qui sont visibles pour l'utilisateur, donc nous préférerions qu'elles ne disparaissent pas.
SECONDARY_SERVER
: C'est un processus qui tient un serveur secondaire -- le tuer n'aura pas beaucoup d'impact pour l'utilisateur. l'utilisateur.
HIDDEN_APP
: Il s'agit d'un processus n'hébergeant que des activités qui ne sont pas visibles, il peut donc être tué sans aucune perturbation.
CONTENT_PROVIDER
: Il s'agit d'un processus avec un fournisseur de contenu qui n'a pas de clients attachés à lui. S'il avait des clients, son ajustement serait celui du processus le plus prioritaire parmi ces clients. processus.
EMPTY_APP
: Il s'agit d'un processus sans rien en cours d'exécution il. C'est certainement le premier à disparaître.
Ces groupes sont définis par oom_adj
et les pommes seraient classées dans l'un de ces groupes en fonction de leur valeur limite. oom_adj
valeur attribuée à cette application particulière. Les "applications d'avant-plan" ont généralement une valeur oom_adj
valeur de 0
ou moins (afin qu'ils soient les moins susceptibles d'être tués, c'est-à-dire une priorité élevée).
Les "applications vides" ont un taux de oom_adj
(ils sont tués tôt, c'est-à-dire en basse priorité). Aussi, oom_adj
La valeur change en fonction de l'état de l'application de l'utilisateur. 0
lorsque l'application est active au premier plan et une valeur plus élevée lorsque l'application passe en arrière-plan.
Pourquoi leur "tuabilité" diffère-t-elle ? Les applications appartenant à ces différents groupes (qui ont des oom_adj's
), commencent à être tués à différents niveaux de RAM libre. Ces limites de déclenchement de la RAM sont définies par les valeurs de LMK minfree. Les 6 catégories ci-dessus correspondent à 6 limites de RAM qui sont définies dans LMK minfree. eg : Stock Android 4.3 dans mon est livré avec les valeurs minfree suivantes 48,60,72,84,96,120
. (ces sont en MB).
![enter image description here]()
En pratique, cela signifie que les applications vides seront tuées lorsque la mémoire vive descend en dessous de 120mb, les fournisseurs de contenu lorsqu'elle descend en dessous de 96mb, les applications cachées lorsqu'elle descend en dessous de 84mb et ainsi de suite enfin, les applications d'avant-plan sont tuées lorsque la mémoire vive descend en dessous de 48mb.
NB :
-
Dans les noyaux plus récents, oom_ score _adj
est utilisé à la place de l'ancien oom_adj
. (la plage valide de oom_score_adj est de -1000 à 1000). Mais oom_adj
est également maintenu pour une éventuelle compatibilité.
-
Il est dit qu'il existe de nombreuses catégories de processus d'OOM auxquelles sont attribuées différentes oom_adj
priorités par le ActivityManagerService
Mais finalement, tous ces éléments seront considérés comme faisant partie des six slots/groupes ci-dessus (selon oom_limits), dans le but d'être tués par les triggers LMK minfree. Par conséquent, ces six sont les plus importants pour les utilisateurs normaux.
- Nous pouvons vérifier les valeurs de minfree (ou les modifier) et voir les OOM. des applications/processus avec cette application Memory Manager.
-
Tous les appareils n'ont pas la même configuration d'OOM.
Améliorer la gestion de la RAM
Aujourd'hui, le mécanisme de gestion de la RAM est mis en œuvre de manière très conviviale dans les paramètres du système (par exemple, l'optimisation des applications dans les paramètres de la batterie), Applications protégées dans certains ROMS, par exemple EMUI de Huawei etc.) et peuvent avoir le même effet que celui décrit ci-dessus :
![enter image description here]()
Cela dit, nous pouvons maintenant explorer les moyens d'utiliser la RAM sans tuer trop souvent les applications de premier plan. Les domaines ciblés seront les suivants :
1. ajuster les valeurs de minifree en fonction de ses besoins
2. le verrouillage des applications en mémoire pour éviter qu'elles ne soient détruites.
3. passer outre la limite des applications cachées d'Android
-
Ajustement des valeurs minifree
-
Vous pouvez modifier les valeurs minfree avec le gestionnaire de mémoire et appuyer sur appliquer. (En outre, il y a une option "appliquer au démarrage" et cocher pour préserver les paramètres entre les démarrages). Plusieurs applications peuvent réaliser cela, par exemple Gestionnaire de mémoire , Gestionnaire Minfree etc.
-
Vous pouvez également utiliser terminal/adb en utilisant les pages :
#!/system/bin/sh echo “values” > /sys/module
-
Verrouiller les applications pour qu'elles restent en mémoire (les rendre résidentes)
a) Utiliser les paramètres de l'application (Xposed)
- Une méthode simple consiste à utiliser le module Xposed, les paramètres de l'application (vous avez besoin de Cadre Xposed installé)
- Après avoir installé le framework, téléchargez le module 'App Settings' via l'installateur Xposed.
- Ouvrez les paramètres de l'application et permettez aux applications de se charger, sélectionnez l'application cible (dans ce cas-ci navigateur firefox )
- Dans la page des paramètres, activez le commutateur et activez le mode d'édition, cochez l'option "Résident" et enregistrez. ( En rendant les applications résidentes, les applications restent en mémoire sans être tuées et il est conseillé d'utiliser le bouton de sortie de l'application cible si elle n'est plus nécessaire, sinon elle privera les autres applications de mémoire).
![enter image description here]()
b) En utilisant armoire à souvenirs
Une autre mise en œuvre de ce concept consiste à verrouiller l'application cible en mémoire en contrôlant les fichiers système pour la mise en place de oom_adj
pour tous les processus en cours.
Comment fonctionne l'application :
Memory locker contrôle les fichiers du répertoire /data et contrôle également les fichiers système dans Root pour définir oom_adj pour les processus en cours.
Toutes les applications applications verrouillées sont automatiquement verrouillées après chaque redémarrage. Les applications sont classées en tant qu'applications téléchargées/système. et cliquez sur le verrou sur le côté droit. (Vous pouvez éventuellement définir oom_adj
priorité)
-
Remplacer la limite des applications cachées
-
En plus du mécanisme de destruction de la mémoire faible, il existe un autre paramètre qui contrôle la destruction des applications cachées et vides. Les applications sont détruites lorsqu'elles dépassent les limites spécifiées.
-
Il existe un paramètre du fichier build.prop qui permet de contrôler cette valeur (la valeur par défaut est généralement un nombre faible, inférieur à 25, et la modifier peut augmenter cette valeur à une valeur beaucoup plus grande, comme 80)
-
Ajoutez cette ligne au fichier build.prop dans /system et laissez une autre ligne vierge en dessous (assurez-vous de faire un back up avant)
ro.sys.fw.bg_apps_limit=80
Références et crédits
-
Gestion de la RAM sous Android (Crédits spéciaux : mrhnet )
- Casier à mémoire
- Xposed - Informations générales, versions et journal des modifications