Dataserialisering i mobil utveckling — vad det är, format och arbetsprincip

Vad är serialisering?

Serialisering är processen att omvandla ett objekt i arbetsminnet till en linjär sekvens av byte eller tecken som kan överföras över nätverk, sparas i en fil eller skickas till en annan process. Utan serialisering är nätverkskommunikation, tillståndslagring och kommunikation mellan processer inte möjlig.

Serialisering omfattar två motsatta processer. Den direkta processen (serialisering) packar data i ett format för överföring. Den omvända processen (deserialisering) återställer data tillbaka till ett objekt. Deserialisering är kritisk för säkerheten: felaktiga indata kan leda till sårbarheter i applikationen.

Vid utveckling av mobila applikationer används serialisering överallt: skicka förfrågningar till servern och bearbeta svar, spara applikationstillstånd vid skärmrotation, cacha data på disken och överföra data mellan skärmar via Intent (Android) eller Segue (iOS).

Huvudsakliga uppgifter för serialisering

• Nätverkskommunikation — dataöverföring mellan klient och server
• Tillståndslagring — spara och återställa applikationsdata
• Cachning — spara resultat av förfrågningar för offline-åtkomst
• Plattformsoberoende — datautbyte mellan system på olika språk
• Loggning — serialisering av objekt för skrivning till loggar

Huvudsakliga serialiseringsformat

Serialiseringsformat delas in i text- och binära format. Textformat (JSON, XML) är läsbara för människor och kräver inga verktyg för visning. Binära format (Protobuf, FlatBuffers, MessagePack) är mer kompakta och snabbare, men inte läsbara utan deserialisering. Valet av format är en kompromiss mellan prestanda och bekvämlighet vid felsökning.

Förutom JSON, XML och Protobuf finns specialiserade format: FlatBuffers från Google för spel och AR, MessagePack — kompakt binärt alternativ till JSON, Avro från Apache för stora data i Kafka, YAML — konfigurationsformat med stöd för kommentarer.

Serialisering i mobil utveckling

Serialisering på mobila plattformar har sin egen specificitet: begränsad trafik, svagare processorer och behovet av att spara tillstånd vid skärmrotation. På Android används Gson, Moshi, Kotlinx Serialization. På iOS — Codable, JSONSerialization, PropertyListEncoder. Rätt val av bibliotek påverkar kritiskt applikationens prestanda.

Kotlinx Serialization — ett modernt bibliotek från JetBrains för Kotlin Multiplatform Mobile. Det stödjer JSON, Protobuf, CBOR och anpassade format. Kodgenerering sker i kompileringsfasen genom Kotlin Serialization-plugin, vilket säkerställer hög prestanda utan reflektion.

Kotlinx Serialization (Kotlin Multiplatform)

Biblioteket Kotlinx Serialization använder annoteringen @Serializable för klasser och en kompilatorplugin för att generera serialiserare. Detta säkerställer hög prestanda och typsäkerhet. Standardformat är JSON, men andra format stöds också via ytterligare moduler.

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)

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

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

Codable på iOS (Swift)

Protokollet Codable — den inbyggda serialiseringsmekanismen i Swift. Det kombinerar protokollen Encodable (serialisering) och Decodable (deserialisering). JSONEncoder och JSONDecoder bearbetar automatiskt nästlade strukturer, arrayer, valfria värden och anpassade nycklar via 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)

Prestanda och jämförelse av format

Prestanda hos serialiseringsformat utvärderas enligt tre mått: meddelandestorlek, serialiseringshastighet och deserialiseringshastighet. För mobila applikationer är alla tre kritiska: storleken påverkar trafik och laddningstid, hastigheten — gränssnittets responsivitet och applikationens starttid.

Protobuf och FlatBuffers visar bäst resultat tack vare binär representation. FlatBuffers utmärker sig genom att inte kräva ett separat deserialiseringssteg — data läses direkt från den binära bufferten, vilket är idealiskt för spel och AR-applikationer med krav på minimal latens. JSON förblir det mest populära formatet för REST API, trots lägre prestanda, tack vare enkelhet och universalitet.

Jämförande tester

Praktiska tester på en uppsättning av 1000 användarobjekt visar: Protobuf skapar meddelanden på 12 KB (JSON — 85 KB, XML — 120 KB). Serialiseringstid: Protobuf — 2 ms, JSON — 8 ms, XML — 25 ms. Dessa siffror gör binära format att föredra för system med hög belastning och mobila applikationer med begränsad trafik.

Exempel på dataserialisering

Exempel demonstrerar serialisering av samma objekt i olika format. Detta hjälper till att visuellt jämföra storlek och läsbarhet. Samma User-objekt kommer att serialiseras i JSON, XML och Protobuf — det syns tydligt att JSON är mer kompakt än XML, och Protobuf är mest kompakt och samtidigt oläsligt.

Ett objekt i tre format

JSON — minimalistisk syntax, nycklar inom citationstecken, värden av olika typer. Tar 80 tecken. Läsbarhet hög, visuell struktur tydlig. Lämpligt för API där utvecklings- och felsökningshastighet är viktig.

XML — varje element är inslaget i en öppnings- och stängningstagg. Tar 150 tecken. Läsbarhet medel, struktur strikt. Lämpligt för dokumentflöden och system som kräver validering via XSD.

Protobuf — binärt, 32 byte för dessa data. Oläsligt — kräver deserialisering för visning. Minimal storlek gör det idealiskt för system med hög belastning och mobila applikationer.

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

Bästa praxis för serialisering

Bästa praxis hjälper till att undvika typiska misstag och välja rätt serialiseringsstrategi för projektet. Att följa dessa rekommendationer förbättrar prestanda, säkerhet och kodunderhåll.

Rekommendationer för mobil utveckling

1. Välj format efter scenario — JSON för REST API, Protobuf för gRPC och mikrotjänster
2. Undvik Java Serializable — långsam och osäker mekanism, använd Kotlinx Serialization eller Moshi
3. Ignorera okända nycklar — konfigurera parsern att hoppa över fält som inte finns i modellen
4. Cacha deserialiserad data — undvik upprepad parsning av samma data
5. Validera indata — kontrollera gränser och typer vid deserialisering

Säkerhet och serialisering

Serialiseringssäkerhet — en kritisk aspekt, särskilt vid deserialisering av data från otillförlitliga källor. Deserialiseringsattacker kan leda till fjärrkörexvering (RCE), en av de farligaste sårbarheterna i webb- och mobila applikationer. De mest kända fallen är kopplade till Java Serializable och Python pickle.

Protobuf och JSON har inbyggt skydd mot sådana attacker, eftersom de bara arbetar med data, inte med godtyckliga objekt. Java Serializable kan däremot återställa vilken klass som helst som är tillgänglig i classpath, vilket gör det farligt för att ta emot data från externa källor. På Android rekommenderas att använda Kotlinx Serialization eller Moshi istället för standard Java Serialization.

Ytterligare säkerhetsåtgärder: sätt en gräns för storleken på indata, validera schemat före deserialisering, lita inte på Content-Type från HTTP-rubriker, använd en vitlista (allowlist) för tillåtna klasser. Uppdatera serialiseringsbibliotek regelbundet, eftersom sårbarheter i dem upptäcks och åtgärdas periodiskt.