Tappar anslutningen — vad det är, typiska orsaker och lösningsmetoder

Vad betyder "tappar anslutningen" i mobila appar?

Tappar anslutningen — en användarterm som beskriver situationen när appen förlorar anslutningen till servern, slutar svara på åtgärder eller avslutas med ett fel. I teknisk mening kan det vara: nätverksfel (timeout, DNS failure), ANR (blockering av UI-tråden), crash (ohanterat undantag) eller race condition (kapplöpningstillstånd).

För användaren ser alla dessa scenarier likadana ut: appen slutar fungera. Skillnaden för utvecklaren ligger i tillvägagångssättet för diagnos och reparation. Nätverksfel löses med retry-mekanismer, ANR — genom att flytta operationer utanför UI-tråden, crash — genom undantagshantering.

Enligt Crittercism (nu Apteligent) förlorar en genomsnittlig mobil app 1-2% av sina användare vid varje krasch. För en app med 1 miljon användare innebär detta 10-20 tusen förlorade installationer per bugg. Detta är särskilt kritiskt för appar inom finans- och medicinsektorn.

Huvudorsaker till anslutningsförlust

Instabilt nätverk — mobila enheter växlar ständigt mellan Wi-Fi och mobilt nätverk, går in i områden utan täckning (tunnelbana, hiss, källare). Varje växling orsakar tillfällig anslutningsförlust som appen måste hantera korrekt.

Timeoutar — om servern inte svarar inom den angivna tiden (vanligtvis 10-30 sekunder) kastar klienten SocketTimeoutException. Långa timeoutar utan återkoppling uppfattas av användaren som frysning. Det rekommenderas att ställa in timeout på högst 15 sekunder.

val client = OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .writeTimeout(15, TimeUnit.SECONDS)
    .retryOnConnectionFailure(true)
    .build()

Kapplöpningstillstånd (race condition) — uppstår när flera trådar samtidigt läser och skriver samma data utan synkronisering. Till exempel kan inläsning av data från cachen i UI-tråden parallellt med uppdatering av cachen från nätverket leda till visning av föråldrade eller felaktiga data.

• Ohanterade undantag i callback eller coroutine leder till att appen kraschar
• Memory pressure — systemet dödar appen vid minnesbrist för förgrundsappen
• Lifecycle race — async operation slutförs efter att Activity/Fragment har förstörts
• UI-blockering — körning av nätverk eller databas på huvudtråden orsakar ANR efter 5 sekunder

Arkitektur för feltoleranta applikationer

Offline-first — arkitekturmönster där lokal lagring (Room, CoreData) är den enda sanningskällan. Nätverket används för datasynkronisering i bakgrunden. Användaren ser alltid aktuell data från den lokala cachen, även utan nätverk.

Repository pattern — en enda ingångspunkt för data som avgör om data ska hämtas från nätverket eller cachen. Repositoriet abstraherar datakällan från ViewModel och UI. Vid nätverksfel växlar repositoriet automatiskt till den lokala källan.

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUsers(): Result<List<User>> {
        return try {
            val remote = api.fetchUsers()
            dao.insertAll(remote)
            Result.success(remote)
        } catch (e: IOException) {
            val cached = dao.getAll()
            if (cached.isNotEmpty()) {
                Result.success(cached) // returnera cache vid nätverksfel
            } else {
                Result.failure(e)
            }
        }
    }
}

Circuit Breaker — mönster för att skydda servern från en översvämning av begäranden när den är otillgänglig. Efter N på varandra följande fel öppnas brytaren och alla begäranden returnerar omedelbart fel utan anslutningsförsök. Efter en angiven time-out går brytaren över till halvöppet tillstånd för en testbegäran.

Hur hanterar man nätverksfel?

Exponential backoff — standard retry-mekanism. Efter första misslyckandet vänta 1 sekund, efter andra — 2 sekunder, sedan 4, 8, 16. Begränsa maximalt antal försök (vanligtvis 3-5) för att inte överbelasta servern och batteriet.

Användaråterkoppling — vid nätverksfel visa ett begripligt meddelande: "Ingen anslutning", "Servern är tillfälligt otillgänglig", "Kontrollera internet". Använd Snackbar eller Inline State View. Visa aldrig tekniska fel (HTTP 500, SocketException) för användaren.

ConnectivityManager — Android API för nätverksövervakning. Låt appen reagera på förändringar: vid nätverksförlust visa en placeholder, vid återställning — uppdatera automatiskt data. I iOS använd NWPathMonitor från Network-ramverket.

class NetworkMonitor(private val context: Context) {
    private val manager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

    fun isOnline(): Boolean {
        val network = manager.activeNetwork ?: return false
        val caps = manager.getNetworkCapabilities(network) ?: return false
        return caps.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    }
}

Övervaknings- och loggningsverktyg

Crashlytics (Firebase) — standardverktyg för krashrapportering för mobila appar. Samlar stacktrace för alla ohanterade undantag, OS-version, enhetsmodell och kraschens tidpunkt. Möjliggör gruppering av fel och tilldelning av ansvariga för åtgärder.

Sentry — alternativ till Crashlytics med stöd för prestandaövervakning. Möjliggör spårning av specifika transaktioner (t.ex. "användarautentisering") och att se vid vilket steg felet uppstod. Performance tracing hjälper att skilja nätverks-timeoutar från buggar i applogiken.

Timber — loggningsbibliotek för Android med automatisk tillägg av taggar per klass. I debug-bygge logga alla nätverksbegäranden och svar. I release-bygge — endast fel och varningar via Crashlytics.setCustomLog.

Enligt Firebase Summit 2023 minskar appar som implementerat Crashlytics + Performance Monitoring den genomsnittliga tiden för upptäckt och reparation av kritiska buggar från 3 dagar till 4 timmar. Det rekommenderas att ställa in larm för varje krasch med en frekvens högre än 0,1% av aktiva användare.