Не знаю, на чём делать акцент в статье: Смотрите, я сделал классное приложение! Может быть, вам пригодится. Или: Смотрите, я написал приложение на Swift и Rust не зная этих языков, полагаясь на LLM, и у меня получилось! Или, может быть: Смотрите, я хотел сделать лучше другой опенсорсный проект, но у меня не вышло. В общем, это будет история обо всём понемногу.

TL;DR — Смотрите, я сделал классное приложение!

Итак, StillCore — это полностью открытое приложение, которое показывает потребление энергии на эпловских чипах по компонентам, общее потребление энергии, частоты и загруженность разных кластеров CPU и GPU, а также пытается показывать температуры (что самое сложное и не документированное в системе). Оно является нативным SwiftUI-приложением, не требует админских прав и старается потреблять как можно меньше ресурсов.

В статье «Зачем я написал ещё одну утилиту мониторинга CPU для Мака» я уже рассказывал, зачем мне это нужно и почему не подходят существующие решения. Но хочу отдельно отметить, что та утилита не имеет никакого отношения к этому приложению. StillCore — это зрелое отдельное приложение, а не просто обёртка над консольной командой. Оно намного проще в установке и эксплуатации.

Зачем оно нужно

Когда меня спросили, зачем я сделал это приложение, я сначала даже растерялся. Я так давно мониторю потребление энергии, что уже и не помню, как это — не мониторить. Но потом я вспомнил пару причин.

Современные эпловские чипы реально очень эффективные. Например, macOS в простое после перезагрузки потребляет около 0.02 W. Логично, что даже когда запущена куча всего, но компьютер не делает ничего полезного, потребление не должно быть сильно выше. Но вот вы начинаете пользоваться приложением с анимацией (привет, Яндекс.Музыка), стартуете какой-то Docker-контейнер в фоне, печатаете текст (привет, Notes) или даже просто открыли чат с LLM (привет, плагин Codex для VS Code). Должно ли от этого сократиться время автономной работы вашего ноутбука на 2 часа? В идеале, конечно, нет. Но на практике кривое приложение легко может выжрать одно ядро вашего CPU (5–7 W).

Допустим, у вас топовый макбук с батареей 100 Wh и обычно вам его хватает на 10 часов (как раз среднее потребление 10 W). Со средним потреблением 17 W он проживёт меньше 6 часов! Непонятно, за что вы деньги платили.

Собственно, StillCore помог мне найти и красиво оформить резонансный баг с перерисовкой в десктопном Codex; обратил внимание на другой баг с плагином Codex для VS Code; научил, что окно Яндекс.Музыки нужно всегда закрывать, а за запущенный докер даже с десятком контейнеров можно не париться. Помог рассчитать настройки графики в Civilization VI, при которых заряда хватит на катку во время трансатлантического перелёта (ну почти).

Дизайн, интерфейс, возможности

Очевидно, что дизайн берёт истоки ещё от Intel Power Gadget. Как ясно из названия, эта утилита не годится для мониторинга Apple Silicon-чипов. Но цель была не просто скопировать 1 в 1, а улучшить многие моменты.

Во-первых, IPG был просто окном. Ты открывал приложение, смотрел, закрывал. Если приложение не было запущено заранее, ты не мог посмотреть, что случилось с системой вот только что. Вместо этого StillCore живёт в строке меню и рассчитано на то, чтобы быть запущенным всегда. Дополнительно, в иконку можно вывести какой-то один показатель, чтобы видеть его всегда. Например, можно вывести иконку заряда батареи и скрыть системную. При этом осталась возможность «отцепить» окно от строки меню и использовать как обычное всегда-открытое окно.

Кроме того, я постарался объединить графики частот и загруженности кластеров. Идея такая — линией показана частота, а полупрозрачная заливка показывает загруженность для этой частоты. Т.е. если использование — 100%, то заливка идёт до линии частоты, если меньше, то заливка пропорционально ниже.

Частота обновления графика регулируется прямо в окне с помощью клавиш -/+ на клавиатуре. Можно обновлять хоть 10 раз в секунду, хоть раз в 10 секунд.

Ну и отдельная функция StillCore — мониторинг текущей сессии работы от батареи. Это требует установки системного хелпера, запущенного даже когда приложение не работает. Мне всегда казалось странным, что есть метрика (по крайней мере, в старых версиях macOS) «ваш ноутбук будет работать ещё 1,5 часа», которая не имеет ничего общего с реальностью, а понятной и доступной метрики «ваш ноутбук работает 8 часов с последней зарядки» нет. Поэтому я её добавил в своё приложение и теперь оно показывает, например: Drained 56% over 8h 12m + 12h sleep.

Ядро метрик от macmon

Изначально я вообще не собирался писать какое-то своё приложение. Есть такая консольная утилита, написанная на Rust — macmon. Её особенность в том, что автор по сути сделал реверс-инжениринг стандартной утилиты powermetrics и нашёл способ получать всё, что нужно, без админских прав.

