Comment fonctionne Hedroom, étape par étape

Hedroom lit quelques chiffres dans macOS, remarque quand une app dérape, suggère une correction et mesure ce qui s’est passé après votre accord. Voici chaque étape, avec les seuils utilisés.

Les chiffres de cette page proviennent des documents de conception et du code de Hedroom. Quand un chiffre est une mesure, il indique quand et sur quel Mac. Hedroom n’est pas encore sorti ; rien de tout cela ne décrit donc une version publique.

1. Échantillonner : ce qu’il lit et à quelle fréquence

Toutes les mesures viennent d’un seul échantillonneur qui s’exécute hors du thread principal, pour que l’app reste réactive. Chaque source est un morceau de code distinct derrière une interface, ce qui permet aussi de la tester avec de fausses données. Voici les sources :

Le cycle

Un « cycle » est une série de mesures. Sa fréquence dépend de ce que vous faites :

Les Réglages proposent un choix « Vérifier mon Mac toutes les » de 2, 5 ou 10 secondes pour la fréquence fenêtre ouverte ; les fréquences en arrière-plan en découlent. Les mesures brutes sont conservées 48 heures. Tout reste sur votre Mac, dans un fichier de base de données de votre dossier Bibliothèque. Voir Confidentialité.

2. Détecter : ce qui compte comme un constat

Hedroom ne donne pas l’alerte simplement parce qu’un chiffre est grand. Il compare chaque app à sa taille habituelle sur votre Mac, et attend de voir si le changement dure.

Mémoire : Sain, Sous tension, Critique

Hedroom affiche l’un de trois états. Les seuils sont écrits et testés.

Un swap simplement utilisé ne met jamais le Mac Sous tension, car macOS conserve l’ancien swap. Seul le swap qui croît compte. Une mémoire très « utilisée » avec une pression saine est Sain. Pourquoi la pression, pas la RAM utilisée explique la différence.

Une fuite : une app bien au-delà de sa taille habituelle, pendant un certain temps

Pour chaque app, Hedroom apprend une taille habituelle à partir de vos 7 derniers jours d’utilisation normale. Il ne signale une fuite que si toutes ces conditions sont réunies :

• L’app fait au moins 3 fois sa taille habituelle. À 2,5 fois, elle apparaît comme « en croissance » et rien de plus.
• Elle fait au moins 1 Go, ou 6 % de votre RAM si c’est plus.
• Elle y reste 20 minutes d’affilée, ou continue de croître selon une tendance sur 30 minutes.
• Elle ne figure pas sur votre liste « Ne jamais toucher », n’est pas faite par Apple (avec une petite exception pour les apps Apple que vous utilisez vous-même) et n’est pas une app que la bibliothèque de processus marque comme normalement volumineuse, comme un éditeur vidéo ou Docker.

Tant que Hedroom n’a pas appris une app pendant environ 6 heures, il dit qu’il apprend encore. Pour une app qu’il connaît par son nom, il utilise la taille typique de la bibliothèque de processus ; pour une app inconnue, il ne signale qu’une taille d’au moins 15 % de votre RAM qui continue de croître, et dit « anormalement volumineux » plutôt qu’un ratio.

CPU qui s’emballe

Une app en arrière-plan (pas celle que vous utilisez) qui consomme en moyenne 80 % d’un cœur ou plus pendant 3 minutes, et au moins 3 fois son propre CPU d’arrière-plan habituel, est une app qui s’emballe, sauf si la bibliothèque la marque comme normalement occupée (compilateurs, sauvegardes, encodeurs vidéo, indexation) ou si elle est en appel. Elle apparaît dans Aujourd’hui après 3 minutes. Une notification attend que cela dure depuis 10 minutes.

Limiter le bruit

Le même constat sur la même app ne déclenche une notification qu’une fois toutes les 6 heures au plus. Les notifications non urgentes s’arrêtent à 3 par jour. Si vous en ignorez une trois fois pour une app, Hedroom cesse de la signaler et propose une entrée « Ne jamais toucher ».

3. Décider : une suggestion, puis la barrière de sécurité

Quand Hedroom pourrait faire plus d’une chose, il les classe selon ce qu’elles rendraient par rapport à leur risque, et affiche les deux premières. Forcer à quitter n’est jamais proposé comme correction classée.

Avant toute relance, fermeture, mise en pause ou déplacement vers les cœurs d’efficacité, la demande passe par une barrière de sécurité. Elle refuse quand la cible est :

• Hedroom lui-même (ignoré silencieusement).
• Faite par Apple ou située dans un dossier système, hormis les apps Apple que vous utilisez vous-même, que vous pouvez relancer ou quitter d’un clic.
• Sur votre liste « Ne jamais toucher ».
• L’app que vous utilisez en ce moment, quand une règle demande une pause, un déplacement ou une fermeture.
• Lecture audio, utilisation du micro, ou app d’appel pendant qu’une caméra est active.
• Une app de sauvegarde pendant une sauvegarde.
• Non connue pour supporter la mise en pause, quand une règle veut la mettre en pause ou la quitter et que vous n’avez pas choisi l’app vous-même. Hedroom ne peut pas voir de façon fiable le travail non enregistré.
• Une app que la bibliothèque marque comme dangereuse à relancer, en cas de pression critique.
• Une fermeture forcée sans seconde confirmation distincte.

Si Hedroom ne peut pas vérifier l’une de ces conditions (par exemple, la vérification audio échoue), les règles ne font rien et un clic vous demande d’abord. Un refus est affiché avec sa raison, sous forme de phrase comme « Slack est en appel. », pas comme une erreur. Tout ce qui est refusé ou fait est consigné. Plus d’informations sur Ce que Hedroom ne fait jamais.

