Como o Hedroom funciona, passo a passo

O Hedroom lê alguns números do macOS, percebe quando um app deu errado, sugere uma correção e mede o que aconteceu depois que você aceita. Aqui está cada passo, com os limites que ele usa.

Os números desta página vêm dos documentos de projeto e do código do próprio Hedroom. Quando um número é uma medição, a página diz quando e em qual Mac. O Hedroom ainda não foi lançado, então nada disto descreve uma versão pública.

1. Amostrar: o que ele lê e com que frequência

Todas as leituras vêm de um único amostrador que roda fora da thread principal, para o app continuar respondendo. Cada fonte é um trecho de código separado atrás de uma interface, que é também como ela é testada com dados falsos. Estas são as fontes:

O tick

Um “tick” é uma rodada de leituras. A frequência depende do que você está fazendo:

Em Ajustes há a opção “Verificar meu Mac a cada” de 2, 5 ou 10 segundos para a frequência com a janela aberta; as frequências em segundo plano acompanham essa escolha. As leituras brutas são guardadas por 48 horas. Tudo fica no seu Mac, em um único arquivo de banco de dados na sua pasta Biblioteca. Veja Privacidade.

2. Detectar: o que conta como constatação

O Hedroom não dispara um alerta só porque um número é grande. Ele compara cada app com o tamanho habitual desse app no seu Mac e espera para ver se a mudança dura.

Memória: Saudável, Sob tensão, Crítica

O Hedroom mostra um de três estados. Os limites estão escritos e testados.

Swap que está apenas usado nunca deixa o Mac Sob tensão, porque o macOS mantém swap antigo. Só conta o swap que está crescendo. Muita memória “usada” com pressão saudável é Saudável. Por que pressão, não RAM usada explica a diferença.

Um vazamento: um app muito acima do tamanho habitual, por um tempo

Para cada app, o Hedroom aprende um tamanho habitual a partir dos seus últimos 7 dias de uso normal. Ele só sinaliza um vazamento quando tudo isto é verdade:

• O app está com pelo menos 3 vezes o tamanho habitual. Com 2,5 vezes, aparece como “crescendo” e nada mais.
• Tem pelo menos 1 GB, ou 6% da sua RAM se isso for maior.
• Ficou assim por 20 minutos seguidos, ou continua crescendo em uma tendência de 30 minutos.
• Não está na sua lista Nunca tocar, não é da Apple (com uma pequena exceção para apps da Apple que você mesmo usa) e não é um app que a biblioteca de processos marca como normalmente grande, como um editor de vídeo ou o Docker.

Até o Hedroom aprender um app por cerca de 6 horas, ele diz que ainda está aprendendo. Para um app que conhece pelo nome, usa o tamanho típico da biblioteca de processos; para um app desconhecido, sinaliza apenas um tamanho de pelo menos 15% da sua RAM que ainda esteja crescendo, e diz “incomumente grande” em vez de uma proporção.

CPU descontrolada

Um app em segundo plano (não o que você está usando) que usa em média 80% de um núcleo ou mais por 3 minutos, e pelo menos 3 vezes a própria CPU habitual em segundo plano, é descontrolado, a menos que a biblioteca o marque como normalmente ocupado (compiladores, backups, codificadores de vídeo, indexação) ou que ele esteja em uma chamada. Aparece em Hoje depois de 3 minutos. Uma notificação espera até durar 10 minutos.

Controle de ruído

O mesmo achado sobre o mesmo app notifica no máximo uma vez a cada 6 horas. Notificações não urgentes param em 3 por dia. Dispense uma três vezes para um app, e o Hedroom para de notificar sobre ele e oferece uma entrada em Nunca tocar.

3. Decidir: uma sugestão, depois a barreira de segurança

Quando há mais de uma coisa que o Hedroom poderia fazer, ele as classifica pelo quanto devolveriam em relação ao risco e mostra as duas primeiras. Forçar o encerramento nunca é oferecido como uma correção classificada.

Antes de qualquer reabertura, encerramento, pausa ou movimento para os núcleos de eficiência, o pedido passa por uma barreira de segurança. Ela recusa quando o alvo é:

• O próprio Hedroom (ignorado em silêncio).
• Feito pela Apple ou em uma pasta do sistema, exceto os apps da Apple que você mesmo usa, que você pode reabrir ou encerrar com um clique.
• Na sua lista Nunca tocar.
• O app que você está usando agora, quando uma regra pede pausa, movimento ou encerramento.
• Tocando áudio, usando o microfone, ou um app de chamadas com uma câmera ligada.
• Um app de backup enquanto um backup está rodando.
• Não conhecido por lidar bem com a pausa, quando uma regra quer pausá-lo ou encerrá-lo e você não escolheu o app. O Hedroom não consegue ver com segurança o trabalho não salvo.
• Um app que a biblioteca marca como inseguro para reabrir, durante pressão crítica.
• Um encerramento forçado sem uma segunda confirmação, separada.

