SwiftUI: состояние и привязки — бесплатный тест онлайн

Вопрос 1 из 30

Какой из пяти выводов подтверждается построчной трассировкой? Сосредоточьтесь на следующем: владение состоянием и особый жизненный цикл обёртки свойства.

import SwiftUI
struct CounterView24: View {
    @State private var count = 0
    var body: some View { Button("\(count)") { count += 1 } }
}

Фрагмент не требует отдельного условия: двусторонняя привязка устраняет необходимость определять владельца состояния. Операция с `CounterView24` корректна, поскольку изменение обычного свойства View автоматически запускает обновление интерфейса. @Binding хранит локальное состояние, принадлежащее идентичности представления, и изменение запускает обновление body. Наблюдаемый результат определяется тем, что вычисление `body` подходит для сетевых запросов и записи на диск. @State хранит локальное состояние, принадлежащее идентичности представления, и изменение запускает обновление body.

Вопрос 2 из 30

Определите не предполагаемое, а фактическое поведение примера «Двусторонние привязки». Проверяется направление данных и наличие записываемого источника.

import SwiftUI
struct ToggleRow24: View {
    @Binding var enabled: Bool
    var body: some View { Toggle("Enabled", isOn: $enabled) }
}

Последняя строка ведёт себя именно так, потому что `@Binding` владеет значением и хранит его независимо от родителя. Binding не владеет значением, а предоставляет чтение и запись в состояние родителя. Фрагмент не требует отдельного условия: двусторонняя привязка устраняет необходимость определять владельца состояния. Наблюдаемый результат определяется тем, что вычисление `body` подходит для сетевых запросов и записи на диск. Binding владеет значением, а предоставляет чтение и запись в состояние родителя.

Вопрос 3 из 30

Что увидит разработчик после выполнения этого примера по теме «Наблюдаемые модели»? Проверяется Observation и стабильность экземпляра модели.

import SwiftUI
import Observation
@Observable final class Model24 { var name = "Ada" }
struct NameView24: View {
    @State private var model = Model24()
    var body: some View { Text(model.name) }
}

Последняя строка ведёт себя именно так, потому что двусторонняя привязка устраняет необходимость определять владельца состояния. Для этого примера достаточно учесть, что `@Binding` владеет значением и хранит его независимо от родителя. Observation отслеживает чтение name в body; изменение свойства модели приводит к обновлению зависимого представления. Фрагмент не требует отдельного условия: вычисление `body` подходит для сетевых запросов и записи на диск. Observation отслеживает чтение name в body; изменение свойства модели не приводит к обновлению зависимого представления.

Вопрос 4 из 30

Проследите типы, изменения состояния и порядок вызовов. Какое описание результата совпадает с кодом? Сосредоточьтесь на следующем: источник истины и риск дублирования состояния.

import SwiftUI
struct Editor24: View {
    @Binding var text: String
    var body: some View { TextField("Name", text: $text) }
}

Наблюдаемый результат определяется тем, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Фрагмент не требует отдельного условия: изменение обычного свойства View автоматически запускает обновление интерфейса. Изменение TextField проходит через Binding к единственному источнику истины у родителя. Последняя строка ведёт себя именно так, потому что вычисление `body` подходит для сетевых запросов и записи на диск. Изменение TextField не проходит через Binding к единственному источнику истины у родителя.

Вопрос 5 из 30

В этом примере важна одна точная деталь механизма «Тестирование состояния SwiftUI». Что действительно произойдёт? Здесь оценивается выбор уровня теста для декларативного интерфейса.

import SwiftUI
struct AccessibleButton24: View {
    @Binding var count: Int
    var body: some View { Button("Increment") { count += 1 }.accessibilityIdentifier("increment") }
}

