В начале 2010-х годов команда разработчиков Mozilla стояла перед амбициозной задачей — выпустить мобильную операционную систему, построенную на веб-технологиях. Этот продукт получил название Firefox OS. Работая в условиях ограниченного времени и ресурсов, специалисты столкнулись с непростой проблемой, которая напрямую касалась энергопотребления устройств, на которых должна была работать система. Один из неожиданных факторов, который серьезно влиял на расход энергии, оказался крошечный анимационный индикатор загрузки данных. Рассказываем, как формат APNG позволил снизить энергопотребление в 10 раз и поспособствовал успешному запуску Firefox OS 1.
0. Firefox OS был крупным экспериментом, ведь система базировалась целиком на HTML, CSS и JavaScript. Такой подход в 2013 году вызывал скепсис — мобильные устройства тех лет зачастую были слишком слабы, а стандарты веба еще не были достаточно зрелыми. Тем не менее, команда пыталась найти компромиссы и решить сложные инженерные задачи, которые возникали на пути. В феврале 2013 года на Mobile World Congress в Берлине поставили задачу выпустить первую стабильную версию операционной системы.
В условиях жестких сроков оставалось сделать многое, и одной из ключевых проблем стало управление энергопотреблением во время типовых пользовательских сценариев, например веб-серфинга. В ходе профилирования работы системы разработчики обнаружили, что небольшой 16х16 пикселей анимированный индикатор, показывающий передачу данных, потребляет ошеломляющее количество энергии. Стандартная реализация такой анимации предполагала обновление кадров каждые примерно 16 миллисекунд, то есть на уровне 60 кадров в секунду, при том что сама анимация задумывалась лишь проработанной с частотой около 10-15 кадров в секунду. Излишнее количество обновлений кадров приводило к постоянным перерасчетам расположения элементов страницы — так называемому reflow, который требовал значительных ресурсов центрального процессора. Одним из первых шагов оптимизации стало выравнивание всех кадров анимации по размеру, чтобы избежать изменения размеров элемента и тем самым уменьшить операции reflow.
Это помогло частично снизить энергопотребление, но пока решение было далек от идеального. Дело в том, что каждое обновление фрейма не только вызывало перерасчет компоновки страницы на уровне браузера, но и заставляло графический процессор (GPU) активно работать, даже если визуальное содержимое было очень ограниченным. В то время мобильные системы на базе систем на кристалле (SoC) имели два ключевых аппаратных блока для работы с изображениями: графический процессор, отвечающий за сложные визуальные эффекты и графику, и дисплейный процессор, который непосредственно отправлял кадры на экран. Важно понимать различия между ними: GPU в основном работает «в памяти», изготавливая изображения, а дисплейный процессор выступает как специализированный модуль, умеющий напрямую выводить слои на экран с минимальным энергопотреблением. Ключевая идея оптимизации состояла в том, чтобы использовать возможности дисплейного процессора для отображения анимации без включения GPU.
Если анимация будет представлена отдельным графическим слоем, который можно будет обрабатывать аппаратным коммутатором экранных слоев, GPU сможет оставаться в выключенном или низкопотребляющем режиме, что существенно сократит расход энергии. Первым испытанным решением стала замена тега <img>, который содержал анимацию, на элемент <canvas>. Внутри канваса с помощью JavaScript рисовались кадры анимации с необходимой частотой. С точки зрения логики, такой подход должен был задействовать аппаратные возможности и снизить энергопотребление. Однако неожиданно иконка исчезала со сцены — аппаратные драйвера Qualcomm для Android в 2013 году имели баг, из-за которого текстуры размером от 9 до 16 пикселей не рендерились корректно.
Исправить драйверы было невозможно из-за закрытого характера программного обеспечения и отсутствия поддержки обновлений. Поэтому разработчики придумали обойти проблему, увеличив размер текстур анимации минимум до 32х32 пикселей. Хотя это немного увеличило потребление памяти, иконка стала корректно отображаться, и энергозатраты уже достигли приемлемого уровня. Но оставалась еще одна проблема. Для обновления кадров сейчас использовался JavaScript, который требовал периодического пробуждения CPU.
Даже короткие пробуждения зачастую выводили процессор из состояния энергосбережения и переводили его в высокопроизводительный режим, что резко повышало энергозатраты. Переходный процесс между состояниями питания обычно занимает миллисекунды, поэтому даже невысокая частота обновления кадров создавалась дополнительной нагрузкой. Здесь на помощь пришел формат анимированных PNG — APNG. Разработка стандарта началась в Mozilla еще в 2006 году и была впервые реализована в Firefox 3.0 в 2008 году.
APNG позволял хранить несколько кадров анимации в одном файле PNG с возможностью контроля частоты кадров и без необходимости использования JavaScript для обновления изображения. Использование APNG означало, что браузер сам мог аппаратно обрабатывать анимацию, выделяя отдельный слой, который дисплейный процессор мог эффективно выводить без участия GPU и частого пробуждения CPU. Переход на APNG сделал анимацию плавной и энергоэффективной. Энергопотребление снизилось более чем в 10 раз по сравнению с первоначальной реализацией, что позволило отвечать высоким стандартам мобильной работы и увеличило время автономной работы устройств на базе Firefox OS. Можно сказать, что APNG сыграл ключевую роль в успехе запуска Firefox OS 1.
0. Это были один из самых гладких релизов программного продукта в карьере разработчика, несмотря на многочисленные вызовы и жесткие ограничения. Хотя проект и не получил долгосрочного коммерческого успеха, его технические достижения и опыт до сих пор оказывают влияние на мобильные разработки. Интересно, что спустя годы часть наработок и принципов Firefox OS была подхвачена и развита в проекте KaiOS — современной операционной системе для «умных» кнопочных телефонов. Там также используется рендеринг на основе веб-технологий и продуманные решения для экономии энергии.
Кроме того, история Firefox OS и использование APNG отлично иллюстрируют, как важны низкоуровневые оптимизации в мобильной разработке. Часто именно тонкое понимание взаимодействия аппаратных компонентов, драйверов и программных средств рендеринга позволяет добиться значительных улучшений, которые пользователь напрямую не замечает, но очень ценит — например, более долгую работу телефона без подзарядки. Формат APNG сегодня продолжает развиваться и находить применение в различных сферах, где важна компактная и аккуратная анимация. В основе его успеха — возможность объединить простоту PNG и гибкость анимации без компромиссов по качеству и ресурсам. В случае Firefox OS он стал не просто инновационным форматом, а настоящим спасителем, позволившим сэкономить заряд батареи и облегчить выпуск первой стабильной версии системы.
Опыт Firefox OS напоминает о том, что инновации в области ПО и аппаратного обеспечения идут рука об руку с инженерной ловкостью и прагматизмом. Весь цикл от выявления проблемы до её решения через глубокие технические исследования и творческие обходные пути заслуживает внимания тех, кто интересуется мобильными технологиями, оптимизацией ресурсов и развитием стандартов веба. Сегодня, глядя на эту историю спустя годы, можно отметить, насколько важно масштабно подходить к проектированию платформ и внедрять современные форматы изображений с пониманием их влияния на всю цепочку аппаратно-программного взаимодействия. И в этом ключе APNG оставил заметный след, задав планку качества и эффективности для будущих проектов в индустрии.
