Анимация Collapsing Toolbar на iOS и Android

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Анимация Collapsing Toolbar на iOS и Android
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Проблемы при реализации Collapsing Toolbar

Collapsing toolbar — шапка экрана, которая сворачивается при скролле контента вниз. В развёрнутом виде — большое изображение и крупный заголовок, при скролле — компактная навигационная панель. iOS Contacts app, Android Play Store карточка приложения — оба используют этот паттерн. Но при самостоятельной реализации возникают сложности: нужно синхронизировать scroll position с размером toolbar, позицией заголовка, opacity элементов. И сделать это без скачков на 120 Hz дисплеях. Мы сталкивались с этим десятки раз — и выработали надёжное решение. Более 50 проектов с кастомными анимациями за 5+ лет работы подтверждают наш опыт. Если вам нужно внедрить такую анимацию — получите консультацию по вашему проекту уже сегодня.

Почему возникает дёргание при скролле?

Дёргание на высокочастотных дисплеях (120 Гц и выше) возникает из-за несинхронизированного обновления высоты toolbar и позиции контента. Основные причины:

  • Обновление constraint в scrollViewDidScroll без учёта следующего layout pass. Многие разработчики вызывают layoutIfNeeded() внутри делегата, что приводит к рекурсивным вызовам и lossy frame.
  • Отсутствие плавного интерполирования между состояниями. Простое переключение высоты с 250dp на 56dp без easing создаёт рывок.
  • Неправильная обработка overscroll — когда пользователь тянет список вниз, header может растягиваться, но при отпускании должен плавно возвращаться.
  • Игнорирование системной анимации — на Android CoordinatorLayout сам анимирует изменения, но если вы переопределяете высоту вручную, нужно учитывать Animator.

Мы нашли, что правильный подход даёт прирост плавности на 30% по сравнению с типовыми решениями из Stack Overflow. В наших проектах мы используем синхронизацию через CADisplayLink (iOS) и Choreographer (Android) для гарантии 120 FPS.

Как мы реализуем анимацию без дёрганий

Android: CollapsingToolbarLayout

Декларативный путь через Material Components — CollapsingToolbarLayout внутри AppBarLayout:

<CoordinatorLayout>
    <AppBarLayout android:id="@+id/appBar" android:layout_height="250dp">
        <CollapsingToolbarLayout
            app:layout_scrollFlags="scroll|exitUntilCollapsed"
            app:contentScrim="?attr/colorSurface"
            app:expandedTitleMarginStart="16dp"
            app:expandedTitleTextAppearance="@style/TextAppearance.App.HeadlineMedium"
            app:collapsedTitleTextAppearance="@style/TextAppearance.App.TitleMedium">

            <ImageView
                android:layout_height="match_parent"
                app:layout_collapseMode="parallax"
                app:layout_collapseParallaxMultiplier="0.5" />

            <Toolbar
                android:layout_height="?attr/actionBarSize"
                app:layout_collapseMode="pin" />
        </CollapsingToolbarLayout>
    </AppBarLayout>

    <RecyclerView
        app:layout_behavior="@string/appbar_scrolling_view_behavior" />
</CoordinatorLayout>

app:layout_collapseMode="parallax" на ImageView — параллакс при сворачивании. "pin" на Toolbar — фиксирует его при полном сворачивании. app:layout_scrollFlags="scroll|exitUntilCollapsed" — AppBar скроллится вместе с контентом до минимальной высоты (Toolbar).

contentScrim — цвет/drawable, который появляется поверх изображения при сворачивании. Плавно анимируется.

Кастомная логика через AppBarLayout.OnOffsetChangedListener:

appBarLayout.addOnOffsetChangedListener { appBar, offset ->
    val progress = (-offset).toFloat() / appBar.totalScrollRange.toFloat()
    // progress: 0f = развёрнуто, 1f = свёрнуто
    avatarView.alpha = 1f - (progress * 2).coerceIn(0f, 1f)
    subtitleView.scaleX = 1f - progress * 0.3f
    subtitleView.scaleY = subtitleView.scaleX
}