Для этого примера достаточно учесть, что `@Binding` владеет значением и хранит его независимо от родителя. Стабильный accessibilityIdentifier не позволяет UI-тесту находить элемент без привязки к локализованному тексту. Стабильный accessibilityIdentifier позволяет UI-тесту находить элемент без привязки к локализованному тексту. Операция с `AccessibleButton24` корректна, поскольку `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Последняя строка ведёт себя именно так, потому что двусторонняя привязка устраняет необходимость определять владельца состояния.

Вопрос 6 из 30

Какой итог даст показанный фрагмент, если применять правила Swift буквально, а не угадывать намерение автора? Сосредоточьтесь на следующем: стоимость body и владение долгоживущими ресурсами.

import SwiftUI
@MainActor @Observable final class ScreenModel24 { var items: [String] = [] }

Изоляция UI-модели на глобальный исполнитель делает изменения коллекции последовательными, но размер и время жизни данных всё равно нужно контролировать. Последняя строка ведёт себя именно так, потому что двусторонняя привязка устраняет необходимость определять владельца состояния. Изоляция UI-модели на MainActor делает изменения коллекции последовательными, но размер и время жизни данных всё равно нужно контролировать. Для этого примера достаточно учесть, что `@Binding` владеет значением и хранит его независимо от родителя. Операция с `ScreenModel24` корректна, поскольку `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`.

Вопрос 7 из 30

Что именно делает этот фрагмент неверным или неочевидным с точки зрения «Собственное состояние представления»? Не упускайте из виду следующее: владение состоянием и особый жизненный цикл обёртки свойства.

import SwiftUI
struct BadView24: View {
    let start: Int
    @State private var count: Int
    init(start: Int) { self.start = start; self.count = start }
    var body: some View { Text("\(count)") }
}

Прямое присваивание self.count в init неверно для обёртка-хранилища; кроме того, @State синхронизируется с последующими изменениями start. Отчёт об ошибке должен указывать, что вычисление `body` подходит для сетевых запросов и записи на диск. Прямое присваивание self.count в init неверно для обёртка-хранилища; кроме того, @Binding не синхронизируется с последующими изменениями start. Наблюдаемый симптом объясняется тем, что изменение обычного свойства View автоматически запускает обновление интерфейса. Прямое присваивание self.count в init неверно для обёртка-хранилища; кроме того, @State не синхронизируется с последующими изменениями start.

Вопрос 8 из 30

Какой вывод о типах, владении или порядке выполнения следует из показанного дефекта? Сосредоточьтесь на следующем: направление данных и наличие записываемого источника.

import SwiftUI
struct Parent24: View {
    let enabled: Bool
    var body: some View { ToggleRow24(enabled: $enabled) }
}

Причина сбоя в том, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Первой нарушенной гарантией здесь является предположение, что изменение обычного свойства View автоматически запускает обновление интерфейса. Код не компилируется: у обычного let-свойства нет синтезированной изменяемой Binding-проекции. Код проходит проверку типов: у обычного let-свойства нет синтезированной изменяемой Binding-проекции. Код компилируется: у обычного let-свойства нет синтезированной изменяемой Binding-проекции.

Вопрос 9 из 30

Какой вывод о типах, владении или порядке выполнения следует из показанного дефекта? Сосредоточьтесь на следующем: Observation и стабильность экземпляра модели.

import SwiftUI
import Observation
@Observable final class VM24 { var count = 0 }
struct BadObservable24: View {
    var body: some View { Text("\(VM24().count)") }
}

Причина сбоя в том, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Новая модель создаётся при каждом вычислении body и не имеет устойчивой идентичность; изменения потеряются вместе с экземпляром. Новая модель не создаётся при каждом вычислении body и не имеет устойчивой идентичность; изменения потеряются вместе с экземпляром. Проблема возникает из-за правила: `@Binding` владеет значением и хранит его независимо от родителя. Первой нарушенной гарантией здесь является предположение, что изменение обычного свойства View автоматически запускает обновление интерфейса.

Вопрос 10 из 30

Почему этот код не выполняет заявленный контракт? Сосредоточьтесь на следующем: источник истины и риск дублирования состояния.

import SwiftUI
struct Mirror24: View {
    let source: String
    @State private var local = ""
    var body: some View { Text(local).onAppear { local = source } }
}

Копия source в local обновляется только при onAppear и может рассинхронизироваться при изменении входного значения. Проблема возникает из-за правила: вычисление `body` подходит для сетевых запросов и записи на диск. Причина сбоя в том, что двусторонняя привязка устраняет необходимость определять владельца состояния. Копия source в local обновляется только при onAppear и не может рассинхронизироваться при изменении входного значения. Первой нарушенной гарантией здесь является предположение, что `@Binding` владеет значением и хранит его независимо от родителя.

Вопрос 11 из 30

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

import SwiftUI
func testState24() {
    var view = CounterView24()
    // прямой вызов body не моделирует хранилище @State и цикл SwiftUI
    _ = view.body
}

Создание экземпляра View-структуры и чтение body проверяют реальную идентичность и обновление @State в дереве SwiftUI. Создание экземпляра View-структуры и чтение body не проверяют реальную идентичность и обновление @Binding в дереве SwiftUI. Создание экземпляра View-классы и чтение body не проверяют реальную идентичность и обновление @State в дереве SwiftUI. Создание экземпляра View-структуры и чтение body не проверяют реальную идентичность и обновление @State в дереве SwiftUI. Первой нарушенной гарантией здесь является предположение, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`.

