On-Demand Resources: що це, механізм запиту та зберігання ресурсів

Що таке On-Demand Resources в iOS

On-Demand Resources (ODR) — це система керування вмістом, вбудована в iOS, tvOS та macOS. Вона дозволяє розробнику розділити ресурси застосунку на обов’язкові (входять в інсталяційний пакет) і ті, що завантажуються на вимогу (зберігаються в App Store та завантажуються за потреби).

Основні поняття ODR

Система ODR оперує трьома ключовими сутностями: теги, ресурсні пакети та запити. Тег — це рядок-ідентифікатор, який об’єднує групу файлів. Ресурсний пакет — набір даних, пов’язаних із тегом. Запит — програмний виклик NSBundleResourceRequest, що ініціює завантаження пакета.

Життєвий цикл запиту ресурсу

Завантаження ресурсу проходить кілька стадій: ініціалізація запиту із зазначеними тегами, перевірка доступності в локальному сховищі, завантаження з серверів Apple за відсутності, сповіщення застосунку про готовність та звільнення ресурсу після використання. Система автоматично керує кешуванням та видаленням невикористаних ресурсів.

Як працює ODR в iOS

Механізм ODR заснований на фоновій службі, яка керує запитам ресурсів із хмарного сховища App Store. Коли застосунок запитує тег, система перевіряє, чи є ресурс у локальному кеші. Якщо ні — починає завантаження через фонову URL-сесію з підтримкою відновлення при обриві з’єднання.

Керування запитам через NSBundleResourceRequest

import Foundation

class ResourceManager {
    let odrRequest = NSBundleResourceRequest(tags: ["level-3"])

    func loadLevel3() {
        odrRequest.conditionallyBeginAccessingResources { available in
            if available {
                self.startLevel3()
            } else {
                self.odrRequest.beginAccessingResources { error in
                    guard error == nil else { return }
                    self.startLevel3()
                }
            }
        }
    }

    func releaseResources() {
        odrRequest.endAccessingResources()
    }
}

Метод conditionallyBeginAccessingResources перевіряє наявність ресурсу в кеші без негайного завантаження. Якщо прапорець доступності позитивний — застосунок продовжує роботу без затримки. Якщо ресурс відсутній, beginAccessingResources запускає завантаження з індикацією прогресу через властивість progress.

Фонове завантаження та пріоритети

Система iOS сама керує пріоритетами завантаження ODR-ресурсів залежно від поточної активності застосунку. Якщо застосунок знаходиться на передньому плані, завантаження виконується з високим пріоритетом. У фоновому режимі iOS може відкласти завантаження або призупинити його при низькому заряді батареї.

• Високий пріоритет — негайне завантаження для ресурсів, потрібних прямо зараз
• Низький пріоритет — відкладене завантаження для prefetching та попереднього кешування
• Фоновий — завантаження лише за активного Wi-Fi та достатнього заряду

Типи ресурсів і теги ODR

Ресурси ODR можуть включати зображення, відео, аудіофайли, спрайти, дані рівнів та будь-які інші файли, не критичні для запуску застосунку. Кожен ресурс прив’язується до одного або кількох тегів, які визначають його належність до функціонального блоку.

Content Tagging у Xcode

У Xcode теги налаштовуються через інспектор Resource Tags на вкладці Target Membership. Розробник вказує для кожного файлу в проекті, чи входить він до основного бандла чи завантажується за тегом. Один файл може належати кільком тегам, що дозволяє перевикористовувати ресурси між різними розділами застосунку.

<!-- Приклад конфігурації Resource Tags у Info.plist -->
<key>NSBundleResourceRequestTags</key>
<dict>
    <key>level-3</key>
    <array>
        <string>levels/level3.scnassets</string>
        <string>textures/level3_tex.png</string>
    </array>
</dict>

Категорії тегів за часом життя

Apple виділяє три категорії ODR-тегів залежно від того, як довго ресурс повинен зберігатися на пристрої. Initial Install Tags завантажуються разом із застосунком і ніколи не видаляються системою. Prefetch Tag Order визначає порядок фонового підвантаження одразу після інсталяції. Основні теги запитуються на вимогу та можуть бути видалені iOS при нестачі місця.