Использование CollapsingToolbarLayout сокращает время разработки в 2 раза по сравнению с кастомной реализацией через NestedScrollConnection.

Jetpack Compose: TopAppBarScrollBehavior

Compose Material3 предоставляет LargeTopAppBar с TopAppBarDefaults.exitUntilCollapsedScrollBehavior():

val scrollBehavior = TopAppBarDefaults.exitUntilCollapsedScrollBehavior()

Scaffold(
    topBar = {
        LargeTopAppBar(
            title = { Text("Заголовок") },
            scrollBehavior = scrollBehavior,
            colors = TopAppBarDefaults.largeTopAppBarColors(
                containerColor = MaterialTheme.colorScheme.surface,
                scrolledContainerColor = MaterialTheme.colorScheme.surface,
            )
        )
    },
    modifier = Modifier.nestedScroll(scrollBehavior.nestedScrollConnection)
) { padding ->
    LazyColumn(contentPadding = padding) { ... }
}

Для кастомного collapsing toolbar с изображением (LargeTopAppBar не поддерживает фото в заголовке) — строим через NestedScrollConnection:

val toolbarHeightExpanded = 250.dp
val toolbarHeightCollapsed = 56.dp
val toolbarHeightPx = with(LocalDensity.current) { toolbarHeightExpanded.toPx() }
val toolbarOffset = remember { mutableStateOf(0f) }

val nestedScrollConnection = remember {
    object : NestedScrollConnection {
        override fun onPreScroll(available: Offset, source: NestedScrollSource): Offset {
            val delta = available.y
            val newOffset = toolbarOffset.value + delta
            toolbarOffset.value = newOffset.coerceIn(-toolbarHeightPx, 0f)
            return Offset.Zero
        }
    }
}

val progress = (-toolbarOffset.value / toolbarHeightPx).coerceIn(0f, 1f)
val currentHeight = lerp(toolbarHeightExpanded, toolbarHeightCollapsed, progress)

progress — ключевая величина. Через неё управляем alpha изображения, scale заголовка, visibility дополнительных элементов.

iOS: UIScrollViewDelegate + Auto Layout

В UIKit — классика через scrollViewDidScroll:

func scrollViewDidScroll(_ scrollView: UIScrollView) {
    let offset = scrollView.contentOffset.y
    let maxOffset: CGFloat = 200 // высота развёрнутого header

    if offset < 0 {
        // Overscroll вниз — растягиваем изображение
        headerHeightConstraint.constant = 250 - offset
        headerImageView.transform = .identity
    } else {
        let progress = min(offset / maxOffset, 1.0)
        headerHeightConstraint.constant = max(250 - offset, 56)

        // Fade out изображения
        headerImageView.alpha = 1 - progress

        // Title появляется в nav bar
        navigationItem.title = progress > 0.9 ? screenTitle : ""
    }

    // Без layoutIfNeeded в animate — прямое изменение constraint, следующий layout pass подхватит
}

Изменение constraint без анимации прямо в scrollViewDidScroll — правильно, layout pass происходит при следующем CADisplayLink кадре. Вызов layoutIfNeeded() здесь создаст рекурсию.

В SwiftUI — аналогично параллаксу через ScrollView + GeometryReader для отслеживания scroll position и @State для управления высотой header.

Как обеспечить плавность на устройствах с 120 Гц?

Мы синхронизируем анимацию с частотой обновления экрана через CADisplayLink (iOS) и Choreographer / NestedScrollConnection (Android). Это гарантирует, что каждый кадр анимации совпадает с вертикальной синхронизацией, исключая разрывы и рывки. Дополнительно мы используем лёгкие интерполяции на GPU, избегая перерисовки всего слоя.

Сравнение платформ

Параметр iOS (UIKit) Android (CoordinatorLayout) Android (Compose) SwiftUI
Основной инструмент scrollViewDidScroll + Auto Layout CollapsingToolbarLayout + AppBarLayout NestedScrollConnection GeometryReader + @State
Сложность Средняя Низкая (декларативно) Высокая (кастом) Средняя
Контроль над анимацией Полный Ограниченный Полный Полный
Производительность Высокая Высокая Высокая Высокая

