Desserialização: o que é, processo de restauração de dados

O que é desserialização?

Desserialização é o processo de converter um fluxo de bytes ou texto estruturado em um objeto de linguagem de programação. No desenvolvimento móvel, esse processo ocorre toda vez que um aplicativo recebe uma resposta do servidor: uma string JSON se torna uma instância da classe User, Order ou Product. A estabilidade das telas que exibem dados ao usuário depende diretamente da correção da desserialização.

Diferença da serialização

Serialização e desserialização são processos mutuamente inversos, raramente simétricos na prática. Serialização converte um objeto em uma string para envio ao servidor, enquanto a desserialização restaura o objeto a partir da string recebida. O servidor pode enviar um campo que não existe no modelo do cliente, usar um formato de data diferente ou retornar null em vez de um número. De acordo com Square Engineering (2025), a assimetria de formatos causa 23% dos erros da camada de rede em aplicativos Android. Para reduzir o risco, utilizam-se versionamento de esquema e especificação de contrato rigorosa via OpenAPI.

Formatos de dados para desserialização

JSON continua sendo o formato mais popular para APIs móveis devido à sua legibilidade humana e suporte nativo. Protobuf do Google é usado em sistemas de alta carga — é 3 a 6 vezes mais compacto que JSON e analisa mais rápido, mas requer geração de código a partir de arquivos .proto e não é legível sem ferramentas. XML é menos comum em aplicativos móveis modernos, embora seja usado em serviços SOAP de sistemas empresariais e arquivos de configuração do Android. MessagePack é um formato binário semelhante ao JSON em estrutura, porém mais compacto, popular em sistemas de tempo real.

Como funciona a desserialização

O processo de desserialização passa por três estágios. Primeiro, a tokenização divide o texto bruto em tokens: chaves, strings, números e delimitadores. Em seguida, a análise sintática verifica a correção da estrutura — se os colchetes estão fechados, se o tipo de aspas está correto, se o formato está em conformidade com RFC 8259. O estágio final é o mapeamento para o modelo de objetos do aplicativo, onde cada chave JSON recebe uma propriedade de classe considerando a estratégia de nomenclatura.

Reflection vs Code generation

Duas abordagens de mapeamento surgiram no desenvolvimento móvel. Reflection (Gson, JSONSerialization) analisa a estrutura da classe em tempo de execução via Java Reflection API ou Objective-C runtime — é flexível e não requer configuração adicional, mas é mais lento e consome mais memória. Code generation (Moshi codegen, kotlinx.serialization, Codable) gera código em tempo de compilação: mais rápido, seguro em termos de tipos e não expõe a estrutura interna através de reflection. JetBrains e Square recomendam code generation para builds de produção — os ganhos de desempenho chegam a 2-4 vezes nos benchmarks do 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)

Exemplo de desserialização de JSON em um modelo User em Swift. A estratégia convertFromSnakeCase converte automaticamente chaves de API em snake_case para propriedades do modelo em camelCase — uma prática padrão em projetos iOS. O parâmetro data são os bytes brutos da resposta do servidor obtidos via URLSession. O tratamento de erros através de try permite capturar JSON malformado sem travar o aplicativo.

O papel das estratégias de decodificação

JSONDecoder suporta quatro estratégias de chaves: useDefaultKeys (correspondência exata), convertFromSnakeCase (snake_case → camelCase), custom (closure) e convertFromKebabCase (kebab-case → camelCase). Para datas, estão disponíveis .iso8601, .secondsSince1970, .millisecondsSince1970 e um dateFormatter personalizado. Escolher a estratégia correta é o primeiro passo para uma desserialização robusta, prevenindo a maioria dos erros de incompatibilidade de formatos.

Desserialização no iOS

JSONDecoder é o mecanismo padrão de desserialização no SDK do iOS, funcionando com o protocolo Codable. JSONDecoder analisa automaticamente JSON em instâncias de struct ou class, suportando objetos aninhados, arrays e primitivos. Para lógica personalizada, utiliza-se o método init(from: Decoder) — ele permite lidar com formatos não padronizados, campos ausentes em uma versão antiga da API ou combinar várias chaves JSON em uma única propriedade.

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 determina como o JSONDecoder interpreta strings de data. .iso8601 é o mais utilizado — o formato padrão de APIs REST. O enum aninhado OrderStatus é decodificado automaticamente a partir de valores de string JSON. Isso evita números mágicos e torna o código autodocumentado — o status do pedido sempre tem um conjunto estritamente definido de valores.

