Нетривиальные анимации в мире iOS-разработки

В мире мобильной разработки мы постоянно анимируем: двигаем объекты, меняем их размер, прозрачность и так далее. Для простых случаев есть UIView.animate и CABasicAnimation — этого более чем достаточно. Но для сложных задач этого бывает мало.

Представьте: у вас есть карта, и нужно сделать сложную цепочку анимаций — сначала zoom out на 5%, затем zoom in на 10%, одновременно:

• по нелинейной траектории появляется круг,

• он увеличивается, двигается с ускорением и замедлением,

• становится прозрачным,

• сквозь него проявляется экран с постом,

• который разворачивается на весь экран.

Первая идея — использовать Timer и обновлять все параметры раз в 1/60 секунды:

var startTime = CACurrentMediaTime()let duration = 0.4timer = Timer.scheduledTimer(withTimeInterval: 1.0 / 60.0, repeats: true) { [weak self] timer in    guard let self else { return }    let progress = min((CACurrentMediaTime() - startTime) / duration, 1)    self.topConstraint.constant = 200 * CGFloat(progress)    self.view.layoutIfNeeded() // пересчёт всей системы констрейнтов 60 раз в секунду    if progress >= 1 { timer.invalidate() }}

Но тут будет проблема:

• Все расчёты идут по сути на CPU, а не на GPU.

• При layoutIfNeeded() каждый кадр пересчитывается вся система constraints — это дорого, так как происходит решение системы линейных уравнений.

• Если устройство под нагрузкой, анимация рвётся, и FPS падает с 60 до 10–20 — а мы всё ещё делаем вычисления 60 раз в секунду. Timer не знает про реальную частоту обновления экрана и просто молотит вхолостую.

И вот тут спасает CADisplayLink — таймер, синхронизированный с реальным обновлением экрана. Он срабатывает ровно тогда, когда экран готов принять новый кадр. Никаких лишних расчётов, только актуальные кадры, как бы ни менялась частота обновления (120 Гц на ProMotion, 60 Гц или просадка под нагрузкой — CADisplayLink подстроится сам).

9 лет назад я столкнулся с этой проблемой, создавая:

• анимацию концентрических мигающих кругов;

• сложную карту с zoom и движением по кривой Безье, как описал выше.

Тогда я написал свой DisplayLinkAnimator — класс, который позволяет управлять сложными кастомными анимациями точно и эффективно.

Какую ещё проблему он решает

Хорош он тем ещё, что решает следующую проблему: иногда требуется сделать параллельно анимацию двух объектов. Но если делать анимацию стандартными средствами — несмотря на то, что это может быть просто изменением значений NSLayoutConstraint — у анимации происходит рассинхрон. Например, между двумя view, которые должны меняться согласованно, появляется расстояние, или же одна наезжает на другую. Притом анимация самая простая, но из-за особенностей работы keyframe-анимаций эта проблема не решается.

И тут помогает DisplayLinkAnimator: с помощью него каждое изменение NSLayoutConstraint приводит к их точному изменению, и все позиции и размеры всех view строго согласованы — потому что в каждом кадре вы сами считаете все значения от одного и того же progress.

Как устроено ядро

Идея простая: на старте запоминаем CACurrentMediaTime(), на каждый тик CADisplayLink считаем progress = elapsed / duration, прогоняем его через timing-функцию и отдаём наружу в колбэк. Вот сердцевина класса:

open class VoDisplayLinkAnimator {    private var displayLink: CADisplayLink?    private var startTime = 0.0    private var animationDuration = 15.0    public var preferredFramesPerSecond: Int = UIScreen.main.maximumFramesPerSecond {        didSet { displayLink?.preferredFramesPerSecond = preferredFramesPerSecond }    }    private var animation: ((_ x: Double, _ time: Double) -> Void)?    private var timingFunction: ((_ x: Double, _ lastY: Double) -> Double)?    private var completion: ((Bool) -> Void)?    private func startDisplayLink() {        startTime = CACurrentMediaTime()        let displayLink = CADisplayLink(target: self, selector: #selector(displayLinkDidFire))        displayLink.preferredFramesPerSecond = preferredFramesPerSecond        displayLink.add(to: .main, forMode: .common)        self.displayLink = displayLink    }    @objc private func displayLinkDidFire(_ displayLink: CADisplayLink) {        guard !isPaused.value else {            // на паузе «двигаем» точку отсчёта, чтобы elapsed не убегал вперёд            startTime = CACurrentMediaTime() - elapsedTime            return        }        let elapsed = CACurrentMediaTime() - startTime        elapsedTime = elapsed        let progress = elapsed / animationDuration        if elapsed > animationDuration {            publish(progress: 1)   // гарантированно довести до конечного состояния            stopDisplayLink()            return        }        publish(progress: progress)    }    private func publish(progress: Double) {        let timingValue = if let bezierCurve {            bezierCurve.y(of: progress)        } else if let timingFunction {            timingFunction(progress, lastTimingValue)        } else {            progress        }        animation?(elapsedTime, timingValue)    }}

Ключевые моменты:

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

• Когда время вышло, мы принудительно публикуем progress = 1, чтобы анимация всегда заканчивалась в точном конечном состоянии, без «недокрученных» дробных кадров.

• progress (линейное время от 0 до 1) и timingValue (значение после timing-функции) разделены — это и даёт гибкость.

Пример 1. Строго синхронные констрейнты

Та самая проблема рассинхрона. Две view должны двигаться так, чтобы расстояние между ними всегда было ровно 60pt. Считаем оба констрейнта от одного progress:

let animator = VoDisplayLinkAnimator()let startTop: CGFloat = 0let endTop: CGFloat = 200animator.startAnimation(animationDuration: 0.4) { [weak self] progress in    guard let self else { return }    // progress идёт строго от 0 до 1, один и тот же для всех вью в этом кадре    let value = startTop + (endTop - startTop) * CGFloat(progress)    self.firstViewTopConstraint.constant = value    self.secondViewTopConstraint.constant = value + 60 // всегда ровно на 60pt ниже    self.view.layoutIfNeeded()} completion: { finished in    print("animation finished: \(finished)")}

Никакого «расхождения» между вью быть не может в принципе: оба значения — функция одного аргумента.

Пример 2. Кастомная timing-функция

timingFunction принимает линейный x (0…1) и должна вернуть «изиннутое» значение. Например, классический easeInOut:

animator.startAnimation(    animationDuration: 0.6,    animation: { [weak self] easedProgress in        self?.circleWidthConstraint.constant = 200 * CGFloat(easedProgress)        self?.view.layoutIfNeeded()    },    timingFunction: { x, _ in        // ускорение в начале, замедление в конце        x < 0.5 ? 2 * x * x : 1 - pow(-2 * x + 2, 2) / 2    })

Здесь timing-функция — обычное Swift-замыкание, так что вы не ограничены набором стандартных кривых: пружины, отскоки, ступеньки — всё, что выразимо математически.

Пример 3. Произвольная кривая Безье как timing

Стандартный CAMediaTimingFunction ограничен кубической кривой Безье — это всего две контрольные точки. А что, если нужна траектория сложнее, с несколькими «горбами»? В библиотеке есть BezierCurve, который аппроксимирует кривую по произвольному числу контрольных точек (предпросчёт делается на фоне, чтобы не лагать на старте):

animator.startBezierAnimation(    animationDuration: 1.2,    animation: { [weak self] easedProgress in        // easedProgress — это y кривой Безье для текущего x (линейного прогресса)        self?.apply(progress: easedProgress)    },    bezierCurve: {        // сколько угодно контрольных точек — не ограничены двумя, как в CAMediaTimingFunction        BezierCurve(            controlPoints: [                VoPoint(x: 0,    y: 0),                VoPoint(x: 0.2,  y: 0.9),                VoPoint(x: 0.8,  y: 0.1),                VoPoint(x: 1,    y: 1)            ],            pointsCount: 200        )    })

BezierCurve.y(of:) внутри использует бинарный поиск по предпросчитанным точкам и линейную интерполяцию между ними — то есть на каждом кадре это дёшево, вся тяжёлая работа сделана один раз при инициализации.

Пауза и возобновление

Анимацию можно поставить на паузу и продолжить ровно с того же места — внутри просто сдвигается точка отсчёта startTime, так что elapsed не «перепрыгивает»:

animator.togglePauseAnimation() // pause / resume// animator.isAnimationPaused -> Bool// animator.isWorking          -> идёт ли анимация прямо сейчас

А чтобы прервать анимацию досрочно, есть stopAnimation(). Если передать needCompleteAnimationAfterStopping: true в startAnimation, то при остановке состояние будет принудительно доведено до финального (progress = 1).

Пара слов про потокобезопасность

Флаги isPaused / isForceStopped обёрнуты в простой AtomicValue на concurrent-очереди с барьером на запись — CADisplayLink тикает на main, а управлять анимацией могут из другого места, и так мы избегаем гонок:

public final class AtomicValue<T> {    private let accessQueue = DispatchQueue(label: "SynchronizedValueAccess", attributes: .concurrent)    private var _value: T    public init(_ value: T) { self._value = value }    public var value: T {        get {            var currentValue: T?            accessQueue.sync { currentValue = self._value }            return currentValue!        }        set {            accessQueue.async(flags: .barrier) { self._value = newValue }        }    }}

Итог

CADisplayLink — правильный инструмент, когда нужны не «анимируй мне эту view», а точные, синхронные, нелинейные анимации, где вы сами контролируете каждый кадр и каждое значение. DisplayLinkAnimator оборачивает его в удобный API: линейный прогресс, кастомные timing-функции, многоточечные кривые Безье, пауза/возобновление и гарантированное доведение до конечного состояния.

Исходники и пример проекта — на GitHub: github.com/vientooscuro/DisplayLinkAnimator