Производителност в мобилната разработка: какво е, какви метрики и как да се подобрява

Защо приложението забавя?

Производителността на приложението е пряко свързана с jank — забележимо забавяне между действието на потребителя и реакцията на интерфейса. Основни причини: блокиране на основната нишка (тежки операции на UI нишката), често прерисуване на оформлението (overdraw), изтичания на памет (чест GC), неоптимални алгоритми (O(n²) върху големи данни). Честота на кадрите (FPS) — брой кадри в секунда. За комфортно изживяване са необходими стабилни 60 FPS (Android) или 120 FPS (iPhone Pro, iPad Pro). VSync синхронизира рендерирането с честотата на опресняване на екрана.

Jank възниква, когато рендерирането на един кадър надвишава 16,6 ms (за 60 FPS) или 8,3 ms (за 120 FPS). Профилирането на GPU (Profile GPU Rendering на Android, Core Animation на iOS) показва кои етапи на рендериране отнемат най-много време. Основни етапи: Layout (подреждане на елементи), Draw (рисуване), Display (прехвърляне в буфера на кадрите). Най-честият проблем е инфлацията на оформлението в XML, особено при сложни вложени ConstraintLayout.

Time-to-Interactive (TTI) — времето, за което приложението става напълно готово за взаимодействие. TTI включва Cold Start, зареждане на данни и инициализация на библиотеки. Google препоръчва TTI под 5 секунди, Apple — под 2 секунди за основните екрани. Мързеливо зареждане — техника за отложено зареждане на съдържание и библиотеки, критична за подобряване на TTI. В IT Sectr използваме мързелива инициализация по подразбиране във всички проекти.

ANR и срив

ANR и сривът са основните врагове на производителността на мобилното приложение. ANR (Application Not Responding) — диалогов прозорец на Android, който се появява, ако основната нишка е блокирана повече от 5 секунди. Причини: синхронни мрежови заявки на UI нишката, работа с база данни без корутини, декодиране на голям bitmap без намаляване на извадката, deadlock на основната нишка. Стекът за извиквания на ANR се записва в /data/anr/traces.txt и позволява определяне на точното място на блокиране.

Срив — неочаквано прекратяване на приложението. На Android — Exception (Java/Kotlin) или Signal (роден код). На iOS — NSException или сигнал (EXC_BAD_ACCESS — достъп до освободена памет). Инструменти за отчитане на сривове: Firebase Crashlytics, Sentry, BugSnag. Те събират stacktrace, данни за устройството и стъпки за възпроизвеждане. Stack Overflow — препълване на стека за извиквания поради безкрайна рекурсия. OutOfMemoryError — когато купчината (heap) е пълна.

StrictMode — инструмент на Android за откриване на нарушения на безопасността на нишките. Позволява задаване на правила: ThreadPolicy (забрана на диск/мрежа на основната нишка), VmPolicy (откриване на изтичания на Activity, SQLite, CloseGuard). StrictMode трябва да се включва само в debug сборка — в release не трябва да работи. На iOS аналогът е Main Thread Checker (Xcode), който автоматично открива UIKit извиквания, които не са на основната нишка.

Управление на паметта (GC, ARC, Retain Cycle)

Изтичане на памет

Изтичане на памет (Memory Leak) — ситуация, при която обект остава в паметта, въпреки че приложението вече не го използва. Това пряко намалява производителността на приложението. На Android GC (Garbage Collection) не може да събере обект, ако има силна референция към него. Типични причини: статични референции към Activity, неотменени callback/наблюдатели, вътрешни класове с имплицитна референция към външния клас, Handler с неизчистени съобщения. LeakCanary — библиотека за автоматично откриване на изтичания.

Retain Cycle (Цикъл на задържане)

ARC (Automatic Reference Counting) — модел за управление на паметта в iOS. Всеки обект има брояч на референции (retain count). Когато броячът достигне нула, паметта се освобождава. Retain Cycle възниква, когато два обекта държат силни референции един към друг (A → B и B → A). ARC никога няма да нулира броячите. Решение: слаби (weak) или безстопанствени (unowned) референции. Weak автоматично се нулира (става nil) при освобождаване на обекта. Unowned не се нулира, но гарантира, че обектът е жив.

GC срещу ARC

GC (Garbage Collection) работи на Android (Java/Kotlin). GC периодично спира изпълнението (пауза Stop-the-World) за търсене и освобождаване на недостижими обекти. Задействане на GC: когато купчината (heap) се напълни до определен процент. ARC работи на iOS (Swift/Objective-C) и няма паузи — броячите се актуализират атомарно при всяко присвояване. ARC е по-предвидим, но може да натрупа прекомерни retain/release операции при висока честота на присвояване.

