Mobil İnkişafda Performans: bu nədir, hansı metrikalar və necə yaxşılaşdırmaq olar

Tətbiq niyə yavaşdır?

Tətbiq performansı birbaşa jank (istifadəçi hərəkəti ilə UI cavabı arasında nəzərə çarpan gecikmə) ilə bağlıdır. Əsas səbəblər: Əsas ipin bloklanması (UI ipində ağır əməliyyatlar), tez-tez layout yenidən çəkilməsi (overdraw), yaddaş sızmaları (tez-tez GC), optimal olmayan alqoritmlər (böyük verilərdə O(n²)). Frame Rate (FPS) — saniyədə kadr sayı. Rahat təcrübə üçün sabit 60 FPS (Android) və ya 120 FPS (iPhone Pro, iPad Pro) lazımdır. VSync — renderi ekran yeniləmə tezliyi ilə sinxronlaşdırır.

Jank tək kadrın render edilməsi 16.6 ms (60 FPS üçün) və ya 8.3 ms (120 FPS üçün) keçdikdə baş verir. GPU profilləməsi (Android-də Profile GPU Rendering, iOS-da Core Animation) render mərhələlərindən hansının ən çox vaxt apardığını göstərir. Əsas mərhələlər: Layout (elementlərin yerləşdirilməsi), Draw (çəkmə), Display (kadr buferinə ötürmə). Ən çox rast gəlinən problem XML-də layout şişməsidir, xüsusilə mürəkkəb iç-içə ConstraintLayout istifadə edərkən.

Time-to-Interactive (TTI) — tətbiqin tam qarşılıqlı əlaqəyə hazır olması üçün lazım olan vaxt. TTI Soyuq Başlatma, məlumat yükləmə və kitabxana başlatmanı əhatə edir. Google TTI-ni 5 saniyədən az, Apple — əsas ekranlar üçün 2 saniyədən az tövsiyə edir. Tənbəl Yükləmə — məzmun və kitabxanaların gecikmiş yüklənməsi texnikası, TTI-ni yaxşılaşdırmaq üçün vacibdir. IT Sectr-də bütün layihələrdə standart olaraq tənbəl başlatmadan istifadə edirik.

ANR və Çökmə

ANR və çökmə mobil tətbiq performansının əsas düşmənləridir. ANR (Application Not Responding) — əsas ip 5 saniyədən çox bloklanarsa Android-də görünən dialoq qutusu. Səbəblər: UI ipində sinxron şəbəkə sorğuları, coroutine olmadan verilənlər bazası ilə iş, downsampling olmadan böyük bitmap dekod, Əsas ipdə deadlock. ANR çağrı yığını /data/anr/traces.txt-də saxlanılır və dəqiq bloklama yerini təyin etməyə imkan verir.

Çökmə — gözlənilməz tətbiq sonlanması. Android-də — Exception (Java/Kotlin) və ya Signal (yerli kod). iOS-da — NSException və ya siqnal (EXC_BAD_ACCESS — azad edilmiş yaddaşa giriş). Çökmə Hesabatı Alətləri: Firebase Crashlytics, Sentry, BugSnag. Bunlar stacktrace, cihaz məlumatları və bərpa addımlarını toplayır. Stack Overflow — sonsuz rekursiya səbəbindən çağrı yığını daşması. OutOfMemoryError — yığın (heap) dolduqda.

StrictMode — ip təhlükəsizliyi pozuntularını aşkar etmək üçün Android aləti. Qaydalar təyin etməyə imkan verir: ThreadPolicy (əsas ipdə disk/şəbəkə qadağan), VmPolicy (Activity, SQLite, CloseGuard sızmalarını aşkar et). StrictMode yalnız debug qurmalarında aktiv edilməlidir — buraxılışda işləməməlidir. iOS-da ekvivalenti Main Thread Checker (Xcode)-dır, avtomatik olaraq əsas ipdə olmayan UIKit çağrılarını aşkar edir.

