闭包在WebView预热阶段引发内存常驻，本质是JS闭包意外持有Activity、Context或WebView实例等原生对象，导致GC无法回收，表现为预热后内存基线抬升、多次预热不回落、低内存设备进程被杀。
闭包在 WebView 预热阶段引发的初始化内存常驻，本质是 JavaScript 层闭包意外持有了原生上下文（如 Activity、Context、WebView 实例本身），导致 GC 无法回收，进而使这部分内存长期驻留。这种风险不易被常规内存监控直接标记为“泄漏”，但会表现为预热后 WebView 占用内存基线明显抬高、多次预热后内存不回落、甚至触发低内存设备的进程回收。
观察预热后内存基线是否异常抬升
WebView 预热通常指在后台提前创建 WebView 实例、调用 loadUrl("about:blank") 或执行简单 JS 初始化。若预热完成后，应用空闲状态下的 Java 堆与 Native 内存未回归至预热前水平，就需警惕：
- 使用 Android Profiler 的 Memory 跟踪，对比预热前、预热完成 30 秒后、强制 GC 后的内存快照，重点关注
WebView、WebViewCore、JsBridge相关对象的实例数和 retained size - 特别注意 Native Heap 中持续增长的 GPU texture、skia bitmap 等分配——它们常由 JS 闭包中长期引用的 Canvas、Image 或 Web Worker 持有
- 若预热仅执行一次，但后续每次打开 WebView 页面时内存起点都比上一次更高，说明预热产生的 JS 上下文未被彻底销毁
检查 JS 层是否通过闭包捕获了原生对象引用
常见高危模式包括：
- 在预热阶段通过
addJavascriptInterface()注入 Java 对象后，JS 侧定义了闭包函数并将其赋值给全局变量或长期存活对象（如window.bridge = { handler: function() { nativeObj.doSomething(); } }），此时闭包隐式持有nativeObj引用 - 使用
eval()或Function()动态生成函数，且该函数访问了外层作用域中传入的 WebView 引用或 Context 相关变量 - 预热时注册了未清理的事件监听器（如
window.addEventListener('message', (e) => { ... })），而回调函数中引用了预热期间创建的 DOM 元素或 JS 对象，这些对象又间接关联到原生资源
验证 JS 执行环境是否真正隔离销毁
WebView 预热若复用同一 WebView 实例，其 JS 执行上下文（V8 Context）默认不会随页面跳转自动销毁。关键验证点：
- 调用
webView.evaluateJavascript("window.location.href", ...)，确认返回的是预热页（如about:blank）而非业务页，排除误用已加载业务内容的 WebView 做预热 - 在预热后、正式使用前，执行
webView.clearCache(true)和webView.clearHistory()，再尝试webView.reload()—— 若 reload 触发 JS 报错（如ReferenceError: xxx is not defined），说明旧上下文已被清空；若仍能正常访问预热时定义的变量/函数，则上下文仍在驻留 - 对预热 WebView 调用
destroy()后再重建，观察内存是否回落。若不回落，说明销毁前已有闭包将对象挂载到全局或长期存活对象上
使用 Chrome DevTools 远程调试定位闭包持有链
启用 WebView 调试后（WebView.setWebContentsDebuggingEnabled(true)），通过 chrome://inspect 可连接预热中的 WebView：
- 在 Memory 面板中录制 Heap Snapshot，筛选
Closure类型对象，查看其 retaining path 是否包含AndroidWebView、JavaObjectWrapper或自定义桥接类 - 在 Sources 面板中暂停 JS 执行，检查 Scope 面板中 Closure 作用域内变量是否包含疑似原生引用（如
this指向非标准 JS 对象、变量名含ctx/activity/webview） - 在 Console 中运行
console.memory，对比预热前后totalJSHeapSize和usedJSHeapSize增量，若增量显著且 GC 后不释放，大概率存在闭包常驻
