Serializacja danych w programowaniu mobilnym — co to jest, formaty i zasada działania

Co to jest serializacja?

Serializacja to proces przekształcania obiektu znajdującego się w pamięci operacyjnej w liniową sekwencję bajtów lub znaków, którą można przesłać przez sieć, zapisać w pliku lub przekazać innemu procesowi. Bez serializacji niemożliwa jest komunikacja sieciowa, przechowywanie stanu i komunikacja międzyprocesowa.

Serializacja obejmuje dwa przeciwstawne procesy. Proces bezpośredni (serializacja) pakuje dane w format do przesłania. Proces odwrotny (deserializacja) przywraca dane z powrotem do obiektu. Deserializacja jest krytyczna dla bezpieczeństwa: nieprawidłowe dane wejściowe mogą prowadzić do podatności w aplikacji.

W tworzeniu aplikacji mobilnych serializacja jest używana wszechobecnie: wysyłanie zapytań do serwera i przetwarzanie odpowiedzi, zapisywanie stanu aplikacji przy obrocie ekranu, buforowanie danych na dysku i przesyłanie danych między ekranami przez Intent (Android) lub Segue (iOS).

Główne zadania serializacji

• Komunikacja sieciowa — przesyłanie danych między klientem a serwerem
• Przechowywanie stanu — zapisywanie i przywracanie danych aplikacji
• Buforowanie — zapisywanie wyników zapytań do dostępu offline
• Wieloplatformowość — wymiana danych między systemami w różnych językach
• Logowanie — serializacja obiektów do zapisu w logach

Główne formaty serializacji

Formaty serializacji dzielą się na tekstowe i binarne. Formatów tekstowych (JSON, XML) są czytelne dla człowieka i nie wymagają narzędzi do przeglądania. Formatów binarnych (Protobuf, FlatBuffers, MessagePack) są bardziej zwarte i szybsze, ale nieczytelne bez deserializacji. Wybór formatu to kompromis między wydajnością a wygodą debugowania.

Oprócz JSON, XML i Protobuf istnieją wyspecjalizowane formaty: FlatBuffers od Google do gier i AR, MessagePack — zwarta binarna alternatywa JSON, Avro od Apache do dużych danych w Kafka, YAML — format konfiguracyjny z obsługą komentarzy.

Serializacja w programowaniu mobilnym

Serializacja na platformach mobilnych ma swoją specyfikę: ograniczony ruch, słabsze procesory i konieczność zapisywania stanu przy obrotach ekranu. Na Androidzie używane są Gson, Moshi, Kotlinx Serialization. Na iOS — Codable, JSONSerialization, PropertyListEncoder. Właściwy wybór biblioteki krytycznie wpływa na wydajność aplikacji.

Kotlinx Serialization to nowoczesna biblioteka od JetBrains dla Kotlin Multiplatform Mobile. Obsługuje JSON, Protobuf, CBOR i niestandardowe formaty. Generowanie kodu odbywa się na etapie kompilacji przez plugin Kotlin Serialization, co zapewnia wysoką wydajność bez użycia refleksji.

Kotlinx Serialization (Kotlin Multiplatform)

Biblioteka Kotlinx Serialization używa adnotacji @Serializable dla klas i pluginu kompilatora do generowania serializatorów. Zapewnia to wysoką wydajność i bezpieczeństwo typów. Domyślny format to JSON, ale obsługiwane są również inne formaty poprzez dodatkowe moduły.

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)

    // Serializacja
    val jsonString = json.encodeToString(project)

    // Deserializacja
    val restored = json.decodeFromString<Project>(jsonString)
}

Codable na iOS (Swift)

Protokół Codable to wbudowany mechanizm serializacji w Swift. Łączy protokoły Encodable (serializacja) i Decodable (deserializacja). JSONEncoder i JSONDecoder automatycznie przetwarzają zagnieżdżone struktury, tablice, wartości opcjonalne i niestandardowe klucze przez 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)

Wydajność i porównanie formatów

Wydajność formatów serializacji ocenia się według trzech metryk: rozmiar wiadomości, szybkość serializacji i szybkość deserializacji. Dla aplikacji mobilnych wszystkie trzy są krytyczne: rozmiar wpływa na ruch i czas ładowania, szybkość — na responsywność interfejsu i czas uruchamiania aplikacji.

