StrictMode: ano ito, mode ng mahigpit na panuntunan at debug sa Android

Ano ang StrictMode

StrictMode ay isang API na kasama sa Android SDK mula noong API Level 9 (Android 2.3 Gingerbread). Ang gawain nito ay tuklasin sa real-time ang hindi sinasadyang pagpapatakbo ng mabibigat na operasyon sa pangunahing (UI) thread na maaaring humarang sa rendering ng interface. Ang pangunahing thread ay responsable para sa pagproseso ng input ng user, pagkalkula ng layout, at rendering — anumang pagharang na mas mahaba sa 16 ms ay nagdudulot ng paglaktaw ng frame.

Pilosopiya ng Tool

StrictMode ay sumusunod sa prinsipyong “fail fast” — tuklasin ang problema sa lalong madaling panahon, mas mabuti sa unang paglitaw nito. Sa halip na maghintay ng mga reklamo ng user tungkol sa pagbagal, ang developer ay tumatanggap ng signal (log, dialog, o crash) direkta sa yugto ng pag-develop. Ang tool ay hindi nangangailangan ng mga karagdagang library o configuration ng Gradle — sapat na ang ilang linya ng code sa Application.onCreate at ito ay awtomatikong gumagana sa lahat ng device.

Target na Audience

Ang StrictMode ay para sa lahat ng Android developer, anuman ang karanasan. Sa mga nagsisimula, nakakatulong itong bumuo ng tamang gawi (huwag gumawa ng network request sa UI thread), sa mga may karanasan — i-automate ang kontrol sa kalidad sa CI/CD pipeline. Ang malalaking proyekto (Google, Uber, Spotify) ay nagpapagana ng StrictMode sa debug builds na may penaltyDeath, at sa release builds ay pinapatay ito sa pamamagitan ng pagsusuri ng BuildConfig.DEBUG.

Paano Gumagana ang StrictMode

StrictMode ay humaharang sa mga system call na maaaring humarang sa thread at ikinukumpara ang mga ito sa set ng mga aktibong patakaran. Kung ang call ay tumutugma sa isang patakaran at isinasagawa sa pangunahing thread, inilalapat ng StrictMode ang itinakdang penalty. Ang mekanismo ng pagharang ay ipinapatupad sa pamamagitan ng isang intra-process hook — hindi ito gumagamit ng reflection at gumagana nang may minimal na overhead.

Mekanismo ng Detectio n

Sa pag-activate ng patakaran, inilalagay ng StrictMode ang handler nito sa entry point ng mga system call (FileInputStream, FileOutputStream, Socket, URLConnection). Kapag ang application ay tumawag, halimbawa, URLConnection.openStream sa pangunahing thread, sinusuri ng StrictMode ang kasalukuyang thread — kung ito ay main thread, ang tool ay mag-activate. Sa Android 6.0+ ang mekanismo ay pinalakas: ang mga network call sa main thread ay bumubuo ng NetworkOnMainThreadException kahit walang StrictMode, ngunit pinapayagan ng StrictMode ang kontrol ng disk I/O rin.

Penalty (parusa)

Ang bawat patakaran ay maaaring magkaroon ng sariling uri ng penalty o kombinasyon: penaltyLog — pagsusulat sa LogCat na may stacktrace, penaltyDialog — pagpapakita ng dialog sa user (debug lang), penaltyDeath — pagtatapon ng exception at crash ng application, penaltyDropBox — pag-save ng data sa DropBoxManager para sa susunod na pagsusuri. Para sa CI/CD pipeline ay inirerekomenda ang penaltyDeath — ginagarantiyang walang merge na may paglabag ang hindi mapapansin.

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

Mga Patakaran ng StrictMode

Hinahati ng StrictMode ang mga patakaran sa dalawang antas: ThreadPolicy (thread — kung ano ang hindi dapat gawin sa pangunahing thread) at VmPolicy (virtual machine — mga tagas ng memorya at resource). Ang parehong antas ay naka-configure nang nakapag-iisa at gumagana nang magkatulad.

ThreadPolicy: disk at network

Sa antas ng thread, kinokontrol ng StrictMode ang apat na uri ng paglabag: pagbasa mula sa disk (detectDiskReads), pagsulat sa disk (detectDiskWrites), operasyon sa network (detectNetwork), at custom na mabagal na tawag (detectCustomSlowCalls). Ang disk_read ay na-trigger sa anumang pagbasa ng SharedPreferences, SQLite, mga file sa pangunahing thread. Ang network — sa mga HTTP request, WebSocket, Socket connection. Sa Android 11+ idinagdag ang detectUnbufferedIO para sa detectio n ng I/O na walang buffer.