4. Agir, avec accord

Les actions sont petites et réversibles :

• Relance demande à l’app de quitter, comme ⌘Q, attend, puis la rouvre.
• Cœurs d’efficacité abaisse la priorité d’une app pour que son travail s’exécute sur les cœurs d’efficacité.
• Pause fige une app jusqu’à ce que vous reveniez dessus, ou 60 minutes au plus. Un petit processus de garde la reprend même si Hedroom plante.

Un clic sur un bouton vaut accord pour cette action. Une règle est un accord que vous avez donné à l’avance, et chaque modèle est livré désactivé. Quitter ou relancer une app qui n’est pas connue comme sûre demande toujours d’abord. Rien n’est jamais supprimé sans votre permission, à chaque fois ; le nettoyage déplace les fichiers dans la Corbeille. Les corrections et les règles listent chaque limite.

5. Reçu : avant, après et un verdict honnête

Chaque action produit un reçu. Hedroom compare les mesures des 5 minutes avant l’action à celles de 5 à 15 minutes après, en ignorant les 30 premières secondes (60 secondes après une relance) le temps que tout se stabilise.

Il y a quatre issues honnêtes :

• Mesuré. Le changement atteint au moins le plus petit que Hedroom compte : 100 Mo de mémoire, 10 points de pourcentage d’un cœur de CPU, 0,3 W ou 50 Mo d’espace disque.
• Aucun effet. Le changement était plus petit, ou dans le mauvais sens. Le reçu indique « Aucun effet mesurable. » et ne s’attribue aucun mérite.
• Non mesurable. D’autres apps ont trop changé en même temps (une autre app a varié de plus de 1 Go, une nouvelle app a été lancée en utilisant plus de 500 Mo, vous avez quitté d’autres apps, le Mac s’est mis en veille, ou le courant a été branché ou débranché). Le reçu le dit au lieu de s’attribuer le mérite, et il est exclu des totaux.
• Annulé. Vous avez annulé l’action, ou Hedroom a quitté, avant la fin de la mesure. Rien n’est revendiqué.

Chaque reçu porte aussi un niveau de fiabilité (élevé, moyen ou faible). Un reçu à faible fiabilité est étiqueté « approximatif » et n’est pas compté dans les totaux. Un reçu compare deux fenêtres de temps ; ce n’est pas un essai contrôlé. Pour en lire un, voir Comment lire un reçu.

Pourquoi la pression de la mémoire, pas la RAM utilisée

Un Mac allumé depuis un moment affiche la majeure partie de sa mémoire comme utilisée, par conception. macOS remplit la mémoire libre avec des fichiers en cache, car cela rend plus rapide la prochaine chose que vous ouvrez, et la rend dès qu’une app en a besoin. Une barre de mémoire pleine n’est pas un problème. Ce qui compte, c’est de savoir si macOS a du mal à trouver de la place : c’est la pression de la mémoire, avec la vitesse de croissance du swap. C’est pourquoi Hedroom n’a pas de bouton qui « vide » la mémoire. Cela force macOS à jeter le cache utile. Le guide sur la pression et la RAM utilisée montre comment le vérifier vous-même dans Moniteur d’activité.

Ce qui le rend économe

Le budget de Hedroom est de moins de 0,5 % d’un cœur de CPU en moyenne et de moins de 80 Mo de mémoire. Ce qui a été mesuré jusqu’ici :

Lisez cela comme mesuré, pas promis. C’est un seul Mac, et une partie des exécutions s’est faite au cycle plus rapide de 2 secondes, car ce Mac était sous pression de mémoire. La première exécution après l’installation lance une analyse du stockage qui dure quelques minutes, jusqu’à un cœur, à basse priorité. Les onglets autres qu’Aujourd’hui n’ont pas tous été re-mesurés. Avant les corrections consignées dans les mêmes notes, une fenêtre ouverte coûtait 20 à 40 % d’un cœur ; cela a été trouvé par ces tests et corrigé. Les fichiers bruts et le compte rendu complet se trouvent dans le dossier bench/results du dépôt, et les Réglages affichent le coût propre de Hedroom mesuré sur votre Mac. Le critère de publication est le benchmark et une mesure de surcharge sur la version signée, qui n’a pas encore eu lieu.

Ce qui le garde léger : un seul échantillonneur pour tout, un cycle plus lent quand il ne se passe rien, des analyses par app seulement tous les quelques cycles en arrière-plan, un contenu de fenêtre construit uniquement quand une fenêtre est à l’écran, et des animations qui s’arrêtent quand la fenêtre est masquée.

Ce qu’il refuse de toucher

• macOS lui-même : tout ce qui est signé par Apple ou situé dans un dossier système. Hedroom explique ces processus, comme kernel_task et WindowServer, et ne les met jamais en pause, ne les ralentit ni ne les quitte. Voir kernel_task, WindowServer et autres processus expliqués.
• L’app au premier plan, les apps en appel, les apps qui lisent de l’audio ou utilisent le micro ou la caméra, les apps de sauvegarde pendant une sauvegarde.
• Les apps de votre liste « Ne jamais toucher ».
• Vos fichiers, sauf si vous confirmez vous-même chaque suppression. Le nettoyage passe d’abord par la Corbeille.

La liste complète, avec des tests derrière chaque ligne, se trouve sur Ce que Hedroom ne fait jamais. Ensuite : chaque fonctionnalité et ses limites, comment Hedroom se compare et le glossaire.