Jetpack Compose Battle: Онлайн-собеседования Senior разработчика / Мобильный разработчик

• Алексей Гладков приветствует зрителей и просит проверить звук и видео.  

• Представляет двух участников: Алексея Панова и Никиту Куликова.  

• Алексей Панов рассказывает о своем опыте работы с Compose и формате собеседования.  

• Алексей Панов объясняет, что Compose - это фреймворк для создания интерфейсов.  

• Compose позволяет описывать интерфейсы декларативным стилем программирования.  

• Compose подходит для различных платформ, включая Android, iOS, десктоп и веб.  

• Compose состоит из нескольких частей: рантайм, аннотации, базовые библиотеки.  

• Композитные функции помечены аннотацией @Compose и требуют контекста компоузера.  

• Контекст компоузера позволяет управлять рендерингом и запоминать позиции.  

• Группы в Compose позволяют повторно использовать вычисления.  

• Группы создаются с помощью уникальных идентификаторов и могут быть переиспользованы в разных частях приложения.  

• Группы работают за линейное время и используют структуру данных, похожую на стек и хэшмапу.  

• Удаление группы данных может быть нелинейным процессом.  

• Большинство операций выполняются за один проход.  

• Переорганизация структуры данных требует линейной сложности.  

• Компоновка функций оставляет "отпечатки" на экране пользователя.  

• Компоузер получает доступ к экрану и рисует элементы.  

• В Android есть суперклассы для вьюшек, в Compose такого нет.  

• Компоновка имеет фазы: измерение, отрисовка, применение модификаторов.  

• Модификаторы меняют порядок отрисовки элементов.  

• Компоновка создается через сет-контент и инициализацию компоузера.  

• Sub-Composition создает отдельный контекст компоузера.  

• Используется для обхода багов и улучшения производительности.  

• В обычном случае инициализируется контекст компоузера в фрагменте или вьюшке.  

• Компоузер понимает, какие части экрана нужно перерисовывать.  

• Используются флаги для определения изменений параметров.  

• Оптимизации позволяют не перерисовывать весь экран при изменении параметров.  

• Компоузер проверяет, изменились ли параметры.  

• Стейбл объекты позволяют избежать ненужных проверок при рекомпозиции.  

• Использование стейбл объектов улучшает производительность и оптимизирует дерево компоновки.  

• Комбайлер помечает стабильные классы, которые не имеют изменяемых элементов.  

• Использование обычных списков в композите не рекомендуется.  

• Рекомендуется использовать правильные коллекции для композа.  

• Оба аннотации являются маркерами стабильности.  

• @Immutable гарантирует, что никакие поля структуры не изменяются.  

• Технически разницы между ними нет, это задел на будущее.  

• MutableState позволяет изменять состояние и уведомлять о необходимости рекомпозиции.  

• Композер подписывается на изменения состояния через делегат.  

• Можно вызвать рекомпозицию вручную через контент-провайдер.  

• MutableState откладывает изменения до следующей композиции.  

• Это предотвращает проблемы с изменением параметров во время рекомпозиции.  

• Механизм работает через сохранение всех параметров и их применение разом.  

• MutableState не обладает атомарностью, что может привести к проблемам.  

• Запись в MutableState не является томарной операцией.  

• Для решения проблемы можно добавлять изменения только при рекомпозиции.  

• Обсуждение вопросов о рисовании композа на экране и мультиплеформенности.  

• Планируется доклад о рисовании композа на iOS.  

• Вопросы о первой фазе композиции и её реализации.  

• Экран с контактами, которые можно выбрать и изменить их фон.  

• Проблемы с компоновкой функций и их нестабильность.  

• Задача: найти и объяснить проблемы в коде.  

• Создание объектов в композиции.  

• Использование immutable list вместо list.  

• Проблемы с лямбдами и их нестабильность в композиции.  

• Композиция может запоминать лямбды, но это не всегда так.  

• Лямбды могут создавать новые объекты при каждой рекомпозиции.  

• Лучше оборачивать лямбды в mutable для стабильности.  

• Передача функций без создания новых объектов.  