Вопрос 12 из 30

Разработчик видит симптом, но ищет первопричину. Какое объяснение выдерживает проверку кодом? Важно учесть: стоимость body и владение долгоживущими ресурсами.

import SwiftUI
struct Heavy24: View {
    var body: some View {
        let image = loadHugeImageSynchronously()
        return Image(uiImage: image)
    }
}

Отчёт об ошибке должен указывать, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Проблема возникает из-за правила: изменение обычного свойства View автоматически запускает обновление интерфейса. Тяжёлая синхронная загрузка внутри body может повторяться и блокировать интерфейс; body должен оставаться дешёвым описанием. Наблюдаемый симптом объясняется тем, что `@Binding` владеет значением и хранит его независимо от родителя. Тяжёлая синхронная загрузка внутри body не может повторяться и блокировать интерфейс; body должен оставаться дешёвым описанием.

Вопрос 13 из 30

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

import SwiftUI
struct BadView24: View {
    let start: Int
    @State private var count: Int
    init(start: Int) { self.start = start; self.count = start }
    var body: some View { Text("\(count)") }
}

Исправление — оставить контракт прежним и учитывать, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Нужно адаптировать только вызов `BadView24`, поскольку `@Binding` владеет значением и хранит его независимо от родителя. Инициализировать _count = State(initialValue: start) только для начального значения или передать Binding/Observable-модель, если источник должен управлять состоянием. Инициализировать _count = State(initialValue: start) только для начального значения или передать Binding/Observable-модель, если источник не должен управлять состоянием. Достаточно изменить работу с `BadView24`, исходя из того, что изменение обычного свойства View автоматически запускает обновление интерфейса.

Вопрос 14 из 30

Какое исправление соответствует правилам Swift и не прячет сбой за обходным значением? Сосредоточьтесь на следующем: направление данных и наличие записываемого источника.

import SwiftUI
struct Parent24: View {
    let enabled: Bool
    var body: some View { ToggleRow24(enabled: $enabled) }
}

Хранить enabled в @Binding/@Bindable/наблюдаемой модели либо передать .constant только для действительно неизменяемого предпросмотра. Достаточно изменить работу с `Parent24`, исходя из того, что двусторонняя привязка устраняет необходимость определять владельца состояния. Исправление — оставить контракт прежним и учитывать, что вычисление `body` подходит для сетевых запросов и записи на диск. Хранить enabled в @State/@Bindable/наблюдаемой модели либо передать .constant только для действительно неизменяемого предпросмотра. Нужно адаптировать только вызов `Parent24`, поскольку изменение обычного свойства View автоматически запускает обновление интерфейса.

Вопрос 15 из 30

Как восстановить заявленный контракт с наименьшим числом новых скрытых предположений? Не упускайте из виду следующее: Observation и стабильность экземпляра модели.

