Instagram Direct объяснила переход на Compose и сокращение кода интерфейса
Совместный кейс Meta и Google от 30 сентября связывает перенос мессенджера с более компактной архитектурой. Опубликованные показатели работы агентов относятся к конкретному проекту и методике команды.
Перенос без внешней смены продукта
Команда Instagram Direct перевела крупную поверхность Android-приложения на Jetpack Compose. В кейсе заявлены уменьшение кода интерфейса наполовину, сокращение времени работы агента на 35%, числа обменов с инженером на 32% и токенных затрат на 33%. Эти величины описывают внутреннюю работу команды, а не независимый сравнительный тест всех UI-фреймворков. Масштаб миграции усложнялся разнообразием состояния: один экран поддерживал более двухсот видов сообщений. Поэтому изменение основы интерфейса нельзя было свести к замене нескольких виджетов.
Почему смешанный код создаёт дополнительные условия
Декларативный Compose строит представление из состояния. Старый View-подход предполагает другой жизненный цикл и обновление объектов интерфейса. Официальная документация Compose допускает совместное использование при постепенном переносе. Однако граница между двумя системами требует аккуратного управления состоянием: одно значение не должно одновременно жить в нескольких несовместимых местах. В кейсе Meta это особенно важно для генерации кода, когда агент может продолжить ближайший видимый шаблон. Проблема относится к организации приложения, а не к обещанию, что один синтаксис автоматически исключает ошибки.
В Compose дорогие вычисления в теле функции могут повторяться при частых обновлениях. Официальное руководство приводит пример сортировки списка и сохранения результата через remember. Для длинной переписки это отдельная стоимость по сравнению с отрисовкой одной строки: одинаковая картинка не означает одинаковое количество работы. Декларативное описание также зависит от идентичности элементов и источника состояния. Поэтому сокращение кода интерфейса и уменьшение работы при каждом кадре возникают через разные механизмы, хотя могут сопровождать одну миграцию.
Производительность проверяли отдельно от объёма кода
Пользователю важно время до взаимодействия, полная загрузка содержимого и плавность прокрутки. В публикации описаны постепенные включения Compose-элементов в RecyclerView и последующая работа с LazyColumn. Общие рекомендации Android по производительности объясняют, почему компактный исходник сам по себе недостаточен: composable-функции могут вызываться часто, дорогие вычисления стоит выносить или запоминать, а элементы длинных списков нуждаются в устойчивой идентичности. Изменение количества строк ничего не говорит о стоимости перерасчёта каждого кадра. Поэтому сравнение должно учитывать конкретный сценарий и сборку приложения.
Что даёт опубликованный разбор
Кейс полезен как описание перехода большой работающей системы, в которой нельзя остановить развитие продукта ради полной переписи. Он показывает необходимость отделять состояние от оболочки списка, оставляя возможность переносить компоненты последовательно. Применимость процентов ограничена выбранными задачами и инфраструктурой Meta. Нельзя подставлять их в смету другого приложения без собственных замеров. Для самого Compose в источниках отдельно описаны Baseline Profiles и правила уменьшения лишней работы при перерисовке. Эти механизмы доступны и без применения агентов: архитектурные изменения, подготовка кода к исполнению и скорость написания исправлений являются разными предметами измерения.
Архитектура и продуктовые измерения
Даже внутри одного мессенджера разные экраны имеют разную нагрузку: пустой диалог, длинная переписка и медиасообщения используют ресурсы неодинаково. Поэтому вывод о производительности требует набора сценариев, а не одного удачного открытия. Отдельно следует интерпретировать токенные затраты: они зависят от объёма контекста и числа попыток агента и не являются измерением времени, которое пользователь проводит в интерфейсе.
