Серіалізація даних у мобільній розробці — що це, формати та принцип роботи

Що таке серіалізація?

Серіалізація — це процес перетворення об’єкта, що знаходиться в оперативній пам’яті, в лінійну послідовність байтів або символів, яку можна передати мережею, зберегти у файлі або передати іншому процесу. Без серіалізації неможлива мережева комунікація, збереження стану та міжпроцесна взаємодія.

Серіалізація включає два протилежні процеси. Прямий процес (серіалізація) пакує дані у формат для передачі. Зворотний процес (десеріалізація) відновлює дані обернення в об’єкт. Десеріалізація критично важлива для безпеки: некоректні вхідні дані можуть призвести до вразливостей в додатку.

У розробці мобільних додатків серіалізація використовується повсюди: відправлення запитів на сервер та обробка відповідей, збереження стану додатка при повороті екрану, кешування даних на диску та передача даних між екранами через Intent (Android) або Segue (iOS).

Основні завдання серіалізації

• Мережева взаємодія — передача даних між клієнтом та сервером
• Збереження стану — зберігання та відновлення даних додатка
• Кешування — зберігання результатів запитів для офлайн-доступу
• Кросплатформеність — обмін даними між системами різними мовами
• Логування — серіалізація об’єктів для запису в логи

Основні формати серіалізації

Формати серіалізації поділяються на текстові та бінарні. Текстові формати (JSON, XML) читаються людьми та не вимагають інструментів для перегляду. Бінарні формати (Protobuf, FlatBuffers, MessagePack) компактніші та швидші, але нечитанні без десеріалізації. Вибір формату — компроміс між продуктивністю та зручністю налагодження.

Крім JSON, XML та Protobuf, існують спеціалізовані формати: FlatBuffers від Google для ігор та AR, MessagePack — компактна бінарна альтернатива JSON, Avro від Apache для великих даних у Kafka, YAML — конфігураційний формат з підтримкою коментарів.

Серіалізація в мобільній розробці

Серіалізація на мобільних платформах має свою специфіку: обмежений трафік, слабші процесори та необхідність зберігати стан при поворотах екрану. На Android використовуються Gson, Moshi, Kotlinx Serialization. На iOS — Codable, JSONSerialization, PropertyListEncoder. Правильний вибір бібліотеки критично впливає на продуктивність додатка.

Kotlinx Serialization — сучасна бібліотека від JetBrains для Kotlin Multiplatform Mobile. Вона підтримує JSON, Protobuf, CBOR та користувацькі формати. Генерація коду відбувається на етапі компіляції через плагін Kotlin Serialization, що забезпечує високу продуктивність без використання рефлексії.

Kotlinx Serialization (Kotlin Multiplatform)

Бібліотека Kotlinx Serialization використовує анотацію @Serializable для класів та плагін компілятора для генерації серіалізаторів. Це забезпечує високу продуктивність та типову безпеку. Типовий формат — JSON, але інші формати підтримуються через додаткові модулі.

import kotlinx.serialization.Serializable
import kotlinx.serialization.json.Json
import kotlinx.serialization.encodeToString
import kotlinx.serialization.decodeFromString

@Serializable
data class Project(
    val id: Int,
    val name: String,
    val platforms: List<String>,
    val active: Boolean
)

val json = Json {
    prettyPrint = true
    ignoreUnknownKeys = true
    encodeDefaults = true
}

fun main() {
    val project = Project(1, "MobileApp",
        listOf("Android", "iOS"), true)

    // Сериализация
    val jsonString = json.encodeToString(project)

    // Десериализация
    val restored = json.decodeFromString<Project>(jsonString)
}

Codable на iOS (Swift)

Протокол Codable — це вбудований механізм серіалізації в Swift. Він об’єднує протоколи Encodable (серіалізація) та Decodable (десеріалізація). JSONEncoder та JSONDecoder автоматично обробляють вкладені структури, масиви, опціональні значення та користувацькі ключі через CodingKeys.

import Foundation

struct AppConfig: Codable {
    let appName: String
    let version: String
    let features: [String]
    let isProduction: Bool
}

let config = AppConfig(
    appName: "MyApp",
    version: "2.1.0",
    features: ["push", "analytics", "offline"],
    isProduction: true
)

let encoder = JSONEncoder()
encoder.outputFormatting = [.prettyPrinted, .sortedKeys]

guard let data = try? encoder.encode(config) else { return }
let jsonString = String(data: data, encoding: .utf8)