Property Wrappers no Codable

Desde o Swift 4.2, o Codable suporta property wrappers para desserialização personalizada de propriedades individuais. @DefaultValue é um wrapper popular que define um valor padrão se o campo estiver ausente no JSON. @LosslessString converte uma string em número e vice-versa. Isso é especialmente útil quando o servidor envia um id como a string "123" mas o modelo espera um Int. Property wrappers reduzem código boilerplate em init(from:) e tornam os modelos mais limpos.

Desserialização no Android

No Android, a escolha da biblioteca de desserialização depende do idioma e dos requisitos do projeto. Gson do Google é a opção mais comum, funcionando via reflection, mas com problemas de desempenho em hierarquias complexas. Moshi da Square suporta tanto reflection quanto code generation, consumindo menos memória e processando grandes respostas mais rapidamente. kotlinx.serialization da JetBrains é uma solução nativa Kotlin com integração ao compilador que não usa 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 é uma anotação do compilador Kotlin que ativa a geração de código para a classe. O parâmetro ignoreUnknownKeys evita falhas se o servidor enviar um campo ausente no modelo. Para mapear chaves snake_case, usa-se @SerialName — o equivalente ao convertFromSnakeCase do iOS. De acordo com JetBrains (2026), a biblioteca suporta multiplataforma: a mesma classe Serializable funciona no Android, iOS (KMP) e Kotlin do lado do servidor.

Comparação entre Gson, Moshi e kotlinx.serialization

A escolha entre bibliotecas se resume a um compromisso entre velocidade e flexibilidade. Gson é bom para protótipos e projetos Java — não requer anotações e funciona imediatamente. Moshi ocupa uma posição intermediária: codegen via @JsonClass(generateAdapter = true) oferece velocidade próxima à kotlinx.serialization, enquanto o modo reflection oferece a flexibilidade do Gson. kotlinx.serialization é a opção mais rápida para projetos Kotlin puros, mas requer Kotlin 1.4+ e o plugin Kotlin Serialization no Gradle.

Erros típicos e sua prevenção

Type mismatch é uma situação em que o JSON contém um valor de um tipo, mas o modelo espera outro. O servidor enviou a string "42" em vez de um número, ou o número 1 em vez de true booleano. No iOS, o JSONDecoder lançará DecodingError.typeMismatch por padrão; no Android, o Gson tentará converter, enquanto Moshi e kotlinx.serialization exigem adaptadores explícitos. A solução é usar estratégias lenient ou desserializadores personalizados para campos específicos.

Campos ausentes e nullable

Quando o servidor não inclui um campo opcional, o código falha com um erro. Campos Optional em Swift e tipos nullable em Kotlin resolvem o problema: se o campo é null ou está ausente no JSON, a propriedade recebe nil/null e o aplicativo continua funcionando. Para campos obrigatórios, vale verificar sua presença no nível do cliente API antes da desserialização. Moshi e kotlinx.serialization exigem todos os campos por padrão — a marcação nullable e valores padrão removem essa restrição.

Incompatibilidade de versões de API

Alterações na estrutura JSON no servidor são uma fonte comum de falhas em produção. A prática padrão é o versionamento de esquema através de um campo version no objeto raiz e suporte a 2-3 versões anteriores no cliente. kotlinx.serialization permite declarar vários modelos para diferentes versões e selecionar o correto com base no campo version após a análise inicial em JsonElement. Proteção adicional inclui ignoreUnknownKeys para novos campos e valores padrão para campos que podem ser removidos.

Registro de erros de desserialização é uma prática obrigatória em produção. Envolva decode em do/catch, registre o JSON bruto e o tipo de modelo esperado no Crashlytics ou Sentry. Isso permitirá identificar rapidamente qual campo de qual API quebrou e em qual versão do aplicativo. Sem registro, um erro de desserialização parece uma falha misteriosa sem contexto.