Deserialization: ano ito, proseso ng pagbawi ng data

Ano ang deserialization?

Deserialization — ang proseso ng pag-convert ng byte stream o structured text sa isang object ng programming language. Sa mobile development, ang prosesong ito ay nangyayari sa tuwing ang application ay tumatanggap ng tugon mula sa server: ang JSON string ay nagiging instance ng klase na User, Order o Product. Ang katatagan ng mga screen na nagpapakita ng data sa user ay direktang nakadepende sa kawastuhan ng deserialization.

Pagkakaiba mula sa serialization

Ang serialization at deserialization ay magkasalungat na proseso, bihirang simetriko sa praktika. Serialization ay nagko-convert ng object sa string para ipadala sa server, ang deserialization ay nagbabawi ng object mula sa natanggap na string. Ang server ay maaaring magpadala ng field na wala sa modelo ng client, gumamit ng ibang format ng petsa, o magbalik ng null sa halip na numero. Ayon sa Square Engineering (2025), ang asimetrya ng format ay sanhi ng 23% ng mga error sa network layer sa Android application. Para mabawasan ang panganib, ginagamit ang schema versioning at mahigpit na kontrata sa pamamagitan ng OpenAPI.

Mga format ng data para sa deserialization

JSON ay nananatiling pinakasikat na format para sa mobile API dahil sa pagiging nababasa at built-in na suporta. Protobuf mula sa Google ay ginagamit sa high-load system — ito ay 3-6 beses na mas compact kaysa JSON at mas mabilis na ma-parse, ngunit nangangailangan ng pagbuo ng code mula sa .proto file at hindi nababasa nang walang tool. XML ay mas madalang sa modernong mobile application, ngunit ginagamit sa SOAP services ng corporate system at Android configuration file. MessagePack — binary format na katulad ng JSON sa istraktura ngunit mas compact, sikat sa real-time system.

Paano gumagana ang deserialization

Ang proseso ng deserialization ay dumadaan sa tatlong yugto. Una tokenization ay hinahati ang raw text sa mga lexeme: mga key, string, numero at separator. Pagkatapos syntactic analysis ay sinusuri ang kawastuhan ng istraktura — kung sarado ang mga bracket, kung tama ang uri ng panipi, kung ang format ay sumusunod sa RFC 8259. Ang huling yugto ay pamamahagi sa object model ng application, kung saan ang bawat JSON key ay binibigyan ng property ng klase na isinasaalang-alang ang estratehiya ng pagpangalan.

Reflection vs Code generation

Sa mobile development, dalawang approach sa pamamahagi ang nabuo. Reflection (Gson, JSONSerialization) ay sinusuri ang istraktura ng klase sa runtime sa pamamagitan ng Java Reflection API o Objective-C runtime — ito ay flexible at hindi nangangailangan ng karagdagang configuration, ngunit mas mabagal at gumagamit ng mas maraming memory. Code generation (Moshi codegen, kotlinx.serialization, Codable) ay bumubuo ng code sa yugto ng compilation: mas mabilis, mas ligtas sa uri, at hindi naglalantad ng internal na istraktura sa pamamagitan ng reflection. Inirerekomenda ng JetBrains at Square ang code generation para sa production build — ang pagtaas ng performance ay umaabot ng 2-4 beses sa mga benchmark ng 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)

Halimbawa ng deserialization ng JSON sa User model sa Swift. Ang estratehiyang convertFromSnakeCase ay awtomatikong nagko-convert ng snake_case API key sa camelCase property ng modelo — karaniwang kasanayan sa iOS projects. Ang parameter na data ay ang raw bytes ng tugon ng server, na nakuha sa pamamagitan ng URLSession. Ang paghawak ng error sa pamamagitan ng try ay nagpapahintulot na mahuli ang hindi valid na JSON nang hindi nagca-crash ang application.

Papel ng mga decoding strategy

Ang JSONDecoder ay sumusuporta sa apat na key strategy: useDefaultKeys (eksaktong tugma), convertFromSnakeCase (snake_case → camelCase), custom (closure) at convertFromKebabCase (kebab-case → camelCase). Para sa mga petsa, available ang .iso8601, .secondsSince1970, .millisecondsSince1970 at custom na dateFormatter. Ang pagpili ng tamang estratehiya ay ang unang hakbang patungo sa matatag na deserialization, na pumipigil sa karamihan ng mga error sa hindi pagkakatugma ng format.

Deserialization sa iOS

JSONDecoder — ang karaniwang mekanismo ng deserialization sa iOS SDK na gumagana sa Codable protocol. Ang JSONDecoder ay awtomatikong nagpa-parse ng JSON sa mga instance ng struct o class, sumusuporta sa mga nested object, array at primitive na uri. Para sa custom na logic, ginagamit ang method na init(from: Decoder) — ito ay nagpapahintulot na hawakan ang hindi karaniwang mga format, mga field na hindi kasama sa mas lumang bersyon ng API, o pagsamahin ang maramihang JSON key sa iisang property.

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 ay tumutukoy kung paano binibigyang-kahulugan ng JSONDecoder ang mga string na may petsa. Pinakamadalas gamitin ang .iso8601 — ang karaniwang format ng REST API. Ang nested enum na OrderStatus ay awtomatikong nade-decode mula sa JSON string values. Ito ay umiiwas sa magic numbers at ginagawang self-documenting ang code — ang status ng order ay laging may mahigpit na tinukoy na hanay ng mga halaga.

