Что такое кэш и как он работает

Что проверяют

Знаете ли вы, какими средствами платформы кэш делается на практике, и где проходит граница между кэшем и постоянным хранилищем. Тема базовая, поэтому ценятся точные имена и понимание политик вытеснения, а не пересказ мысли «чтобы работало быстрее».

Как отвечать

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

Слои в iOS стоит перечислить конкретно:

URLCache кэширует ответы HTTP в памяти и на диске, ориентируясь на заголовки сервера; поведение отдельного запроса задаётся политикой у URLRequest.

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

Собственный каталог Caches для картинок и файлов: система вправе вычистить его при нехватке места на устройстве.

Хранилище данных пользователя (файлы в Documents, Core Data, SQLite) кэшем не является, даже если туда положили ответ сервера.

Политики свежести: срок жизни записи, вытеснение давно не используемых, условный запрос с ETag и ответ 304, когда данные не изменились.

Где спотыкаются

Складывают кэш в Documents. Каталог попадает в резервную копию, она распухает, и на ревью это претензия. Для восстановимых данных есть Caches и флаг исключения из бэкапа.

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

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