Зафиксировано: после длительной нагрузки приложение замедляется на физическом устройстве, но не в эмуляторе. Как доказать, что причина — тепловое ограничение устройства, а не утечка ресурсов приложения?
Нужно повторить одинаковый длительный сценарий на холодном и прогретом физическом устройстве, зафиксировав время отклика, частоту кадров, загрузку CPU и GPU, потребление памяти и доступные признаки теплового состояния. Доказательством теплового ограничения будет воспроизводимое ухудшение производительности после нагрева с восстановлением после охлаждения при отсутствии продолжающегося роста памяти или фоновой активности приложения.
Эмулятор не является достаточной заменой физическому устройству: его производительность и тепловая модель зависят от компьютера-хоста и обычно не воспроизводят поведение реального мобильного SoC при длительной нагрузке.
Мобильные устройства рассчитаны на ограниченное энергопотребление и обычно не имеют активного охлаждения, сравнимого с настольными компьютерами. Поэтому производители ОС, прошивок и процессоров используют thermal throttling — снижение частот или доступной мощности при перегреве.
Подход появился как компромисс между производительностью, безопасной температурой, автономностью и предотвращением повреждения компонентов. Для пользователя это может проявляться не сразу: приложение сначала работает нормально, а затем начинает пропускать кадры, дольше обрабатывать действия или медленнее выполнять вычисления.
Замедление после длительной работы может быть вызвано разными причинами: тепловым ограничением, утечкой памяти, бесконечной фоновой задачей, ростом очереди запросов или деградацией самого алгоритма. Ошибка в диагностике приводит к неверному исправлению: например, оптимизация памяти не устранит троттлинг, а ограничение частоты обновления интерфейса не исправит утечку.
Особенно рискованно делать вывод только по эмулятору. Эмулятор может показывать стабильную скорость благодаря ресурсам компьютера, тогда как физическое устройство снижает производительность из-за нагрева корпуса, аккумулятора или процессора.
Сначала зафиксируйте базовый результат на одном и том же устройстве после охлаждения. Используйте одинаковую сборку, сценарий, длительность нагрузки, яркость, подключение к сети и состояние фоновых приложений; несколько прогонов нужны для исключения случайных выбросов.
Затем повторите сценарий непрерывно до появления деградации. В каждый момент измеряйте:
Признак теплового ограничения — ухудшение производительности после прогрева при стабилизации или снижении вычислительных частот, а также заметное восстановление после паузы и охлаждения. Само значение температуры не является достаточным доказательством: важнее согласованная временная связь между нагревом, снижением производительности и последующим восстановлением.
Для проверки альтернативы повторите тест с приложением в бездействии или с минимальной нагрузкой. Если устройство замедляется целиком, а не только внутри приложения, это усиливает гипотезу о тепловом ограничении. Если же память приложения постоянно растёт, после охлаждения проблема сохраняется, а профилировщик показывает накопление объектов или длительные фоновые задачи, вероятнее утечка или дефект приложения.
Нужно также повторить сценарий на нескольких экземплярах той же модели и, по возможности, на другой модели. Это помогает отделить дефект приложения от особенностей конкретного SoC, прошивки или изношенного аккумулятора. Системное ограничение не следует отключать в тестовой сборке: цель теста — подтвердить его влияние и оценить приемлемость деградации, а не обойти защитный механизм.
В видеоредакторе через 15 минут экспорта и предварительного просмотра частота кадров падала, хотя эмулятор сохранял стабильный результат. Рассматривались три варианта: тестировать только на эмуляторе, профилировать память приложения или проводить длительный прогон на физическом устройстве.
Эмулятор был быстрым и удобным, но не показал теплового поведения реального телефона. Профилирование памяти помогло исключить утечку, однако само по себе не объясняло восстановление скорости после паузы. Тест на одном физическом устройстве давал результат, но не позволял понять, является ли он особенностью конкретного экземпляра.
Выбрали контролируемый прогон на нескольких физических устройствах с измерением кадров, загрузки CPU/GPU, памяти и теплового состояния. После прогрева производительность снижалась, при охлаждении возвращалась, а память оставалась стабильной; на разных экземплярах одной модели эффект был сходным. Команда оптимизировала пиковую нагрузку и добавила приемлемый режим качества при перегреве, не отключая системное ограничение.
Нет. Восстановление после охлаждения — сильный признак, но не уникальное доказательство: пауза может остановить утечку, очистить очередь задач или завершить сетевые операции. Нужны повторяемый цикл «холодное состояние — длительная нагрузка — деградация — охлаждение — восстановление» и параллельные метрики памяти, CPU/GPU и активности приложения.
Да. Приложение может постоянно использовать процессор, из-за чего устройство нагревается, а система затем снижает доступную частоту. В этом случае троттлинг — не первопричина, а реакция платформы на чрезмерную нагрузку. Профилирование должно показать, какие операции создают нагрузку; исправление может потребовать уменьшения вычислений, частоты перерисовки или параллелизма.
У моделей отличаются процессоры, графические блоки, система охлаждения, версия прошивки и пороги теплового управления. Разный результат может быть нормальным следствием аппаратных характеристик, а не ошибкой приложения. Для вывода нужно сравнивать одинаковый сценарий на нескольких экземплярах одной модели, а затем проверять переносимость эффекта на другие поддерживаемые конфигурации.