StrictMode: какво е това, режим на строги правила и дебъг в Android

Какво е StrictMode

StrictMode е API, който е част от Android SDK от API Level 9 (Android 2.3 Gingerbread). Задачата му е да открива по време на изпълнение случайното извършване на тежки операции в главната (UI) нишка, които могат да блокират изобразяването на интерфейса. Главната нишка отговаря за обработката на потребителския вход, изчисляването на layout и изобразяването — всяко блокиране по-дълго от 16 ms води до пропускане на кадър.

Философия на инструмента

StrictMode следва принципа „fail fast“ — да се открие проблемът възможно най-рано, за предпочитане в момента на първото му появяване. Вместо да чака оплаквания на потребителите за забавяне, разработчикът получава сигнал (логове, диалог или crash) още на етапа на разработка. Инструментът не изисква допълнителни библиотеки или конфигурация на Gradle — достатъчни са няколко реда код в Application.onCreate и той работи автоматично на всички устройства.

Целева аудитория

StrictMode е предназначен за всички разработчици на Android, независимо от опита. На начинаещите помага да изградят правилни навици (да не правят мрежови заявки в UI нишката), на опитните — да автоматизират контрола на качеството в CI/CD пайплайна. Големите проекти (Google, Uber, Spotify) включват StrictMode в debug версиите с penaltyDeath, а в release версиите го изключват чрез проверка на BuildConfig.DEBUG.

Как работи StrictMode

StrictMode прихваща системните извиквания, които могат да блокират нишката, и ги сравнява с набора от активни политики. Ако извикването съответства на политика и се изпълнява в главната нишка, StrictMode прилага зададената санкция (penalty). Механизмът на прихващане е реализиран чрез hook в рамките на процеса — не използва reflection и работи с минимален overhead.

Механизъм на откриване

При активиране на политика StrictMode вмъква своя обработчик във входната точка на системните извиквания (FileInputStream, FileOutputStream, Socket, URLConnection). Когато приложението извика например URLConnection.openStream в главната нишка, StrictMode проверява текущата нишка — ако това е main thread, инструментът се задейства. В Android 6.0+ механизмът е усилен: мрежовите извиквания в main thread генерират NetworkOnMainThreadException дори без StrictMode, но StrictMode позволява да се контролира и disk I/O.

Penalty (санкция)

Всяка политика може да има свой тип санкция или комбинация: penaltyLog — запис в LogCat със stacktrace, penaltyDialog — показване на диалог на потребителя (само в debug), penaltyDeath — хвърляне на изключение и срив на приложението, penaltyDropBox — запазване на данни в DropBoxManager за последващ анализ. За CI/CD пайплайна се препоръчва penaltyDeath — това гарантира, че нито един merge с нарушение няма да остане незабелязан.

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        if (BuildConfig.DEBUG) {
            StrictMode.setThreadPolicy(
                StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()
                    .detectDiskWrites()
                    .detectNetwork()
                    .penaltyLog()
                    .penaltyDeath()
                    .build()
            )
        }
    }
}

Политики на StrictMode

StrictMode разделя политиките на две нива: ThreadPolicy (нишкови — какво не трябва да се прави в главната нишка) и VmPolicy (на виртуалната машина — изтичания на памет и ресурси). И двете нива се настройват независимо и работят паралелно.

ThreadPolicy: диск и мрежа

На ниво нишка StrictMode контролира четири типа нарушения: четене от диск (detectDiskReads), запис на диск (detectDiskWrites), мрежови операции (detectNetwork) и потребителски бавни извиквания (detectCustomSlowCalls). disk_read се задейства при всяко четене на SharedPreferences, SQLite или файлове в главната нишка. network — при HTTP заявки, WebSocket, Socket връзки. В Android 11+ е добавен detectUnbufferedIO за откриване на небуфериран I/O.

VmPolicy: изтичания на памет

VmPolicy контролира изтичанията на ниво виртуална машина ART: detectActivityLeaks (Activity, които не са били унищожени), detectLeakedClosableObjects (незатворени Cursor, Stream, Socket), detectLeakedRegistrationObjects (неотменени BroadcastReceiver, ServiceConnection). Ако VmPolicy установи, че Activity е създадена, но не е унищожена след извикването на onDestroy, той извежда пълен stack trace — това спестява часове при отстраняването на изтичания на памет.

Потребителски етикети (customSlowCall)

Чрез detectCustomSlowCalls можете да отбележите собствени методи като „подозрителни“ и да получавате предупреждение при превишаване на зададен праг. Например, ако вашият метод loadUserProfile() обикновено отнема 5 ms, но в някои случаи 200 ms, обвийте го в StrictMode.noteSlowCall("loadUserProfile"). Ако продължителността надхвърли прага (по подразбиране 2000 ms), StrictMode генерира санкция. Прагът се настройва чрез setSlowCallDurationThreshold.

Как да настроите StrictMode

Основната настройка на StrictMode отнема 10 реда код и се извършва в метода onCreate на персонализирания клас Application. Основно правило: StrictMode се включва само в debug версии — в release версиите той забавя приложението и може да създаде фалшиви сигнали.

Основна конфигурация

Създайте клас, наследяващ Application, регистрирайте го в AndroidManifest.xml чрез атрибута android:name и добавете конфигурацията на StrictMode. ThreadPolicy.Builder включва всички детектори и всички видове санкции (освен dialog — той работи само при свързан debugger). VmPolicy.Builder добавя детектори за изтичания на Activity и Closable обекти. За големи проекти (100+ екрана) се препоръчва настройка на VmPolicy с penaltyDeath за детектора Activity Leaks — това е строго, но ефективно.

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        if (BuildConfig.DEBUG) {
            StrictMode.setVmPolicy(
                StrictMode.VmPolicy.Builder()
                    .detectActivityLeaks()
                    .detectLeakedClosableObjects()
                    .detectLeakedRegistrationObjects()
                    .penaltyLog()
                    .penaltyDeath()
                    .build()
            )
        }
    }
}

