Разработка приложений для Smart TV: о чём не предупреждают

Я занимаюсь разработкой под Smart TV большую часть своей карьеры, и у меня до сих пор дёргается глаз, когда кто-то говорит "ну это же просто веб-приложение, да?" Нет. Нет, это не так. Давайте расскажу, что на самом деле происходит, когда вы пытаетесь выпустить продакшен-приложение на WebOS, Tizen и чём бы там ни занимался Roku.

С браузерами всё хуже, чем вы думаете

Вот о чём никто не предупреждает: браузеры на Smart TV — старые. Не "ой, надо полифил подключить" старые. Я говорю про Chromium 38 на некоторых LG 2019 года. Это браузер 2014 года на железе, проданном в 2019-м. Никакого CSS Grid на старых моделях. Никакого IntersectionObserver. Иногда даже fetch нет. Вы пишете JavaScript, который должен работать на том, что по сути является музейным экспонатом.

Samsung Tizen чуть лучше, но со своими причудами. Браузер Tizen 3.0 поддерживает большинство фич ES6, но управление памятью непредсказуемое. Я видел, как приложения падали на Tizen из-за того, что одна постер-картинка в высоком разрешении превышала лимит памяти WebView. И никакой деградации — приложение просто умирает.

Мой подход: я веду строгую матрицу совместимости. Каждая фича проверяется на самой слабой целевой платформе. Транспилируем всё до ES5 через Babel, агрессивно полифилим и тестируем на реальном железе. Эмуляторы врут. Эмулятор LG скажет вам, что всё отлично, пока реальный телевизор показывает чёрный экран.

Пространственная навигация — отдельная инженерная дисциплина

В вебе пользователи кликают. На мобильных — тапают. На телевизоре у них крестовина — вверх, вниз, влево, вправо, ОК, назад. Вот и всё. А теперь попробуйте сделать сложный интерфейс, работающий только с этими кнопками.

Пространственная навигация кажется простой, пока в вашей сетке карточек в одном ряду не окажется 4 элемента, а в следующем — 3. Нажимаете "вниз" с 4-й карточки — куда уходит фокус? А если есть вложенные прокручиваемые области? Что если нажатие "влево" из сайдбара должно перекинуть фокус на основной контент? Каждый переход фокуса нужно либо явно определить, либо обработать умным алгоритмом.

Я написал собственный движок пространственной навигации, который рассчитывает ближайший фокусируемый элемент на основе вектора направления и области перекрытия. Встроенная навигация браузера (да, на некоторых ТВ она есть) почти всегда сломана — она может перебросить фокус на элемент в противоположном конце экрана, потому что технически он "ближайший" в этом направлении, если мерить от угла элемента.

Система навигации также должна обрабатывать scroll-into-view, память фокуса (запоминать, где вы были, когда возвращаетесь в секцию) и ловушки фокуса для модалок и оверлеев. Одно это может занять недели.

Память: невидимая стена

Большинство Smart TV поставляются с 512 МБ — 1.5 ГБ оперативной памяти, и ваше приложение получает лишь часть. На WebOS веб-рантайм обычно получает около 200-300 МБ. Звучит терпимо, пока не поймёшь, что одно декодированное 4K-изображение может съесть 30+ МБ памяти.

Вот чему я научился на горьком опыте:

• Виртуализируйте всё. Если у вас список из 200 каналов, рендерите только 10-15 видимых. Остальные полностью уничтожайте — не просто прячьте через CSS.
• Управление картинками — критично. Загружайте лениво, используйте подходящие разрешения (превью не обязано быть 1920x1080) и активно освобождайте object URL, когда картинки уходят из зоны видимости.
• Следите за утечками памяти одержимо. Один забытый обработчик событий или неочищенный интервал может медленно поедать память, пока приложение не упадёт через 30 минут. На телевизоре пользователи не обновляют страницу — приложение может работать часами.
• Профилируйте на реальном железе. Профилирование памяти в Chrome DevTools на вашем MacBook ничего не значит. У JavaScript-движка телевизора другое поведение GC, другие потолки памяти и другие характеристики производительности.

Проблема UX с пультом ДУ

Проектирование под телевизионный пульт фундаментально отличается от работы с тачем или мышью. Пользователь сидит в 3 метрах от экрана. Он не может тапнуть куда хочет — он должен добираться до нужного элемента пошагово. Каждое лишнее нажатие на пути к контенту — провал вашего UX.

Хороший ТВ-UX минимизирует количество нажатий до любого контента. Я целюсь в максимум 3 нажатия от домашнего экрана до начала воспроизведения. Это ограничение формирует всю информационную архитектуру. Глубокие деревья категорий? Забудьте. Вложенные меню настроек? Выпрямляйте.

И ещё принцип "10-foot UI": текст должен быть минимум 24px (а честно говоря, 28-32px для основного текста). Области фокуса должны иметь щедрые отступы. Контрастность важна даже больше, чем на мобильных, потому что качество ТВ-экранов сильно варьируется, а освещение в гостиных непредсказуемо.

Что в итоге делает это стоящим

Несмотря на всю боль, разработка под Smart TV — одна из самых благодарных задач в моей практике. Ограничения заставляют писать эффективный код. Нельзя спрятаться за 16 ГБ RAM и быстрым SSD. Каждая оптимизация важна, каждый байт на счету, и когда опыт получается правильным — когда приложение работает плавно и отзывчиво на телевизоре за $200 — это по-настоящему приятно.

Нужна помощь с разработкой под Smart TV?

Если вы строите стриминговый продукт и мучаетесь с телевизионными платформами — я решаю именно такие задачи уже 9+ лет. OTT-платформы, которые я построил, обслуживают 80M+ зрителей на 15+ типах устройств — включая WebOS, Tizen, Android TV и Roku. Нужно новое Smart TV приложение с нуля или помощь с оптимизацией существующего — дам честную оценку, что потребуется.