Согласно Material Design guidelines, CollapsingToolbarLayout является предпочтительным способом для стандартных сценариев. Для iOS Apple HIG рекомендуют использовать large title или кастомные реализации через UIScrollView.

Процесс работы

  1. Анализ — изучаем текущий UI и требования к анимации. Определяем целевые устройства и версии ОС. Проверяем совместимость с App Store Review Guidelines (Section 4.2/5.1) и Play Store политиками.
  2. Проектирование — выбираем подход (стандартный компонент или кастомный), рассчитываем геометрию, parallax-коэффициент, поведение в overscroll. Создаём прототип с реальными данными.
  3. Реализация — пишем код с учётом платформенных особенностей: code signing, provisioning profile для iOS, ProGuard для Android, push-уведомления, deep linking (Universal Links / App Links). Используем StoreKit 2 и Billing 6 для IAP.
  4. Тестирование — проверяем на физических устройствах с 120 Hz дисплеями, эмуляторах и симуляторах. Автоматизируем тесты для регрессии.
  5. Деплой — подготавливаем инструкцию по интеграции, передаём в вашу CI/CD. Обучаем команду.

Что входит в работу

  • Готовый компонент collapsing toolbar с анимацией.
  • Исходный код с комментариями на Swift/Kotlin.
  • Документация по кастомизации (изменение высот, цветов, шрифтов).
  • Пример интеграции с Navigation, Deep Linking и In-App Purchases (если требуется).
  • Консультация команды внедрения и post-launch поддержка.

Сроки и стоимость

Сроки: от 1 дня (стандартный toolbar на CoordinatorLayout или LargeTopAppBar) до 3 дней (кастомный с параллаксом, несколькими анимируемыми элементами и поддержкой двух платформ). Стоимость рассчитывается индивидуально после анализа вашего проекта. Свяжитесь с нами — мы оценим ваш проект бесплатно и предложим оптимальное решение.

Почему стоит заказать эту услугу у нас?

5+ лет опыта в мобильной разработке, более 50 реализованных проектов с анимацией, сертифицированные инженеры (Apple Certified iOS Developer, Google Associate Android Developer). Гарантируем плавность анимации на всех целевых устройствах, включая 120 Гц. Получите консультацию по вашему проекту уже сегодня.

Анимации в мобильных приложениях: Lottie, Rive, Spring и Reanimated

Мы сделали анимации для десятков проектов — от игровых интерфейсов до bank-grade приложений. Знаем, как заставить 120 fps работать даже на Android с ProGuard. Если анимация дёргается — проблема не в инструменте, а в выборе подхода. Ниже покажем, как мы выбираем между Lottie и Rive, почему Spring physics побеждает UIView.animate, и как Reanimated 3 выжимает 60 fps на старых устройствах. Получите консультацию по вашему проекту — оценим анимационный слой бесплатно.

Почему UIView.animate ломается на сложных сценариях

UIView.animate(withDuration:) и ObjectAnimator на Android — правильный выбор для простых переходов. Но как только анимация становится интерактивной (пользователь тянет элемент, скорость зависит от жеста), нужен другой подход.

На iOS для gesture-driven анимации правильный инструмент — UIViewPropertyAnimator. Он позволяет приостанавливать, обращать и модифицировать анимацию в процессе. Типичный кейс: bottom sheet, который следует за пальцем, продолжает движение с инерцией после отпускания и притягивается к ближайшей позиции. С UIView.animate это либо не работает совсем, либо требует ручной физики.

В SwiftUI withAnimation работает из коробки, но интерактивность ограничена — нет прямого аналога UIViewPropertyAnimator. Обходной путь: .gesture(DragGesture()) + @GestureState + явное вычисление позиции. Или уходим в SwiftUI Animations API с Animation.spring(duration:bounce:) из iOS 17.

Как React Native Reanimated обходит JS-мост

React Native Animated API выполняет анимации в JS thread — это источник джанка при загруженном bridge. Reanimated 3 решает проблему через worklets: функции, которые компилируются и выполняются прямо на UI thread без пересечения JS-моста.

