Bağlantı kopması — tipik nedenler ve çözüm yöntemleri

Mobil uygulamalarda “bağlantı kopması” ne anlama gelir?

Bağlantı kopması — uygulamanın sunucuyla bağlantısını kaybettiği, eylemlere yanıt vermeyi bıraktığı veya bir hatayla sonlandığı durumu tanımlayan bir kullanıcı terimidir. Teknik olarak bu şunlar olabilir: ağ hatası (zaman aşımı, DNS hatası), ANR (UI iş parçacığının donması), çökme (işlenmemiş istisna) veya yarışma koşulu (race condition).

Kullanıcının bakış açısından, tüm bu senaryolar aynı görünür: uygulama çalışmayı durdurur. Geliştiriciler için fark, tanı ve düzeltme yaklaşımındadır. Ağ hataları yeniden deneme mekanizmalarıyla, ANR işlemlerin UI iş parçacığından taşınmasıyla, çökmeler istisna işlemeyle çözülür.

Crittercism (şimdi Apteligent)’e göre, bir mobil uygulama her çökmede ortalama %1–2 oranında kullanıcı kaybeder. 1 milyon kullanıcılı bir uygulama için bu, tek bir hata başına 10–20 bin kayıp kurulum anlamına gelir. Bu özellikle finans ve tıp sektörlerindeki uygulamalar için kritiktir.

Bağlantı kaybının ana nedenleri

Dengesiz ağ — mobil cihazlar sürekli olarak Wi-Fi ve mobil ağ arasında geçiş yapar, kapsama alanı olmayan bölgelere (metro, asansör, bodrum) girer. Her geçiş, uygulamanın doğru şekilde ele alması gereken geçici bir bağlantı kaybına neden olur.

Zaman aşımları — sunucu belirlenen zaman aşımı (genellikle 10–30 saniye) içinde yanıt vermezse, istemci SocketTimeoutException fırlatır. Geri bildirim olmadan uzun zaman aşımları kullanıcı tarafından donma olarak algılanır. Zaman aşımının 15 saniyeden fazla olmaması önerilir.

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

Yarışma koşulu (race condition) — birden çok iş parçacığının eşzamanlı olarak aynı verileri senkronizasyon olmadan okuması ve yazmasıyla oluşur. Örneğin, ağdan önbelleği güncellerken UI iş parçacığında önbellekten veri yüklemek, güncel olmayan veya yanlış verilerin görüntülenmesine yol açabilir.

• İşlenmemiş istisnalar bir geri arama veya coroutine içinde uygulama çökmesine yol açar
• Bellek baskısı — ön plandaki uygulama için yeterli bellek olmadığında sistem uygulamayı öldürür
• Yaşam döngüsü yarışı — Activity/Fragment yok edildikten sonra bir async işlem tamamlanır
• UI blokajı — ana iş parçacığında ağ veya veritabanı işlemleri yapmak 5 saniye sonra ANR’ye neden olur

Hataya dayanıklı uygulamalar için mimari

Offline-first — yerel depolamanın (Room, CoreData) tek gerçek kaynağı olduğu bir mimari desendir. Ağ, arka planda veri senkronizasyonu için kullanılır. Kullanıcı, ağ bağlantısı olmasa bile yerel önbellekten her zaman güncel verileri görür.

Repository deseni — verilerin ağdan mı yoksa önbellekten mi alınacağına karar veren tek bir giriş noktasıdır. Repository, ViewModel ve UI’dan veri kaynağını soyutlar. Ağ hatası durumunda, repository otomatik olarak yerel kaynağa geçer.

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) // return cache on network error
            } else {
                Result.failure(e)
            }
        }
    }
}

Devre Kesici (Circuit Breaker) — sunucu kullanılamadığında onu istek yağmurundan koruyan bir desendir. Ardışık N hatadan sonra devre kesici açılır ve tüm istekler bağlantı kurmayı denemeden hemen bir hata döndürür. Belirli bir zaman aşımından sonra, devre kesici bir test isteği için yarı açık duruma geçer.

Ağ hataları nasıl ele alınır?

Üstel geri çekilme (Exponential backoff) — standart bir yeniden deneme mekanizmasıdır. İlk başarısızlıktan sonra 1 saniye bekleyin; ikinciden sonra 2 saniye; ardından 4, 8, 16. Sunucuyu ve pili aşırı yüklememek için maksimum yeniden deneme sayısını (genellikle 3–5) sınırlayın.

Kullanıcı geri bildirimi — ağ hatasında net bir mesaj gösterin: “Bağlantı yok”, “Sunucu geçici olarak kullanılamıyor”, “İnternet bağlantınızı kontrol edin”. Snackbar veya Inline State View kullanın. Kullanıcıya asla teknik hataları (HTTP 500, SocketException) göstermeyin.

ConnectivityManager — ağ izleme için Android API’sidir. Uygulamanın değişikliklere tepki vermesine izin verin: bağlantı kaybında bir yer tutucu gösterin, geri yüklemede otomatik olarak verileri güncelleyin. iOS’ta Network çerçevesinden NWPathMonitor’u kullanın.

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)
    }
}

İzleme ve günlük kaydı araçları

Crashlytics (Firebase) — mobil uygulamalar için standart bir çökme raporlama aracıdır. Tüm işlenmemiş istisnaların yığın izlerini, işletim sistemi sürümünü, cihaz modelini ve çökme zamanını toplar. Hataları gruplamaya ve düzeltmeler için sorumlu kişiler atamaya olanak tanır.

Sentry — performans izleme desteğiyle Crashlytics’e bir alternatiftir. Belirli işlemleri (örneğin, “kullanıcı yetkilendirmesi”) izlemeye ve hatanın hangi adımda oluştuğunu görmeye olanak tanır. Performans izleme, ağ zaman aşımlarını uygulama mantığındaki hatalardan ayırt etmeye yardımcı olur.

Timber — sınıfa göre otomatik etiket ekleme özelliğine sahip Android için bir günlük kaydı kütüphanesidir. Hata ayıklama yapılarında tüm ağ isteklerini ve yanıtlarını kaydedin. Sürüm yapılarında, Crashlytics.setCustomLog aracılığıyla yalnızca hataları ve uyarıları kaydedin.

Firebase Summit 2023’e göre, Crashlytics + Performance Monitoring’i uygulayan uygulamalar, kritik hataları tespit etme ve düzeltme ortalama süresini 3 günden 4 saate düşürür. Aktif kullanıcıların %0,1’inden daha sık görülen her çökme için uyarılar ayarlamanız önerilir.