Крім категорій, кожен тег може мати пріоритет завантаження. Теги з високим пріоритетом завантажуються перед низькопріоритетними, навіть якщо вони були запрошені пізніше. Це дозволяє розробнику керувати порядком появи вмісту: спочатку критичні ресурси для головного екрана, потім додаткові матеріали для глибоких розділів застосунку.

• Initial install tags — завантажуються при першій інсталяції, не видаляються системою
• Prefetched tags — завантажуються у фоновому режимі після інсталяції для покращення UX
• On-demand tags — запитуються програмно, можуть бути видалені iOS при дефіциті місця

Налаштування On-Demand Resources у Xcode

Налаштування ODR у Xcode включає три етапи: категоризація ресурсів за тегами, конфігурація параметрів завантаження в Info.plist та програмна реалізація запитів через NSBundleResourceRequest. Більша частина роботи виконується на стороні збірки проекту.

Категоризація в Target Membership

// Перевірка статусу та моніторинг прогресу ODR
func monitorODRProgress(tag: String) {
    let request = NSBundleResourceRequest(tags: [tag])
    let observer = request.progress.observe(\.fractionCompleted) { progress, _ in
        DispatchQueue.main.async {
            let percent = Int(progress.fractionCompleted * 100)
            print("ODR: \(percent)% завантажено")
        }
    }
}

Прогрес завантаження відстежується через властивість progress класу NSProgress з підтримкою KVO-спостереження. Застосунок може відображати індикатор завантаження користувачу під час завантаження ресурсів. Після завершення завантаження ресурси доступні в основному бандлі застосунку через стандартні механізми FileManager та NSDataAsset.

Параметри квот та обмежень

Квоти на ODR залежать від версії iOS. Починаючи з iOS 13, пристрій може зберігати до 20 ГБ завантажених на вимогу ресурсів на один аккаунт. Цей об’єм розподіляється між усіма застосунками, встановленими на пристрої — якщо один застосунок зайняв багато місця, іншим залишається менше.

Моніторинг зайнятого місця виконується через NSBundleResourceRequest. Застосунок може перевіряти доступне ODR-сховище та залежно від цього вирішувати, які ресурси завантажувати в першу чергу. Рекомендується реалізувати fallback-механізм: якщо ODR-сховище переповнене, використовувати ресурси з основного бандла зменшеної якості.

Розробнику важливо враховувати, що iOS може в будь-який момент прийняти рішення про видалення On-Demand ресурсів — застосунок повинен коректно обробляти ситуацію, коли раніше завантажений ресурс раптово недоступний. Рекомендується перехоплювати помилки доступу до ресурсів та повторно запитувати їх через beginAccessingResources. Для критично важливих ресурсів, без яких застосунок не може функціонувати, використовуйте Initial Install Tags, які не видаляються системою.

Переваги та обмеження ODR

On-Demand Resources дають розробнику гнучкий інструмент керування розміром застосунку, але накладають ряд обмежень, пов’язаних із доступністю мережі та політиками сховища iOS.

Переваги використання ODR

Головна перевага ODR — радикальне скорочення розміру початкової інсталяції. Ігри з кількома рівнями, застосунки з відео-контентом або великими наборами зображень можуть завантажувати контент порційно. Користувач отримує доступ до базового функціоналу одразу, а додаткові ресурси завантажуються фоном.

Обмеження технології

ODR вимагає постійного підключення до інтернету для завантаження ресурсів при першому зверненні. Користувач у зоні з поганим покриттям може зіткнутися із затримками та помилками завантаження. Крім того, Apple не гарантує, що завантажені ресурси залишаться на пристрої — при нестачі місця iOS може видалити On-Demand теги без попередження.

• Необхідність мережі — перший запит ресурсу вимагає підключення до інтернету
• Автоматичне видалення — iOS може очистити кеш при нестачі місця на пристрої
• Складність налагодження — відтворення проблем із завантаженням вимагає симуляції різних мережевих умов
• Розмір тегу — Apple рекомендує не перевищувати 512 МБ на один тег для оптимальної продуктивності
• Обробка помилок — застосунок повинен коректно обробляти збої завантаження та повторювати запити