В
SwiftUI постоянно встречаются два похожих, но работающих по-разному подхода:
some View и
AnyView. Для новичка разница незаметна: и там и там возвращается
View. Но для
SwiftUI это две совершенно разные истории, которые влияют на то, как фреймворк будет обновлять интерфейс и потреблять ресурсы.
Что скрывается за some View:
Когда вы объявляете
var body: some View, происходит нечто похожее на контракт с компилятором. Вы обещаете, что свойство будет возвращать значение конкретного типа, соответствующего протоколу
View, но сам тип остается неназванным. Компилятор это устраивает, он самостоятельно определит тип на основе того, что вы написали внутри.
Дальше вступает
SwiftUI. Получив от компилятора точную информацию о типах всех вложенных элементов, фреймворк выстраивает статическое представление интерфейса. Это как если бы
SwiftUI заранее знал полную схему экрана со всеми ячейками, текстами и изображениями. Благодаря этому при изменении данных он может быстро понять, какая именно часть экрана требует перерисовки, и обновить только ее.
Как работает AnyView:
AnyView работает иначе. Он стирает тип и оставляет от конкретной вьюхи только факт, что она соответствует протоколу
View. Для
SwiftUI это означает потерю информации: он больше не знает, что внутри: текст, изображение или целый стек. Все, что остается - черный ящик.
Типичная ситуация, когда хочется использовать
AnyView: возврат разных типов в зависимости от условия:
func content(isLoggedIn: Bool) -> some View {
if isLoggedIn {
return HomeView()
} else {
return LoginView()
}
}
Компилятору это не понравится: типы разные, а
some View требует один конкретный. Самый простой, но неправильный способ починить: обернуть оба варианта в
AnyView. Код скомпилируется, но
SwiftUI потеряет информацию о структуре и не сможет нормально оптимизировать обновления.
Правильный подход - ViewBuilder:
Вместо ручного возврата и стирания типов
SwiftUI предлагает использовать
@ViewBuilder. Этот атрибут превращает набор
View в единое выражение с типом
ConditionalContent:
@ViewBuilder
func content(isLoggedIn: Bool) -> some View {
if isLoggedIn {
HomeView()
} else {
LoginView()
}
}
Тип остается конкретным и известным компилятору, просто он умеет описывать условную структуру. Все преимущества оптимизации сохраняются.
Когда AnyView все-таки нужен:
Есть ситуации, где без стирания типа не обойтись:
- Массив вьюх разного типа.
- Инъекция вьюхи во время выполнения, когда тип заранее неизвестен.
- API, где нельзя использовать дженерики.
Например, список разнородных ячеек, которые приходят из конфигурации:
let cells: [AnyView] = [
AnyView(ProfileCell()),
AnyView(SettingsCell()),
AnyView(NotificationCell())
]
Но даже здесь стоит подумать: возможно, можно обойтись перечислением с
associated value или каким-то другим дизайном, сохраняющим типы.
Простое правило:
Если
SwiftUI может узнать тип на этапе компиляции - используйте
some View. Если тип становится известен только во время выполнения - используйте
AnyView.
AnyView сам по себе не зло. Зло - использовать его как костыль, чтобы быстро починить ошибку компиляции, не задумываясь о последствиях для производительности.
Вывод:
Разница между
some View и
AnyView - это разница между статической типизацией с возможностью оптимизации и динамической диспетчеризацией с потерей производительности.
SwiftUI спроектирован так, чтобы максимально использовать информацию о типах на этапе компиляции. Любое стирание типов заставляет фреймворк работать вслепую, что рано или поздно скажется на плавности интерфейса. Хорошая привычка - всегда сначала пробовать
some View и только в крайнем случае опускаться до
AnyView, четко понимая цену такого решения.
