Uziladi — bu nima, odatiy sabablari va hal qilish usullari

Mobil ilovalarda "uziladi" nimani anglatadi?

Uziladi — foydalanuvchi atamasi bo'lib, ilova server bilan aloqani yo'qotganda, harakatlarga javob bermasa yoki xato bilan tugasa, vaziyatni tavsiflaydi. Texnik jihatdan bu bo'lishi mumkin: tarmoq xatosi (timeout, DNS failure), ANR (UI oqimining bloklanishi), crash (boshqarilmagan istisno) yoki race condition (poyga holati).

Foydalanuvchi uchun bu stsenariylarning barchasi bir xil ko'rinadi: ilova ishlashni to'xtatadi. Dasturchi uchun farq diagnostika va tuzatish yondashuvidadir. Tarmoq xatolari retry mexanizmlari bilan, ANR — operatsiyalarni UI oqimidan chiqarish bilan, crash — istisnolarni boshqarish bilan hal qilinadi.

Crittercism (hozir Apteligent) ma'lumotlariga ko'ra, o'rtacha mobil ilova har bir ishdan chiqishda foydalanuvchilarning 1-2% ini yo'qotadi. 1 million foydalanuvchiga ega ilova uchun bu bitta xato uchun 10-20 ming yo'qotilgan o'rnatishni anglatadi. Bu, ayniqsa, moliyaviy va tibbiy sektordagi ilovalar uchun juda muhimdir.

Aloqa yo'qolishining asosiy sabablari

Beqaror tarmoq — mobil qurilmalar doimiy Wi-Fi va mobil tarmoq o'rtasida almashadi, qamrovsiz zonalarga (metro, lift, yerto'la) kiradi. Har bir almashish vaqtincha aloqa yo'qolishiga sabab bo'ladi, ilova buni to'g'ri boshqarishi kerak.

Taymautlar — agar server belgilangan vaqt ichida (odatda 10-30 soniya) javob bermasa, mijoz SocketTimeoutException tashlaydi. Uzoq taymautlar qayta aloqasiz foydalanuvchi tomonidan muzlash sifatida qabul qilinadi. Taymautni 15 soniyadan ko'p bo'lmagan qilib o'rnatish tavsiya etiladi.

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

Poyga holati (race condition) — bir nechta oqim bir vaqtning o'zida sinxronizatsiyasiz bir xil ma'lumotlarni o'qib va yozganda yuzaga keladi. Masalan, UI oqimida keshdan ma'lumotlarni yuklash tarmoqdan keshnini yangilash bilan parallel ravishda eskirgan yoki noto'g'ri ma'lumotlarning ko'rsatilishiga olib kelishi mumkin.

• Boshqarilmagan istisnolar callback yoki coroutine-da ilovaning ishdan chiqishiga olib keladi
• Xotira bosimi — tizim oldingi plandagi ilova uchun xotira yetishmasligida ilovani o'ldiradi
• Lifecycle race — async operatsiya Activity/Fragment yo'q qilinganidan keyin tugallanadi
• UI bloklanishi — tarmoq yoki ma'lumotlar bazasini asosiy oqimda bajarish 5 soniyadan keyin ANRga sabab bo'ladi

Bardoshli ilovalar uchun arxitektura

Offline-first — mahalliy xotira (Room, CoreData) yagona haqiqat manbai bo'lgan arxitektura namunasi. Tarmoq fon ma'lumotlarini sinxronizatsiya qilish uchun ishlatiladi. Foydalanuvchi tarmoq bo'lmaganda ham doimo mahalliy keshdan dolzarb ma'lumotlarni ko'radi.

Repository pattern — ma'lumotlar uchun yagona kirish nuqtasi, ma'lumotlarni tarmoq yoki keshdan olishni hal qiladi. Repozitoriy ma'lumot manbasini ViewModel va UIdan abstraksiyalaydi. Tarmoq xatosida repozitoriy avtomatik ravishda mahalliy manbaga o'tadi.

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) // tarmoq xatosida keshnı qaytar
            } else {
                Result.failure(e)
            }
        }
    }
}

Circuit Breaker — serverning mavjud bo'lmaganda so'rovlar toshqinidan himoya qilish namunasi. N ketma-ket xatodan keyin kalit ochiladi va barcha so'rovlar ulanishga urinishsiz darhol xato qaytaradi. Belgilangan taymautdan so'ng kalit sinov so'rovi uchun yarim ochiq holatga o'tadi.

Tarmoq xatolarini qanday boshqarish?

Exponential backoff — standart retry mexanizmi. Birinchi muvaffaqiyatsizlikdan so'ng 1 soniya, ikkinchidan so'ng 2 soniya, keyin 4, 8, 16 kutib turing. Maksimal urinishlar sonini cheklang (odatda 3-5), server va batareyani ortiqcha yuklamaslik uchun.

Foydalanuvchi fikr-mulohazasi — tarmoq xatosida tushunarli xabarni ko'rsating: "Aloqa yo'q", "Server vaqtincha mavjud emas", "Internetni tekshiring". Snackbar yoki Inline State View dan foydalaning. Hech qachon foydalanuvchiga texnik xatolarni (HTTP 500, SocketException) ko'rsatmang.

ConnectivityManager — tarmoqni kuzatish uchun Android API. Ilovaga o'zgarishlarga reaksiya berishga ruxsat bering: tarmoq yo'qolganda placeholder ko'rsating, tiklanishda avtomatik ma'lumotlarni yangilang. iOS da Network framework dan NWPathMonitor dan foydalaning.

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

Monitoring va loglash vositalari

Crashlytics (Firebase) — mobil ilovalar uchun standart ishdan chiqish hisoboti vositasi. Barcha boshqarilmagan istisnolarning stacktrace ini, OT versiyasini, qurilma modelini va ishdan chiqish vaqtini to'playdi. Xatolarni guruhlash va tuzatishlar uchun mas'ullarni tayinlash imkonini beradi.

Sentry — Crashlytics ga muqobil bo'lib, ishlash monitoringini qo'llab-quvvatlaydi. Muayyan tranzaksiyalarni (masalan, "foydalanuvchi autentifikatsiyasi") kuzatish va xato qaysi bosqichda sodir bo'lganini ko'rish imkonini beradi. Performance tracing tarmoq taymautlarini ilova mantiqidagi xatolardan ajratishga yordam beradi.

Timber — Android uchun sinf bo'yicha avtomatik teglar qo'shadigan loglash kutubxonasi. Debug qurilishida barcha tarmoq so'rovlari va javoblarini loglang. Release qurilishida — faqat Crashlytics.setCustomLog orqali xato va ogohlantirishlarni loglang.

Firebase Summit 2023 ma'lumotlariga ko'ra, Crashlytics + Performance Monitoring ni joriy qilgan ilovalar kritik xatolarni aniqlash va tuzatishning o'rtacha vaqtini 3 kundan 4 soatgacha qisqartiradi. Faol foydalanuvchilarning 0.1% dan ko'p chastotali har bir ishdan chiqishga ogohlantirishlar o'rnatish tavsiya etiladi.