9 вопросов по теме «iOS: Сеть и хранение» на собеседовании

Короткий ответ: .default использует постоянные хранилища кэша, cookies и credentials; .ephemeral не сохраняет эти данные сессии на диск. .background(withIdentifier:) передаёт загрузки системе и может продолжать их при приостановке или системном завершении приложения. Принудительное закрытие пользователем — исключение: фоновые передачи отменяются, автоматический перезапуск для них не происходит до следующего запуска пользователем.

Подробно:

1. Типы задач — dataTask получает данные в память, downloadTask пишет временный файл, uploadTask отправляет тело. Для загрузок в фоне, переживающих выход из приложения, тело upload должно быть файлом.
2. Отмена — task.cancel() запрашивает отмену; завершение обычно приходит с URLError.cancelled. У async-методов URLSession отмена вызывающей Task распространяется на запрос.
3. Возобновление — после системного завершения воссоздайте background-сессию с тем же идентификатором и обработайте delegate-события; учитывайте системные условия запуска.
4. Таймауты — timeoutIntervalForRequest ограничивает ожидание очередных данных, timeoutIntervalForResource — длительность ресурса целиком; задавайте значения под сценарий.

⚠️ Частая ошибка: обещать, что background-запрос переживёт любое закрытие, или что .ephemeral не оставит файлов. Пользовательский force-quit меняет поведение, а download-задача и код приложения могут писать на диск и в ephemeral-сессии.

Короткий ответ: Пиннинг — проверка, что сервер предъявил именно наш сертификат или ключ, а не любой, которому доверяет система. Защищает от MITM с подставным или скомпрометированным CA. Реализация — URLSessionDelegate с проверкой challenge или ATS-пиннинг в Info.plist (iOS 14+). Пинить лучше публичный ключ (SPKI), а не сертификат.

Подробно:

func urlSession(_ session: URLSession,
                didReceive challenge: URLAuthenticationChallenge) async
    -> (URLSession.AuthChallengeDisposition, URLCredential?) {
    guard let trust = challenge.protectionSpace.serverTrust,
          SecTrustEvaluateWithError(trust, nil),
          let key = publicKeyHash(trust) else {
        return (.cancelAuthenticationChallenge, nil)  // цепочка не прошла — рвём соединение
    }
    return pinnedHashes.contains(key)
        ? (.useCredential, URLCredential(trust: trust))
        : (.cancelAuthenticationChallenge, nil)       // ключ не наш — MITM?
}

1. Сертификат vs ключ — пин сертификата ломается при каждом продлении; пин SPKI-ключа переживает ротацию сертификата, пока пара ключей та же.
2. ATS-пиннинг — NSPinnedDomains в Info.plist: декларативно, без кода (iOS 14+).
3. Финтех-стандарт — банковские приложения пинят обязательно (Т-Банк спросит) и всегда держат резервный ключ на случай компрометации.

⚠️ Частая ошибка: запинить leaf-сертификат без плана ротации: сертификат продлили — и все установленные приложения перестали ходить в сеть. Пинь ключ и держи backup-пин.

Короткий ответ: Snake_case — keyDecodingStrategy = .convertFromSnakeCase или явные CodingKeys; вложенный объект без промежуточной модели — nestedContainer(keyedBy:) в кастомном init(from:); легаси-поле — decodeIfPresent с дефолтом.

Подробно:

// {"user_name": "Алия", "stats": {"total_orders": 5}, "legacy_flag": null}
struct User: Decodable {
    let userName: String
    let totalOrders: Int
    let legacyFlag: Bool

    enum CodingKeys: String, CodingKey {
        case userName = "user_name", stats, legacyFlag = "legacy_flag"
    }
    enum StatsKeys: String, CodingKey { case totalOrders = "total_orders" }

