Mobil ishlab chiqishda ishlash: bu nima, qanday ko'rsatkichlar va qanday yaxshilash

Nima uchun ilova sekin?

Ilova ishlashi to'g'ridan-to'g'ri jank (foydalanuvchi harakati va UI javobi o'rtasidagi sezilarli kechikish) bilan bog'liq. Asosiy sabablar: asosiy oqimni bloklash (UI oqimida og'ir operatsiyalar), tez-tez layout qayta chizish (overdraw), xotira oqishi (tez-tez GC), optimal bo'lmagan algoritmlar (katta ma'lumotlarda O(n²)). Frame Rate (FPS) — soniyadagi kadrlar soni. Qulay tajriba uchun barqaror 60 FPS (Android) yoki 120 FPS (iPhone Pro, iPad Pro) kerak. VSync — renderlashni ekran yangilash tezligi bilan sinxronlashtiradi.

Jank bitta kadrni renderlash 16.6 ms (60 FPS uchun) yoki 8.3 ms (120 FPS uchun) dan oshganda yuz beradi. GPU profillash (Android-da Profile GPU Rendering, iOS-da Core Animation) renderlashning qaysi bosqichlari eng ko'p vaqt olishini ko'rsatadi. Asosiy bosqichlar: Layout (elementlarni joylashtirish), Draw (chizish), Display (kadr buferiga uzatish). Eng keng tarqalgan muammo — XML-da layout inflyatsiyasi, ayniqsa murakkab ichki ConstraintLayout dan foydalanganda.

Time-to-Interactive (TTI) — ilova to'liq o'zaro aloqaga tayyor bo'lish vaqti. TTI sovuq ishga tushirish, ma'lumotlarni yuklash va kutubxonalarni ishga tushirishni o'z ichiga oladi. Google TTI 5 soniyadan kam, Apple — asosiy ekranlar uchun 2 soniyadan kam bo'lishini tavsiya qiladi. Dangasa yuklash — kontent va kutubxonalarni kechiktirib yuklash texnikasi, TTI ni yaxshilash uchun muhim. IT Sectr da biz barcha loyihalarda sukut bo'yicha dangasa ishga tushirishdan foydalanamiz.

ANR va qulash

ANR va qulash mobil ilova ishlashining asosiy dushmanlari. ANR (Application Not Responding) — asosiy oqim 5 soniyadan ko'proq bloklangan bo'lsa, Android-da paydo bo'ladigan dialog oynasi. Sabablari: UI oqimida sinxron tarmoq so'rovlari, coroutinesiz ma'lumotlar bazasi bilan ishlash, downsamplingsiz katta bitmap dekodlash, asosiy oqimda deadlock. ANR qo'ng'iroqlar steki /data/anr/traces.txt da saqlanadi va aniq bloklanish joyini aniqlash imkonini beradi.

Qulash — ilovaning kutilmagan tugashi. Android-da — Exception (Java/Kotlin) yoki Signal (mahalliy kod). iOS-da — NSException yoki signal (EXC_BAD_ACCESS — bo'shatilgan xotiraga kirish). Qulash hisoboti vositalari: Firebase Crashlytics, Sentry, BugSnag. Ular stacktrace, qurilma ma'lumotlari va takrorlash bosqichlarini to'playdi. Stack Overflow — cheksiz rekursiya tufayli qo'ng'iroqlar stekining to'lib ketishi. OutOfMemoryError — heap to'lganda.

StrictMode — oqim xavfsizligi buzilishlarini aniqlash uchun Android vositasi. Qoidalarni o'rnatish imkonini beradi: ThreadPolicy (asosiy oqimda disk/tarmoqni taqiqlash), VmPolicy (Activity, SQLite, CloseGuard oqishlarini aniqlash). StrictMode faqat debug yig'ishda yoqilishi kerak — relizda u ishlamasligi kerak. iOS-da ekvivalenti — Main Thread Checker (Xcode), avtomatik ravishda asosiy oqimda bo'lmagan UIKit chaqiruvlarini aniqlaydi.

Xotira boshqaruvi (GC, ARC, Retain Cycle)

Xotira oqishi

Xotira oqishi (Memory Leak) — ob'ekt ilova uni endi ishlatmasa ham xotirada qoladigan vaziyat. Bu to'g'ridan-to'g'ri ilova ishlashini pasaytiradi. Android-da GC (Garbage Collection) ob'ektga kuchli havola bo'lsa, uni to'plashi mumkin emas. Oddiy sabablar: Activity ga statik havolalar, tozalanmagan callback/kuzatuvchilar, tashqi sinfga yashirin havolaga ega ichki sinflar, tozalanmagan xabarlarga ega Handler. LeakCanary — avtomatik oqishni aniqlash uchun kutubxona.

Retain Cycle (Saqlash sikli)

ARC (Automatic Reference Counting) — iOS-da xotira boshqaruvi modeli. Har bir ob'ekt havola hisoblagichiga (retain count) ega. Hisoblagich nolga yetganda, xotira bo'shatiladi. Retain Cycle ikki ob'ekt bir-biriga kuchli havolalarni ushlab turganda yuz beradi (A → B va B → A). ARC hisoblagichlarni hech qachon nolga tushirmaydi. Yechim: zaif (weak) yoki egasiz (unowned) havolalar. Weak ob'ekt bo'shatilganda avtomatik ravishda nil bo'ladi. Unowned nil bo'lmaydi, lekin ob'ektning tirikligini kafolatlaydi.

GC vs ARC

GC (Garbage Collection) Android-da (Java/Kotlin) ishlaydi. GC erishib bo'lmaydigan ob'ektlarni topish va bo'shatish uchun davriy ravishda bajarishni to'xtatadi (Stop-the-World pauzasi). GC trigeri: heap ma'lum foizga to'lganda. ARC iOS-da (Swift/Objective-C) ishlaydi va pauzalarga ega emas — hisoblagichlar har bir tayinlashda atomik tarzda yangilanadi. ARC ko'proq bashorat qilinadi, lekin yuqori tayinlash chastotasida haddan tashqari retain/release operatsiyalarini to'plashi mumkin.

Zaif havola (Weak Reference) va kuchli havola (Strong Reference) — havola turi GC/ARC ob'ektni bo'shata olishini aniqlaydi. Strong Reference — bu havola mavjud ekan, ob'ekt yig'ilmaydi. Weak Reference — GC/ARC ob'ektni to'plashi mumkin; zaif havola nil bo'ladi (Swift/Java WeakReference da). Unowned Reference (Swift) — bo'shatilganda nil bo'lmaydi; ob'ekt o'lgandan keyin unga kirish qulashga sabab bo'ladi. Android-da zaif havolalar uchun java.lang.ref.WeakReference ishlatiladi.

LeakCanary orqali Android-da oqishni aniqlash misoli:

// Утечка: анонимный класс держит ссылку на Activity
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val handler = object : Handler(Looper.getMainLooper()) {
            override fun handleMessage(msg: Message) {
                // Используем `this@MainActivity`, сохраняя ссылку на Activity
                Log.d("TAG", "Handler received message")
            }
        }
        handler.sendEmptyMessageDelayed(0, 60000)
    }
}

// Исправление: статический Handler + WeakReference
class SafeHandler(activity: MainActivity) : Handler() {
    private val weakActivity =
        WeakReference(activity)

    override fun handleMessage(msg: Message) {
        weakActivity.get() ?: return
        Log.d("TAG", "Handler received message")
    }
}

Profillash (Instruments, Android Profiler)

Profillash — ilova ishlashini o'lchash jarayoni: CPU, xotira, tarmoq, energiya iste'moli. Profillashsiz ko'r-ko'rona optimallashtirish foydasiz — kodning qaysi qismi haqiqatan ham sekinligini bilmaysiz.

Instruments (Xcode) — iOS uchun eng kuchli vosita. Time Profiler qaysi funksiyalar eng ko'p CPU iste'mol qilishini ko'rsatadi. Allocations ob'ekt yaratish va bo'shatishni kuzatadi. Leaks avtomatik ravishda retain cycle larni topadi. Profillash bosqichlari: (1) Instruments ni ishga tushiring; (2) shablonni tanlang (CPU uchun Time Profiler); (3) muammoli stsenariyni bajaring; (4) qo'ng'iroqlar stekini tahlil qiling — eng keng ustun eng "issiq" funksiyadir.

Android Profiler Android Studio-ga o'rnatilgan (View → Tool Windows → Profiler). CPU Profiler har bir oqimning yukini ko'rsatadi. Memory Profiler — heap dump va ajratish kuzatuvi. Network Profiler — vaqtlar bilan barcha HTTP so'rovlari. Energy Profiler — energiya iste'moli: WakeLock, Location, Network. Batafsil kuzatish uchun Systrace (Android 10+) yoki Perfetto — mikrosekund aniqlikdagi tizim kuzatuvi ishlatiladi.

Ilovani ishga tushirish (Sovuq/Issiq/Iliq ishga tushirish)

Ilovani ishga tushirish asosiy ishlash ko'rsatkichlaridan biridir. Uch turga bo'linadi: Sovuq ishga tushirish — ilova noldan boshlanadi: jarayon yaratiladi, Application.onCreate (Android) / AppDelegate.applicationDidFinishLaunching (iOS), sinflarni yuklash, kutubxonalarni ishga tushirish. Iliq ishga tushirish — jarayon mavjud, lekin Activity/ViewController yo'q qilingan (masalan, ekranni aylantirishda yoki xotiradan qaytishda). Issiq ishga tushirish — Activity/ViewController xotirada, ilova oddiygina ko'rsatiladi (boshqa ilovadan almashish).

Sovuq ishga tushirish eng muhim ko'rsatkichdir. Android-da o'z ichiga oladi: (1) launch Activity — XML yuklash, View ishga tushirish; (2) birinchi kadr — birinchi rendergacha vaqt. Google tavsiya qiladi: launch Activity < 200 ms, birinchi kadr < 500 ms, TTI < 5 soniya. Sovuq ishga tushirishni optimallashtirish: Application.onCreate ni kamaytiring (dangasa ishga tushirish uchun coroutine), SplashScreen API (Android 12+) dan foydalaning, kutubxona ishga tushirishni kechiktiring (WorkManager, DI), keraksiz ContentProviders larni olib tashlang.

iOS-da sovuq ishga tushirish o'z ichiga oladi: Mach-O ikkilik faylini yuklash, dyld (dinamik bog'lovchi), Objective-C runtime ishga tushirish, dastur delegati, birinchi kontroller. Chrome Custom Tabs (Android) va Universal Links (iOS) — to'liq sovuq ishga tushirishsiz ilovada tashqi kontentni tez ochish texnologiyalari. Sovuq ishga tushirishni haqiqiy o'rta darajadagi qurilmalarda sinash tavsiya etiladi.

Hajm optimallashtirish

Ilova hajmi — o'rnatish va yangilanishlar uchun ishlash omilidir. Konversiyaga ta'sir qiladi: har 10 MB konversiyani 1% ga kamaytiradi. Google Play tavsiya qiladi APK hajmi 150 MB dan kam; App Store — 200 MB dan kam (mobil tarmoqlar — 100 MB). Asosiy optimallashtirish usullari: tasvirni siqish (PNG o'rniga WebP 25-35% tejaydi), vektorlashtirish (Android-da VectorDrawable, iOS-da SF Symbols), foydalanilmagan kodni olib tashlash (R8/ProGuard), foydalanilmagan resurslarni olib tashlash (lint → unused resources).

App Bundle (Android) — Google Play har bir qurilma uchun optimallashtirilgan APK yaratadigan nashr formati. App Bundle yuklab olish hajmini 20-40% kamaytiradi. Dynamic Delivery — talab bo'yicha yuklanadigan modullar (on-demand feature modules). iOS-da ekvivalenti On-Demand Resources (ODR): birinchi ishga tushirishdan keyin yuklanadigan resurslar (o'yin darajalari, videolar).

Dangasa yuklash — modullar va kutubxonalar ishga tushirishda emas, balki kerak bo'lganda yuklanadigan texnika. Split APK (Android) va App Slicing (iOS) — ilovani arxitektura uyalariga bo'lish: arm64-v8a, x86_64. Ilova hajmini optimallashtirish — doimiy jarayon: APK tarkibini tahlil qiling (Android Studio-da Analyze APK), takroriy ikonkalarni olib tashlang, bir nechta PNG zichligi o'rniga SVG dan foydalaning. IT Sectr da har bir MR uchun CI/CD da qurilish hajmi tekshiruvini kiritamiz.