Инженеры Яндекс Еды опубликовали детальный разбор того, как разработка медиаленты в мобильном приложении превратилась в один из самых технически насыщенных проектов за последние годы. То, что на этапе планирования выглядело как «ещё один список с видео», обернулось полноценной инженерной битвой с фризами, чёрными экранами и памятью, которая утекала на глазах.
Простая задача с неожиданным характером
Всё начиналось предсказуемо. Продуктовая гипотеза была чёткой: пользователи Яндекс Еды нередко не знают, куда именно хотят пойти - они ищут вдохновение. Короткие видео, редакционные подборки, тематические рекомендации прямо в ленте могли бы помочь с выбором ресторана быстрее и эффективнее, чем статичные карточки. Решение казалось логичным. Реализация - посильной. смотреть Англия - Гана на RUTUBE Спорт
Но за фасадом привычного интерфейса скрывалась система, которая одновременно затрагивала несколько тяжёлых доменов: сетевые ограничения, декодирование медиа, управление памятью, жизненный цикл вложенных контейнеров и динамически собираемый UI. Медиалента встраивалась не в отдельный экран, а сразу в два BDUI-экрана - и каждый был построен на своей архитектуре. Рядом жили тяжёлые изображения, карусели, карты и сложные layout-деревья, которые команда не контролировала напрямую.
Архитектура, которая затрещала под нагрузкой
Первоначальный подход был классическим: ограниченный пул плееров, предзагрузка соседних роликов, автоплей по видимости. Каждая карточка - независимая, жизненный цикл - свой. На бумаге это работало. На реальных данных - нет.
Проблемы не заставили себя ждать. Фризы при скролле, нестабильный автоплей, рост потребления памяти на длинных сессиях, нагрев устройства. Хуже всего вели себя падения, которые воспроизводились только на части устройств и только в условиях реального использования - эмулятор их попросту не замечал. Именно такие баги съедают больше всего времени.
- Глубокая вложенность UIViewController и UIHostingController создавала лишний оверхед на каждом уровне
- Одновременный автоплей нескольких видео вызывал конкуренцию за аппаратные декодеры
- Непредсказуемое окружение BDUI усложняло управление ресурсами
- Высокий трафик на основном пользовательском сценарии исключал право на ошибку
Observability как отдельная задача
Команда быстро поняла: без инструментов наблюдения за системой в продакшене двигаться дальше бессмысленно. Красивая реализация без возможности дебага в реальных условиях - это иллюзия контроля. Поэтому отдельным направлением стало построение observability: метрики, трассировка состояний плееров, контроль памяти в длинных списках.
Параллельно пересматривалась ресурсная политика. Воспроизводить все видео в зоне видимости - продуктово логично, инженерно - дорого. Пришлось искать компромисс между UX-требованием к мгновенному старту и реальными ограничениями железа. Победила не красивая реализация, а предсказуемая и управляемая. Именно такой подход в итоге оказался эффективнее - и именно он позволил медиаленте стабильно работать на массовом сценарии, где любая ошибка немедленно масштабируется на миллионы сессий.
