Розробка Android TV: де рветься навігація пультом
На телевізорі немає тачскріна — єдиний вхід це пульт, і вся навігація пультом Android TV тримається на фокусі.
Варто виділенню загубитися під час переходу між рядами карток, і людина перестає розуміти, де вона перебуває: екран виглядає живим, але жоден елемент не підсвічений, а натискання йдуть у нікуди.
На великому екрані це помітніше, ніж на телефоні: елементів більше, відстані між ними ширші, підказок менше.
Фокус інтерфейсу на великому екрані не успадковується сам собою.
Доводиться явно описувати, куди піде виділення при натисканні вгору, вниз, вліво та вправо, що станеться на межі списку і як повернути позицію після перемальовування даних — інакше ряди залипають і перестають гортатися.
Окремий клас збоїв — повернення додатка після згортання: активність перестворюється, плеєр втрачає позицію, і користувач потрапляє не на ту хвилину, яку дивився.
До цього додається сумісність: додаток не запускається на телевізорі через різну розрядність прошивок, урізаний набір системних модулів і старі версії платформи на бюджетних моделях.
Підтримка пультів і геймпадів додає ще один шар: одні виробники надсилають повтори утримання, інші — власні коди клавіш, а геймпади поводяться інакше, ніж інфрачервоні пульти.
Ламається це не в окремих шматках коду, а на стиках: навігація, плеєр і життєвий цикл додатка тягнуть одне одного, і правка одного ламає інше. Як це закривається на рівні архітектури телевізійної збірки — розбираємо далі.
Що змінюється після запуску: відгук, стабільність, підтримка
Після переробки додаток на Android TV стартує за лічені секунди, а відгук інтерфейсу на натискання кнопки пульта відчувається миттєвим: фокус переходить між плитками без затримки, підвантаження постерів не блокує навігацію.
Це результат того, що важкі операції винесені з головного потоку, а стартові дані кешуються на пристрої.
Плавність інтерфейсу на телевізорі тримається завдяки розкладці під керування з пульта: великі зони фокуса, прокручування рядами, передзавантаження наступного екрана. На слабкому апаратному забезпеченні приставок така схема прибирає ривки під час швидкого гортання каталогу.
Плеєр за слабкої мережі перемикає якість адаптивно, тому просідання каналу знижує чіткість картинки, а не зупиняє відтворення. Буферизація налаштована так, що короткі обриви зв'язку залишаються непомітними, а частка успішно розпочатих сесій перегляду зростає.
Оновлення виходять без простою: збірка спочатку йде обмеженій групі, потім на всіх, а попередня версія залишається доступною для відкату. Раніше падіння на старті після релізу призводило до падіння додатка на частині пристроїв — цей клас відмов усунено.
Звернень до підтримки стає менше: збої фіксуються у звітах про падіння раніше, ніж користувач бере пульт і телефонує. Ми дивимося на частку успішних запусків, глибину перегляду та частоту збоїв за моделями пристроїв — саме за цими метриками видно ефект від переробки.
Варіанти збірки під телевізор: порівняння підходів
Телевізор — не телефон із великим екраном: керування лише пультом, фокус ходить по D-pad, плеєр живе в окремому життєвому циклі, а вихід додатка на передній план влаштований інакше.
Тому вибір упирається не в дизайн, а в те, скільки коду ви готові тримати роздільно і як плануєте проходити публікацію в каталозі телевізора.
Нижче — чотири схеми, між якими реально обирають на старті: усі вони проходять модерацію в телевізійному каталозі, але по-різному поводяться під час розвитку продукту та на слабких приставках.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Нативна збірка під телевізор | Свій ТБ-напрям: власний плеєр, складні екрани, жорсткі вимоги до відгуку пульта | Два продукти розвиваються й тестуються роздільно, релізи розсинхронізуються |
| Єдина кодова база телефон і телевізор | Контент-сервіс, де логіка й дані однакові, відрізняється лише шар представлення | Компроміси в інтерфейсі; обробку фокуса й пульта все одно пишуть окремо |
| Обгортка поверх готового додатка | Потрібно швидко закрити телевізор, унікального інтерфейсу мінімум | Плеєр і навігація обмежені можливостями прошарку, на слабких приставках помітні затримки |
| Вітрина із зовнішнім програванням | Каталог і підбір контенту важливіші за плеєр, відтворення віддається системі | Немає контролю над відтворенням і рекламою, частина аналітики губиться |
На практиці вибір майже завжди гібридний: загальну логіку та роботу з даними виносимо в один модуль, а навігацію, фокус і плеєр тримаємо окремими реалізаціями під телевізор. Так зберігається єдиний цикл випуску версій і не втрачається відгук пульта.
Етапи роботи: від аудиту інтерфейсу до передачі збірки
Етапи йдуть у жорсткій послідовності: спочатку фіксуємо, що саме ламається у глядача, потім проєктуємо поведінку інтерфейсу, і лише потім перевіряємо його на живих приставках і телевізорах.
Порядок міняти не можна — схема навігації та правила фокуса визначають, як поведеться плеєр, а не навпаки. Тому кожен крок закінчується артефактом, який стає входом для наступного.
- Аудит телевізійного інтерфейсу. Проходимо поточний додаток або прототип із пульта: де губиться фокус, скільки кроків до запуску контенту, що відбувається при згортанні та поверненні. На виході — перелік вузьких місць із пріоритетами та цільові сценарії глядача.
- Схема навігації екранів. Будуємо карту переходів: стартовий екран, каталог, картка, плеєр, пошук, налаштування. Для кожного переходу задаємо правила фокуса, поведінку кнопки «назад» і повернення рівно в те місце, звідки глядач пішов.
- Налаштування плеєра та буферизації. Підбираємо розмір буфера під нестабільну мережу, поведінку при зміні якості, перехід між роликами та довантаження. Окремо налаштовуємо старт: скільки глядач чекає до першого кадру і що бачить у цей час.
- Перевірка на реальних пристроях. Проганяємо збірку на слабких приставках і телевізорах минулих років, а не лише на емуляторі: довгі сесії, перемикання входів, нестача пам'яті, пульти різних виробників.
- Приймання за сценаріями. Контрольний список проходів із навігації та відтворення, заміри часу запуску й перемикань, перевірка поведінки при обриві мережі. Усе, що не пройшло, повертається в роботу до передачі.
- Передача збірки та документації. Віддаємо підписану збірку, карту навігації, регламент випуску оновлень та інструкцію для вашої команди, щоб наступна версія збиралася без нас.
Комплект постачання: збірка, схеми екранів, регламенти
Комплект постачання — це те, що залишається у замовника після передачі проєкту і не потребує нас для повсякденної роботи.
Ми віддаємо не лише робочий додаток, а й знання про те, як він влаштований: де проходить фокус між блоками інтерфейсу, як поводиться плеєр при обриві мережі, що робити при збої публікації. Нижче — повний перелік із поясненням, навіщо кожен елемент потрібен в експлуатації.
- Зібраний пакет для публікації — підписаний релізний артефакт, готовий до завантаження в консоль розробника, окрема налагоджувальна збірка для тестових пристроїв і скрипти, якими обидві версії збираються без ручних правок.
- Схема екранів і станів — карта переходів із логікою фокуса при керуванні пультом, включно з тупиковими та помилковими сценаріями: порожній каталог, довге завантаження, втрата з'єднання, неможливість відтворення.
- Список перевірених пристроїв — які моделі телевізорів і ТБ-приставок пройшли ручну перевірку, на яких версіях системи та типах пультів, що покрито автотестами навігації, а що залишилося за ручним прийманням.
- Документація зі збірки — як підняти середовище з нуля, де зберігаються ключі підпису, які параметри змінюються для різних середовищ, якими командами випускається нова збірка.
- Регламент публікації оновлень — порядок випуску з поетапним розгортанням на частку аудиторії, критерії зупинки викату при зростанні збоїв і покроковий відкат на попередній реліз.
- Інструкція з підтримки — типові звернення і що робити за кожним, куди дивитися логи, як перемикати поведінку додатка віддалено, без випуску нової версії.
- Правила поведінки при помилках — узгоджена політика повторів, екранів-заглушок і повідомлень, щоб додаток не «падав у чорний екран» на очах у глядача.
Кожен документ написаний так, щоб ним користувався ваш інженер, а не лише автор коду: без посилань на листування та усні домовленості. Опишіть задачу — повернемося з оцінкою та планом, включно зі складом такого комплекту під ваш проєкт.
Кейс: навігація та плеєр для телевізійного сервісу
Сервіс кіно та серіалів вийшов на Google TV з каталогом на кілька тисяч позицій. Фокус губився при поверненні з плеєра: інтерфейс відкривався на першому ряду замість картки, з якої користувач ішов, а перехід по горизонталі через межу ряду виводив виділення за межі екрана.
Частка успішних запусків трималася близько 88% — частина падінь припадала на старт потоку, частина на повторний вхід у додаток.
Друга проблема виявлялася на довгому перегляді. Після двох годин відтворення зростала затримка відгуку на натискання пульта, а на слабких приставках потік обривався і не відновлювався сам. Звернення до підтримки за цими двома сценаріями займали помітну частку звернень щодо додатка.
Що змінили
Переписали модель фокуса: стан картки зберігається в навігаційному стеку, переходи між рядами описані явними правилами, прокручування каталогу йде з передзавантаженням наступного екрана.
Плеєр перевели на актуальну гілку медіастеку Android з окремим буфером на старті та відновленням позиції після обриву мережі; каталог і обкладинки кешуються на диск, тому холодний запуск не чекає мережу.
Час відгуку інтерфейсу скоротився з 0,7 до 0,15 с, частка успішних запусків зросла до 99,2%. При тригодинному перегляді відтворення йшло без обривів і просідань, а звернень до підтримки щодо навігації та показу стало більш ніж удвічі менше.
Чим відрізняється розробка Android TV від додатка під телефон?
Телевізійна збірка — не розтягнутий телефонний інтерфейс. Дотиків тут немає: користувач рухається хрестовиною пульта, і вся логіка будується навколо фокуса — що виділено зараз і куди він піде при натисканні вліво або вниз. Втрата фокуса після діалогу чи виходу з плеєра — це екран, який пульт більше не слухає.
Змінюється й фізика сприйняття. Екран дивляться з трьох метрів, тому елементи помітно більші, відступи між ними більші, а краї картинки йдуть у безпечні зони панелей.
Сітка з десяти колонок перетворюється на горизонтальний ряд із п'яти-шести постерів: інакше підписи не читаються, а влучити в потрібну картку стає важко.
Інакше поводиться й фон. Телевізор переходить у режим очікування, додаток втрачає фокус і йде у фон, і від нього чекають паузи зі збереженням позиції відтворення.
Повернення має відновлювати стан без перезапуску — користувач чекає продовження з тієї ж секунди, а не повторного завантаження каталогу.
Відтворення спирається на апаратний декодер і медіасесію: звук має коректно йти на зовнішній ресивер, а картинка — переживати перемикання входів. Оновлення надходять рідше, ніж на телефоні, тому сумісність із попередніми версіями системи перевіряється окремо.
Продукт при цьому залишається одним: спільний код, дані та серверна частина, але дві точки входу й дві збірки з різною навігацією, маніфестами та правилами магазину. Саме на цьому стику найчастіше й ламається телевізійна версія.
Часті технічні питання перед стартом проєкту
Телевізійна збірка — окрема гілка інтерфейсу: пульт дає лише напрямки, вибір і повернення, тому навігація будується на фокусі, а не на дотиках. Нижче — сумніви, які найчастіше обговорюємо до старту.
Як додаток керується одним пультом?
Позиція фокуса відновлюється після підвантаження списку, утримання кнопки прискорює прокручування, а кожен сценарій закривається за кінцеву кількість натискань. Окремо перевіряємо поведінку на пультах різних виробників і при введенні тексту.
Що станеться з уже випущеним додатком для телефонів?
Спільний шар авторизації та роботи з даними, роздільні інтерфейсні гілки. Телевізійна збірка випускається своїм циклом і не зсуває мобільні релізи.
Чи можна змінювати інтерфейс без повторної перевірки збірки?
Так: головна та розділи описуються керованою конфігурацією, яку додаток забирає при старті. Порядок блоків, тексти й добірки змінюються без нової публікації — перевірку проходить лише збірка.
Що відбувається за слабкої мережі?
Каталог і останні стани кешуються локально, навігація залишається відзивчивою. Відтворення при просіданні переходить на нижчий профіль якості, а запити повторюються з наростальною паузою.
Як підтримується додаток після оновлення системи?
Тримаємо матрицю перевірок на актуальних гілках прошивок і цільові збірки під різні сімейства пристроїв. Якщо платформа змінює поведінку, випускаємо сумісне оновлення.
Обговоримо задачу та повернемося з оцінкою і планом
Щоб оцінка строків збірки додатка на Android TV була реалістичною, а не «плюс-мінус квартал», потрібен мінімум вхідних даних. Чим конкретніший стартовий опис, тим менше припущень у плані робіт із телевізійного додатка і тим точніше ми називаємо склад команди.
- Сценарії перегляду. Прямий ефір, архів, підписки, продовження з місця зупинки, кілька профілів в одній квартирі — кожен сценарій змінює архітектуру плеєра та логіку зберігання станів.
- Список цільових пристроїв. Моделі телевізорів і приставок, версії системи, пульти з голосовим пошуком і без. Навігація, яка працює на одному пристрої, ламається на іншому, — це закладаємо в перевірки заздалегідь.
- Доступи до поточної збірки. Репозиторій, ключі підпису, консоль розробника, тестові облікові записи. Почати з робочого коду швидше, ніж відновлювати контекст за розповідями.
- Обмеження за строками запуску. Прив'язка до виходу контенту або вимоги партнера задає порядок етапів: спочатку каркас і навігація, потім плеєр, потім доопрацювання.
- Відповідальний за приймання. Хто приймає результат, у якому вигляді фіксує зауваження і за якими критеріями вважає задачу закритою.
- Поточний зворотний зв'язок. Що вже ламається у глядачів: зависання при перемиканні, втрата позиції, повільний старт — перші кандидати в план.
Після цього повертаємося з оцінкою строків збірки, складом команди та планом робіт із телевізійного додатка, окремо проговорюємо передачу проєкту: документацію, доступи та порядок підтримки після запуску. Опишіть задачу у вільній формі — цього достатньо, щоб обговорити її предметно.
