[Android] 发消息后内存/线程持续递增至1.1GB后前台崩溃——补充WebView/Chromium线程泄漏证据

## 现象
小米/Redmi(23116PN5BC, Android 16, API 36) 上，Cindy 客户端 `com.xd.cindycn` v0.1.7：
- 打开 App 慢、对话回复慢、界面滑动/弹窗卡顿
- **发消息时最明显**：先卡顿后在前台直接退出（闪退）
- 越用越卡，多聊几轮后必崩；后台易被杀

## 已采集的现场证据（adb 只读，未改设置）
本次通过 adb 做了只读诊断，抓到与 #2726/#1692 同簇的现场数据，**补充其中缺少的 WebView/Chromium + 线程泄漏证据**。

### 1. 技术栈
这是 **React Native (Expo) + Hermes** 应用（**不是 Flutter**），进程内还驻留 Themis 风控 SDK（内嵌 V8）、Reanimated worklets、Hermes profiler 采样器、Fresco、OkHttp。
- APK 163MB，含 `assets/index.android.bundle` **17MB**
- 运行时加载 `libhermesvm.so`、`libreactnative.so`、`libworklets.so`、`libthemis*.so`(含 V8)、`libjsijniprofiler.so`

### 2. 发一条消息，内存 +270MB、线程 +36（实时测）
| 时间 | RSS | 线程 | 说明 |
|------|-----|------|------|
| 17:07:44 | 658MB | 82 | 基线 |
| 17:08:12 | 617MB | 82 | GC 释放 56MB（发送瞬间）|
| 17:08:33 | 902MB | 111 | **+213MB，线程 82→111** |
| 17:08:38 | 946MB | 111 | 峰值 |

### 3. 新增内容/发送时拉起整套 Chromium/WebView + 线程池（关键）
发消息后线程新增（82→117）：
```
Chrome_ProcessLa Chrome_IOThread NetworkService VizWebView
Chrome_InProcGp Chrome_ChildIOT ← Chromium/WebView 成套
CrAsyncTask #5/#6/#7 VideoCaptureThr AudioThread
OkHttp TaskRunn: 2→7 ThreadPoolForeg×6 ThreadPoolSingl×3
```
**这些 Chromium/WebView/线程池线程发送后不释放（5 秒后仍在原位，无回落）→ 跨消息累积。**

### 4. 连续 3 条消息：内存递增至 1.1GB+ 后前台崩溃
| 时间 | RSS | 线程 | 阶段 |
|------|-----|------|------|
| 17:09:39 | 1063MB | 111 | 基线 |
| 17:09:50 | 1071MB | 111 | 第1条 |
| 17:09:59 | 1193MB | 114 | 第2条 |
| 17:10:02 | 1194MB | 114 | 第3条(峰值) |
| 17:10:03 | **进程死亡** | — | 崩溃 |

崩溃日志：
```
17:10:03.571 WINDOW DIED ...com.xd.cindycn.MainActivity
17:10:03.576 Process com.xd.cindycn (pid 2601) has died: fg TOP
17:10:03.599 Force removing ActivityRecord...: app died, no saved state
17:10:12.828 tombstoned: intercept ... kDebuggerdNativeBacktrace
17:10:12.828 ...APP_SCOUT_WARNING...com.xd.cindycn-2601
```

### 5. GC 与主线程阻塞
```
Background young concurrent copying GC freed 100MB
Background concurrent copying GC freed 141MB
Waiting for a blocking GC Alloc ← 主线程阻塞（卡顿/ANR 直接原因）
```
当天 ANR 至少 8 次（09:45–14:28）。

### 6. 熄屏后台仍烧 CPU 34.7%，被系统节流
```
SSRU-CpuResourceTracker: AppCpuState{uid=10735, pkgName=com.xd.cindycn, usages=34.717, restricter=1}
```
CPU tick 采样：`RenderThread` 175 tick/2.5s（绝对主力，RN 新架构重渲染），远高于其他线程。

## 与 #2726 / #1692 的关系
已交叉引用同一故障簇（发消息 → GC/内存压力 → 输入或渲染超时 → 退出）。本报告**补充了它们缺失的证据**：
- #2726 持有者分析的 `WaitingForGcToComplete` / React Native selectable 文本挂载，与本站 `Waiting for a blocking GC Alloc` 一致；
- 但**新证据指向一个此前未提及的资源泄漏源：发送消息时新建的 Chromium/WebView 成套线程 + OkHttp 2→7 线程 + ThreadPool 批量新建，且不释放**。这解释了为何内存会从 ~700MB 一路递增到 1.1GB+（持续无界增长），是 #2726 里"RSS 不持续无界增长"验收点最直接的反例。
- 建议排查发送时是否重复创建 WebView/OkHttpClient/线程池而未复用或销毁。

## 复现方式
在小米/Redmi（Android 16）上打开 Cindy → 持续发送纯文字消息 3-5 条 → 观察内存(RSS)快速上升、机身发烫（实测 55.8°C，触发系统降频）、随后前台退出。

## 设备信息
型号 23116PN5BC，Android 16 (API 36)，Cindy v0.1.7（2026-08-28 凌晨更新），包名 `com.xd.cindycn`。

> 附：完整诊断报告与逐条原始数据见本次会话存档（本 issue 已包含核心数据）。

Start by reproducing the issue on the specified Xiaomi/Redmi Android 16 device while collecting RSS, thread counts, GC, and ANR data during repeated message sends. Trace the send-message path for repeated WebView/Chromium, OkHttpClient, or thread-pool creation and whether those resources are released. Done means the resource growth is explained and repeated sends no longer accumulate threads or memory until the app exits.

Written by the indexing model from the issue text.