Deserializacja: co to jest, proces odtwarzania danych

Czym jest deserializacja?

Deserializacja — proces przekształcania strumienia bajtów lub strukturalnego tekstu w obiekt języka programowania. W programowaniu mobilnym ten proces zachodzi za każdym razem, gdy aplikacja otrzymuje odpowiedź z serwera: ciąg JSON zamienia się w instancję klasy User, Order lub Product. Od poprawności deserializacji bezpośrednio zależy stabilność ekranów wyświetlających dane użytkownikowi.

Różnica między serializacją a deserializacją

Serializacja i deserializacja to procesy wzajemnie odwrotne, rzadko symetryczne w praktyce. Serializacja przekształca obiekt w ciąg znaków do wysłania na serwer, deserializacja odtwarza obiekt z otrzymanego ciągu. Serwer może przesłać pole, którego nie ma w modelu klienta, użyć innego formatu daty lub zwrócić null zamiast liczby. Według danych Square Engineering (2025), asymetria formatów jest przyczyną 23% błędów warstwy sieciowej w aplikacjach Android. Aby zmniejszyć ryzyko, stosuje się wersjonowanie schematu i ścisłą specyfikację kontraktową przez OpenAPI.

Formaty danych do deserializacji

JSON pozostaje najpopularniejszym formatem dla mobilnych API dzięki czytelności i wbudowanemu wsparciu. Protobuf od Google jest używany w systemach high-load — jest 3-6 razy bardziej zwarty niż JSON i szybciej się parsuje, ale wymaga generowania kodu z plików .proto i jest nieczytelny bez narzędzi. XML rzadziej występuje w nowoczesnych aplikacjach mobilnych, jednak znajduje zastosowanie w usługach SOAP systemów korporacyjnych i plikach konfiguracyjnych Androida. MessagePack — format binarny, podobny do JSON pod względem struktury, ale bardziej zwarty, popularny w systemach czasu rzeczywistego.

Jak działa deserializacja

Proces deserializacji przebiega w trzech etapach. Najpierw tokenizacja dzieli surowy tekst na leksemy: klucze, ciągi znaków, liczby i separatory. Następnie analiza składniowa sprawdza poprawność struktury — czy nawiasy są zamknięte, czy typ cudzysłowu jest prawidłowy, czy format odpowiada specyfikacji RFC 8259. Ostatnim etapem jest mapowanie na model obiektowy aplikacji, gdzie każdemu kluczowi JSON przypisywana jest właściwość klasy z uwzględnieniem strategii nazewnictwa.

Reflection vs Code generation

W programowaniu mobilnym wykształciły się dwa podejścia do mapowania. Reflection (Gson, JSONSerialization) analizuje strukturę klasy w runtime przez Java Reflection API lub Objective-C runtime — jest elastyczne i nie wymaga dodatkowej konfiguracji, ale wolniejsze i zużywa więcej pamięci. Code generation (Moshi codegen, kotlinx.serialization, Codable) generuje kod na etapie kompilacji: szybciej, bezpieczniej pod względem typów i nie ujawnia wewnętrznej struktury przez reflection. JetBrains i Square zalecają code generation dla wersji produkcyjnych — przyrost wydajności sięga 2-4 razy w benchmarkach Google.

struct User: Codable {
    let id: Int
    let name: String
    let email: String
    let createdAt: Date
}

let json = """
{
    "id": 42,
    "name": "Alice",
    "email": "alice@example.com",
    "created_at": "2026-06-01T12:00:00Z"
}
"""
let decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase
let user = try decoder.decode(User.self, from: data)

Przykład deserializacji JSON do modelu User w Swift. Strategia convertFromSnakeCase automatycznie przekształca klucze API w formacie snake_case na właściwości modelu w camelCase — standardowa praktyka w projektach iOS. Parametr data to surowe bajty odpowiedzi serwera, otrzymane przez URLSession. Obsługa błędów przez try pozwala przechwycić nieprawidłowy JSON bez crashowania aplikacji.

Rola strategii dekodowania

JSONDecoder obsługuje cztery strategie kluczy: useDefaultKeys (dokładne dopasowanie), convertFromSnakeCase (snake_case → camelCase), custom (closure) i convertFromKebabCase (kebab-case → camelCase). Dla dat przewidziano .iso8601, .secondsSince1970, .millisecondsSince1970 oraz niestandardowy dateFormatter. Wybór odpowiedniej strategii to pierwszy krok do stabilnej deserializacji, zapobiegający większości błędów niezgodności formatów.

Deserializacja na iOS

JSONDecoder — standardowy mechanizm deserializacji w iOS SDK, działający z protokołem Codable. JSONDecoder automatycznie parsuje JSON do instancji struct lub class, obsługując zagnieżdżone obiekty, tablice i typy prymitywne. Do niestandardowej logiki używa się metody init(from: Decoder) — pozwala ona obsłużyć nietypowe formaty, pominięte pola w starszej wersji API lub połączyć kilka kluczy JSON w jedną właściwość.

struct Order: Decodable {
    let orderId: String
    let amount: Double
    let status: OrderStatus

    enum OrderStatus: String, Decodable {
        case pending, confirmed, shipped, cancelled
    }
}

