StrictMode卡顿与泄漏检测-StrictMode原理(2)：CloseGuard、IO卡顿与SqliteCursor泄漏的配置骨架

1. 从一次「主线程卡到掉帧」说起StrictMode 在 Android 开发里算是个老熟人但很多人只停留在ThreadPolicy里加个detectAll就完事。真正让它在排查资源泄漏和 IO 卡顿上发挥价值的是它背后那套「埋桩—拆桩—爆炸」的关闭检测机制。这篇是 StrictMode 原理系列的第二篇聚焦三个关键词CloseGuard、IO 卡顿检测、SqliteCursor 泄漏检测。如果你正在被「主线程读文件导致掉帧」或者「Cursor 没关导致内存涨」这类问题折磨这篇会给你一套可以直接复制进项目的配置骨架以及触发验证的具体动作。先说清楚 StrictMode 到底能做什么。它本质上是 Android 在开发期提供的一个「运行时哨兵」通过BlockGuard在文件 IO、网络访问、数据库操作等关键路径上埋点一旦检测到主线程做了不该做的事或者资源对象被 GC 回收时还没关闭就按你配置的 penalty 方式上报。适合谁适合所有在开发期想提前暴露性能与泄漏问题的 Android 工程师尤其是做中大型项目、模块多、第三方库杂的场景。我试过在一个老项目里只开penaltyLog不崩溃结果日志里刷出几十条A resource failed to call close顺着查下去发现三个模块的流没关。这就是 StrictMode 的价值它不帮你修但它帮你定位。2. CloseGuard 与 IO 关闭检测的埋桩原理2.1 CloseGuard 的三个动作open、close、warnIfOpenCloseGuard 是 StrictMode 专门用来处理「资源未关闭」的类核心就三个函数。open(String closer)在资源构造时调用相当于埋下一颗桩子记录下「谁该关我」close()在资源正常释放时调用把桩子拆掉warnIfOpen()则在对象被 GC 回收时检查桩子还在不在还在就说明没关触发上报。用FileOutputStream举例最直观。它的构造函数里有guard.open(close)这就是埋桩close()方法里有guard.close()这是拆桩而finalize()里有guard.warnIfOpen()这是爆炸。所以当你 new 了一个FileOutputStream写文件却没调close()等 GC 回收它时warnIfOpen发现桩子还在就会通过reporter.report把堆栈打出来。这套机制不依赖你手动检查完全靠 GC 触发所以泄漏检测是「延迟但确定」的。2.2 IO 卡顿检测走的是 BlockGuardOS 这条链IO 卡顿检测和关闭检测是两条不同的路径。文件流的调用链大致是FileInputStream/FileOutputStream - IOBridge - ForwardingOs - BlockGuardOS - LibCore.OS。关键在BlockGuardOS这一层它在open方法里会调用BlockGuard.getThreadPolicy().onReadFromDisk()和onWriteToDisk()在close里还会检查 socket 的onNetwork()。这些onXxx方法最终回到StrictMode判断当前线程策略掩码里有没有对应的DETECT_THREAD_DISK_READ之类的位。有的话就构造一个DiskReadViolation走违规处理流程。所以主线程做 IO 被检测到本质是BlockGuardOS在代理系统调用时顺手问了一句「当前线程策略允许吗」。2.3 SqliteCursor 泄漏检测靠 finalize 里的 mWindow 判断SQLiteCursor的泄漏检测逻辑在它的finalize()里。当mWindow ! null时说明这个 Cursor 执行过move系列方法、查询窗口还开着但对象已经被回收了意味着你没调close()。这时如果StrictMode.vmSqliteObjectLeaksEnabled()为 true就会调用StrictMode.onSqliteObjectLeaked上报日志里会带上 database label、table 名和截断到 1000 字符的 SQL。这里有个细节mWindow只有在执行过move之后才会被赋值。所以如果你 new 了 Cursor 但没 move 就丢了可能不会触发这条检测。这也是为什么有些泄漏「看起来没报」的原因。3. 可复制的 StrictMode 配置骨架下面这套配置可以直接放进Application.onCreate()里开发期开启Release 关闭。我把它拆成 ThreadPolicy 和 VmPolicy 两块penalty 用penaltyLog加penaltyDeathOnNetwork的组合既能看日志又能在网络违规时直接崩逼你改。class MyApp : Application() { override fun onCreate() { super.onCreate() if (BuildConfig.DEBUG) { enableStrictMode() } } private fun enableStrictMode() { StrictMode.setThreadPolicy( StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .detectCustomSlowCalls() .penaltyLog() .penaltyDeathOnNetwork() .build() ) StrictMode.setVmPolicy( StrictMode.VmPolicy.Builder() .detectLeakedSqlLiteObjects() .detectLeakedClosableObjects() .detectActivityLeaks() .detectLeakedRegistrationObjects() .penaltyLog() .build() ) } }几个参数说明一下。detectLeakedClosableObjects()对应 CloseGuard 那条链能抓FileOutputStream、ParcelFileDescriptor这类没关的对象。detectLeakedSqlLiteObjects()对应 SqliteCursor 泄漏。detectActivityLeaks()抓 Activity 被静态引用。penaltyDeathOnNetwork()只在网络违规时崩因为主线程网络是硬伤其他用penaltyLog避免开发时频繁崩溃影响调试。注意penaltyDeath和penaltyDeathOnNetwork不要同时开否则一个磁盘读违规就崩开发体验很差。建议网络用 death其余用 log。如果你只想临时验证某个模块可以用StrictMode.noteSlowCall手动埋点配合detectCustomSlowCalls使用StrictMode.noteSlowCall(loadUserProfile) // 执行可能慢的逻辑4. 触发验证一次 SqliteCursor 泄漏与主线程 IO配置好之后怎么确认它真的在工作写两个触发动作。第一个主线程 IO。在某个 Button 点击里直接读文件findViewByIdButton(R.id.btn_io).setOnClickListener { val file File(getExternalFilesDir(), hello.json) val outputStream FileOutputStream(file) outputStream.write(hello world.toByteArray()) // 故意不 close }运行后看 Logcat过滤StrictMode你会看到类似StrictMode policy violation; ~durationxx ms: android.os.StrictMode$DiskWriteViolation的日志带上堆栈指向你的点击回调。如果开了detectLeakedClosableObjects等 GC 之后还会看到A resource failed to call close。第二个SqliteCursor 泄漏。写一个查询但不关 Cursorval db SQLiteDatabase.openOrCreateDatabase( File(getExternalFilesDir(), test.db), null ) db.execSQL(CREATE TABLE IF NOT EXISTS user(id INTEGER, name TEXT)) db.execSQL(INSERT INTO user VALUES(1, taotoken)) val cursor db.rawQuery(SELECT * FROM user, null) cursor.moveToFirst() // 故意不 close然后触发 GC Runtime.getRuntime().gc() Runtime.getRuntime().gc()日志里会出现Finalizing a Cursor that has not been deactivated or closed后面跟着 database、table 和 query 信息。这就是SQLiteCursor.finalize()里mWindow ! null触发的上报。提示GC 触发有延迟多调几次System.gc()或者用 Android Studio 的 Profiler 手动触发 GC能更快看到泄漏日志。5. 本篇常见错排查日志里看不到任何 StrictMode 输出。先确认BuildConfig.DEBUG为 true再确认penaltyLog()加了。有些 ROM 会过滤 StrictMode 日志用adb logcat -s StrictMode单独抓。另外如果用了penaltyDeath进程直接崩了日志可能在 crash 之前就输出了去 logcat 的 crash buffer 里找。CloseGuard 不报泄漏。检查对象是否真的被 GC 回收了。如果对象还被强引用持有finalize不会执行warnIfOpen自然不触发。另外CloseGuard.setEnabled(false)如果被某处调用整个机制会静默关闭全局搜一下有没有这行。SqliteCursor 泄漏检测不生效。确认 Cursor 执行过move系列方法否则mWindow为 nullfinalize里判断不成立。另外detectLeakedSqlLiteObjects()在部分高版本 API 上行为有变化建议用detectLeakedClosableObjects()兜底。主线程 IO 没报但确实卡。StrictMode 只检测它埋点的那些路径比如FileInputStream、FileOutputStream、SQLiteDatabase等。如果你用的是 NIO 的FileChannel或者某些第三方库自己封装的 IO可能绕过BlockGuardOS检测不到。这种情况需要结合 Systrace 或 Profiler 看主线程耗时。排查这类问题除了本地日志也可以借助 AI 工具辅助分析堆栈。我平时会把 StrictMode 的违规堆栈贴给模型让它帮我定位是哪个模块的调用链通过统一的 Key/API 通道接入会比较省事。TaoToken 提供模型对话、Coding Plan、API Keys 管理这些入口接入文档在 https://taotoken.net/api 需要的话可以从 API Keys 页面 https://taotoken.net/api-keys 拿 Key再对照文档 https://taotoken.net/doc 配置。模型对话入口在 https://taotoken.net/chat 长期做编码和 Agent 的可以看 Coding Plan https://taotoken.net/coding-plan 。6. 把 StrictMode 当成开发期的常驻哨兵StrictMode 的关闭检测和 IO 卡顿检测本质是 Android 在系统调用层埋了一套「开发期断言」。CloseGuard 管资源关闭BlockGuardOS 管主线程 IOSQLiteCursor 的 finalize 管数据库游标泄漏。三者共用同一套违规上报通道配置上就是 ThreadPolicy 和 VmPolicy 两块。实际用的时候建议开发期常开penaltyLog网络违规用penaltyDeathOnNetwork强制暴露。每次新增模块或者引入第三方库跑一遍主流程看日志里有没有新的违规。把 StrictMode 日志当成代码 review 的一部分比等到线上 OOM 或者 ANR 再去查要省事得多。配置骨架可以直接复制触发验证的两个例子也可以放进你的测试用例里确保检测机制真的在工作。