Property Wrappers sa Codable

Simula sa Swift 4.2, sinusuportahan ng Codable ang property wrappers para sa custom na deserialization ng mga indibidwal na property. @DefaultValue — sikat na wrapper na nagtatakda ng default na halaga kung ang field ay wala sa JSON. @LosslessString ay nagko-convert ng string sa numero at vice versa. Ito ay lalong kapaki-pakinabang kapag ang server ay nagpapadala ng id bilang string „123” at ang modelo ay umaasa ng Int. Binabawasan ng property wrappers ang boilerplate code sa init(from:) at ginagawang mas malinis ang mga modelo.

Deserialization sa Android

Sa Android, ang pagpili ng deserialization library ay depende sa wika at pangangailangan ng proyekto. Gson mula sa Google — ang pinakakaraniwang opsyon, na gumagana sa pamamagitan ng reflection, ngunit may problema sa performance sa kumplikadong hierarchies. Moshi mula sa Square ay sumusuporta sa parehong reflection at code generation, gumagamit ng mas kaunting memory at mas mabilis na nagproseso ng malalaking tugon. kotlinx.serialization mula sa JetBrains — native na Kotlin solution na may integration sa compiler na hindi gumagamit ng reflection.

@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 — anotasyon ng Kotlin compiler na nagpapagana ng code generation para sa klase. Ang parameter na ignoreUnknownKeys ay pumipigil sa pag-crash kung ang server ay nagpadala ng field na wala sa modelo. Para sa pagmamapa ng snake_case key, ginagamit ang @SerialName — katumbas ng convertFromSnakeCase mula sa iOS. Ayon sa JetBrains (2026), sinusuportahan ng library ang multi-platform: ang parehong Serializable class ay gumagana sa Android, iOS (KMP) at server Kotlin.

Paghahambing ng Gson, Moshi at kotlinx.serialization

Ang pagpili sa pagitan ng mga library ay bumababa sa kompromiso ng bilis-flexibility. Gson ay mabuti para sa mga prototype at proyekto sa Java — hindi nangangailangan ng anotasyon at gumagana „handa na”. Moshi ay nasa gitnang posisyon: ang codegen sa pamamagitan ng @JsonClass(generateAdapter = true) ay nagbibigay ng bilis na malapit sa kotlinx.serialization, at ang reflection mode ay nagbibigay ng flexibility ng Gson. kotlinx.serialization — ang pinakamabilis na opsyon para sa purong Kotlin projects, ngunit nangangailangan ng Kotlin 1.4+ at Kotlin Serialization plugin sa Gradle.

Mga karaniwang error at pag-iwas sa mga ito

Type mismatch — sitwasyon kung saan ang JSON ay naglalaman ng halaga ng isang uri at ang modelo ay umaasa ng ibang uri. Nagpadala ang server ng string na „42” sa halip na numero o numero 1 sa halip na boolean true. Sa iOS, ang JSONDecoder ay magtatapon ng DecodingError.typeMismatch bilang default, sa Android ang Gson ay susubukang i-convert, at ang Moshi at kotlinx.serialization ay nangangailangan ng mga explicit adapter. Solusyon — gumamit ng lenient strategy o custom na deserializer para sa mga partikular na field.

Mga nawawalang field at nullable

Kapag hindi isinama ng server ang isang opsyonal na field, ang code ay nagca-crash na may error. Optional sa Swift at nullable na uri sa Kotlin ay lumulutas ng problema: kung ang field ay null o wala sa JSON, ang property ay nakakakuha ng halagang nil/null at ang application ay patuloy na gumagana. Para sa mga mandatoryong field, mainam na suriin ang kanilang presensya sa antas ng API client bago ang deserialization. Ang Moshi at kotlinx.serialization ay nangangailangan ng lahat ng field bilang default — ang nullable marking at default values ay nag-aalis ng limitasyong ito.

Hindi pagkakatugma ng mga bersyon ng API

Ang pagbabago ng istraktura ng JSON sa server — karaniwang pinagmumulan ng pag-crash sa produksyon. Ang karaniwang kasanayan ay schema versioning sa pamamagitan ng field na version sa root object at suporta para sa 2-3 nakaraang bersyon sa panig ng client. Ang kotlinx.serialization ay nagpapahintulot na magdeklara ng maramihang modelo para sa iba’t ibang bersyon at pumili ng angkop batay sa field na version pagkatapos ng paunang pag-parse sa JsonElement. Karagdagang proteksyon — ignoreUnknownKeys para sa mga bagong field at default values para sa mga field na maaaring alisin.

Pag-log ng mga error sa deserialization — mandatoryong kasanayan sa produksyon. Balutin ang decode sa do/catch, i-log ang raw JSON at ang inaasahang uri ng modelo sa Crashlytics o Sentry. Ito ay magbibigay-daan upang mabilis na matukoy kung aling field ng aling API ang nasira at sa aling bersyon ng application. Kung walang pag-log, ang error sa deserialization ay lilitaw bilang isang misteryosong crash na walang konteksto.