Yaddaş İdarəetməsi (GC, ARC, Retain Cycle)

Yaddaş Sızması

Yaddaş sızması (Memory Leak) — tətbiq artıq istifadə etməsə belə, obyektin yaddaşda qalması vəziyyətidir. Bu, birbaşa tətbiq performansını azaldır. Android-də GC (Garbage Collection) obyektə güclü istinad varsa onu toplaya bilməz. Tipik səbəblər: Activity-ə statik istinadlar, təmizlənməmiş callback/observerlər, xarici sinfə örtük istinadı olan daxili siniflər, təmizlənməmiş mesajları olan Handler. LeakCanary — avtomatik sızma aşkarlanması üçün kitabxana.

Retain Cycle (Saxlama Dövrü)

ARC (Automatic Reference Counting) — iOS-da yaddaş idarəetmə modeli. Hər obyektin istinad sayğacı (retain count) var. Sayğac sıfıra çatdıqda yaddaş azad edilir. Retain Cycle iki obyekt bir-birinə güclü istinadlar saxladıqda baş verir (A → B və B → A). ARC sayğacları heç vaxt sıfırlamayacaq. Həll: zəif (weak) və ya sahibsiz (unowned) istinadlar. Weak obyekt azad edildikdə avtomatik olaraq nil olur. Unowned nil olmur, ancaq obyektin canlı olduğunu təmin edir.

GC vs ARC

GC (Garbage Collection) Android-də (Java/Kotlin) işləyir. GC əlçatmaz obyektləri tapmaq və azad etmək üçün dövri olaraq icranı dayandırır (Stop-the-World fasiləsi). GC Tətikləyicisi: yığın (heap) müəyyən faizə çatdıqda. ARC iOS-da (Swift/Objective-C) işləyir və fasilələri yoxdur — sayğaclar hər təyinatda atomik olaraq yenilənir. ARC daha proqnozlaşdırıla biləndir, ancaq yüksək təyinat tezliyində həddindən artıq retain/release əməliyyatları toplaya bilər.

Zəif İstinad (Weak Reference) və Güclü İstinad (Strong Reference) — istinad növü GC/ARC-nin obyekti azad edə biləcəyini müəyyən edir. Strong Reference — bu istinad mövcud olduğu müddətcə obyekt toplanmayacaq. Weak Reference — GC/ARC obyekti toplaya bilər; zəif istinad nil olur (Swift/Java WeakReference-da). Unowned Reference (Swift) — azad edildikdə nil olmur; obyekt öldükdən sonra ona giriş çökməyə səbəb olur. Android-də zəif istinadlar üçün java.lang.ref.WeakReference istifadə olunur.

LeakCanary ilə Android-də sızma aşkarlanması nümunəsi:

// Утечка: анонимный класс держит ссылку на 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")
    }
}

Profilləmə (Instruments, Android Profiler)

Profilləmə tətbiq performansının (CPU, yaddaş, şəbəkə, enerji istehlakı) ölçülməsi prosesidir. Profilləmə olmadan kor optimallaşdırma faydasızdır — kodun hansı hissəsinin həqiqətən yavaş olduğunu bilməyəcəksiniz.

Instruments (Xcode) — iOS üçün ən güclü alət. Time Profiler hansı funksiyaların ən çox CPU istehlak etdiyini göstərir. Allocations obyekt yaradılması və azad edilməsini izləyir. Leaks avtomatik olaraq retain cycle-ları tapır. Profilləmə addımları: (1) Instruments-ı başladın; (2) şablon seçin (CPU üçün Time Profiler); (3) problemli ssenarini işə salın; (4) çağrı yığınını analiz edin — ən geniş sütun ən "isti" funksiyadır.

