Думаю, многие замечали: пользоваться приложением на перегретом устройстве бывает крайне некомфортно. Страдает не только плавность работы и отзывчивость интерфейса — само устройство становится неприятно держать в руках.
С пользовательской точки зрения проблема очевидна. Но с точки зрения продукта все не так однозначно: насколько сильно нагрев влияет на UX? Как часто пользователи действительно сталкиваются с лагами интерфейса из-за перегрева? И можно ли измерить этот эффект не на уровне ощущений, а с помощью понятных метрик?
Меня зовут Игорь Науменко и я — ведущий iOS разработчик в ОККО. В этой статье попробуем разобраться, как подойти к измерению влияния нагрева на пользовательский опыт, и посмотрим, можно ли повлиять на результат, если перегрев уже начал сказываться на работе приложения.
Что такое thermal state и каким он бывает
Для начала разберемся, что такое thermal state.
Thermal state — это индикатор тепловой нагрузки устройства. Он учитывает температуру и другие системные факторы, чтобы определить, нужно ли ограничивать доступные ресурсы ради охлаждения.
У thermal state есть четыре уровня:
Nominal — все в порядке, устройство работает в штатном режиме.
Fair — устройство начинает нагреваться. Пользователь, скорее всего, уже может физически заметить, что девайс стал горячее, но серьезного падения производительности еще нет.
Serious — промежуточное состояние, при котором уже можно заметить изменения в работе приложения: снижается плавность, ухудшается отзывчивость интерфейса, отдельные операции могут выполняться медленнее.
Critical — температурный режим, в котором iOS отдает приоритет охлаждению устройства. В некоторых случаях система может даже ограничить или временно заблокировать работу с ним. До такого состояния устройство обычно доходит не только из-за нагрузки самого приложения. Чаще всего подключаются внешние факторы: например, если телефон долго находится под прямыми солнечными лучами.
На iOS рост thermal state пользователь чаще всего ощущает через проблемы интерфейса. Анимации и скролл становятся менее плавными, отклик интерфейса замедляется, а общая отзывчивость приложения снижается.
В некоторых сценариях это почти незаметно, но при более высокой тепловой нагрузке деградация может стать очень ощутимой: приложение будто начинает «тяжелее» реагировать на действия пользователя.
Отдельный важный фактор — физический дискомфорт. Горячее устройство неприятно держать в руках, и это само по себе ухудшает опыт взаимодействия с приложением, даже если функционально оно продолжает работать корректно.
Анализируем факторы нагрева
Разложим анализ на три шага.
Сначала измерим сам нагрев: посмотрим, как быстро устройство переходит между разными thermal state, как долго остается в каждом состоянии и насколько часто пользователи вообще сталкиваются с повышенной тепловой нагрузкой. Отдельно разберем, как нагрев влияет на длительность нахождения пользователя в плейбеке.
Затем посмотрим на метрики интерфейса: плавность, отзывчивость и другие показатели, которые могут снижаться по мере роста температурного режима.
В конце сопоставим эти данные и попробуем восстановить пользовательскую сессию: что происходило с приложением по мере того, как устройство нагревалось, какие действия выполнял пользователь и в какой момент деградация становилась заметной.
iOS предоставляет нам только текущий thermal state и уведомления о его изменениях. Поэтому все остальные события, необходимые для построения метрик, придется связывать именно с этим состоянием и моментами его изменения.
Для этого будем логировать:
изменение thermal state;
начало и завершение пользовательской сессии;
начало и завершение плейбека;
начало и завершение загрузки.
Каждое событие должно сопровождаться контекстом, чтобы мы могли корректно разделить данные и понять, какие факторы сильнее всего влияют на нагрев. Среди таких факторов — модель устройства, наличие зарядки, режим энергосбережения, активный плейбек, текущий thermal state и другие параметры.
Завершение сессии
Но перед тем как перейти к самим метрикам, стоит отдельно посмотреть на событие завершения пользовательской сессии. С ним все не так очевидно, как с остальными событиями.
На первый взгляд может показаться, что достаточно отправлять событие в момент, когда приложение получает applicationWillTerminate от iOS. Но у такого подхода есть сразу несколько проблем.
Мы потеряем сценарий, в котором пользователь просто уходит из приложения в background. После этого приложение может перейти в suspended-состояние, а при следующем запуске фактически начнется уже новая пользовательская сессия.
Даже если мы попытаемся отправить событие в обработчике applicationWillTerminate, сама отправка запроса в этот момент не гарантирована. Система может завершить приложение раньше, чем событие успеет уйти на сервер.
Поэтому границу сессии лучше определять не через applicationWillTerminate, а через переходы жизненного цикла приложения.
Мы сохраняем событие завершения сессии в момент, когда приложение получает resignActive — то есть становится неактивным. Это происходит, когда пользователь уходит в background, открывает менеджер задач или, например, получает входящий звонок.
После этого мы смотрим, что произошло дальше. Если приложение снова стало активным (becomeActive), значит пользователь вернулся и продолжил ту же сессию. В таком случае ранее сохраненное событие завершения можно удалить.
Если же приложение так и не вернулось в активное состояние и было завершено системой, мы отправляем сохраненный event при следующем запуске — со всеми параметрами, которые были актуальны на момент ее окончания. Так мы можем не терять данные о завершении сессии, но при этом не разрывать ее в тех случаях, когда пользователь просто ненадолго ушел из приложения и вернулся обратно.
Ниже — пример того, как температурный режим используется в коде. В основе лежит поле thermalState и подписка на его изменения. Благодаря этому мы можем отслеживать переходы между температурными состояниями и связывать их с пользовательскими событиями.
final class ThermalMonitor { func start() { NotificationCenter.default.addObserver( self, selector: #selector(thermalStateDidChange), name: ProcessInfo.thermalStateDidChangeNotification, // подписка на изменения object: nil ) trackThermalEvent(name: .sessionStarted) } @objc private func thermalStateDidChange() { let state = ProcessInfo.processInfo.thermalState // текущее состояние trackThermalEvent(name: .thermalStateChanged, state: state) } }
Температурные метрики
Перейдем к метрикам. В этом анализе нас интересуют четыре основных показателя:
максимальный нагрев за сессию;
скорость нагрева;
суммарное время, которое устройство проводит в каждом температурном режиме;
влияние thermal state на длительность нахождения пользователя в плейбеке.
Максимальный нагрев за сессию
Начнем с максимального нагрева за сессию.
Если посмотреть только на состояние устройства в момент старта приложения, мы получим базовую картину: с каким уровнем нагрева пользователи обычно приходят в наше приложение.
По всем стартам видно, что только около 4% пользователей открывают приложение уже с повышенным thermal state. Это довольно редкий сценарий. Вероятно, до запуска приложения они активно пользовались устройством: играли, смотрели видео, использовали навигацию или выполняли другие ресурсоемкие действия.
Сам по себе сценарий старта приложения с повышенным thermal state встречается довольно редко. Но это особенно хорошо видно, если сравнить его со стартами, которые происходят во время зарядки.
Здесь сразу заметно, что зарядка — очень существенный фактор нагрева устройства: доля сессий с повышенным температурным состоянием увеличивается примерно в пять раз.
Если же смотреть не только на состояние устройства в момент старта, а на максимальный thermal state на протяжении всей пользовательской сессии, картина меняется. Доля сессий с повышенным нагревом достигает 16% — это примерно в четыре раза больше, чем на старте приложения.
Из этого можно сделать второй вывод: даже если пользователь приходит в приложение с нормальным температурным состоянием, в течение сессии устройство все равно может заметно нагреться.
Еще очевиднее это становится, если рассматривать не все сессии, а только те, в которых происходили зарядка, загрузка или плейбек.
В таких срезах зарядка оказывается не просто значимым фактором, а фактором номер один: в сессиях с зарядкой уже 36% пользователей переходят в повышенный температурный режим.
Загрузка и плейбек влияют на нагрев не так сильно. Тем не менее при плейбеке мы тоже видим заметный эффект: около 20% пользователей переходят в повышенный thermal state.
При этом важно помнить: зарядка сама по себе — скорее сопутствующий фактор. Она усиливает нагрев, но особенно заметный эффект появляется в сочетании с другими сценариями.
Если посмотреть на комбинированные факторы — например, зарядку вместе с загрузкой или зарядку вместе с плейбеком, — становится видно, что связка «зарядка + плейбек» дает самый сильный эффект. В таких сессиях 58% пользователей переходят в повышенное состояние нагрева, а 22% доходят до уровня serious.
Особенно заметен этот эффект на более старых устройствах.
Загрузка в сочетании с зарядкой тоже довольно сильно нагревает устройство, хотя и не так серьезно, как плейбек. Но здесь важно учитывать частотность сценария: загрузка встречается в пользовательских сессиях примерно в 50 раз реже, чем плейбек. Поэтому на общую картину она влияет значительно слабее.
Зарядка, напротив, как и плейбек, встречается часто. Более четверти пользовательских сессий включают зарядку. А на более старых устройствах, например на iPhone 11, доля таких сессий достигает уже примерно трети.
Скорость нагрева устройств
Перейдем к метрике скорости нагрева устройств. Здесь мы смотрим на все пользовательские сессии: они могут включать плейбек, зарядку, загрузку или не включать ни один из этих факторов.
Если взять сессии, которые в принципе дошли до соответствующего температурного режима, то медианные значения выглядят так:
до fair устройство доходит примерно за 31 минуту;
до serious — за 50 минут;
до critical — за 77 минут.
Но картина заметно меняется, если смотреть на отдельные модели устройств. Например, на iPhone 17 Pro эти значения увеличиваются в несколько раз. Это говорит о том, что устройство нагревается значительно медленнее.
На это влияют как минимум два фактора. Во-первых, iPhone 17 Pro — более новое устройство. Ему реже требуется зарядка, а производительности достаточно, чтобы не нагреваться на простых пользовательских сценариях. Во-вторых, iPhone 17 Pro отличается от флагманов прошлых поколений конструкцией: у него лучше организовано охлаждение. Поэтому скорость нагрева заметно отличается в лучшую сторону.
Но разница видна не только на самых новых моделях. Даже если сравнить более современное и мощное устройство с более старым — например, iPhone 16 Pro и iPhone 11, — различие все равно будет существенным: примерно в полтора раза.
В этом случае речь уже не только о конструкции, но и о возрасте устройства: насколько часто ему требуется зарядка, насколько эффективно оно справляется с нагрузкой и как быстро переходит в повышенные температурные режимы.
Оба фактора — поколение устройства и особенности его конструкции — серьезно влияют на скорость нагрева. Еще заметнее это становится, если смотреть не на все пользовательские сессии, а только на сессии с плейбеком. В этом сценарии устройство может дойти до состояния serious уже примерно за полчаса.
Даже iPhone 17 Pro, который по-прежнему сильно выигрывает относительно средней сессии, в плейбеке нагревается заметно быстрее. До fair он доходит примерно за 36 минут, до serious — за 71 минуту. Переход в critical маловероятен, но если он все же происходит, то обычно занимает больше полутора часов. Для других устройств ситуация хуже. Некоторые флагманские модели прошлых поколений доходят до fair уже за 22, 26 или 29 минут.
При этом важно отметить: разница между устройствами в данных по всем сессиям и в данных только по плейбеку выглядит по-разному. В обычных сессиях преимущество iPhone 17 Pro заметно сильнее. В плейбеке этот разрыв сокращается.
Это может говорить о том, что благодаря более эффективному охлаждению iPhone 17 Pro хорошо справляется с умеренной нагрузкой. Но когда включается плейбек, нагрузка становится достаточно высокой, и даже продвинутая система охлаждения уже не полностью компенсирует рост температурного режима.
Если же вернуться к iPhone 11, ситуация выглядит значительно хуже. В сессиях с плейбеком этому устройству нужно около 15 минут, чтобы дойти до состояния fair. Примерно за полчаса оно уже достигает serious и успевает провести в этом режиме некоторое время. До critical устройство может дойти примерно за 42 минуты.
То есть даже относительно короткий сценарий просмотра контента может привести к заметному нагреву.
Именно поэтому на iPhone 11 проблемы, связанные с повышенным thermal state, будут проявляться гораздо сильнее, чем на iPhone 17 Pro: снижение плавности, замедление отклика и физический дискомфорт для пользователя станут заметны раньше.
Переходы между режимами и разброс по времени
До сих пор мы смотрели, как быстро устройство нагревается из холодного старта. Но плейбек далеко не всегда начинается с Nominal: устройство может уже быть теплым, а из любого режима оно способно двигаться как вверх, так и вниз. Поэтому метрику «время до достижения состояния» имеет смысл обобщить: для плейбека, который уже находится в некотором температурном режиме, посмотреть, куда он переходит дальше, как часто и за какое время. И главное — смотреть не только на медиану, но и на разброс.
Возьмем три среза по стартовому состоянию плейбека — Nominal, Fair и Serious. Внутри каждого среза «доля» показывает, какая часть сессий хотя бы раз достигла указанного режима, а время — это медиана (p50) и p80 времени до первого попадания в этот режим. p80 — порог, ниже которого укладываются 80% переходов: он показывает не «типичную», а «медленную» часть распределения.
Несколько оговорок, прежде чем читать эти числа. Во-первых, эти срезы посчитаны на отдельной выборке — поэтому значения могут слегка расходиться. Доли внутри одного среза могут в сумме превышать 100%: за сессию устройство может побывать в нескольких режимах, и каждое достижение учитывается отдельно — это не взаимоисключающие исходы. Для Critical мы приводим только долю, но не время: таких переходов в каждой когорте в сравнении с другими слишком мало. Зато доля показательна — Critical редок при любом стартовом состоянии, и до него устройство обычно доходит не от одного плейбека, а при наложении факторов: зарядка, высокая температура окружения, прямые солнечные лучи.
Само направление переходов закономерно и большого открытия не несет: из любого повышенного режима устройство заметно чаще двигается вниз, к более холодному состоянию, чем вверх. Это ожидаемо — снижение нагрева ровно то, ради чего работает вся терморегуляция iOS. Интереснее посмотреть на разброс, и здесь p80 добавляет к медиане важную деталь: «типичного» устройства, по сути, нет. У каждого перехода p80 в два-пять раз больше медианы — то есть рядом с быстрой половиной всегда тянется заметный медленный хвост.
И этот разброс работает в обе стороны. При нагреве он на стороне пользователя: до Fair медиана из холодного старта — около 20 минут, но у более «холодной» пятой части устройств это уже порядка 70 минут, почти втрое дольше. Для этих сессий нагрев может вообще не успеть проявиться за обычный просмотр — запас по времени у них кратно больше.
При остывании та же ширина распределения играет уже против пользователя. По медиане возврат выглядит обнадеживающе: из Fair в Nominal — около 3 минут, из Serious в Nominal — около 9. Но p80 рисует другую картину: среди сессий, которые вообще вернулись в более холодный режим, у медленной пятой части на это уходит уже около 17 минут из Fair и около 33 минуты из Serious. То есть «быстрое остывание» — это про медиану; для заметной доли пользователей повышенный режим держится не пару минут, а полчаса и дольше.
Сложим обе стороны. iOS хорошо справляется с нагревом: в среднем устройство возвращается вниз чаще и быстрее, чем уходит вверх. Но разброс важнее усреднения — и он распределен неравномерно. Быстрый нагрев и медленное остывание сходятся не на случайных пользователях, а ровно на тех, кто и так в зоне риска: старые устройства, долгий плейбек, зарядка во время просмотра. Нагрев не размазан по аудитории ровным слоем — он концентрируется там, где условия и так хуже всего, и там же бьет сильнее всего.
Суммарное время в температурном режиме
Рассмотрим следующую метрику — суммарное время, которое пользователи проводят в каждом температурном режиме. По этим данным видно, что 27% времени пользователи проводят в состоянии повышенного нагрева. При этом, как мы помним, только 16% сессий вообще содержат повышенный thermal state. Это важное различие. Оно говорит о том, что если устройство уже дошло до fair или serious, то оно, как правило, остается в этом состоянии достаточно долго.
Та же тенденция сохраняется и для более высоких температурных режимов — serious и даже critical. Правда, доля сессий с critical сама по себе довольно мала, поэтому с продуктовой точки зрения этот сценарий менее значим. А вот для serious картина уже заметнее: в этом состоянии пользователи проводят около 5% времени, хотя сам режим встречается только в 3% сессий.
Температурный режим и длительность плейбека
Рассмотрим, как температурный режим влияет на длительность плейбека. Для начала важно понять, как корректно это измерить. Мы хотели исключить из анализа косвенные факторы, поэтому решили сравнивать не всех пользователей между собой, а плейбеки внутри одной и той же пользовательской сессии.
Так мы выделили три группы:
Первый плейбек в сессии без повышенного нагрева. Для него мы фиксируем длительность и используем ее как базу для сравнения.
Второй плейбек в той же пользовательской сессии, тоже без повышенного нагрева. Например, пользователь что-то посмотрел, вышел из плейбека, потом вернулся и снова начал смотреть контент — при этом устройство все еще не перешло в повышенный thermal state.
Между первой и второй группой мы видим разницу в 4,7%. То есть второй плейбек в среднем оказывается примерно на 5% короче первого. Это можно считать базовым снижением длительности повторного просмотра внутри одной сессии.
Второй плейбек, но уже с повышенным уровнем нагрева. В этом сценарии устройство успело нагреться, например во время первого плейбека, и следующий просмотр пользователь начинает уже при повышенном thermal state.
Здесь снижение заметно сильнее: при переходе в fair длительность плейбека падает на 15%, а при переходе в serious — на 22%.
Важно, что это снижение накладывается поверх базовой разницы между первым и вторым плейбеком. То есть речь не просто о естественном сокращении повторного просмотра, а о дополнительном эффекте, который связан именно с нагревом устройства.
Подведем итог по масштабу проблемы. Плейбек и зарядка — два частых фактора, которые сильнее всего связаны с ростом температуры устройства во время пользовательских сессий. В результате пользователи проводят более четверти времени в повышенном температурном режиме.
А в отдельных сценариях, например при сочетании плейбека и зарядки, повышенный thermal state встречается уже в большей части сессий. Все это влияет не только на технические метрики, но и на пользовательское поведение: при повышенном температурном режиме мы видим падение длительности плейбека вплоть до 22%.
UX: метрики плавности и отзывчивости
Перейдем к измерениям интерфейса — метрикам плавности и отзывчивости. Но сначала нужно ответить на вопрос: как вообще можно собрать такие данные?
Первой идеей, скорее всего, будет использовать MetricKit. Это системный инструмент iOS, который предоставляет довольно много данных по performance-аналитике устройства. В частности, через него можно получать информацию о hangs — зависаниях, которые возникают во время работы приложения.
Но у MetricKit есть важное ограничение: он отдает данные агрегированно и довольно редко — реже, чем раз в сутки.
Из-за этого мы не можем восстановить контекст конкретного события. Если в данных появился hang, мы не знаем, что именно происходило в момент зависания: в каком thermal state находилось устройство, был ли активен плейбек, шла ли зарядка, выполнялась ли загрузка и так далее.
А значит, по одним только данным MetricKit невозможно корректно понять, повлиял ли температурный режим на конкретную деградацию интерфейса.
Поэтому мы пошли другим путем и реализовали собственную логику агрегации на основе времени генерации кадра. Эти данные мы получаем через CADisplayLink.
CADisplayLink — это таймер, синхронизированный с циклом обновления экрана. С помощью его полей можно понять, сколько времени заняла генерация текущего кадра, а затем на основе этих данных построить более сложные метрики плавности и отзывчивости интерфейса.
В коде это выглядит достаточно просто: мы создаем CADisplayLink и передаем в него селектор. Этот селектор вызывается при каждом обновлении экрана, а значит, на каждом таком вызове мы можем получить данные о текущем кадре.
// Setup let link = CADisplayLink(target: self, selector: #selector(frameTick)) link.add(to: .main, forMode: .common) @objc private func frameTick(_ link: CADisplayLink) { let duration = link.duration // интервал кадра (целевой — 1/60 или 1/120 с) let timestamp = link.timestamp // момент начала текущего кадра let targetTimestamp = link.targetTimestamp // ожидаемый timestamp следующего кадра // touch latency registerTouchStartLatency(session: session, timestamp: now) registerTouchEndLatency(session: session, id: id, timestamp: now) // fps metrics let delta = link.timestamp - lastTimestamp lastTimestamp = link.timestamp multidelegate.addFrame(duration: delta, timestamp: link.timestamp) }
Дальше эти данные передаются в агрегаторы метрик. Уже там мы считаем показатели плавности и отзывчивости, после чего отправляем их в аналитику и получаем итоговую картину по пользовательским сессиям.
Метрики плавности: FPS, jitter и dropped frames
Сначала рассмотрим метрики плавности.
Самая известная из них — средний FPS. Но у этой метрики есть важное ограничение: это именно среднее значение. Если не произошло чего-то совсем катастрофического, средний FPS может не показать локальные просадки производительности.
Поэтому мы используем еще две метрики: jitter и dropped frames.
Jitter — это стандартное отклонение длительности кадра. Эта метрика показывает нестабильность генерации кадров и измеряется в миллисекундах. Чем выше jitter, тем менее равномерно приложение отрисовывает интерфейс.
Dropped frames — это доля кадров, время генерации которых сильно превысило ожидаемое время отрисовки. Такие кадры мы считаем пропущенными.
Важно учитывать, что при долгом зависании пользователь теряет не один кадр, а сразу несколько. Например, на экране с частотой 60 Гц один кадр должен занимать примерно 16,7 мс. Если приложение зависло на 160 мс, оно фактически пропустило около десяти кадров. Поэтому при расчете dropped frames мы учитываем не только сам факт просадки, но и ее длительность.
Теперь посмотрим на данные по плавности работы приложения. Для медианного пользователя средний FPS выглядит почти идеальным. Важно уточнить, что речь идет о данных для устройств с экраном 60 Гц: в таком случае 58,6 FPS — это практически максимум, который можно получить в реальных условиях.
Для медианного пользователя мы также видим около 5 мс jitter и примерно 4% потерянных кадров. Это достаточно хорошие показатели.
Но если посмотреть на 90-й перцентиль, то есть на 10% худших сценариев, картина становится менее радужной.
Средний FPS в этих сценариях меняется незначительно — примерно на 3,5 кадра в секунду. По одной только этой метрике может показаться, что серьезной проблемы нет. Но jitter и доля потерянных кадров вырастают примерно в три раза. А это уже может быть заметно для пользователя: интерфейс начинает ощущаться менее стабильным, появляются локальные просадки и рывки.
Если добавить к этим данным контекст температурного режима, то для медианного пользователя влияние нагрева выглядит умеренным. Средний FPS практически не меняется. Jitter действительно растет — вплоть до 40% при переходе к более высоким температурным режимам. На первый взгляд это звучит серьезно, особенно если смотреть только на относительное изменение.
Но важно учитывать абсолютные значения. Даже в режиме critical при таких показателях приложение все еще работает достаточно плавно. Да, изменения есть, но для медианного пользователя они, скорее всего, не сломают пользовательский опыт.
Совсем другая картина появляется в 10% худших сценариев. Там ситуация изначально заметно сложнее: jitter достигает примерно 13 мс, а каждый восьмой кадр оказывается потерянным — то есть генерируется слишком долго.
При этом влияние нагрева в этих сценариях гораздо выше, чем для медианного пользователя, особенно при переходе в critical. Здесь начинает заметно падать даже средний FPS. Это важный сигнал: если просадка видна уже в средней метрике, значит, проблема действительно серьезная. В таких сценариях FPS снижается примерно на 20%. Jitter растет кратно, а количество потерянных кадров увеличивается почти в три раза.
Все это говорит о том, что для худших сценариев критический уровень нагрева может делать работу с приложением практически невозможной. Интерфейс становится настолько нестабильным и неплавным, что пользователь уже не просто замечает отдельные просадки — он сталкивается с серьезными проблемами всего опыта взаимодействия.
Метрика отзывчивости
Но плавность — не единственная метрика интерфейса. Возможно, еще важнее метрика отзывчивости. Под отзывчивостью мы понимаем время реакции интерфейса на действие пользователя: сколько проходит между взаимодействием и моментом, когда пользователь видит результат на экране.
Измеряем мы это тоже с помощью данных из CADisplayLink. Мы фиксируем момент, когда произошло пользовательское взаимодействие, а затем определяем, сколько времени прошло между завершением этого взаимодействия и ближайшим обновлением экрана.
Конечно, у такого подхода есть ограничение. Мы не анализируем каждый конкретный сценарий отдельно, поэтому не можем гарантировать, что на экране действительно произошло визуальное изменение именно в ответ на это действие.
Тем не менее такая метрика дает нам приближенную, но полезную оценку того, насколько быстро интерфейс реагирует на действия пользователя в разных температурных режимах. Поэтому в этой метрике мы смотрим не на гарантированное изменение интерфейса после действия, а на то, когда был сгенерирован следующий кадр после пользовательского взаимодействия.
По latency получаем такие данные: для медианного взаимодействия задержка составляет около 18 мс. Для устройства с экраном 60 Гц это более чем приемлемый показатель. Скорее всего, такая задержка почти никогда не будет заметна пользователю: если подвисание и есть, оно минимальное.
Для 90-го перцентиля ситуация уже менее однозначная. Здесь задержка достигает примерно 70 мс.
70 мс — это уже близко к порогу заметности. Обычно считается, что при задержке около 100 мс и выше пользователь начинает ощущать, что приложение «подтупливает» и что-то работает не так. Но на практике эта граница может быть ниже: например, субъективно такие проблемы уже могут ощущаться в районе 70–80 мс, особенно если часто работаешь с производительностью интерфейса.
Если добавить к этим данным контекст температурного режима, становится видно, что нагрев действительно влияет на задержку реакции интерфейса на действия пользователя — причем на всех уровнях измерения.
Для медианного пользователя влияние нагрева на отзывчивость остается небольшим. Даже при переходе к critical задержка меняется примерно с 16 до 19 мс. Формально изменение есть, но абсолютные значения настолько низкие, что оно вряд ли заметно повлияет на пользовательский опыт.
Если посмотреть на 90-й перцентиль, картина становится серьезнее. Здесь разница между nominal и critical составляет уже около 30%. Кроме того, сами значения находятся гораздо ближе к порогу заметности.
В такой зоне каждая дополнительная миллисекунда уже важна: чем ближе задержка к заметному для пользователя уровню, тем выше риск, что интерфейс начнет восприниматься как медленный или нестабильный.
Еще сложнее ситуация выглядит в изначально проблемных сценариях — там, где latency уже превышает 50 мс. Это означает, что во время взаимодействия было пропущено несколько кадров, то есть пользователь уже столкнулся с некоторым зависанием.
Если среди таких сценариев посмотреть на 90-й перцентиль, влияние температурного режима становится максимальным. При переходе от nominal к critical задержка увеличивается примерно на 70%.
И это особенно важно, потому что даже в nominal такие сценарии уже находятся в зоне заметной деградации: задержка около 150 мс, скорее всего, будет ощутима для большинства пользователей. Дальнейший рост только ухудшает опыт.
Иными словами, нагрев сильнее всего бьет не по среднему пользователю, а по тем сценариям, которые уже были проблемными. Именно там дополнительная задержка становится наиболее критичной, а влияние температурного режима — самым заметным.
Итоги по метрикам плавности и отзывчивости
Подведем итог по плавности и отзывчивости приложения под нагревом. Для медианного пользователя меняется не так много. Да, при росте thermal state увеличиваются jitter и latency, но абсолютные значения остаются на уровнях, которые пользователь, скорее всего, не заметит. Поэтому формально хотя задержка есть, но на пользовательский опыт она почти не влияет.
Совсем другая картина появляется в сценариях, где что-то уже идет не так. Если интерфейс и до нагрева находился около порога заметности — или даже немного за ним, — пользовательский опыт еще мог оставаться приемлемым. Просадки были, но они не обязательно приводили к сильной фрустрации.
Однако при росте температурного режима эти проблемы усиливаются: jitter увеличивается кратно, а touch latency может вырасти примерно на 70%. В результате нагрев становится не самостоятельной причиной всех проблем, а усилителем уже существующей деградации. То, что раньше было на грани заметности, после нагрева становится очевидным. А в худших сценариях пользоваться приложением может быть практически невозможно.
Основной вывод по плавности и отзывчивости такой: нагрев сильнее всего бьет по худшим сценариям.
Выводы
Нагрев случается достаточно часто: повышенный thermal state встречается примерно в 16% всех пользовательских сессий. Но еще важнее другое: если устройство уже нагрелось, оно остается в этом состоянии надолго. В итоге пользователи проводят в повышенном температурном режиме около 27% времени.
В плейбеке устройство может нагреться очень быстро. До состояния fair можно дойти примерно за 19 минут — это длительность короткой серии сериала или относительно небольшого видео. Причем для этого не обязательно нужен старый девайс: достаточно устройства, которое не относится к самым новым моделям с более эффективным охлаждением.
Модель устройства определяет запас прочности. Это хорошо видно по скорости нагрева: iPhone 11 нагревается гораздо быстрее, чем iPhone 17 Pro. Даже если сравнивать не с самым новым устройством, а, например, с iPhone 15 Pro, разница все равно остается существенной. Но дело не только в том, что старые устройства быстрее нагреваются. На них выше и само влияние нагрева на пользовательский опыт. Как мы увидели на проблемных сценариях, при росте температурного режима снижение плавности и отзывчивости становится гораздо заметнее. Часть такого проблемного сценария — это более старое устройство.
На старых девайсах плавность и отзывчивость падают сильнее, а сами метрики быстрее приближаются к порогу заметности. Это особенно важно потому, что такое устройство уже изначально может работать не так стабильно, как, например, iPhone 16 Pro или iPhone 17 Pro. А при росте thermal state это становится еще заметнее. Но частота столкновения с нагревом определяется не только моделью устройства. Не менее важен профиль использования приложения.
Например, у 40% пользователей устройства практически никогда не переходят в повышенный температурный режим. Возможно, они редко смотрят контент, смотрят короткие форматы или просто не попадают в сценарии, которые создают заметную нагрузку. Для таких пользователей нагрев фактически не становится проблемой.
Но для другой группы — около 42% пользователей — нагрев уже встречается. Да, он возникает меньше чем в половине сессий. Но сами сессии с нагревом могут быть для них наиболее важными. Например, пользователь может заходить в приложение часто, но смотреть контент только периодически. В таком случае он будет сталкиваться с нагревом именно в те моменты, когда запускает плейбек.
А это как раз тот сценарий, где особенно важно сохранить хороший пользовательский опыт: пользователь хочет смотреть контент без рывков, задержек и физического дискомфорта от горячего устройства.
Остается еще 18% пользователей, для которых нагрев — практически постоянное условие использования приложения. Именно поэтому эта группа отвечает сразу за 28% всех сессий с повышенным температурным режимом.
Устройство имеет решающее значение
Теперь попробуем посмотреть на проблему не только через агрегированные метрики, но и через конкретную пользовательскую сессию. Возьмем для примера iPhone 17 Pro и контент длительностью около полутора часов — условно, короткий фильм.
В таком сценарии почти до середины просмотра пользователь, скорее всего, не почувствует заметных изменений. Устройство будет постепенно нагреваться, но останется просто немного теплым. Работа приложения при этом практически не изменится: плавность и отзывчивость будут оставаться на хорошем уровне.
Ближе к середине просмотра устройство может перейти в температурный режим fair. В этот момент нагрев уже становится физически заметнее. Вероятно, часть пользователей из-за этого решит прервать просмотр и вернуться к контенту позже.
Но с точки зрения интерфейса ситуация все еще остается достаточно стабильной: приложение продолжает работать плавно, без заметной деградации.
К концу фильма устройство может перейти в режим serious. Здесь еще часть пользователей, возможно, решит досмотреть контент позже. Но если пользователь все же досматривает фильм до конца и выходит из приложения, он, скорее всего, заметит, что влияние нагрева на общую плавность и отзывчивость было минимальным.
Даже если деградация технически присутствовала, на iPhone 17 Pro она, скорее всего, останется малозаметной для пользователя. Но все меняется, если рассмотреть ту же сессию на iPhone 11.
Берем тот же контент длительностью около полутора часов. Но на этот раз уже примерно за полчаса устройство доходит до serious, а меньше чем за 60 минут может перейти в critical.
Проблема в том, что даже если пользователь выйдет из плейбека уже на уровне serious, изменения в плавности и отзывчивости будут гораздо заметнее, чем на более современном устройстве.
А если устройство дойдет до critical, ситуация может стать еще хуже: iOS может ограничить работу с приложением или фактически заблокировать дальнейшее использование устройства. В таком состоянии пользователь уже не сможет досмотреть контент, даже если захочет. Сначала ему придется охладить устройство.
Скорее всего, такой сценарий возникает не только из-за самого приложения: обычно подключаются и внешние факторы. Например, телефон может лежать под прямыми солнечными лучами. Часть этих факторов пользователь может устранить — хотя бы убрать устройство с солнца. Но для него это все равно будет неприятным сюрпризом: он хотел просто досмотреть контент, а в итоге столкнулся с перегревом, деградацией интерфейса или даже системным ограничением со стороны iOS.
Любой опыт важен
Здесь возникает логичный вопрос: насколько вообще важен опыт пользователей на iPhone 11? В любом случае этот опыт важен.
Более того, сценарий использования приложения на iPhone 11 примерно в четыре раза популярнее, чем сценарий использования на iPhone 17 Pro. В целом iPhone 11 занимает второе место по количеству сессий в этом году, уступая только iPhone 13.
И это тоже важно: с точки зрения поведения под нагревом iPhone 13 гораздо ближе к iPhone 11, чем к самым новым устройствам с более эффективным охлаждением.
Даже если посмотреть на другие флагманские модели, которые могут показывать себя лучше под нагрузкой — например, iPhone 16 Pro или iPhone 15 Pro Max, — по количеству сессий они все равно уступают iPhone 11 и iPhone 13.
Поэтому, когда мы говорим об ухудшении пользовательского опыта под нагревом на примере iPhone 11, мы говорим не о редком edge case. Это массовый и очень частый пользовательский сценарий, который напрямую влияет на заметную долю аудитории.
Пути решения
Что можно с этим сделать? Пока мы определили для себя три направления дальнейшего исследования.
1. Адаптивное качество плейбека при нагреве
Начнем с самого сложного и самого интересного. Идея простая: чем ниже битрейт во время плейбека, тем медленнее нагревается устройство. Но у этого решения есть очевидный trade-off: чем ниже качество видео, тем меньше пользователь хочет продолжать просмотр.
Поэтому здесь нельзя просто взять и снизить качество всем пользователям при росте thermal state. Нужно понять, где проходит граница: в какой момент снижение качества помогает сохранить комфорт просмотра, а в какой — уже само становится причиной ухудшения пользовательского опыта.
Такой анализ, скорее всего, заслуживает отдельного доклада. Но как направление для исследования это выглядит очень перспективно.
2. Приостановка загрузок во время активного плейбека
Более простое решение. Менее радикальный вариант — предупреждать пользователя при нагреве, что загрузку контента лучше остановить, если он сейчас находится в плейбеке.
Это действительно может помочь части пользователей. Но, как мы уже выяснили, загрузки в нашем приложении встречаются довольно редко. Поэтому такой механизм, скорее всего, повлияет только на небольшую долю сессий.
3. Уведомления пользователя о перегреве
Частично этим уже занимается сама iOS. Если устройство какое-то время находится в режиме critical и не может охладиться, система может прийти к выводу, что на нагрев влияют внешние факторы: например, пользователь находится в жаркой среде или держит телефон под прямыми солнечными лучами.
В таком случае iOS предложит охладить устройство самостоятельно и может ограничить работу с приложением. И в целом это правильно: на этом этапе системе важнее защитить устройство, чем сохранить пользовательский сценарий. Но, возможно, пользователю стоит сообщать о проблеме немного раньше — до того, как устройство дойдет до критического температурного режима.
Ведь пользоваться сильно перегретым телефоном физически неприятно. Во-вторых, если пользователь уже смотрит контент, ему может быть важно хотя бы завершить текущий просмотр, а не столкнуться с внезапной блокировкой или помехами в работе приложения.
Более раннее предупреждение может дать пользователю возможность повлиять на ситуацию: убрать телефон из-под солнца, временно отключить зарядку, снизить яркость или как-то иначе улучшить внешние условия. В результате устройство может нагреваться медленнее, дольше оставаться в приемлемом температурном режиме или вообще не дойти до критического состояния в этой сессии.
В итоге мы видим, что нагрев комплексно влияет на UX и сильнее всего бьет по уязвимым сценариям. Среди ключевых факторов — модель устройства. Чем современнее девайс и чем лучше он справляется с охлаждением, тем меньше он подвержен деградации при росте thermal state.
Самый проблемный пользовательский сценарий — плейбек, особенно в сочетании с зарядкой. В этом случае устройство может нагреваться довольно быстро. А если к этому добавляются другие факторы — например, более старая модель устройства или внешняя жара, — пользователь может столкнуться с очень заметным снижением качества опыта: от физического дискомфорта до просадок плавности, роста задержек и невозможности нормально досмотреть контент.