• Использование модификаторов для гибкости компонентов.  

• Проблемы с типографиями и локальными стилями.  

• Различие между статическими и обычными композиционными локалями.  

• Проблемы с созданием своих локалей и их использованием.  

• Неявное поведение и проблемы с контекстом.  

• Сортировка контактов при каждой рекомпозиции.  

• Проблемы с изменением фона и рекомпозицией.  

• Использование делегатов и их влияние на рекомпозицию.  

• Проблемы с жизненным циклом и использованием локалей.  

• Использование диспетчера для управления состоянием.  

• Проблемы с рекомпозицией и выполнением в главном потоке.  

• Анимации выполняются на мейн-потоке, а не на условном диспетчере композиции.  

• Монотонный фрейм клок инициализируется в начальной композиции и синхронизирует кадры анимации.  

• Без монотонного фрейм клока анимация может быть рваной.  

• LazyCol уничтожает элементы, которые не на экране, что экономит ресурсы.  

• Когда элементов мало, лучше использовать обычный Col, чтобы избежать ресурсоемких операций.  

• При изменении контактов все элементы перерисовываются, что может быть неэффективно.  

• Использование одинаковых ключей для элементов может привести к ошибкам.  

• Компоузер не может преобразовать лямбду в стейбл, что может вызвать проблемы.  

• Оптимизация лямбды в мембер может улучшить производительность.  

• Модификаторы могут влиять на рендеринг элементов за пределами их бокса.  

• Использование бокса вместо колом может улучшить визуализацию элементов.  

• Вертикальный скролл может занимать все пространство экрана, что может скрыть элементы.  

• Оптимизация компоновки элементов может улучшить производительность.  

• Использование скрол стейта может вызывать рекомпозицию при каждом изменении.  

• Оптимизация может предотвратить ненужные рекомпозиции и улучшить производительность.  

• Функция вызывается часто при скролле, что приводит к частой рекомпозиции.  

• Использование функции stateOf могло бы уменьшить количество вызовов рекомпозиции.  

• StateOf позволяет создавать мутабельные состояния, которые не вызывают рекомпозицию при изменении.  

• Изменение бэкграунда требует перерендеринга всех элементов, зависящих от него.  

• Использование модификатора дроуби хайн для оптимизации отрисовки бэкграунда.  

• Применение фазы яута для изменения положения вьюшек.  

• SiteEffect вызывается только один раз при первой отрисовке.  

• LaunchEffect выполняется при запуске и отображает код, указанный в эффекте.  

• LaunchEffect создает контекст и выполняется до момента инвалидации или удаления с экрана.  

• Собеседование прошло успешно, обсуждались многие аспекты Compose.  

• Вопросы касались отрисовки, стейтов, снапшотов и оптимизации.  

• Обсуждались мелкие детали пользовательского интерфейса и использование аниме презибилити.  

• Вопросы касались процесса отрисовки и работы Compose.  

• Обсуждение снапшотов и их использования в Compose.  

• Вопросы о подписке на изменения стейтов и их реализации в Compose.  

• Подписка на обновления стейта происходит во время чтения стейта, а не создания.  

• Снэпшот содержит значения стейта и мерш полюса.  

• Компоузер ищет ключевые слова и методы для стейта и создает обертку вокруг него.  

• Снэпшоты позволяют сохранять изменения глобального состояния.  

• Иерархия снапшотов применяется постепенно, от локального к глобальному.  

• Глобальный снапшот называется экстенд и вызывает рекомпозицию.  

• Подписка на обновления происходит во время чтения стейта.  

• Рекомпозиция происходит по команде хореографа, а не в случайное время.  

• Рекомпозиция важна для анимации, чтобы экран обновлялся по кадрам.  

• Вопросы о различиях между персистентным и мьютексным листом.  

• Обсуждение создания вью-моделей в Android и мультиплатформенной среде.  

• Рекомендация использовать коллект стейт для подписки в Android.  

• Благодарность пользователю за поддержку канала.  

• Анонс будущих собеседований и приглашение к участию.  

• Напоминание о важности подготовки к сложным вопросам на собеседованиях.