AskaEth
22d655b73b
主人报「网易云分享文本到 App 会闪退」。已修的那个 P0（df7b504 / 6d4f2cd：面板一打开就崩 / 点展开又崩）是 Dp.Infinity 当哨兵值与展开态没去掉 verticalScroll，那是**最可能**的成因。 这一批把这**整条链**（Manifest 的 intent-filter → ShareIntake → 落地面板 → sendConfirm → 气泡渲染）从「假设主人的包就是当前 HEAD」重审了一遍，找残留崩溃点。 结论：**当前 HEAD 这条路径我没有找到残留崩溃点**。逐项复核见下面「查了什么」。审查中发现 一处**不变量只写在 KDoc 里、实现并不保证**的地方，本批把它补实（不改变任何现状行为）。 改了什么（最小的一处 + 一处 KDoc 更正）： 1. `shareConfirmWindowCap` 从纯透传改成**守卫式**：`measured` 非有限（`Dp.Infinity` / `Dp.Unspecified` 即 NaN）时与「还没量到」同等对待，回落 150dp。它上面那段 KDoc 一直写着「返回值永远不是 Dp.Infinity」，而实现是 `measured ?: 150.dp` —— 今天唯一的调用方传的是 null 或 `getLineBottom(...).toDp()`（恒有限），所以**现状没有可触发的崩溃**；但那条不变量此前只由 「调用方的好习惯」保证，而它正是 W58 崩过两次的那一条。补守卫之后可以给出一句可证明的话： 这一层给出的上限**恒有限**，于是面板里那两个 `verticalScroll`（外层预览区 / 收起态正文窗） 在任何输入与状态下都不可能落在无界高度上。 2. `ShareConfirmBody` 那段 KDoc 里一句不准确的话改准：旧文说该函数的出口「要么返回 null（不设 上限）」——它恒返回 Dp，「不设上限」发生在展开态那一支（连 verticalScroll 一起去掉），与它是两回事。 新增测试： - `ShareTextPipelineTest`（12 例，新文件）：把「分享一段文本进来」这条链从 Intent 字段一路串到 气泡正文（`ShareRules.extract` → `shareConfirmPreview` / `shareConfirmBody` / `shareConfirmCanSend` → `parse`），此前**跨层串测完全空缺**（每一站各自有单测，没有一处把它们接起来）。钉三件事： ①**内容一字不丢**（「分享单曲 + 链接 + emoji + 多行」逐字节到气泡正文；用户补的描述同样）； ②**正文里的标记按既有语义走且绝不抛异常**（`<p><p>` / `<action>` / 全角半角星号 / `1 < 2` / 半个代理对 / `\u0000` / 200 个落单 `<p>` / 10 万字符都过一遍）； ③**面板预览不过解析器、气泡过解析器**（同一段带标记的字，预览里是原样、气泡里被剥离—— 这是如实记下的一处不一致，不是崩溃）。 - `ShareConfirmTest`：把 `Dp.Infinity` 与 `Dp.Unspecified` 放进「任何输入都给不出非有限上限」的 输入表——原先那张表**恰好漏掉了唯一能推翻该断言的两个值**。反证过：把实现改回纯透传时， 这一条用例确实 FAILED（`no input can produce a non finite cap`），改回守卫后通过。 查了什么（逐项，都是读代码 + 纯函数求证，不是猜）： ① Intent 形态：`getCharSequenceExtra` 对非 CharSequence（`String[]` / `ArrayList`）是**catch 住 ClassCastException 回 null**（SDK 源码 `BaseOs/BaseBundle.getCharSequence` 已核），不抛； EXTRA_STREAM 走原始值按形态分派；字符串形态只认 `content://`；ClipData 纯文本条目只当 「带着内容迹象」用来出告知。② 空/边界输入：空串 / 纯空白 → `worthDelivering=false` 静默 （正确）；`<p><p>` / 星号 / `<` 一律不抛（新用例钉住）。③ 面板渲染：Miuix 的 `WindowDialog` / `TextField` 里**没有**任何 scroll 节点（反编译 `miuix-ui-0.9.3` 的 class 查过），面板里的两个 `verticalScroll` 各自都先过一层有限的 `heightIn`。④ 出队闸门：闸门在 `take()` 之前、认领落在 VM 状态里，重建不会再取；`claimSharedContent` 只有 Compose 主线程一个调用点。⑤ 发送后渲染： `parse` 的落单标签口径（W55）与既有契约一致，新用例把分享正文含标记时的落点一并钉住。 ⑥ 通知/保活：分享落地与 `ProactiveFrameIntake` / `KeepAliveService` 之间没有任何联动路径。 没覆盖 / 只能上真机的：渲染层本身（本模块没有 Compose UI 测试依赖，`checkScrollableContainerConstraints` 那一类崩溃单测抓不到——W58 的教训），以及任何需要设备的观感；本批**没有**装包上机（emulator-5554 上有别的会话在跑，主仓在我复核期间刚构建过 APK，我刻意没有动它）。 真跑：`./gradlew.bat assembleDebug` 通过；`./gradlew.bat testDebugUnitTest` 全量 **115 suites / 1400 tests / 0 skipped / 0 failures / 0 errors**（基线 114 / 1388，差的正是本批 新增的 1 个 suite 12 例，其余一条没碰坏）。