StrictMode: ce este, modul reguli stricte și depanare în Android

Ce este StrictMode

StrictMode este o API inclusă în Android SDK începând cu API Level 9 (Android 2.3 Gingerbread). Sarcina sa este de a detecta în timp real executarea accidentală a operațiilor grele pe firul principal (UI) care pot bloca randarea interfeței. Firul principal este responsabil pentru procesarea intrărilor utilizatorului, calcularea layout-ului și randare — orice blocare mai lungă de 16 ms duce la omiterea cadrelor.

Filosofia instrumentului

StrictMode urmează principiul „fail fast” — detectează problema cât mai devreme posibil, ideal în momentul primei sale apariții. În loc să aștepte plângerile utilizatorilor privind încetinirile, dezvoltatorul primește un semnal (loguri, dialog sau crash) direct în faza de dezvoltare. Instrumentul nu necesită biblioteci suplimentare sau configurare Gradle — sunt suficiente câteva linii de cod în Application.onCreate și funcționează automat pe toate dispozitivele.

Publicul țintă

StrictMode este destinat tuturor dezvoltatorilor Android, indiferent de experiență. Începătorilor îi ajută să formeze obiceiuri corecte (să nu facă solicitări de rețea în firul UI), iar celor experimentați — să automatizeze controlul calității în pipeline-ul CI/CD. Proiectele mari (Google, Uber, Spotify) activează StrictMode în debug builds cu penaltyDeath, iar în release builds îl dezactivează prin verificarea BuildConfig.DEBUG.

Cum funcționează StrictMode

StrictMode interceptează apelurile de sistem care pot bloca firul de execuție și le compară cu setul de politici active. Dacă apelul corespunde unei politici și este executat pe firul principal, StrictMode aplică penalty-ul stabilit. Mecanismul de interceptare este implementat printr-un hook intra-proces — nu folosește reflection și funcționează cu un overhead minim.

Mecanismul de detectare

La activarea politicii, StrictMode își plasează handlerul în punctul de intrare al apelurilor de sistem (FileInputStream, FileOutputStream, Socket, URLConnection). Când aplicația apelează, de exemplu, URLConnection.openStream pe firul principal, StrictMode verifică firul curent — dacă este main thread, instrumentul se activează. În Android 6.0+ mecanismul a fost întărit: apelurile de rețea în main thread generează NetworkOnMainThreadException chiar și fără StrictMode, dar StrictMode permite controlul și al I/O-ului pe disc.

Penalty (pedeapsa)

Fiecare politică poate avea propriul tip de penalty sau o combinație: penaltyLog — scriere în LogCat cu stacktrace, penaltyDialog — afișarea unui dialog utilizatorului (doar în debug), penaltyDeath — aruncarea unei excepții și crash-ul aplicației, penaltyDropBox — salvarea datelor în DropBoxManager pentru analiză ulterioară. Pentru pipeline-ul CI/CD se recomandă penaltyDeath — garantează că niciun merge cu încălcări nu va trece neobservat.

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

Politicile StrictMode

StrictMode împarte politicile pe două niveluri: ThreadPolicy (de fir — ce să nu se facă pe firul principal) și VmPolicy (mașină virtuală — scurgeri de memorie și resurse). Ambele niveluri se configurează independent și funcționează în paralel.

ThreadPolicy: disc și rețea

La nivel de fir, StrictMode controlează patru tipuri de încălcări: citirea de pe disc (detectDiskReads), scrierea pe disc (detectDiskWrites), operațiile de rețea (detectNetwork) și apelurile lente personalizate (detectCustomSlowCalls). disk_read se declanșează la orice citire SharedPreferences, SQLite, fișiere pe firul principal. network — la cereri HTTP, WebSocket, conexiuni Socket. În Android 11+ a fost adăugat detectUnbufferedIO pentru detectarea I/O-ului fără buffer.

VmPolicy: scurgeri de memorie

VmPolicy controlează scurgerile la nivelul mașinii virtuale ART: detectActivityLeaks (Activități care nu au fost distruse), detectLeakedClosableObjects (Cursor, Stream, Socket neînchise), detectLeakedRegistrationObjects (BroadcastReceiver, ServiceConnection neanulate). Dacă VmPolicy detectează că o Activitate a fost creată dar nu distrusă după apelul onDestroy, afișează stack trace-ul complet — economisește ore de depanare a scurgerilor de memorie.

Etichete personalizate (customSlowCall)

Prin detectCustomSlowCalls puteți marca propriile metode ca „sospicioase” și primiți avertismente la depășirea unui prag stabilit. De exemplu, dacă metoda dvs. loadUserProfile() se execută de obicei în 5 ms, dar în unele cazuri durează 200 ms — înfășurați-o în StrictMode.noteSlowCall("loadUserProfile"). Dacă durata depășește pragul (implicit 2000 ms), StrictMode va genera un penalty. Pragul se configurează prin setSlowCallDurationThreshold.

Cum să configurați StrictMode

Configurarea de bază StrictMode ocupă 10 linii de cod și se realizează în metoda onCreate a unei clase Application personalizate. Regula principală: StrictMode se activează doar în debug builds — în release builds încetinește aplicația și poate genera alarme false.

Configurarea de bază

Creați o clasă care extinde Application, înregistrați-o în AndroidManifest.xml prin atributul android:name și adăugați configurarea StrictMode. ThreadPolicy.Builder activează toți detectorii și toate tipurile de penalty (cu excepția dialog — funcționează doar cu debuggerul conectat). VmPolicy.Builder adaugă detectori de scurgeri Activity și Closable. Pentru proiecte mari (100+ ecrane) se recomandă configurarea VmPolicy cu penaltyDeath pe detectorul Activity Leaks — este strict, dar eficient.

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