let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601
let order = try decoder.decode(Order.self, from: jsonData)

DateDecodingStrategy określa, jak JSONDecoder interpretuje ciągi znaków z datami. Najczęściej używany jest .iso8601 — standardowy format REST API. Zagnieżdżony enum OrderStatus jest automatycznie dekodowany z wartości ciągów JSON. Pozwala to uniknąć magicznych liczb i czyni kod samodokumentującym się — status zamówienia zawsze ma ściśle określony zestaw wartości.

Property Wrappers w Codable

Począwszy od Swift 4.2, Codable obsługuje property wrappers do niestandardowej deserializacji poszczególnych właściwości. @DefaultValue — popularny wrapper, ustawiający wartość domyślną, jeśli pole jest nieobecne w JSON. @LosslessString przekształca ciąg znaków w liczbę i odwrotnie. Jest to szczególnie przydatne, gdy serwer przesyła id w postaci ciągu „123”, a model oczekuje Int. Property wrappers redukują standardowy kod w init(from:) i czynią modele czystszymi.

Deserializacja na Androidzie

Na Androidzie wybór biblioteki deserializacji zależy od języka i wymagań projektu. Gson od Google — najpopularniejsza opcja, działająca przez reflection, ale mająca problemy z wydajnością na złożonych hierarchiach. Moshi od Square obsługuje zarówno reflection, jak i code generation, zużywając mniej pamięci i szybciej przetwarzając duże odpowiedzi. kotlinx.serialization od JetBrains — natywne rozwiązanie Kotlin z integracją w kompilatorze, niewykorzystujące reflection w ogóle.

@Serializable
data class User(
    @SerialName("user_id")
    val userId: Int,
    val name: String,
    val email: String,
    @SerialName("created_at")
    val createdAt: String
)

val json = Json { ignoreUnknownKeys = true }
val user = json.decodeFromString<User>(response)

@Serializable — adnotacja kompilatora Kotlin, aktywująca kodogenerację dla klasy. Parametr ignoreUnknownKeys zapobiega crashem, jeśli serwer przysłał pole nieobecne w modelu. Do mapowania kluczy snake_case używa się @SerialName — odpowiednika convertFromSnakeCase z iOS. Według danych JetBrains (2026), biblioteka obsługuje wieloplatformowość: ta sama klasa Serializable działa na Androidzie, iOS (KMP) i serwerowym Kotlin.

Porównanie Gson, Moshi i kotlinx.serialization

Wybór między bibliotekami sprowadza się do kompromisu szybkość-elastyczność. Gson jest dobry do prototypów i projektów w Javie — nie wymaga adnotacji i działa „od ręki”. Moshi zajmuje środkową pozycję: codegen przez @JsonClass(generateAdapter = true) daje szybkość zbliżoną do kotlinx.serialization, a tryb reflection — elastyczność Gson. kotlinx.serialization — najszybsza opcja dla czystych projektów Kotlin, ale wymaga Kotlin 1.4+ i wtyczki Kotlin Serialization w Gradle.

Typowe błędy i ich zapobieganie

Type mismatch — sytuacja, gdy JSON zawiera wartość jednego typu, a model oczekuje innego. Serwer wysłał ciąg „42” zamiast liczby lub liczbę 1 zamiast logicznej true. Na iOS JSONDecoder domyślnie wyrzuci DecodingError.typeMismatch, na Androidzie Gson spróbuje przekonwertować, a Moshi i kotlinx.serialization wymagają jawnych adapterów. Rozwiązanie — używać strategii lenient lub niestandardowych deserializatorów dla konkretnych pól.

Brakujące pola i nullable

Gdy serwer nie dołącza opcjonalnego pola, kod pada z błędem. Optional w Swift i typy nullable w Kotlin rozwiązują problem: jeśli pole jest null lub nieobecne w JSON, właściwość otrzymuje wartość nil/null, a aplikacja kontynuuje działanie. Dla pól obowiązkowych warto sprawdzać ich obecność na poziomie klienta API przed deserializacją. Moshi i kotlinx.serialization domyślnie wymagają wszystkich pól — oznaczenie nullable i wartości domyślne usuwają to ograniczenie.

Niezgodność wersji API

Zmiana struktury JSON na serwerze — częste źródło crashy w produkcji. Standardową praktyką jest wersjonowanie schematu przez pole version w obiekcie głównym i obsługa 2-3 poprzednich wersji po stronie klienta. kotlinx.serialization pozwala zadeklarować wiele modeli dla różnych wersji i wybrać odpowiedni na podstawie pola version po wstępnym parsowaniu do JsonElement. Dodatkową ochroną jest ignoreUnknownKeys dla nowych pól i wartości domyślne dla pól, które mogą zostać usunięte.

Logowanie błędów deserializacji — obowiązkowa praktyka w produkcji. Owiń decode w do/catch, loguj surowy JSON i typ oczekiwanego modelu w Crashlytics lub Sentry. Pozwoli to szybko określić, które pole którego API się zepsuło i na której wersji aplikacji. Bez logowania błąd deserializacji wygląda jak tajemniczy crash bez kontekstu.