Склад жалуется: iPhone греется — как нагрев стал метрикой продукта

Нагрев iPhone во время работы приложения — измеримый сигнал, а не жалоба на «плохой телефон». iOS через ProcessInfo.thermalState показывает четыре уровня нагрева, и приложение может отслеживать переход между ними так же, как отслеживает падения сети или ошибки API. Для B2B-приложений на складе или в доставке это метрика, которая напрямую бьёт по производительности смены.

склад в Подольске, вторая смена: телефон горячий, сканер тормозит

Кладовщик присылает в поддержку скриншот: экран приложения потемнел сам по себе, штрихкод сканируется с задержкой в несколько секунд, а сам iPhone на ощупь как после часа на солнце. Смена только началась, до конца ещё пять часов, и телефон не первый раз ведёт себя так именно во вторую смену, когда склад грузит машины под вечернюю отгрузку.

Первый ответ поддержки был обычным: «попробуйте перезагрузить телефон», «проверьте, не разряжен ли аккумулятор». Тикет закрыли. Через два дня похожая жалоба пришла с другого склада, с другим iPhone, у другого сотрудника, но с тем же временем суток и тем же набором действий на экране: непрерывное сканирование, фоновая синхронизация с 1С и включённая геолокация одновременно. Совпадение оказалось не в модели телефона, а в сценарии его использования, и это стало понятно только после третьего тикета за неделю.

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

что теряет бизнес, пока никто не мерит нагрев

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

Есть и вторая цена, техническая. Частый нагрев до состояния serious или critical заставляет iOS принудительно снижать частоту процессора и может закрыть приложение на переднем плане без предупреждения. Если в этот момент шло сохранение накладной в 1С, документ рискует не долететь до базы, и кладовщику придётся вводить позиции заново: это уже не неудобство, а повторный ручной труд и риск задвоить или потерять строку в накладной.

Третья цена — организационная. Пока проблему не измерили, решение искали не техническое, а кадровое: закупить запасные телефоны, добавить человека на подмену, продлить перерывы. Всё это стоит денег и рабочего времени, но не устраняет причину: телефон снова нагреется на следующей смене.

почему обычный мониторинг приложения здесь бессилен

Логичный вопрос: разве у приложения не было уже настроено отслеживание падений и ошибок? Было. Crash-репорты, логи сетевых сбоев, мониторинг ответов от 1С: всё это работало исправно и не показало ни одной аномалии. Причина простая: тепловой троттлинг не роняет приложение и не бросает исключение, iOS просто тихо снижает производительность, а если состояние доходит до critical — закрывает процесс так, будто пользователь сам смахнул его из списка недавних. Для системы аналитики это выглядит как обычный выход из приложения, а не как сбой.

Поэтому нагрев нельзя поймать через стандартные средства мониторинга ошибок, его нужно отслеживать отдельно, через собственное свойство операционной системы, и относиться к нему как к отдельной метрике, а не как к побочному эффекту, который обнаружится сам по мере роста числа крашей.

🌡️ четыре уровня нагрева, которые видит iOS

У iOS есть встроенный способ узнать, насколько горячо устройству — свойство ProcessInfo.thermalState. Оно возвращает одно из четырёх состояний, и каждое требует от приложения разного поведения.

До этого случая приложение на складах вообще не читало это свойство: оно просто работало, пока не переставало. thermalState существует в iOS давно, но в мобильной разработке под B2B-сценарии его почти никогда не встраивают в продуктовую аналитику: меряют падения сети, ошибки API, время отклика 1С, а нагрев по умолчанию считают делом операционной системы, а не приложения.

как это выглядит технически

Подписка на изменения занимает один обработчик уведомления ProcessInfo.thermalStateDidChangeNotification: приложение получает текущее состояние в момент запуска и дальше реагирует на каждый переход. Никакого отдельного SDK или сложной интеграции не требуется, это часть стандартного Foundation, доступная в любом проекте на Swift.

что оказалось причиной — не батарея, а три фоновых процесса разом

Диагностику вели через Xcode Instruments: журнал энергии показал не разряд батареи, а постоянную высокую нагрузку на процессор и радиомодуль именно в те минуты, когда приходили жалобы с обоих складов. Совпадение по времени и стало первой зацепкой: команда сопоставила метки из тикетов поддержки с логами энергопотребления на тестовых устройствах и увидела один и тот же паттерн нагрузки.

Причина сложилась из трёх решений, каждое из которых по отдельности выглядело безобидно:

• ✓сканер штрихкодов держал камеру и вспышку включёнными непрерывно, а не по кадру;
• ✓синхронизация с 1С опрашивала сервер каждые пять секунд независимо от того, изменились ли данные;
• ✓геолокация работала в режиме высокой точности всю смену, хотя нужна была раз в несколько минут для отчёта о перемещении сотрудника по территории склада.

По отдельности каждый процесс укладывался в норму и не вызвал бы вопросов при обычном код-ревью. Вместе они грузили процессор и радиомодуль одновременно на протяжении нескольких часов подряд, и телефон не успевал остывать между операциями — особенно на моделях без активного охлаждения, которых в парке устройств склада было большинство.