Se o Hedroom não consegue verificar um desses itens (por exemplo, a verificação de áudio falha), as regras não fazem nada e um clique pergunta antes. Uma recusa aparece com o motivo, como uma frase do tipo “O Slack está em uma chamada.”, não como um erro. Tudo o que foi recusado ou feito é registrado. Mais em O que o Hedroom nunca faz.

4. Agir, com consentimento

As ações são pequenas e reversíveis:

• Reabrir pede ao app que se encerre, como o ⌘Q, espera e o abre de novo.
• Núcleos de eficiência reduz a prioridade de um app para que o trabalho dele rode nos núcleos de eficiência.
• Pausar congela um app até você voltar a ele, ou por no máximo 60 minutos. Um pequeno processo de proteção o retoma mesmo que o Hedroom trave.

Um clique em um botão é consentimento para aquela ação. Uma regra é um consentimento que você deu antes, e todo modelo vem desativado. Encerrar ou reabrir um app que não é conhecido por ser seguro sempre pergunta antes. Nada é excluído sem a sua permissão a cada vez; a limpeza move arquivos para a Lixeira. Correções e Regras listam todos os limites.

5. Recibo: antes, depois e um veredicto honesto

Toda ação produz um recibo. O Hedroom compara as leituras dos 5 minutos antes da ação com as leituras de 5 a 15 minutos depois dela, ignorando os primeiros 30 segundos (60 segundos após uma reabertura) enquanto tudo se estabiliza.

Há quatro resultados honestos:

• Medido. A mudança é pelo menos a menor que o Hedroom conta: 100 MB de memória, 10 pontos percentuais de um núcleo de CPU, 0,3 W ou 50 MB de disco.
• Sem efeito. A mudança foi menor que isso, ou na direção errada. O recibo diz “Sem efeito mensurável.” e não leva o crédito.
• Não mensurável. Outros apps mudaram demais ao mesmo tempo (outro app variou mais de 1 GB, um novo app foi aberto usando mais de 500 MB, você encerrou outros apps, o Mac entrou em repouso ou a energia foi conectada ou desconectada). O recibo diz isso em vez de levar o crédito, e fica fora dos totais.
• Cancelado. Você desfez a ação, ou o Hedroom foi encerrado, antes de a medição terminar. Nada é reivindicado.

Cada recibo também traz um nível de confiança (alto, médio ou baixo). Um recibo de baixa confiança é marcado como “aproximado” e não entra nos totais. Um recibo compara duas janelas de tempo; não é um ensaio controlado. Para ler um, veja Como ler um recibo.

Por que pressão da memória, não RAM usada

Um Mac ligado há algum tempo mostra a maior parte da memória como usada, por projeto. O macOS preenche a memória sobrando com arquivos em cache, porque isso deixa mais rápido o próximo item que você abrir, e a devolve no instante em que um app precisa. Uma barra de memória cheia não é um problema. O que importa é se o macOS está com dificuldade para achar espaço: isso é a pressão da memória, junto com a velocidade de crescimento do swap. É por isso que o Hedroom não tem um botão que “limpa” a memória. Fazer isso obriga o macOS a descartar o cache útil. O guia sobre pressão e RAM usada mostra como conferir isso você mesmo no Monitor de Atividade.

O que o torna leve

O orçamento do Hedroom é menos de 0,5% de um núcleo de CPU em média e menos de 80 MB de memória. O que foi medido até agora:

Leia isto como medido, não prometido. É um Mac só, e partes das execuções ocorreram no tick mais rápido de 2 segundos porque esse Mac estava sob pressão de memória. A primeira execução após a instalação faz uma análise de armazenamento que leva alguns minutos, a até um núcleo, em baixa prioridade. As outras abas além de Hoje não foram todas medidas de novo. Antes das correções registradas nas mesmas notas, uma janela aberta custava de 20 a 40% de um núcleo; isso foi encontrado por este teste e corrigido. Os arquivos brutos e o relato completo estão na pasta bench/results do repositório, e Ajustes mostra o custo medido do próprio Hedroom no seu Mac. O critério de lançamento é o benchmark e uma execução de consumo na versão assinada, que ainda não aconteceu.

O que o mantém leve: um único amostrador para tudo, um tick mais lento quando nada está acontecendo, verificações por app só a cada alguns ticks em segundo plano, conteúdo de janela construído só enquanto uma janela está na tela e animações que param quando a janela está oculta.

No que ele se recusa a mexer

• O próprio macOS: qualquer coisa assinada pela Apple ou em uma pasta do sistema. O Hedroom explica esses processos, como kernel_task e WindowServer, e nunca os pausa, desacelera nem encerra. Veja kernel_task, WindowServer e outros processos explicados.
• O app que está na sua frente, apps em chamada, apps tocando áudio ou usando o microfone ou a câmera, apps de backup durante um backup.
• Apps da sua lista Nunca tocar.
• Seus arquivos, a menos que você confirme cada exclusão você mesmo. A limpeza vai primeiro para a Lixeira.

A lista completa, com testes por trás de cada linha, está em O que o Hedroom nunca faz. A seguir: cada recurso e seus limites, como o Hedroom se compara e o glossário.