Слаба референция (Weak Reference) и силна референция (Strong Reference) — типът референция определя дали GC/ARC може да освободи обекта. Strong Reference — обектът няма да бъде събран, докато съществува тази референция. Weak Reference — GC/ARC може да събере обекта; слабата референция става nil (в Swift/Java WeakReference). Unowned Reference (Swift) — не се нулира при освобождаване; достъпът до нея след смъртта на обекта причинява срив. На Android за слаби референции се използва java.lang.ref.WeakReference.

Пример за откриване на изтичане на Android чрез LeakCanary:

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

Профилиране (Instruments, Android Profiler)

Профилирането е процесът на измерване на производителността на приложението: CPU, памет, мрежа, консумация на енергия. Без профилиране оптимизацията на сляпо е безполезна — няма да разберете коя част от кода реално забавя.

Instruments (Xcode) — най-мощният инструмент за iOS. Time Profiler показва кои функции консумират най-много CPU. Allocations проследява създаването и освобождаването на обекти. Leaks автоматично намира retain cycles. Стъпки на профилиране: (1) стартирайте Instruments; (2) изберете шаблон (Time Profiler за CPU); (3) изпълнете проблемния сценарий; (4) анализирайте стека за извиквания — най-широката колона е най-"горещата" функция.

Android Profiler е вграден в Android Studio (View → Tool Windows → Profiler). CPU Profiler показва натоварването на всяка нишка. Memory Profiler — heap dump и проследяване на разпределението. Network Profiler — всички HTTP заявки с времена. Energy Profiler — консумация на енергия: WakeLock, Location, Network. За детайлно проследяване се използва Systrace (Android 10+) или Perfetto — системно проследяване с точност до микросекунди.

Стартиране на приложението (Cold/Warm/Hot Start)

Стартирането на приложението е един от ключовите показатели за производителност. Разделя се на три типа: Cold Start — приложението стартира от нулата: процесът се създава, Application.onCreate (Android) / AppDelegate.applicationDidFinishLaunching (iOS), зареждане на класове, инициализация на библиотеки. Warm Start — процесът съществува, но Activity/ViewController е унищожен (например при завъртане на екрана или връщане от паметта). Hot Start — Activity/ViewController е в паметта, приложението просто се показва (превключване от друго приложение).

Cold Start е най-важната метрика. На Android включва: (1) стартиране на Activity — зареждане на XML, инициализация на View; (2) първи кадър — време до първото рендериране. Google препоръчва: стартиране на Activity < 200 ms, първи кадър < 500 ms, TTI < 5 секунди. Оптимизация на Cold Start: намалете Application.onCreate (корутини за мързелива инициализация), използвайте SplashScreen API (Android 12+), отложете инициализацията на библиотеки (WorkManager, DI), премахнете ненужните ContentProviders.

На iOS Cold Start включва: зареждане на Mach-O двоичен файл, dyld (динамичен свързвач), инициализация на Objective-Runtime, application delegate, първи контролер. Chrome Custom Tabs (Android) и Universal Links (iOS) — технологии за бързо отваряне на външно съдържание в приложението без пълен Cold Start. Препоръчва се тестване на Cold Start на реални устройства от среден клас.

Оптимизация на размера

Размерът на приложението е фактор за производителност при инсталиране и актуализации. Той влияе върху конверсията: всеки 10 MB намаляват конверсията с 1%. Google Play препоръчва размер на APK под 150 MB; App Store — под 200 MB (клетъчни мрежи — 100 MB). Основни методи за оптимизация: компресия на изображения (WebP вместо PNG спестява 25-35%), векторизация (VectorDrawable на Android, SF Symbols на iOS), премахване на неизползван код (R8/ProGuard), премахване на неизползвани ресурси (lint → unused resources).

App Bundle (Android) — формат за публикуване, при който Google Play генерира оптимизиран APK за всяко устройство. App Bundle намалява размера за изтегляне с 20-40%. Dynamic Delivery — модули, които се изтеглят при поискване (on-demand feature modules). На iOS еквивалентът са On-Demand Resources (ODR): ресурси, изтеглени след първото стартиране (нива на игра, видеа).

Мързеливо зареждане — техника, при която модулите и библиотеките не се зареждат при стартиране, а се зареждат при необходимост. Split APK (Android) и App Slicing (iOS) — разделяне на приложението на архитектурни слотове: arm64-v8a, x86_64. Оптимизация на размера на приложението — непрекъснат процес: анализирайте състава на APK (Analyze APK в Android Studio), премахнете дублирани икони, използвайте SVG вместо множество плътности PNG. В IT Sectr включваме проверка на размера на сборката в CI/CD за всеки MR.