Integrarea în CI/CD

Pentru controlul automat în CI/CD utilizați penaltyDeath — dacă vreun test încalcă politica, aplicația va crasa cu o excepție. Combinați cu Android Test Orchestrator pentru ca fiecare test să ruleze într-un proces curat. Pentru testele UI (Espresso, Compose Test) scrieți un TestRule personalizat care interceptează încălcările StrictMode și le transformă în assertion failure. Exemplu: în @Before activați StrictMode, iar în @After verificați dacă nu au fost violations.

Configurarea pragurilor

Implicit, pragul pentru customSlowCall este de 2000 ms, iar pentru disk_read și disk_write — fără prag (orice operație îl declanșează). Prin setSlowCallDurationThreshold și setSlowIoDurationThreshold puteți seta propriile valori în milisecunde. Dacă aplicația dvs. citește legitim SharedPreferences pe firul principal (configurare mică), măriți pragul la 10–20 ms — va tăia citirile rapide, dar le va păstra pe cele lente.

Cele mai bune practici StrictMode

StrictMode este un instrument puternic, dar capricios. Configurarea incorectă duce la un milion de alarme false, din cauza cărora dezvoltatorii încetează să le mai acorde atenție. Mai jos sunt practici verificate, colectate din experiența echipelor mari Android.

Activați doar în debug builds

Aceasta este o regulă de fier: StrictMode NU trebuie să fie activ NICIODATĂ în release builds. Folosiți flag-ul BuildConfig.DEBUG sau un buildConfigField personalizat. În release builds, multe biblioteci terțe execută legitim operații pe firul principal (inițializare SDK, scriere cache), iar StrictMode va genera alarme false. Mai mult, penaltyDialog în release build va afișa un dialog utilizatorului final — ceea ce este inacceptabil.

Folosiți trei niveluri de severitate

Pentru proiecte mici (1–10 ecrane) configurați penaltyLog — logurile sunt suficiente pentru analiza manuală. Pentru proiecte medii (10–50 ecrane) adăugați penaltyDeath pentru network și customSlowCalls. Pentru proiecte mari (50+ ecrane) activați setul complet de politici cu penaltyDeath în CI/CD, iar pentru dezvoltare locală — penaltyLog. Această gradare permite să nu supraîncărcați dezvoltatorul cu crash-uri false, dar să controlați strict calitatea în pipeline.

Tratați alarmele false

Unele biblioteci (Firebase, Crashlytics, Adjust) execută legitim operații în fundal pe care StrictMode le poate detecta eronat. Soluții: adăugați biblioteca în whitelist prin penaltyListener, actualizați biblioteca la o versiune cu comutare explicită pe background thread sau folosiți StrictMode.vmPolicy. În Android 11+ a apărut StrictMode.OnVmViolationListener pentru filtrarea programatică a încălcărilor după stacktrace.

// Filtrarea alarmelor false prin 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 profilere

StrictMode nu este singurul instrument de control al calității în ecosistemul Android. Pentru a înțelege locul său, să-l comparăm cu Android Lint, Android Profiler și Perfetto după criterii cheie: timpul de verificare, adâncimea analizei și automatizarea.

Cea mai bună strategie este combinarea tuturor celor trei abordări: Android Lint prinde erorile evidente la compilare (de exemplu, un IdleHandler uitat), StrictMode detectează problemele în runtime, iar Android Profiler / Perfetto este utilizat pentru analiza aprofundată când primele două instrumente nu oferă răspunsuri. În proiecte reale (Google Maps, Instagram), StrictMode este implementat în a doua săptămână de dezvoltare — imediat după configurarea arhitecturii de bază.

Exemple de cod cu StrictMode

Să analizăm două scenarii reale în care StrictMode ajută la detectarea și remedierea problemelor de performanță: citirea SharedPreferences pe firul principal și scurgerea Activity printr-un callback neinregistrat.

Detectarea SharedPreferences lente

La pornirea aplicației, StrictMode cu politica detectDiskReads va detecta citirea SharedPreferences pe firul principal. Soluția: încărcați configurația asincron prin CoroutineScope sau cache-uiți în memorie la pornire. SharedPreferences citește sincron fișierul XML de pe disc — chiar și la un fișier mic (1–2 KB), operația durează 1–5 ms, iar pe dispozitive ieftine până la 20 ms, ceea ce poate duce la omiterea cadrelor.

// ❌ Cod problematic — citire SharedPrefs în firul UI
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // StrictMode detectDiskReads → VIOLATION!
        prefs = getSharedPreferences("config", MODE_PRIVATE)
    }
}

// ✅ Cod corectat — citire prin Coroutine
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        loadConfigAsync()
    }
}

Detectarea scurgerii Activity

StrictMode cu VmPolicy.detectActivityLeaks va detecta o Activitate care a ieșit din stivă (finish apelat), dar obiectul Activity continuă să existe în memorie din cauza unei referințe statice sau a unui callback neanulat. Scenariu tipic: înregistrarea EventBus sau LocationListener în onResume fără a apela unregister în onPause. VmPolicy va afișa stack trace-ul cu indicarea liniei unde a fost creată referința.

// ❌ Scurgere — callback neanulat
private var locationCallback: LocationCallback? = null

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

override fun onPause() {
    super.onPause()
    // Uitat: locationManager.unregister(locationCallback)
}