что поменяли в коде

Решение не потребовало новой архитектуры — только пересмотра частоты и приоритетов фоновой работы:

1. ✓камеру сканера перевели в режим захвата по запросу, а не постоянного потока;
2. ✓синхронизацию с 1С сделали событийной: запрос уходит при реальном изменении накладной, а не по таймеру каждые пять секунд;
3. ✓геолокацию понизили до значимых изменений положения вместо непрерывного высокоточного трекинга;
4. ✓добавили подписку на thermalStateDidChangeNotification: при переходе в serious приложение само откладывает фоновую синхронизацию до момента, когда устройство остынет до fair или nominal.

Последний пункт и превратил нагрев из невидимой проблемы в метрику. Теперь приложение логирует каждый переход между состояниями thermalState вместе со сценарием, который выполнялся в этот момент, и эти данные попадают в ту же панель, где видны ошибки синхронизации с 1С. Руководитель IT видит нагрев наравне с остальными техническими показателями, а не узнаёт о нём только из жалоб.

результат: три недели без жалоб на греющиеся телефоны

После обновления кладовщики на обоих складах перестали писать в поддержку про горячие телефоны — за три недели наблюдений не появилось ни одного нового тикета на эту тему. Сессии сканирования стали длиннее без перерывов на «остыть», а случаи, когда накладная не сохранялась после зависания приложения, прекратились: подписка на thermalState теперь принудительно сохраняет данные до того, как iOS решит закрыть процесс.

Практика выдавать кладовщикам запасной телефон на вторую половину смены отменилась сама собой: устройства перестали нагреваться настолько, чтобы это требовалось. Логи thermalState заодно показали то, чего раньше никто не видел: пиковая нагрузка приходится не на утро, как предполагали изначально, а именно на вечернюю отгрузку, когда сканирование, синхронизация и геолокация действительно накладываются друг на друга.

как встроить нагрев в свои продуктовые метрики

Для любого B2B-приложения, которое держит камеру, геолокацию или Bluetooth включёнными часами подряд — сканеры на складе, курьерские приложения, полевой сервис с фото-отчётами — thermalState стоит подключать до того, как появятся первые жалобы, а не после. Это несколько строк кода и одна подписка на уведомление, а не отдельный модуль и не повод для отдельного технического задания.

Мы закладываем такой мониторинг в мобильные приложения, которые интегрируем с 1С: там фоновая синхронизация нагружает устройство сильнее всего и чаще всего остаётся незамеченной до первой жалобы от полевого сотрудника. Для складских и курьерских сценариев собираем именно B2B-приложения с 1С, где сканер, геолокация и синхронизация работают вместе и должны быть согласованы по нагрузке, а не соревноваться за процессор. Разработка такого приложения с нуля начинается от 500 000 руб, состав работ можно посмотреть на странице разработки мобильных приложений, а актуальные цифры уточняйте в тарифах.

Если у вас уже есть приложение и сотрудники жалуются на горячие телефоны, это чаще решается доработкой существующей логики фоновой работы, а не переписыванием приложения заново: та же подписка на thermalState встраивается в готовый проект за несколько дней, без изменения основной бизнес-логики.

❓ Частые вопросы

Как понять, что нагрев телефона — проблема приложения, а не самого iPhone?

Если телефон греется именно во время работы конкретного приложения и остывает после его закрытия, а на других задачах не перегревается — причина в коде, а не в железе. Подтвердить это можно через свойство ProcessInfo.thermalState: оно показывает, при каких сценариях устройство переходит в состояние serious или critical.

Можно ли добавить мониторинг нагрева в уже готовое приложение?

Да, подписка на thermalStateDidChangeNotification — это несколько строк кода в существующем проекте, без переписывания бизнес-логики. Обычно доработка занимает несколько дней: добавляется отслеживание состояния и логика снижения фоновой нагрузки при переходе в serious или critical, а данные попадают в общую панель мониторинга приложения.

Сколько стоит доработка мобильного приложения под контроль перегрева?

Точная стоимость зависит от того, сколько фоновых процессов уже работает в приложении и насколько глубоко нужно менять логику синхронизации. Разработка нового B2B-приложения с 1С начинается от 500 000 руб, доработка готового проекта обычно обходится дешевле и оценивается индивидуально после аудита кода.

Актуально ли это для Android-версии приложения тоже?

На Android есть похожий механизм — PowerManager с методом getThermalStatus и уровнями от NONE до SHUTDOWN, работающий по той же логике. Если приложение выпускается на обеих платформах, мониторинг нагрева стоит закладывать сразу для iOS и Android, а не только для одной из них.

Что делать, если сотрудники уже жалуются на горячие телефоны на складе?

Сначала стоит проверить, повторяется ли жалоба в одном и том же сценарии — сканирование, синхронизация и геолокация одновременно. Дальше нужен аудит фоновой логики приложения: обычно достаточно снизить частоту опроса и добавить отслеживание thermalState, не меняя основной функционал и не закупая новые устройства.