    init(from decoder: Decoder) throws {
        let c = try decoder.container(keyedBy: CodingKeys.self)
        userName = try c.decode(String.self, forKey: .userName)
        let stats = try c.nestedContainer(keyedBy: StatsKeys.self, forKey: .stats)
        totalOrders = try stats.decode(Int.self, forKey: .totalOrders)
        legacyFlag = try c.decodeIfPresent(Bool.self, forKey: .legacyFlag) ?? false
    }
}

1. Стратегия vs CodingKeys — .convertFromSnakeCase короче, но конвертирует каждый ключ в рантайме и прячет соответствие имён; явные ключи быстрее и честнее.
2. Даты — dateDecodingStrategy: .iso8601 или кастомный форматтер, не парсить руками.
3. decodeIfPresent — покрывает и отсутствующий ключ, и null.

⚠️ Частая ошибка: один битый элемент валит декодирование всего массива. Для лент заводят lossy-обёртку: декодировать элементы поштучно и молча пропускать сломанные.

Короткий ответ: NSPersistentContainer поднимает весь стек: модель, координатор, хранилище и viewContext — контекст главного потока для чтения и UI. Запись идёт в фоновых контекстах (performBackgroundTask), а изменения доезжают до UI через automaticallyMergesChangesFromParent и merge policy.

Подробно:

        NSPersistentContainer
                 │
   ┌─────────────┴─────────────┐
   │ viewContext (main)        │ ← чтение, FRC, UI
   │ background contexts       │ ← запись, импорт
   └─────────────┬─────────────┘
     NSPersistentStoreCoordinator
                 │
           SQLite-хранилище

1. viewContext — только главный поток: чтение, NSFetchedResultsController, биндинг в UI.
2. Фоновая запись — container.performBackgroundTask { ctx in … try ctx.save() }: тяжёлый импорт не трогает главный поток.
3. Слияние — viewContext.automaticallyMergesChangesFromParent = true плюс NSMergeByPropertyObjectTrumpMergePolicy: сохранённое в фоне само появляется в UI.
4. Границы потоков — контексты и managed-объекты не потокобезопасны: между контекстами передают NSManagedObjectID, а не сам объект.

⚠️ Частая ошибка: писать большие батчи в viewContext — UI замирает; или трогать managed-объект из чужого потока — редкий и злой краш. Правило: контекст живёт в своём потоке, наружу выходит только objectID.

Короткий ответ: Lightweight-миграцию Core Data выводит сам: добавление и удаление атрибутов, переименования (через renaming ID), смена optionality. Ломается на всём, что требует семантики — разделение и слияние сущностей, преобразование данных: тогда mapping model или поэтапная (staged) миграция.

Подробно:

1. Включение — shouldMigrateStoreAutomatically + shouldInferMappingModelAutomatically; у NSPersistentContainer включены по умолчанию.
2. Heavyweight — NSMappingModel + entity migration policy; ест много памяти, поэтому большие базы мигрируют поэтапно, версия за версией.
3. iOS 17+ — NSStagedMigrationManager формализует поэтапную миграцию кодом вместо зоопарка mapping-моделей.

⚠️ Частая ошибка: тестировать миграцию только на свежей установке. Держи в тестах реальные старые .sqlite-файлы: упавшая миграция — это краш на старте у всех, кто обновился.

Короткий ответ: SwiftData — макро-обёртка над концепциями хранилища Core Data: @Model вместо .xcdatamodeld, @Query для SwiftUI, типизированные предикаты через #Predicate. Честный ответ: greenfield на iOS 17+ со SwiftUI — да; зрелая схема, сложные миграции и тонкая настройка — Core Data.

Подробно:

1. Что даёт — модель прямо в коде через @Model, @Query сам обновляет вью, типобезопасные предикаты вместо строковых NSPredicate.
2. Что под капотом — то же SQLite-хранилище и те же концепции (контекст → ModelContext); это новый слой API, а не новый движок.
3. Ограничения — минимум iOS 17; продвинутые сценарии (сложные merge policy, derived attributes, undo, тонкий тюнинг fetch) пока слабее Core Data; в CIS-проде встречается редко — команды консервативны.