Android Profiler Android Studio-ya daxildir (View → Tool Windows → Profiler). CPU Profiler hər ipin yükünü göstərir. Memory Profiler — yığın dumpı və ayırma izləmə. Network Profiler — vaxtlarla bütün HTTP sorğuları. Energy Profiler — enerji istehlakı: WakeLock, Location, Network. Ətraflı izləmə üçün Systrace (Android 10+) və ya Perfetto — mikrosaniyə dəqiqliyi ilə sistem izləmə istifadə olunur.

Tətbiqin Başladılması (Soyuq/İlıq/İsti Başlatma)

Tətbiqin başladılması performansın əsas göstəricilərindən biridir. Üç növə bölünür: Soyuq Başlatma — tətbiq sıfırdan başlayır: proses yaradılır, Application.onCreate (Android) / AppDelegate.applicationDidFinishLaunching (iOS), sinif yükləmə, kitabxana başlatma. İlıq Başlatma — proses mövcuddur, lakin Activity/ViewController məhv edilib (məsələn, ekranı çevirdikdə və ya yaddaşdan qayıdarkən). İsti Başlatma — Activity/ViewController yaddaşdadır, tətbiq sadəcə göstərilir (başqa tətbiqdən keçid).

Soyuq Başlatma ən vacib metrikadır. Android-də daxildir: (1) launch Activity — XML yükləmə, View başlatma; (2) ilk kadr — ilk renderə qədər vaxt. Google tövsiyə edir: launch Activity < 200 ms, ilk kadr < 500 ms, TTI < 5 saniyə. Soyuq Başlatma optimallaşdırması: Application.onCreate-u azaldın (tənbəl başlatma üçün coroutine), SplashScreen API (Android 12+) istifadə edin, kitabxana başlatmanı təxirə salın (WorkManager, DI), lazımsız ContentProviders-ləri silin.

iOS-da Soyuq Başlatma daxildir: Mach-O binar faylının yüklənməsi, dyld (dinamik birləşdirici), Objective-C runtime başlatması, tətbiq delegate-i, ilk controller. Chrome Custom Tabs (Android) və Universal Links (iOS) — tam Soyuq Başlatma olmadan tətbiqdə xarici məzmunu tez açmaq texnologiyaları. Soyuq Başlatmanı real orta səviyyəli cihazlarda sınamaq tövsiyə olunur.

Ölçü Optimallaşdırması

Tətbiq ölçüsü quraşdırma və yeniləmələr üçün performans faktorudur. Dönüşümə təsir edir: hər 10 MB dönüşümü 1% azaldır. Google Play tövsiyə edir APK ölçüsü 150 MB-dan az; App Store — 200 MB-dan az (mobil şəbəkələr — 100 MB). Əsas optimallaşdırma metodları: şəkil sıxılması (PNG əvəzinə WebP 25-35% qənaət), vektorlaşdırma (Android-də VectorDrawable, iOS-da SF Symbols), istifadə olunmayan kodun silinməsi (R8/ProGuard), istifadə olunmayan resursların silinməsi (lint → unused resources).

App Bundle (Android) — Google Play-in hər cihaz üçün optimallaşdırılmış APK yaratdığı nəşr formatı. App Bundle yükləmə ölçüsünü 20-40% azaldır. Dynamic Delivery — tələb əsasında yüklənən modullar (on-demand feature modules). iOS-da ekvivalenti On-Demand Resources (ODR)-dur: ilk başlatmadan sonra yüklənən resurslar (oyun səviyyələri, videolar).

Tənbəl Yükləmə — modulların və kitabxanaların başlatma zamanı deyil, ehtiyac olduqda yükləndiyi texnika. Split APK (Android) və App Slicing (iOS) — tətbiqin arxitektura yuvalarına bölünməsi: arm64-v8a, x86_64. Tətbiq Ölçüsü Optimallaşdırması — davamlı proses: APK tərkibini analiz edin (Android Studio-da Analyze APK), təkrarlanan ikonları silin, çoxsaylı PNG sıxlıqları əvəzinə SVG istifadə edin. IT Sectr-də hər MR üçün CI/CD-də qurma ölçüsü yoxlamasını daxil edirik.