На устройствах с частотой обновления 60 и 120 Гц одна и та же анимация завершается с разной длительностью. Как доказать, что причина — привязка логики к числу кадров?
Нужно сравнить длительность анимации при разных частотах обновления и отдельно проверить зависимость завершения от количества отрисованных кадров. Если переход завершается после фиксированного числа кадров, он будет длиться примерно вдвое меньше на 120 Гц, чем на 60 Гц. Это доказывает привязку логики к кадрам; корректная реализация должна использовать прошедшее время, а не счётчик кадров.
Ранние мобильные интерфейсы часто проектировались вокруг фиксированной частоты обновления, обычно 60 Гц. При таком подходе разработчик мог неявно считать, что каждый кадр занимает около одной и той же длительности.
Современные устройства используют разные частоты обновления, включая 60, 90 и 120 Гц, а ОС может динамически менять её для экономии энергии. Поэтому количество кадров перестало быть надёжным эквивалентом времени.
Допустим, завершение перехода выполняется после 60 кадров. На экране с частотой 60 Гц это займёт примерно одну секунду, а на 120 Гц — около половины секунды. Пользователь увидит разную скорость интерфейса, а автоматические тесты могут получать разные моменты доступности элементов.
Риск возникает не только в визуальной анимации. От количества кадров могут ошибочно зависеть задержка показа экрана, момент разблокировки кнопки, обработка жеста или запуск следующего этапа сценария.
Сначала тестировщик фиксирует частоту обновления устройства, фактическое время начала и окончания анимации, а также число отрисованных кадров. Проверку повторяют на устройствах с разной частотой обновления и, если возможно, при переключении динамической частоты во время сценария.
Ключевой признак ошибки — постоянное или близкое к постоянному число кадров при различной длительности. Например, если переход заканчивается примерно после 60 кадров и длится около секунды на 60 Гц и около 0,5 секунды на 120 Гц, логика связана с кадрами.
Дополнительная проверка — временно замедлить или ускорить отрисовку, не меняя заданную длительность перехода. При корректной реализации длительность по часам должна оставаться приблизительно постоянной, а число кадров может изменяться.
Правильный механизм вычисляет прогресс как отношение прошедшего времени к заданной длительности. Визуальный кадр лишь отображает текущее состояние; он не должен определять, сколько времени прошло. При пропущенных кадрах прогресс должен перескочить вперёд, а не замедлить реальное завершение.
Измерения нужно проводить с допуском: планирование кадров, нагрузка процессора, энергосбережение и фоновые процессы создают небольшие отклонения. Поэтому единичное отличие по времени недостаточно — важна воспроизводимая зависимость длительности от частоты обновления.
В приложении экран подтверждения закрывался после 45 кадров. На обычных устройствах тесты проходили, но на моделях с высокой частотой обновления пользователь почти не успевал прочитать сообщение.
Рассматривались два варианта. Первый — увеличить число кадров для устройств с высокой частотой обновления; это быстро исправляет один профиль, но требует поддерживать разные значения и ломается при динамическом изменении частоты. Второй — завершать переход по прошедшему времени; он требует изменения механизма анимации, зато одинаково работает на разных устройствах.
Выбрали второй вариант. В тестах проверяли длительность с допустимым диапазоном, а не точное число кадров, и отдельно убедились, что действие недоступно до окончания заданного интервала. В результате скорость перехода стала одинаковой на 60 и 120 Гц, а тесты перестали зависеть от аппаратного профиля.
Нет. Этого достаточно для обнаружения очевидной зависимости, но не для полного доказательства устойчивости. Нужно по возможности проверить динамическое изменение частоты, пропуск кадров и работу под нагрузкой: корректный механизм сохраняет временную длительность, даже если кадры приходят нерегулярно.
Да. Перегрузка устройства может увеличить задержку запуска или вызвать пропуски кадров, но сама заданная длительность должна оставаться примерно постоянной. Если переход замедляется пропорционально числу кадров или ускоряется при увеличении частоты обновления, это уже признак неправильной зависимости; если задержка возникает только до первого кадра, нужно отдельно исследовать производительность и планирование.
Такой тест обнаружит только полное зависание или явный сбой. Он не выявит ускорение анимации на 120 Гц, преждевременную разблокировку элемента или нарушение минимальной длительности перехода. Нужно проверять временную характеристику и порядок связанных событий, сохраняя разумный допуск на планирование ОС.