Краткий ответ

Аннотация @MainActor на протоколе изолирует его требования главным актором. Вызов такого требования из фоновой конкурентной задачи требует асинхронного перехода на MainActor, обычно выраженного через await.

Изоляция относится к контракту протокола, поэтому она сохраняется при обращении к объекту через тип протокола, даже если конкретный тип реализации явно не выглядит изолированным.

Исторический контекст

До появления модели акторов разработчики часто вручную следили за тем, чтобы операции с пользовательским интерфейсом выполнялись на главном потоке. Такой подход зависел от дисциплины команды и легко нарушался при добавлении фоновых операций или новых реализаций протокола.

Глобальные акторы, включая MainActor, позволяют выразить это требование в типовой системе Swift. Протокол при этом описывает не только набор методов, но и допустимый контекст их выполнения.

Постановка проблемы

Предположим, протокол описывает обновление интерфейса, а его реализация вызывается из фоновой задачи. Если контракт не содержит сведения о главном акторе, компилятор не может надёжно проверить, что вызов UI выполняется в правильном контексте.

Ошибочный прямой вызов может привести к нарушению требований UI-фреймворка. Простое добавление await без понимания изоляции также недостаточно: переход должен быть связан именно с изолированным требованием, а не с любым синхронным методом.

Подробное решение

Требования протокола, помеченного @MainActor, считаются изолированными главным актором. Поэтому вызывающий код из другого контекста должен перейти на MainActor, а вызывающий код, уже находящийся на MainActor, может обратиться к требованию без межакторного перехода.

@MainActor
protocol ScreenRendering {
    func render()
}

@MainActor
final class Screen: ScreenRendering {
    func render() { }
}

func refresh(_ screen: any ScreenRendering) async {
    await screen.render()
}

Здесь refresh не изолирована главным актором, поэтому вызов render требует await. await обозначает возможную приостановку перед переходом к MainActor; он не означает, что метод обязательно создаёт новую задачу или выполняется на отдельном потоке.

Реализация требования должна быть совместима с изоляцией контракта. На практике чаще всего изолируют весь реализующий тип или конкретный метод, чтобы его состояние и операции с UI имели единый контекст доступа.

Важно отличать требования протокола от дополнительных методов конкретного типа. Аннотация протокола задаёт изоляцию объявленных в нём требований, но сама по себе не превращает любой произвольный метод реализации в метод MainActor.

Такой дизайн уменьшает число ручных переходов к UI и позволяет компилятору обнаруживать часть ошибок на этапе проверки конкурентности. Компромисс состоит в том, что любой код, вызывающий эти требования из фонового контекста, должен учитывать возможную приостановку и не удерживать во время неё синхронные блокировки.

Ситуация из практики

В приложении был протокол ViewRenderer, который реализовывали несколько экранов. Фоновый загрузчик данных вызывал render напрямую после получения результата. Вариант с ручным вызовом MainActor.run в каждом месте работал, но дублировал переходы и позволял забыть его в новой реализации.

Вариант с аннотацией только отдельных классов защищал существующие экраны, но не гарантировал правильный контекст через сам тип протокола. Выбранное решение — пометить протокол @MainActor, а фоновые операции оставить не изолированными.

После этого контракт явно зафиксировал UI-ограничение: фоновой задаче требовался await при вызове рендера, а компилятор проверял корректность межакторного доступа. Загрузка данных осталась фоновой, а короткая операция обновления интерфейса выполнялась на MainActor.

Что кандидаты часто упускают

Означает ли @MainActor на протоколе, что сама фоновая задача целиком перейдёт на MainActor?

Нет. Изолированными становятся требования протокола и операции, связанные с ними. Фоновая задача остаётся в своём контексте до момента вызова такого требования; затем Swift организует необходимый переход на MainActor.

Это важно для производительности: тяжёлую обработку данных не следует помещать в реализацию требования только потому, что оно изолировано главным актором. Обычно данные подготавливают заранее, а на MainActor выполняют только короткое обновление UI.

Можно ли обращаться к @MainActor-требованию без await, если метод реализации синхронный?

Синхронность реализации не отменяет изоляцию. Из не изолированного контекста вызов всё равно пересекает границу MainActor и должен быть оформлен как потенциально приостанавливающийся.

Без await допустим вызов из контекста, который уже изолирован MainActor, например из другого метода @MainActor. Там переход не требуется, поскольку код уже выполняется в нужной изоляции.

Что произойдёт, если конкретный тип реализует @MainActor-протокол, но сам тип не помечен @MainActor?

Реализация должна удовлетворять изолированному требованию протокола. В зависимости от формы типа и версии Swift это может потребовать изоляции конкретного метода или привести к диагностике о несовместимости изоляции; рассчитывать на автоматическое безопасное наследование изоляции для всего типа не следует.

Надёжный практический вариант — явно пометить реализующий тип или соответствующие методы @MainActor. Это делает намерение очевидным, защищает доступ к связанному состоянию и уменьшает зависимость от тонкостей вывода изоляции компилятором.