VmPolicy: mga tagas ng memorya

Kinokontrol ng VmPolicy ang mga tagas sa antas ng ART virtual machine: detectActivityLeaks (mga Activity na hindi na-destroy), detectLeakedClosableObjects (hindi saradong Cursor, Stream, Socket), detectLeakedRegistrationObjects (hindi kinanselang BroadcastReceiver, ServiceConnection). Kung nakita ng VmPolicy na ang isang Activity ay ginawa ngunit hindi na-destroy pagkatapos ng tawag sa onDestroy, magpapakita ito ng buong stack trace — nakakatipid ng oras sa pag-debug ng mga tagas ng memorya.

Custom na Label (customSlowCall)

Sa pamamagitan ng detectCustomSlowCalls maaari mong markahan ang iyong sariling mga pamamaraan bilang “ kahina-hinala” at makatanggap ng babala kapag lumampas sa itinakdang threshold. Halimbawa, kung ang iyong pamamaraan na loadUserProfile() ay karaniwang tumatakbo ng 5 ms, ngunit sa ilang mga kaso ay tumatagal ng 200 ms — balutin ito sa StrictMode.noteSlowCall("loadUserProfile"). Kung ang tagal ay lumampas sa threshold (default 2000 ms), bubuo ang StrictMode ng penalty. Ang threshold ay naka-configure sa pamamagitan ng setSlowCallDurationThreshold.

Paano I-configure ang StrictMode

Ang pangunahing configuration ng StrictMode ay tumatagal ng 10 linya ng code at ginagawa sa onCreate method ng isang custom na Application class. Pangunahing patakaran: ang StrictMode ay naka-activate lamang sa debug builds — sa release builds ay pinapabagal nito ang application at maaaring lumikha ng mga false positive.

Pangunahing Configuration

Gumawa ng klase na nagmamana ng Application, irehistro ito sa AndroidManifest.xml sa pamamagitan ng android:name attribute, at idagdag ang configuration ng StrictMode. Ang ThreadPolicy.Builder ay nagpapagana ng lahat ng detector at lahat ng uri ng penalty (maliban sa dialog — gumagana lamang kapag nakakonekta ang debugger). Ang VmPolicy.Builder ay nagdaragdag ng mga detector ng pagtagas ng Activity at Closable. Para sa malalaking proyekto (100+ screen) inirerekomenda na i-configure ang VmPolicy na may penaltyDeath sa Activity Leaks detector — ito ay mahigpit ngunit epektibo.

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

Integrasyon sa CI/CD

Para sa awtomatikong kontrol sa CI/CD gamitin ang penaltyDeath — kung ang anumang test ay lumabag sa patakaran, ang application ay mag-crash na may exception. Pagsamahin sa Android Test Orchestrator upang ang bawat test ay tumakbo sa malinis na proseso. Para sa UI tests (Espresso, Compose Test) sumulat ng custom na TestRule na humaharang sa mga paglabag sa StrictMode at ginagawang assertion failure. Halimbawa: sa @Before paganahin ang StrictMode, sa @After suriin kung walang violations.

Configuration ng mga Threshold

Bilang default, ang threshold para sa customSlowCall ay 2000 ms, para sa disk_read at disk_write — walang threshold (anumang operasyon ay nag-trigger). Sa pamamagitan ng setSlowCallDurationThreshold at setSlowIoDurationThreshold maaari kang magtakda ng sarili mong mga halaga sa millisecond. Kung ang iyong application ay lehitimong nagbabasa ng SharedPreferences sa pangunahing thread (maliit na configuration), itaas ang threshold sa 10–20 ms — puputulin nito ang mabilis na pagbasa ngunit pananatilihin ang mabagal.

Mga Pinakamahusay na Kasanayan sa StrictMode

StrictMode ay isang makapangyarihan ngunit pabagu-bagong tool. Ang maling configuration ay humahantong sa milyun-milyong false positive, dahil dito hindi na pinapansin ng mga developer ang mga ito. Nasa ibaba ang mga napatunayang kasanayan na nakalap mula sa karanasan ng malalaking Android team.

Paganahin Lamang sa Debug Builds

Ito ay isang bakal na patakaran: ang StrictMode ay HINDI DAPAT aktibo sa release builds. Gamitin ang BuildConfig.DEBUG flag o custom buildConfigField. Sa release builds, maraming third-party library ang lehitimong nagsasagawa ng mga operasyon sa pangunahing thread (SDK initialization, cache write), at ang StrictMode ay bubuo ng false positive. Bukod pa rito, ang penaltyDialog sa release build ay magpapakita ng dialog sa end user — na hindi katanggap-tanggap.