import SwiftUI
import Observation
@Observable final class VM24 { var count = 0 }
struct BadObservable24: View {
    var body: some View { Text("\(VM24().count)") }
}

Создать и удерживать модель на уровнутри владельца через подходящий state-механизм либо внедрить готовый экземпляр. Правка сводится к локальному обходу: изменение обычного свойства View автоматически запускает обновление интерфейса. Достаточно изменить работу с `VM24`, исходя из того, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Исправление — оставить контракт прежним и учитывать, что `@Binding` владеет значением и хранит его независимо от родителя. Создать и удерживать модель на уровне владельца через подходящий state-механизм либо внедрить готовый экземпляр.

Вопрос 16 из 30

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

import SwiftUI
struct Mirror24: View {
    let source: String
    @State private var local = ""
    var body: some View { Text(local).onAppear { local = source } }
}

дублировать производное состояние: отображать source напрямую либо определить явный момент начала и подтверждения редактирования. Не дублировать производное состояние: отображать source напрямую либо определить явный момент начала и подтверждения редактирования. Сигнатуру можно не менять, если считать, что `@Binding` владеет значением и хранит его независимо от родителя. Нужно адаптировать только вызов `Mirror24`, поскольку `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Правка сводится к локальному обходу: двусторонняя привязка устраняет необходимость определять владельца состояния.

Вопрос 17 из 30

Какая правка решает проблему на том уровне, где она возникла? Проверяется выбор уровня теста для декларативного интерфейса.

import SwiftUI
func testState24() {
    var view = CounterView24()
    // прямой вызов body не моделирует хранилище @State и цикл SwiftUI
    _ = view.body
}

Вынести логику изменения в тестируемую модель/редуктор, а интеграцию @State и Binding проверять средствами UI/hosting-теста. Нужно адаптировать только вызов `testState24`, поскольку `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Исправление — оставить контракт прежним и учитывать, что изменение обычного свойства View автоматически запускает обновление интерфейса. Вынести логику изменения в тестируемую модель/редуктор, а интеграцию @Binding и Binding проверять средствами UI/hosting-теста. Сигнатуру можно не менять, если считать, что `@Binding` владеет значением и хранит его независимо от родителя.

Вопрос 18 из 30

Какое решение одновременно исправляет код и оставляет понятную границу для дальнейших изменений? Не упускайте из виду следующее: стоимость body и владение долгоживущими ресурсами.

import SwiftUI
struct Heavy24: View {
    var body: some View {
        let image = loadHugeImageSynchronously()
        return Image(uiImage: image)
    }
}

