Смартфон лежит экраном вниз на столе. Ничего не запущено. Но через час он тёплый, а заряд упал на 18%. Открываешь статистику батареи — и там это: «Система Android», 31%. Не YouTube, не навигация, не игра. Система Android.
Первый инстинкт — сброс настроек. Второй — нести в сервис. Оба неверные. Потому что проблема не в железе и не в прошивке как таковой. Проблема в том, что ваш смартфон буквально не закончил думать после последнего обновления HyperOS. И сейчас покажем, как его дожать.
Что реально происходит внутри: виртуальная машина, которая застряла на полпути
Каждое Android-приложение написано на Java или Kotlin и хранится на устройстве в формате DEX — это не машинный код, который процессор понимает напрямую, а байткод. Чтобы он работал быстро, Android Runtime (ART) должен его заранее скомпилировать в нативные инструкции вашего конкретного процессора.
Этим занимается инструмент dex2oat. Он берёт DEX-файл и на выходе даёт три артефакта:
| Файл | Что содержит | Зачем нужен |
|---|---|---|
.vdex |
Метаданные верификации + несжатый DEX | Ускоряет повторную верификацию кода |
.odex |
AOT-скомпилированный машинный код | Основной «мозг» — нативные инструкции |
.art |
Строки и классы из APK | Ускоряет холодный старт приложения |
Вот в чём соль: dex2oat умеет работать в нескольких режимах. И выбор режима — это разница между смартфоном, который работает, и смартфоном, который перерабатывает.
Четыре режима компилятора: от «почти ничего» до «всё и сразу»
На Android 8 и выше официально поддерживаются четыре фильтра компиляции. Важный момент для владельцев HyperOS: режим quicken, о котором пишут в старых гайдах, умер на Android 12. Забудьте про него.
| Фильтр | Что делает | Нагрузка на CPU | Актуальность |
|---|---|---|---|
verify |
Только проверяет DEX-байткод на корректность | Минимальная | Android 8+ ✅ |
quicken |
Верификация + лёгкие оптимизации DEX | Низкая | Только Android 11 и ниже ❌ |
speed |
AOT-компиляция всех методов без исключения | Максимальная | Android 8+ ✅ |
speed-profile |
AOT только «горячих» методов из JIT-профиля | Умеренная | Android 8+ ✅ |
speed-profile — это золотая середина. Система не тратит время на компиляцию кода, который вы никогда не запускаете. Она компилирует только то, что JIT уже «видел» в работе и пометил как часто используемое. Быстро, точно, без лишней работы.
Почему после обновления HyperOS телефон ведёт себя как после бессонной ночи
После установки OTA-обновления HyperOS система намеренно выставляет компиляцию в режим verify. Не speed-profile, не speed — просто верификация. Это сделано специально, чтобы не затягивать первую загрузку после апдейта.
Дефолтные значения ART Service выглядят так:
| Триггер | Фильтр компилятора |
|---|---|
| Первая загрузка устройства | verify |
| Первая загрузка после OTA | verify |
| Фоновая оптимизация (bg-dexopt) | speed-profile |
| Неактивные приложения | verify |
Фоновая оптимизация (bg-dexopt) с режимом speed-profile запустится сама — но только когда телефон одновременно заряжается и лежит без дела. И только один раз в сутки. Если вы постоянно пользуетесь смартфоном и редко оставляете его на зарядке в покое — эта фоновая задача просто никогда не доберётся до конца.
Итог: после обновления десятки приложений работают через JIT-компиляцию на лету. Процессор постоянно занят. Батарея тает. Телефон греется. И вот вам — «Система Android» в топе потребителей.
Инструментарий: что нам понадобится
Никакого root. Никаких сторонних прошивок. Только ADB — официальный инструмент отладки от Google.
Что установить на ПК:
- Platform Tools — скачать с developer.android.com/tools/releases/platform-tools. Это архив с
adb.exe(Windows) илиadb(macOS/Linux).
Что включить на смартфоне:
- Настройки → О телефоне → Версия MIUI/HyperOS — тапнуть 7 раз подряд. Появится пункт «Для разработчиков».
- Настройки → Дополнительные настройки → Для разработчиков — включить «Отладка по USB».
- Там же включить «Беспроводную отладку» — пригодится, если хотите работать без кабеля.
Подключаете телефон кабелем, в терминале проверяете связь:
adb devicesЕсли в ответ видите серийный номер устройства со статусом device — всё готово.
Шаг 1: Принудительная компиляция ART. Дожимаем то, что система не доделала
Перед запуском — два условия. Заряд батареи выше 50%. Телефон не горячий. Потому что команда ниже, в отличие от фоновой задачи, не ждёт покоя — она нагружает CPU прямо сейчас.
adb shell cmd package compile -m speed-profile -aФлаг -a означает «все установленные приложения». Команда пройдётся по каждому пакету и скомпилирует методы из накопленных JIT-профилей. В зависимости от количества приложений процесс займёт до 30 минут. Телефон будет тёплым — это норма.
Но здесь есть один скользкий момент, о котором не пишут в коротких гайдах.
Подводный камень №1: speed-profile без профиля — это просто verify в маскировке
Если у приложения ещё нет JIT-профиля (только установленное, или данные были очищены) — ART молча понижает фильтр с speed-profile до verify. Без предупреждения, без ошибки в терминале.
Чтобы убедиться, что компиляция реально сработала для конкретного приложения:
adb shell cmd package compile -m speed-profile -f -v com.example.appСмотрите на поле actualCompilerFilter в выводе:
| Значение | Смысл |
|---|---|
actualCompilerFilter=speed-profile |
✅ Компиляция прошла с профилем |
actualCompilerFilter=verify |
⚠️ Профиль не найден, откат до верификации |
Откат до verify для свежеустановленных приложений — штатное поведение, не баг. Эти приложения подтянутся сами после нескольких сессий использования, когда JIT соберёт достаточно данных.
Шаг 2: Отключаем фоновых «шпионов». Аккуратно и обратимо
Два пакета стабильно появляются в топе фоновой активности на устройствах Xiaomi:
| Пакет | Что делает |
|---|---|
com.miui.analytics |
Собирает данные о паттернах использования устройства, отправляет в Xiaomi |
com.xiaomi.joyose |
Управляет FPS, частотами CPU и яркостью для теплового контроля во время игр |
По com.xiaomi.joyose — честное предупреждение. Официальной документации Xiaomi на этот сервис не существует. Всё, что известно о его поведении — результат реверс-инжиниринга сообщества XDA. Xiaomi официально рекомендует его не трогать, ссылаясь на возможный тепловой дисбаланс. При этом именно обновления Joyose исторически вызывали аномальный нагрев. Парадокс, но факт. Решение — за вами.
Есть два метода отключения. Выбирайте осознанно:
| Параметр | uninstall -k --user 0 |
disable-user --user 0 |
|---|---|---|
| APK остаётся на /system | ✅ | ✅ |
| Место на диске освобождается | ❌ | ❌ |
| Переживает перезагрузку | ✅ | ✅ |
| Переживает factory reset | ✅ (обычно) | ❌ |
| Переживает OTA-обновление | ❌ | ❌ |
| Полный откат одной командой | ✅ install-existing |
✅ pm enable |
Метод A — стандартный (рекомендуется опытным пользователям):
adb shell pm uninstall -k --user 0 com.miui.analytics
adb shell pm uninstall -k --user 0 com.xiaomi.joyoseМетод B — безопаснее для первого раза (полностью обратим одной командой):
adb shell pm disable-user --user 0 com.miui.analytics
adb shell pm disable-user --user 0 com.xiaomi.joyoseЕсли что-то пошло не так — откат:
# Для метода A
adb shell cmd package install-existing com.miui.analytics
# Для метода B
adb shell pm enable --user 0 com.miui.analyticsПодводный камень №2: OTA-обновление всё вернёт обратно
Оба метода не переживают крупные обновления HyperOS. После каждого системного апдейта пакеты восстанавливаются. Это не баг — это архитектурное решение: pm uninstall -k --user 0 и disable-user работают только в пространстве пользователя, не трогая /system.
Практическое решение: сохраните команды из Шага 2 в текстовый файл. После каждого обновления HyperOS — 2 минуты на повторный запуск.
Подводный камень №3: не трогайте com.miui.personalassistant
Этот пакет отвечает за App Vault («экран -1») и одновременно за работу виджетов на рабочем столе. Его удаление ломает систему виджетов — долгое нажатие на рабочий стол перестаёт открывать меню редактирования. Зафиксировано в сообществе, воспроизводится стабильно.
В список пакетов для отключения он не входит.
Шаг 3: Замеряем результат. CPU Throttling Test — единственный честный судья
Утилита CPU Throttling Test (есть в Google Play) запускает синтетическую 15-минутную нагрузку на процессор и в конце выдаёт два числа: пиковая производительность и средняя. Отношение среднего к пиковому — процент стабильности.
Для понимания, что является нормой, а что — провалом:
| Чипсет | Устройство | Пик (GIPS) | Среднее (GIPS) | Стабильность |
|---|---|---|---|---|
| Dimensity 9500s | Poco X8 Pro Max | 443 923 | 364 904 | 82% |
| Snapdragon 7s Gen 2 | референс | 220 978 | 190 041 | 81% |
| Snapdragon 8 Elite Gen 5 | iQOO 15 | ~443 000 | — | ~58% (пик держит ~3 мин) |
Запустите тест до процедуры, запишите цифры. Запустите после — сравните. Если стабильность выросла на 5–15% — вы сделали всё правильно.
Помните: низкая стабильность в тесте не всегда означает плохую прошивку. Иногда это физика конкретного чипсета в конкретном корпусе. Но если после наших манипуляций разница заметна — значит, процессор раньше тратил ресурсы на фоновую работу, а не на вашу нагрузку.
Полный список команд: копируй и используй
# ── ДИАГНОСТИКА ──────────────────────────────────────────
# Проверка подключения
adb devices
# ── ART: ПРИНУДИТЕЛЬНАЯ КОМПИЛЯЦИЯ ───────────────────────
# Запустить speed-profile для всех приложений (заряд >50%!)
adb shell cmd package compile -m speed-profile -a
# Проверить результат для конкретного пакета
adb shell cmd package compile -m speed-profile -f -v com.example.app
# Смотреть: actualCompilerFilter=speed-profile (✅) или =verify (⚠️ нет профиля)
# ── ТЕЛЕМЕТРИЯ: ОТКЛЮЧЕНИЕ ────────────────────────────────
# Метод A — удаление из пространства пользователя
adb shell pm uninstall -k --user 0 com.miui.analytics
adb shell pm uninstall -k --user 0 com.xiaomi.joyose
# Метод B — мягкое отключение (безопаснее)
adb shell pm disable-user --user 0 com.miui.analytics
adb shell pm disable-user --user 0 com.xiaomi.joyose
# ── ОТКАТ ─────────────────────────────────────────────────
# Восстановление после метода A
adb shell cmd package install-existing com.miui.analytics
adb shell cmd package install-existing com.xiaomi.joyose
# Восстановление после метода B
adb shell pm enable --user 0 com.miui.analytics
adb shell pm enable --user 0 com.xiaomi.joyoseСовместимость: какая версия Android, такой и движок
Синтаксис команд одинаков для всех версий, но внутри работает разный движок:
| Android-основа | HyperOS | Движок dexopt |
|---|---|---|
| Android 13 | HyperOS 1.0 (часть устройств) | Package Manager |
| Android 14 | HyperOS 1.0 / 2.0 | ART Service |
| Android 15 | HyperOS 2.0 / 3.0 | ART Service |
Практического значения для пользователя это не имеет — команды работают одинаково. Но если вдруг захотите углубиться в кастомизацию через системные свойства (pm.dexopt.*) — знайте, что на Android 14+ вы работаете уже с ART Service API.
Что в итоге
После прохождения всех трёх шагов у вас будет:
- Скомпилированный в нативный машинный код пул «горячих» методов всех приложений
- Отключена фоновая отправка телеметрии в Xiaomi
- Понимание того, что происходит под капотом после каждого обновления прошивки
Никакой магии. Только то, что система должна была сделать сама, но не успела — или не торопилась.
И да: после следующего OTA-обновления HyperOS не удивляйтесь, когда пункт «Система Android» снова окажется в топе батарейной статистики. Это не регресс прошивки. Это boot-after-ota=verify делает свою работу. Теперь вы знаете, что с этим делать.
|