Gumamit ng Tatlong Antas ng Kahigpitan

Para sa maliliit na proyekto (1–10 screen) i-configure ang penaltyLog — sapat na ang mga log para sa manu-manong pagsusuri. Para sa katamtamang proyekto (10–50 screen) idagdag ang penaltyDeath para sa network at customSlowCalls. Para sa malalaking proyekto (50+ screen) paganahin ang buong set ng mga patakaran na may penaltyDeath sa CI/CD, at para sa lokal na pag-develop — penaltyLog. Ang gradasyon na ito ay nagbibigay-daan na huwag overload ang developer ng false crashes, ngunit mahigpit na kontrolin ang kalidad sa pipeline.

Pangasiwaan ang mga False Positive

Ang ilang mga library (Firebase, Crashlytics, Adjust) ay lehitimong nagsasagawa ng mga operasyon sa background na maaaring maling matukoy ng StrictMode. Mga solusyon: idagdag ang library sa whitelist sa pamamagitan ng penaltyListener, i-update ang library sa bersyon na may explicit na paglipat sa background thread, o gamitin ang StrictMode.vmPolicy. Sa Android 11+ lumitaw ang StrictMode.OnVmViolationListener para sa programmatic na pag-filter ng mga paglabag batay sa stacktrace.

// Pag-filter ng false positive sa pamamagitan ng 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 Profiler

Ang StrictMode ay hindi lamang ang tool sa pagkontrol ng kalidad sa Android ecosystem. Upang maunawaan ang lugar nito, ihambing natin ito sa Android Lint, Android Profiler, at Perfetto batay sa pangunahing pamantayan: oras ng pagsusuri, lalim ng pagsusuri, at automation.

Ang pinakamahusay na diskarte ay pagsamahin ang lahat ng tatlong approach: Android Lint ay nakakahuli ng malinaw na error sa compilation (halimbawa, nakalimutang IdleHandler), StrictMode ay nakakakita ng mga problema sa runtime, at Android Profiler / Perfetto ay ginagamit para sa malalim na pagsusuri kapag ang unang dalawang tool ay hindi nagbibigay ng sagot. Sa totoong proyekto (Google Maps, Instagram), ang StrictMode ay ipinapatupad sa ikalawang linggo ng pag-develop — pagkatapos i-set up ang pangunahing arkitektura.

Mga Halimbawa ng Code na may StrictMode

Tingnan natin ang dalawang totoong senaryo kung saan tinutulungan ng StrictMode na matukoy at maayos ang mga problema sa performance: pagbasa ng SharedPreferences sa pangunahing thread at pagtagas ng Activity sa pamamagitan ng hindi rehistradong callback.

Detectio n ng Mabagal na SharedPreferences

Sa pagsisimula ng application, ang StrictMode na may detectDiskReads patakaran ay makakakita ng pagbasa ng SharedPreferences sa pangunahing thread. Solusyon: i-load ang configuration nang asynchronous sa pamamagitan ng CoroutineScope o i-cache sa memory sa startup. Ang SharedPreferences ay synchronously na nagbabasa ng XML file mula sa disk — kahit na may maliit na file (1–2 KB), ang operasyon ay tumatagal ng 1–5 ms, at sa murang device hanggang 20 ms, na maaaring humantong sa paglaktaw ng frame.

// ❌ Problemadong code — pagbasa ng SharedPrefs sa UI thread
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // StrictMode detectDiskReads → VIOLATION!
        prefs = getSharedPreferences("config", MODE_PRIVATE)
    }
}

// ✅ Naayos na code — pagbasa sa pamamagitan ng Coroutine
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        loadConfigAsync()
    }
}

Detectio n ng Pagtagas ng Activity

Ang StrictMode na may VmPolicy.detectActivityLeaks ay makakakita ng Activity na lumabas na sa stack (finish tinawag), ngunit ang object ng Activity ay nananatili sa memory dahil sa static na reference o hindi rehistradong callback. Karaniwang senaryo: pagrehistro ng EventBus o LocationListener sa onResume nang walang tawag sa unregister sa onPause. Ang VmPolicy ay magpapakita ng stack trace na may indikasyon ng linya kung saan ginawa ang reference.

// ❌ Pagtagas — hindi nakansela ang 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()
    // Nakalimutan: locationManager.unregister(locationCallback)
}