Интеграция в CI/CD

За автоматичен контрол в CI/CD използвайте penaltyDeath — ако някой тест наруши политиката, приложението ще се срине с изключение. Комбинирайте с Android Test Orchestrator, за да стартира всеки тест в чист процес. За UI тестове (Espresso, Compose Test) напишете персонализиран TestRule, който прихваща нарушенията на StrictMode и ги превръща в assertion failure. Пример: в @Before включете StrictMode, а в @After проверете, че не е имало violations.

Настройка на праговете

По подразбиране прагът за customSlowCall е 2000 ms, а за disk_read и disk_write няма праг (всяка операция задейства). Чрез setSlowCallDurationThreshold и setSlowIoDurationThreshold можете да зададете свои стойности в милисекунди. Ако приложението ви легитимно чете SharedPreferences в главната нишка (малка конфигурация), увеличете прага до 10–20 ms — това ще отсече бързите четения, но ще запази бавните.

Най-добри практики за StrictMode

StrictMode е мощен, но капризен инструмент. Неправилната настройка води до милион фалшиви сигнала, поради което разработчиците спират да им обръщат внимание. По-долу са изпитани практики, събрани от опита на големи Android екипи.

Включвайте само в debug версии

Това е желязно правило: StrictMode НИКОГА не трябва да е активен в release версиите. Използвайте флага BuildConfig.DEBUG или персонализиран buildConfigField. В release версиите много външни библиотеки легитимно извършват операции в главната нишка (инициализация на SDK, запис на кеш) и StrictMode ще създаде фалшиви сигнали. Освен това penaltyDialog в release версия ще покаже диалог на крайния потребител — което е недопустимо.

Използвайте три нива на строгост

За малки проекти (1–10 екрана) настройте penaltyLog — достатъчни са логове за ръчен анализ. За средни проекти (10–50 екрана) добавете penaltyDeath за network и customSlowCalls. За големи проекти (50+ екрана) включете пълния набор политики с penaltyDeath в CI/CD, а за локална разработка — penaltyLog. Тази градация не претоварва разработчика с фалшиви сривове, но стриктно контролира качеството в пайплайна.

Обработване на false positives

Някои библиотеки (Firebase, Crashlytics, Adjust) легитимно извършват операции във фонов режим, които StrictMode може погрешно да открие. Решения: добавете библиотеката в whitelist чрез penaltyListener, обновете библиотеката до версия с изрично превключване към background thread, или използвайте StrictMode.vmPolicy. В Android 11+ се появи StrictMode.OnVmViolationListener за програмна филтрация на нарушенията по stacktrace.

// Филтриране на false positives чрез penaltyListener
StrictMode.setThreadPolicy(
    StrictMode.ThreadPolicy.Builder()
        .detectAll()
        .penaltyListener { violation ->
            val stack = violation.stackTraceToString()
            if ("com.google.firebase" !in stack) {
                logViolation(violation)
            }
        }
        .build()
)

StrictMode vs Android Lint vs профилъри

StrictMode не е единственият инструмент за контрол на качеството в Android екосистемата. За да разберем мястото му, ще го сравним с Android Lint, Android Profiler и Perfetto по ключови критерии: време на проверка, дълбочина на анализа и автоматизация.

Най-добрата стратегия е да комбинирате и трите подхода: Android Lint хваща очевидните грешки на етапа на компилация (например забравен IdleHandler), StrictMode открива проблемите по време на изпълнение, а Android Profiler / Perfetto се използва за задълбочен анализ, когато първите два инструмента не дават отговор. В реални проекти (Google Maps, Instagram) StrictMode се внедрява през втората седмица на разработката — веднага след настройката на базовата архитектура.

Примери за код със StrictMode

Ще разгледаме два реални сценария, в които StrictMode помага да се открият и отстранят проблеми с производителността: четене на SharedPreferences в главната нишка и изтичане на Activity чрез нерегистриран callback.

Откриване на бавни SharedPreferences

При стартирането на приложението StrictMode с политика detectDiskReads ще открие четенето на SharedPreferences в главната нишка. Решение: зареждайте конфигурацията асинхронно чрез CoroutineScope или я кеширайте в паметта при старта. SharedPreferences синхронно чете XML файла от диска — дори при малък файл (1–2 KB) операцията отнема 1–5 ms, а на евтини устройства до 20 ms, което може да доведе до пропуснат кадър.

// ❌ Проблемен код — четене на SharedPrefs в UI нишката
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // StrictMode detectDiskReads → VIOLATION!
        prefs = getSharedPreferences("config", MODE_PRIVATE)
    }
}

// ✅ Коригиран код — четене чрез Coroutine
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        loadConfigAsync()
    }
}

Откриване на изтичане на Activity

StrictMode с VmPolicy.detectActivityLeaks ще открие Activity, която е излязла от стека (finish е извикан), но обектът Activity продължава да виси в паметта поради статична референция или нерегистриран callback. Типичен сценарий: регистрация на EventBus или LocationListener в onResume без извикване на unregister в onPause. VmPolicy ще изведе stacktrace с посочване на реда, където е създадена референцията.

// ❌ Изтичане — callback не е отменен
private var locationCallback: LocationCallback? = null

override fun onResume() {
    super.onResume()
    locationCallback = LocationCallback(this::onLocationUpdated)
    locationManager.register(locationCallback) // StrictMode → LEAK!
}

override fun onPause() {
    super.onPause()
    // Забравихте: locationManager.unregister(locationCallback)
}