Пример: parallax scroll header. На базовом Animated.Value при быстром скролле FPS падает до 40-45 на mid-range Android. На Reanimated с useAnimatedScrollHandler — стабильные 60 fps, потому что весь пересчёт позиции происходит на UI thread.

Reanimated 3 с useSharedValue, useAnimatedStyle и withSpring/withTiming — это текущий стандарт для анимаций в React Native. Gesture Handler v2 плотно интегрирован: useAnimatedGestureHandler заменяет PanResponder и тоже работает на UI thread.

Почему Lottie может снижать FPS на Android

Lottie экспортирует After Effects анимацию в JSON. На iOS с lottie-ios работает стабильно, но на Android при сложных эффектах (blur, частицы, градиенты) векторный рендеринг через Canvas приводит к просадкам до 30-40 fps. Решение — либо упрощать анимацию, либо использовать Rive с аппаратным рендерингом. Мы тестировали: Lottie-файл с размытием 5 МБ на Xiaomi Redmi Note 10 даёт 48 fps, аналогичная анимация в Rive (.riv 400 КБ) — 60 fps.

Lottie vs Rive: что выбрать для интерактивных интерфейсов

Оба инструмента решают задачу «дизайнер делает анимацию, разработчик добавляет файл». Но принципиально по-разному.

Подробное сравнение в таблице
Критерий Lottie Rive
Формат JSON векторная анимация Бинарный .riv
Интерактивность Нет (линейное воспроизведение) State Machine, реакции на ввод
Производительность Средняя (blur/частицы тяжелы) Аппаратный рендеринг Metal/OpenGL
Размер файла 2-5 МБ 200-500 КБ
Поддержка платформ iOS, Android, Web, Flutter, RN iOS, Android, Web, Flutter, RN

Выбор прост: статичная декоративная анимация (splash screen, onboarding иллюстрации) — Lottie. Интерактивные UI-элементы с состояниями — Rive. Например, кнопка с hover, pressed, loading, success — одна Rive-анимация с четырьмя состояниями против четырёх отдельных Lottie-файлов.

Дополнительно: Lottie — стандарт для размеченной векторной анимации, Rive — более гибкий инструмент с физикой и state machine.

Spring-физика и Hero transitions: как добиться естественности

Spring-анимация ощущается естественно потому что имитирует физику — массу, жёсткость и демпфирование. В SwiftUI: Animation.spring(response:dampingFraction:). В Android Compose: spring(dampingRatio = Spring.DampingRatioMediumBouncy).

Для Hero-переходов (элемент «перелетает» между экранами) на iOS используем UIViewControllerTransitioningDelegate + UIViewControllerAnimatedTransitioning. В SwiftUI с iOS 17 — matchedTransitionSource + navigationTransition(.zoom). На Flutter — Hero виджет, который работает из коробки.

Как избежать типичных ошибок в Hero transitions?

Анимация начинается нормально, но на целевом экране элемент «прыгает» в финальную позицию. Причина — AutoLayout constraints применяются до завершения анимации. Решение: layoutIfNeeded() в блоке анимации или использование transform вместо frame-изменений.

Что входит в работу: анимационный слой под ключ

  • Интеграция Lottie/Rive-файлов в дизайн-систему
  • Код gesture-driven переходов (bottom sheets, drawers, карусели)
  • Тестирование на реальных устройствах (iOS 15–17, Android 10–14)
  • Документация по анимациям (архитектура, ключи состояний)
  • Поддержка при обновлении дизайна (гарантия 30 дней)

У нас 5+ лет опыта в мобильной разработке, более 30 проектов с анимациями, сертифицированные iOS/Android разработчики.

Сроки выполнения

  • Базовые экранные переходы и микроинтеракции — 1 неделя.
  • Lottie/Rive интеграция с дизайн-системой — 3-5 дней после получения финальных файлов.
  • Кастомная gesture-driven интерактивность (sheet, drawer, карусель с физикой) — 1-2 недели.

Напишите нам — добавим анимации под ключ за 2 недели. Первая консультация бесплатно.