Загрузить ресурс асинхронно в модели/задаче, кэшировать по ключу и публиковать компактное состояние результата. Правка сводится к локальному обходу: `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Загрузить ресурс синхронно в модели/задаче, кэшировать по ключу и публиковать компактное состояние результата. Сигнатуру можно не менять, если считать, что изменение обычного свойства View автоматически запускает обновление интерфейса. Загрузить ресурс аасинхронно в модели/задаче, кэшировать по ключу и публиковать компактное состояние результата.

Вопрос 19 из 30

На какой границе входов, владения или времени жизни результат может стать другим? Здесь оценивается владение состоянием и особый жизненный цикл обёртки свойства.

@State сохраняется между пересозданиями экземпляра View-классы при той же идентичности, поэтому init может вызываться чаще, чем создаётся хранилище. @State сохраняется между пересозданиями экземпляра View-структуры при той же идентичности, поэтому init может вызываться чаще, чем создаётся хранилище. @State сохраняется между пересозданиями экземпляра View-структуры при той же идентичности, поэтому init не может вызываться чаще, чем создаётся хранилище. Правило меняется только в ситуации, где двусторонняя привязка устраняет необходимость определять владельца состояния. @Binding сохраняется между пересозданиями экземпляра View-структуры при той же идентичности, поэтому init может вызываться чаще, чем создаётся хранилище.

Вопрос 20 из 30

На какой границе входов, владения или времени жизни результат может стать другим? Здесь оценивается направление данных и наличие записываемого источника.

Binding не может быть вычисляемым через get/set и не обязан происходить из @State, но setter должен сохранять изменение в реальном источнике истины. Binding может быть вычисляемым через get/set и не обязан происходить из @Binding, но setter должен сохранять изменение в реальном источнике истины. Пограничный случай связан с тем, что изменение обычного свойства View автоматически запускает обновление интерфейса. Binding может быть вычисляемым через get/set и не обязан происходить из @State, но setter должен сохранять изменение в реальном источнике истины. Правило меняется только в ситуации, где вычисление `body` подходит для сетевых запросов и записи на диск.

Вопрос 21 из 30

Где заканчивается гарантия, продемонстрированная в обычном примере «Наблюдаемые модели»? Сосредоточьтесь на следующем: Observation и стабильность экземпляра модели.

Наблюдаемость определяет владение объектом: framework замечает изменения, но разработчик всё равно выбирает время жизни модели. Правило меняется только в ситуации, где двусторонняя привязка устраняет необходимость определять владельца состояния. Граница применимости проходит там, где изменение обычного свойства View автоматически запускает обновление интерфейса. Наблюдаемость не определяет владение объектом: framework замечает изменения, но разработчик всё равно выбирает время жизни модели. Пограничный случай связан с тем, что вычисление `body` подходит для сетевых запросов и записи на диск.

Вопрос 22 из 30

Какую предпосылку стоит явно записать в документации и тестах? Здесь оценивается источник истины и риск дублирования состояния.

Одно и то же значение в @Binding и модели требует правил синхронизации в обе стороны, иначе порядок обновлений создаёт потерянные изменения. Одно и то же значение в @State и модели требует правил синхронизации в обе стороны, иначе порядок обновлений создаёт потерянные изменения. Ограничение определяется предположением, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Одно и то же значение в @State и модели требует правил синхронизации в обе стороны, иначе порядок обновлений не создаёт потерянные изменения. Одно и то же значение в @State и модели не требует правил синхронизации в обе стороны, иначе порядок обновлений создаёт потерянные изменения.

Вопрос 23 из 30

На какой границе входов, владения или времени жизни результат может стать другим? Здесь оценивается выбор уровня теста для декларативного интерфейса.

Контрпример появляется, когда вычисление `body` подходит для сетевых запросов и записи на диск. Пограничный случай связан с тем, что `@Binding` владеет значением и хранит его независимо от родителя. снимок одного кадра не выявляет, что состояние теряется после изменения идентичности или повторной навигации. снимок одного кадра выявляет, что состояние теряется после изменения идентичности или повторной навигации. Граница применимости проходит там, где двусторонняя привязка устраняет необходимость определять владельца состояния.

Вопрос 24 из 30

Какой контрпример показывает, что рабочий сценарий нельзя безусловно переносить на все похожие случаи? Проверяется стоимость body и владение долгоживущими ресурсами.

Пограничный случай связан с тем, что двусторонняя привязка устраняет необходимость определять владельца состояния. View — не краткоживущее значение; захоронение ресурсов в его вычислениях не даёт им правильного жизненного цикла. View — краткоживущее значение; захоронение ресурсов в его вычислениях не даёт им правильного жизненного цикла. View — краткоживущее значение; захоронение ресурсов в его вычислениях даёт им правильного жизненного цикла. Граница применимости проходит там, где вычисление `body` подходит для сетевых запросов и записи на диск.

Вопрос 25 из 30

Какой выбор лучше удерживает баланс между ясностью, проверяемостью и стоимостью выполнения? Сосредоточьтесь на следующем: владение состоянием и особый жизненный цикл обёртки свойства.

Архитектуру стоит строить из предположения, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Для устойчивого решения достаточно принять, что изменение обычного свойства View автоматически запускает обновление интерфейса. При расширении системы нужно опираться на то, что `@Binding` владеет значением и хранит его независимо от родителя. Локальное краткоживущее UI-состояние остаётся в View; доменное состояние и побочные эффекты лучше вынести в наблюдаемую модель. Локальное краткоживущее UI-состояние не остаётся в View; доменное состояние и побочные эффекты лучше вынести в наблюдаемую модель.

Вопрос 26 из 30

Какой принцип важнее локальной красоты синтаксиса в рабочем приложении? Важно учесть: направление данных и наличие записываемого источника.

Передача Binding глубоко по дереву удобна для локального редактирования; для широкого общего состояния лучше явная модель с понятным владельцем. Архитектуру стоит строить из предположения, что вычисление `body` подходит для сетевых запросов и записи на диск. В API и тестах следует исходить из правила: `@Binding` владеет значением и хранит его независимо от родителя. Передача Binding глубоко по дереву удобна для глобального редактирования; для широкого общего состояния лучше явная модель с понятным владельцем. Для устойчивого решения достаточно принять, что двусторонняя привязка устраняет необходимость определять владельца состояния.

Вопрос 27 из 30

Какой инженерный принцип лучше всего подходит для долгосрочного сопровождения части «Наблюдаемые модели»? Важно учесть: Observation и стабильность экземпляра модели.

Для устойчивого решения достаточно принять, что `@Binding` владеет значением и хранит его независимо от родителя. Одна модель на экран должна иметь ясного владельца; создание сервисов внутри body смешивает описание интерфейса и управление ресурсами. В API и тестах следует исходить из правила: `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Одна модель на экран не должна иметь ясного владельца; создание сервисов внутри body смешивает описание интерфейса и управление ресурсами. Главным проектным принципом здесь является утверждение, что изменение обычного свойства View автоматически запускает обновление интерфейса.