⚠️ Частая ошибка: подать SwiftData как «замену Core Data». Это надстройка над той же базой; полнота API и зрелость у Core Data пока выше — собеседующий ждёт именно этой оговорки, а не рекламного энтузиазма.

Короткий ответ: Токены, пароли, ключи — только Keychain: он шифруется системой, переживает переустановку и умеет классы доступа вплоть до биометрии. UserDefaults — нешифрованный plist: попадает в бэкапы и тривиально читается на джейлбрейкнутом устройстве.

Подробно:

1. Классы доступа — kSecAttrAccessibleAfterFirstUnlock для фоновых запросов после перезагрузки; варианты …ThisDeviceOnly не уезжают в бэкап и на другие устройства.
2. Биометрия — SecAccessControl с .biometryCurrentSet: элемент отдаётся только после Face ID/Touch ID.
3. API — сырой SecItemAdd/SecItemCopyMatching многословен; в проде берут тонкую обёртку или проверенную библиотеку.

⚠️ Частая ошибка: «UserDefaults защищён песочницей, значит токену там нормально». Песочница — не шифрование: бэкап, джейлбрейк или доступ к файловой системе отдают plist как есть.

Короткий ответ: Два слоя: NSCache для декодированных картинок (сам чистится под memory pressure) плюс диск для сырых данных. Ключевое — даунсэмплить до размера показа до кэширования, дедуплицировать запросы и отменять загрузку при reuse ячейки. Так устроены Kingfisher и Nuke.

Подробно:

запрос картинки
 │ 1. память (NSCache) ── hit → отдать мгновенно
 │ 2. диск ── hit → decode + downsample → в память
 │ 3. сеть ── download → downsample → диск + память
 └─ in-flight: один URL = одна загрузка (дедупликация)

1. NSCache — авто-эвикция под давлением памяти, totalCostLimit в байтах; хранить уже декодированный UIImage, чтобы не декодировать на скролле.
2. Даунсэмплинг до кэша — декодированный битмап весит w×h×4 байта: фото 4000×3000 ≈ 48 МБ, а ячейке нужно 200×200. CGImageSourceCreateThumbnailAtIndex декодирует сразу в нужный размер.
3. Reuse ячеек — в prepareForReuse отменять таску загрузки, иначе быстрый скролл рисует чужие картинки в ячейках.
4. Дедупликация — десять ячеек с одним URL = одна сетевая загрузка и веер подписчиков.

⚠️ Частая ошибка: кэшировать полноразмерные декодированные картинки — память вылетает на первом же быстром скролле ленты.

Короткий ответ: Локальная база — источник истины: UI всегда читает и пишет локально, а персистентная очередь мутаций доставляет изменения на сервер с ретраями. Ключевые решения: политика конфликтов, «сеть как подсказка, а не как условие» и очередь, которая не теряет операции ни при каком краше.

Подробно:

UI ──► локальная база (истина) ──► очередь мутаций (персистентная)
▲                                        │ retry + backoff
│  merge                                 ▼
└──────────── sync engine ◄──────────── сервер

1. Источник истины — Core Data/SQLite; UI никогда не ждёт сеть, изменения применяются локально сразу (optimistic).
2. Очередь мутаций — каждая операция персистится до подтверждения сервером, ретраи с экспоненциальным backoff. Финтех-правило: поставленный в очередь платёж не теряется никогда.
3. Конфликты — last-write-wins (просто, но теряет данные) vs merge по полям vs server-authoritative с версией/ETag: клиент шлёт базовую версию, сервер решает.
4. Reachability — только хинт — пробуй запрос и обрабатывай ошибку; не «gate» по флагу сети: он врёт (captive portal, полурабочий Wi-Fi).
5. Фон — BGAppRefreshTask негарантирован: бюджет выдаёт система, поэтому синк обязан догонять и при обычном запуске.

⚠️ Частая ошибка: держать очередь мутаций в памяти. Убили приложение — потеряли операции пользователя. Очередь живёт в той же локальной базе, транзакционно с самим изменением данных.