Protobuf i FlatBuffers pokazują najlepsze wyniki dzięki binarnemu formatowi. FlatBuffers różni się tym, że nie wymaga osobnego etapu deserializacji — dane są odczytywane bezpośrednio z bufora binarnego, co jest idealne dla gier i aplikacji AR z wymaganiem minimalnego opóźnienia. JSON pozostaje najpopularniejszym formatem dla REST API, pomimo gorszej wydajności, ze względu na prostotę i uniwersalność.

Testy porównawcze

Praktyczne testy na zbiorze 1000 obiektów użytkowników pokazują: Protobuf tworzy wiadomości o rozmiarze 12 KB (JSON — 85 KB, XML — 120 KB). Czas serializacji: Protobuf — 2 ms, JSON — 8 ms, XML — 25 ms. Te liczby czynią formaty binarne preferowanymi dla systemów high-load i aplikacji mobilnych z ograniczonym ruchem.

Przykłady serializacji danych

Przykłady pokazują serializację tego samego obiektu w różnych formatach. Pomaga to wizualnie porównać rozmiar i czytelność. Ten sam obiekt User zostanie zserializowany w JSON, XML i Protobuf — widać wyraźnie, że JSON jest bardziej zwarty niż XML, a Protobuf jest najbardziej zwarty i jednocześnie nieczytelny.

Jeden obiekt w trzech formatach

JSON — minimalistyczna składnia, klucze w cudzysłowie, wartości różnych typów. Zajmuje 80 znaków. Czytelność wysoka, struktura wizualna przejrzysta. Nadaje się do API, gdzie ważna jest szybkość tworzenia i debugowania.

XML — każdy element jest owinięty w otwierający i zamykający znacznik. Zajmuje 150 znaków. Czytelność średnia, struktura ścisła. Nadaje się do obiegu dokumentów i systemów wymagających walidacji przez XSD.

Protobuf — binarny, 32 bajty dla tych danych. Nieczytelny — wymaga deserializacji do przeglądania. Minimalny rozmiar czyni go idealnym dla systemów wysokiego obciążenia i aplikacji mobilnych.

{
  "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>

Najlepsze praktyki serializacji

Najlepsze praktyki pomagają uniknąć typowych błędów i wybrać odpowiednią strategię serializacji dla projektu. Przestrzeganie tych zaleceń poprawia wydajność, bezpieczeństwo i utrzymywalność kodu.

Zalecenia dla programowania mobilnego

1. Wybieraj format według scenariusza — JSON dla REST API, Protobuf dla gRPC i serwisów
2. Unikaj Java Serializable — wolny i niebezpieczny mechanizm, używaj Kotlinx Serialization lub Moshi
3. Ignoruj nieznane klucze — skonfiguruj parser tak, aby pomijał pola nieobecne w modelu
4. Buforuj dane zdeserializowane — unikaj wielokrotnego parsowania tych samych danych
5. Waliduj dane wejściowe — sprawdzaj granice i typy przy deserializacji

Bezpieczeństwo a serializacja

Bezpieczeństwo serializacji to krytycznie ważny aspekt, szczególnie przy deserializacji danych z niezweryfikowanych źródeł. Ataki na deserializację mogą prowadzić do zdalnego wykonania kodu (RCE), co jest jedną z najniebezpieczniejszych podatności w aplikacjach internetowych i mobilnych. Najbardziej znane przypadki związane są z Java Serializable i Python pickle.

Protobuf i JSON mają wbudowaną ochronę przed takimi atakami, ponieważ działają tylko z danymi, a nie z dowolnymi obiektami. Java Serializable natomiast może przywracać dowolne klasy dostępne w classpath, co czyni go niebezpiecznym do przyjmowania danych z zewnętrznych źródeł. Na Androidzie zaleca się używanie Kotlinx Serialization lub Moshi zamiast standardowej Java Serialization.

Dodatkowe środki bezpieczeństwa: ustaw limit rozmiaru danych wejściowych, waliduj schemat przed deserializacją, nie ufaj Content-Type z nagłówków HTTP, używaj allowlist dla dozwolonych klas. Regularnie aktualizuj biblioteki serializacji, ponieważ podatności w nich są okresowo wykrywane i naprawiane.