Продуктивність та порівняння форматів

Продуктивність форматів серіалізації оцінюється за трьома показниками: розмір повідомлення, швидкість серіалізації та швидкість десеріалізації. Для мобільних додатків усі три критичні: розмір впливає на трафік та час завантаження, швидкість впливає на чутливість інтерфейсу та час запуску додатка.

Protobuf та FlatBuffers показують найкращі результати завдяки бінарному поданню. FlatBuffers виділяється тим, що не потребує окремого кроку десеріалізації — дані читаються безпосередньо з бінарного буферу, що робить його ідеальним для ігор та AR-додатків з вимогами мінімальної затримки. JSON залишається найпопулярнішим форматом для REST API, незважаючи на гіршу продуктивність, завдяки своїй простоті та універсальності.

Порівняльне тестування

Практичні тести на наборі даних з 1000 об’єктів користувачів показують: Protobuf створює повідомлення розміром 12 КБ (JSON — 85 КБ, XML — 120 КБ). Час серіалізації: Protobuf — 2 мс, JSON — 8 мс, XML — 25 мс. Ці цифри роблять бінарні формати бажаними для високонавантажених систем та мобільних додатків з обмеженим трафіком.

Приклади серіалізації даних

Приклади демонструють серіалізацію одного й того ж об’єкта в різних форматах. Це допомагає наочно порівняти розмір та читанність. Однойменний об’єкт User буде серіалізовано в JSON, XML та Protobuf — наочно видно, що JSON компактніший за XML, а Protobuf найкомпактніший і нечитанний.

Один об’єкт у трьох форматах

JSON — мінімалістичний синтаксис, ключі в лапках, значення різних типів. Займає 80 символів. Читанність висока, візуальна структура чітка. Підходить для API, де важлива швидкість розробки та налагодження.

XML — кожен елемент обгорнуто в відкриваючий та закриваючий теги. Займає 150 символів. Читанність середня, структура сувора. Підходить для документообігу та систем, що вимагають валідації XSD.

Protobuf — бінарний, 32 байти для цих даних. Нечитанний — потребує десеріалізації для перегляду. Мінімальний розмір робить його ідеальним для високонавантажених систем та мобільних додатків.

{
  "id": 42,
  "name": "IT Sectr",
  "email": "team@itsectr.com",
  "role": "admin",
  "active": true
}

<user>
    <id>42</id>
    <name>IT Sectr</name>
    <email>team@itsectr.com</email>
    <role>admin</role>
    <active>true</active>
</user>

Найкращі практики серіалізації

Найкращі практики допомагають уникнути типових помилок та вибрати правильну стратегію серіалізації для проєкту. Дотримання цих рекомендацій поліпшує продуктивність, безпеку та підтримку коду.

Рекомендації для мобільної розробки

1. Вибирайте формат за сценарієм — JSON для REST API, Protobuf для gRPC та мікросервісів
2. Уникайте Java Serializable — повільний та небезпечний механізм, використовуйте Kotlinx Serialization або Moshi
3. Ігноруйте невідомі ключі — налаштуйте парсер на пропуск полів, відсутніх у моделі
4. Кешуйте десеріалізовані дані — уникайте повторного аналізу тих самих даних
5. Валідуйте вхідні дані — перевіряйте межі та типи під час десеріалізації

Безпека та серіалізація

Безпека серіалізації — критично важливий аспект, особливо при десеріалізації даних з неперевірених джерел. Атаки на десеріалізацію можуть призвести до віддаленого виконання коду (RCE), що є однією з найнебезпечніших вразливостей у веб-та мобільних додатках. Найвідоміші випадки пов’язані з Java Serializable та Python pickle.

Protobuf та JSON мають вбудований захист від таких атак, оскільки працюють лише з даними, а не з довільними об’єктами. Java Serializable, навпаки, може відновлювати будь-який клас, доступний у classpath, що робить його небезпечним для прийому даних з зовнішніх джерел. На Android рекомендується використовувати Kotlinx Serialization або Moshi замість стандартної Java Serialization.

Додаткові заходи безпеки: встановлювайте ліміт на розмір вхідних даних, валідуйте схему перед десеріалізацією, не довіряйте Content-Type з HTTP-заголовків, використовуйте білий список для дозволених класів. Регулярно оновлювайте бібліотеки серіалізації, оскільки вразливості періодично виявляються та виправляються.