А ещё был мой пайтоновский скрипт, про который я рассказывал в предыдущей статье. И тот пайтоновский скрипт однажды я просто обернул в довольно убогое Swift-приложение, которым пользовался довольно продолжительное время.

И вот одним мартовским днём я нашёл, как мне показалось, баг в macmon и, совершенно ничего не зная про Rust, решил с помощью Codex попробовать раскопать и исправить его. Пока я копал код, я всё больше разбирался, как он работает, мне приходили всё новые идеи, что можно улучшить, и в конце концов я дошёл до главной идеи: а ведь ядро, которое собирает метрики, можно полностью отделить от консольного интерфейса и переиспользовать в других приложениях!

В этот момент обратной дороги уже не было, я понял, что смогу сделать полностью своё нормальное приложение для мониторинга, без обёртки над консольными приложениями, без админских прав, с нормальным интерфейсом. Единственной проблемой было то, что изменения, которые я делал в исходниках macmon, были чудовищными: по сути там всё было так или иначе переписано или изменено. Но именно конечная версия (с разделением на библиотеку и приложение, с кучей исправлений, изменёнными интерфейсами и выводом) мне была необходима для моего приложения.

Я сделал draft pull request, где постарался объяснить мотивацию всех изменений, честно сказал, что сам бы такое мержить не стал, хотел узнать у автора, что он думает. Ответа не было. Тогда я попытался вычленить из этого месива хотя бы те изменения, которые не затрагивают структуру проекта, не затрагивают контракты по выводу, в общем то, что точно ничего не ломает, и сделал ещё три пулреквеста: Io report caller interval, Cpu usage semantics, Optimizations. Ответа снова не поступило.

Это грустный для меня опыт, потому что я бы хотел контрибьютить в уже существующий проект, а не бекпортить изменения в отдельный форк. Ну посмотрим, может быть автор ещё найдётся.

Отдельно отмечу, что язык Rust конечно очень сложен и далёк от интуитивности. Я не пытался в нём разобраться, просто смотрел, что делает LLM, просил исправить явные косяки или переусложнённую логику. Но вот что мне понравилось, так это tooling. Cargo — просто песня, все команды четкие, интуитивные, ошибки максимально конкретные, вывод в консоль красивый!

Приложение на SwiftUI для macOS

И чтобы далеко не отходить, я хочу сразу же поделиться впечатлениями от Swift. Это полная противоположность Rust во всём ) Сам язык интуитивный, простой, даже с некоторыми откровениями. Например, мне очень зашли enums + associated values, теперь очень не хватает такого в Python. Но tooling у Свифта просто мрак. По дефолту xcodebuild срёт в консоль просто невероятное количество мусора. А что будет, если вы ошибётесь где-то во View — это просто ужас. Будет ошибка о том, что компилятор не смог вывести тип по таймауту (!) и иди ищи сам, где именно ты ошибся. И отдельная история — выпуск приложения: подписи, нотаризация, сэндбоксинг, hardened runtime ещё долго будут сниться мне в кошмарах.

Дальше сгруппирую рассказ по челленджам, которые были при разработке.

Графики

Основная функция окна — показывать графики. Изначально я пробовал нативные Charts, но быстро обнаружил, что они очень неоптимальны по производительности из-за SwiftUI-интерфейса — по сути все отображаемые данные заново строятся и копируются при каждом обновлении. Я перешёл на DGCharts и отрисовка ускорилась раз в пять. Благо, у меня было приложение, которое это могло точно показать, хе-хе.

Окна и их состояния

Формально в приложении одно окно, просто иногда оно привязано к иконке, а иногда его можно сделать отдельным. Я пытался договориться с macOS, переставлял флаги, пробовал разные неочевидные свойства, но это всё работало плохо. В macOS у окон слишком много скрытых состояний, на которые нельзя повлиять программно (или я не знаю как) — изначальные свойства окна влияют на тень и активацию, переключение режима окна привязывает его состояние к текущему экрану и так далее.

В итоге я попробовал сделать два разных окна и пересаживать между ними контент при переключении режимов. Оказалось, что это работает сильно лучше. Теперь StillCore корректно работает с полноэкранными приложениями и имеет правильный порядок по ⌘+Tab.

Меню для иконки в строке меню

Мне казалось, что это базовая функциональность, с которой не будет проблем. Но если вы покликаете по виджетам у вас в строке меню, вы заметите, что большинство из них реагируют на левый и правый клик одинаково, либо не реагируют на правый клик вовсе. А если всё же по-разному (как, например, 1password), то реакция на левый клик идёт по mouse up, а не mouse down.

Сейчас я знаю, что это не случайность, а выкрутасы SwiftUI, который даёт удобный инструмент для выпадающих из меню окон, но никак не даёт его кастомизировать. Мне повезло, что я давно пользовался Itsycal, у которого было нужное мне поведение и открытый код. Поэтому мы смогли на пару с Кодексом разобраться, как добиться нужного.