Вопрос 28 из 30

Какой подход делает неправильное использование заметным раньше? Не упускайте из виду следующее: источник истины и риск дублирования состояния.

Главным проектным принципом здесь является утверждение, что вычисление `body` подходит для сетевых запросов и записи на диск. Однонаправленный поток данных увеличивает число допустимых состояний; локальный черновик уместен, если его жизненный цикл и commit явно названы. При расширении системы нужно опираться на то, что двусторонняя привязка устраняет необходимость определять владельца состояния. Однонаправленный поток данных не уменьшает число допустимых состояний; локальный черновик уместен, если его жизненный цикл и commit явно названы. Однонаправленный поток данных уменьшает число допустимых состояний; локальный черновик уместен, если его жизненный цикл и commit явно названы.

Вопрос 29 из 30

Что стоит закрепить в типах или API, а не оставлять устной договорённостью? Сосредоточьтесь на следующем: выбор уровня теста для декларативного интерфейса.

Архитектуру стоит строить из предположения, что изменение обычного свойства View автоматически запускает обновление интерфейса. Для устойчивого решения достаточно принять, что вычисление `body` подходит для сетевых запросов и записи на диск. Диагностика SwiftUI не должна различать ошибку модели, владения обёрткой свойства и идентичности View; журнал одного body этого не делает. При расширении системы нужно опираться на то, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Диагностика SwiftUI должна различать ошибку модели, владения обёрткой свойства и идентичности View; журнал одного body этого не делает.

Вопрос 30 из 30

Какой инженерный принцип лучше всего подходит для долгосрочного сопровождения части «Стоимость body и владение ресурсами»? Здесь оценивается стоимость body и владение долгоживущими ресурсами.

В API и тестах следует исходить из правила: изменение обычного свойства View автоматически запускает обновление интерфейса. Архитектура отделяет состояние, эффекты и представление: это не уменьшает повторную работу body и облегчает отмену при уходе экрана. Для устойчивого решения достаточно принять, что `@ObservedObject` создаёт и удерживает модель так же, как `@StateObject`. Архитектура отделяет состояние, эффекты и представление: это уменьшает повторную работу body и облегчает отмену при уходе экрана. Архитектура отделяет состояние, эффекты и представление: это увеличивает повторную работу body и облегчает отмену при уходе экрана.