@skillbuilder/miniapp-simulator 0.2.2 → 0.2.7

package/docs/electron-review.md

@@ -1,21 +1,232 @@
-# Electron 审核模拟器接入说明
+# 质量评测二期：Electron 内存精测方案
 
-审核模拟器位于 `apps/mini-app-review-simulator`，核心渲染能力来自：
+## 1. 结论与定位
+
+二期采用 Electron 是可行方向，但定位必须是“高置信复测舱”，不是一期 Mars 远程评测的替代品，也不能宣称能得到移动端真实 OOM 阈值。
+
+- 一期负责审核队列内的广覆盖采集：审核员真实使用小工具时采集性能、资源、异常和稳定性证据。
+- 二期负责风险样本、争议样本和健康对照样本的受控复测：在固定 Electron/Chromium/设备档下，重复相同核心操作，采集 GC 后的 renderer retained heap、renderer 进程内存和崩溃原因。
+- 二期的高置信来自“隔离环境 + 固定动作 + 重复测量 + 质量门槛”，不是来自单个 Electron API。
+- 一期与二期数据都上报 APM，通过 `executionEnv`、`heapSource`、版本和设备档分组分析；两套内存数字不能直接混为同一分布。
+
+当前仓库已具备 Electron 审核壳、`webview` 渲染、`webContentsId` 获取、主进程 IPC 和嵌入式 DevTools，但尚未具备完整的二期评测能力。CDP 采集控制器、独立会话、固定操作协议、Apollo 接入、APM 上报与 Electron 侧报告仍需实现和验证。
+
+## 2. 当前实现事实与缺口
+
+| 项目 | 当前实现 | 二期要求 |
+| --- | --- | --- |
+| Electron 审核壳 | `apps/mini-app-review-simulator`，Electron 40 | 固定 Electron/Chromium 版本并随报告登记 |
+| 小工具容器 | Electron `<webview>`，可取得 `webContentsId` | 每次评测创建新的 webview 和独立非持久化 partition |
+| 包切换 | `loadFiles` 会中断并销毁当前 renderer | 等待旧目标退出，登记新 `webContentsId`、PID、进程创建时间 |
+| session | 固定 `persist:mini-app-review` | 每个评测会话使用唯一 partition，避免缓存、Storage、Cookie 和 Service Worker 串包 |
+| DevTools | `detachDevtools` 只隐藏视图，target 的 DevTools 仍打开 | 精测窗口必须真正关闭 DevTools，结束 CDP 后再按需恢复 |
+| CDP | 未接入 | 主进程独占 attach、采样、异常收口和 detach |
+| 审核探针 | Electron 路径未接一期评测插件 | 抽取共享 audit core，Electron 只新增采集适配器 |
+| 策略与上报 | Electron app 未接 Apollo / APM 评测链路 | 读取完整策略，并把样本、事故、结果统一上报 APM |
+
+### 2.1 不能采用的假设
+
+1. **不能假设一个 webview 永远独占一个 OS renderer 进程。** webview 有独立 `webContents`，但 Chromium 可能共享 renderer 进程。必须同时登记 `webContentsId`、`webContents.getOSProcessId()` 和 `app.getAppMetrics()` 的 `creationTime`，发现 PID 归属不唯一时将进程级指标降级为旁证。
+2. **不能把 CDP 堆值命名为“小工具独占堆”。** `Runtime.getHeapUsage` 返回目标 V8 isolate 的堆用量，可能包含 preload、isolated world 和采集代码。统一命名为 `rendererRetainedHeap`，并用空壳基线与重复测量控制系统开销。
+3. **不能使用不存在的 `webContents.getProcessMemoryInfo()`。** 进程指标使用 `webContents.getOSProcessId()` 匹配 `app.getAppMetrics()`；若需读取当前 renderer 的 `process.getProcessMemoryInfo()`，只能通过受信 preload 暴露最小只读 IPC。
+4. **不能让 CDP 与 DevTools 同时占用 target。** Electron 官方行为是打开 DevTools 会使 `webContents.debugger` 分离。精测必须进入独占模式：关闭 DevTools → attach CDP → 采集 → detach → 恢复 DevTools。
+5. **不能用 `Memory.forciblyPurgeJavaScriptMemory` 作为常规采样手段。** 它用于模拟 OOM 干预。常规锚点只使用 `HeapProfiler.collectGarbage`；前者仅用于单独的容灾实验，结果不得进入正常评分样本。
+
+## 3. 测量对象与指标口径
+
+### 3.1 三层证据
+
+| 层级 | 指标 | 用途 | 限制 |
+| --- | --- | --- | --- |
+| Renderer JS 堆 | GC 后 `Runtime.getHeapUsage.usedSize/totalSize` | 判断重复操作后的存活对象增长 | 是 isolate 口径，不是业务对象独占口径 |
+| Renderer 进程 | `app.getAppMetrics()` 的 working set、peak working set；Windows 可用 private bytes | 观察更接近 OOM 的进程压力 | 进程可能共享，平台字段不完全一致 |
+| 小工具运行探针 | 显存估算、Canvas、图片解码、WASM、Worker、FPS、长任务、JS error、context lost | 解释增长来源和体验风险 | GPU/媒体进程可能共享，显存仍是估算值 |
+
+直接稳定性证据还包括 `render-process-gone`：`oom`、`memory-eviction`、`crashed`、`killed` 等原因必须作为事故上报，不能仅依赖内存曲线推测。
+
+### 3.2 retained heap 判定
+
+单次“开始值减结束值”不能判定泄漏。标准流程在相同初始状态下重复相同核心操作至少 3 次：
+
+```text
+fresh webview + unique partition
+  → load ready
+  → warm-up
+  → quiet barrier
+  → collectGarbage + baseline
+  → 核心操作第 1 轮 → quiet barrier → GC → anchor[1]
+  → 核心操作第 2 轮 → quiet barrier → GC → anchor[2]
+  → 核心操作第 3 轮 → quiet barrier → GC → anchor[3]
+  → 收口、销毁 webview、释放 session
+```
+
+quiet barrier 至少满足：guest 已 ready、网络待完成数为 0 并持续 `quietWindowMs`、窗口内没有超阈值长任务、连续动画帧可推进。达不到条件时报告为 `unscorable`，不得拿不稳定锚点出泄漏结论。
+
+种子指标：
+
+- `rendererRetainedHeapBaselineBytes`
+- `rendererRetainedHeapByIterationBytes[]`
+- `rendererRetainedHeapGrowthBytes`
+- `rendererRetainedHeapSlopeMBPerLoop`
+- `rendererProcessWorkingSetP95Bytes`
+- `rendererProcessPeakWorkingSetBytes`
+- `coreFlowCompletedCount`
+- `quietBarrierPassCount`
+- `renderProcessGoneReason`
+
+泄漏候选需同时满足：核心流程完成、锚点质量达标、连续多轮单调增长、增长量超过设备档阈值。阈值在样本验证前只告警，`enforce: false`。
+
+## 4. 审核与复测流程
+
+### 4.1 触发范围
+
+二期不要求审核员对队列中每个包重复做一轮长时间精测。进入 Electron 精测队列的样本包括：
+
+- 一期出现 OOM 风险、heap 持续增长、context lost、白屏、卡死、JS fatal 或进程异常。
+- 一期 `unscorable`、覆盖不足、审核结论争议或同包多次结果不一致。
+- 按业务线和应用形态抽取的健康对照样本，用于计算误报率和阈值分离度。
+- 版本升级、采集逻辑变化、Electron/Chromium 升级后的回归样本。
+
+### 4.2 审核员操作
+
+1. 从精测队列进入一个包，系统自动创建唯一会话、唯一非持久化 partition 和新 webview。
+2. 页面 ready 后先展示核心操作清单；能自动化的步骤由脚本执行，必须人工判断的步骤由审核员完成并点击里程碑。
+3. 每轮必须执行同一条核心路径，例如“进入主功能 → 完成一次核心任务 → 返回初始状态”。自由探索仅作为补充观察，不参与泄漏硬判定。
+4. 系统在每轮结束后自动等待 quiet barrier 并采集锚点；审核员不需要手动触发 GC 或读数。
+5. 完成规定轮次后自动出报告；若页面崩溃、PID 归属异常、CDP 被分离或稳定条件不足，明确显示不可评分原因。
+6. 切换下一个包前销毁 webview 和会话；不得复用上一个包的持久化存储。
+
+## 5. 架构与代码落点
+
+```text
+审核壳 Renderer
+  │ start / milestone / finish
+  ▼
+preload 最小 IPC
+  ▼
+Electron 主进程 AuditController
+  ├─ SessionIsolation：partition / webContents / PID / creationTime
+  ├─ DevToolsLease：关闭 DevTools、独占 CDP、结束后恢复
+  ├─ CdpMemoryAdapter：GC、heap usage、debugger detached
+  ├─ ProcessMemoryAdapter：app.getAppMetrics 匹配 renderer PID
+  ├─ IncidentAdapter：render-process-gone / unresponsive / console
+  └─ APM Reporter
+        ▲
+共享 audit core
+  ├─ probe 与采集质量
+  ├─ 指标派生、规则与三态报告
+  └─ Apollo 完整策略
+```
+
+建议落点：
+
+- `apps/mini-app-review-simulator/src/main/audit/`：Electron 会话控制、CDP、进程指标和事故收口。
+- `apps/mini-app-review-simulator/src/main/devtools.ts`：增加真正关闭/恢复 target DevTools 的租约接口，隐藏视图不等于释放。
+- `apps/mini-app-review-simulator/src/preload/index.ts`：仅暴露类型化的 start/milestone/finish/status IPC。
+- `packages/miniapp-simulator/src/renderer/content-host/webview-content-host.ts`：允许创建 webview 时注入本次会话 partition；partition 必须在首次导航前确定。
+- `packages/miniapp-audit-plugin`：保留平台无关的探针、规则和报告核心；Electron 适配器不得复制一套公式。
+
+CDP 采集状态机：
+
+```text
+idle → preparing → attached → warming → measuring → finalizing → finished
+          │           │           │           │
+          └───────────┴───────────┴───────────┴→ unscorable / crashed
+```
+
+任一异常都必须在 `finally` 中 detach debugger、解除监听并恢复 DevTools；不得让失败会话污染下一个包。
+
+## 6. APM 上报与字段登记
+
+二期沿用现有 APM 事件，不新增自有 `/audit/raw` 接口。`miniapp_audit_session`、`miniapp_audit_incident`、`miniapp_audit_package`、`miniapp_audit_result` 通过 `executionEnv: electron` 与一期区分。所有 `measurement_data` 只放数字；布尔值用 `0/1`。
+
+每次结果必须登记：
+
+- 关联：`sessionId`、`phase1SessionId`、`reviewTaskId`、`appId`、`versionId`、`buildId`、`businessLine`。
+- 环境：`executionEnv`、`heapSource`、`electronVersion`、`chromiumVersion`、`platform`、`arch`、`deviceProfile`、`policyVersion`、`ruleVersion`。
+- 归属：`webContentsId`、`osProcessId`、`processCreationTime`、`partitionId`、`processAttributionReliable`。
+- 过程：`repeatCount`、`coreFlowCompletedCount`、`quietBarrierPassCount`、`durationMs`、`sampleCount`、`debuggerAttached`、`devtoolsClosed`。
+- 指标：retained heap、每轮增长、working set、一期探针指标和事故计数。
+- 结果：`status`、`score`、`coverage`、`blockingPassed`、`unscorableReason`、`renderProcessGoneReason`。
+
+APM 上报失败不能改变小工具运行结果，但必须在本地状态中显示，并做有限重试；最终失败需计数和日志，避免把“没有数据”误判成“没有风险”。
+
+## 7. Apollo 配置
+
+沿用 `miniappSimulatorAuditPolicies`。命中 Electron 场景时整份采用远端策略；未取得配置时使用本地完整默认策略。二期字段建议放入完整策略的 `electron` 段：
 
 ```ts
-import { createElectronReviewSimulator } from "@skillbuilder/miniapp-simulator/adapters/electron";
+electron: {
+  enabled: false,
+  triggerMode: "risk_and_sample",
+  healthySampleRate: 0.05,
+  repeatCount: 3,
+  warmupMs: 10_000,
+  quietWindowMs: 2_000,
+  maxSessionMs: 180_000,
+  collectHeapSnapshot: false,
+  retainedHeapGrowthMBPerLoop: 8,
+  rendererWorkingSetMB: 512,
+  enforce: false,
+}
 ```
 
-审核壳子负责：
+可配置项包括启用开关、抽样率、重复次数、稳定窗口、时长、设备档、阈值和 `enforce`。CDP 命令顺序、GC 时机、指标公式、三态报告和来源隔离留在代码中。
+
+## 8. 报告状态与评分边界
+
+| 状态 | 条件 |
+| --- | --- |
+| `scored` | 环境隔离成功、核心路径完成、重复轮次与锚点质量达标，且没有归属冲突 |
+| `unscorable` | CDP attach/detach 异常、DevTools 抢占、quiet barrier 不足、操作未完成、PID 归属不可靠或样本不足 |
+| `loadFailed` | 包无法启动，或 renderer 在进入有效采集前退出 |
+| `crashed` | 采集中出现 `render-process-gone`，保留具体 reason 和已采证据 |
+
+OOM、`memory-eviction` 和 crash 是直接事故证据；内存增长是风险证据。桌面 Electron 阈值只用于同环境相对筛查，不能直接等同 Android/iOS 的 OOM 线。
+
+## 9. 实施顺序
+
+### P0：可信原型
+
+1. 真正关闭嵌入式 DevTools，成功 attach CDP，完成后恢复 DevTools。
+2. 创建唯一非持久化 partition，记录 webContents/PID/creationTime，验证连续换包无 Storage、Cookie、Cache、Service Worker 串包。
+3. 采集 `HeapProfiler.collectGarbage + Runtime.getHeapUsage` 和 `app.getAppMetrics()`。
+4. 接入 `render-process-gone` 与 debugger `detach` 事件，所有异常均能收口。
+5. 用 5 个代表性测试包跑通完整操作，不只打开页面。
+
+### P1：可评测闭环
+
+1. 接入一期共享探针、规则、三态报告和 APM 上报。
+2. 实现核心操作里程碑、重复轮次和 quiet barrier。
+3. 接 Apollo 完整策略和本地默认配置，默认 `enforce: false`。
+4. 在界面展示环境、轮次、采集质量、事故、分项指标和不可评分原因。
+
+### P2：样本校准与准入
+
+1. 建立已知泄漏、正常高水位、WebGL、WASM、Worker、资源释放、OOM/crash 等样本集。
+2. 同包同版本至少重复 5 次，计算关键指标变异系数；不稳定指标不得进入评分。
+3. 用风险样本和健康样本计算召回、误报和阈值分离度。
+4. Electron/Chromium 升级、探针变更、设备档变更后重新校准。
+5. 达到验证门槛后再按业务线灰度开启 `enforce`。
 
-- 收集审核员输入的 `appUrl`、`appId`、`versionId`。
-- 管理 Electron 窗口、preload 和 IPC。
-- 存储运行事件、截图和导出记录。
+## 10. 原型验收门槛
 
-SDK 负责：
+- DevTools 关闭后 CDP attach 成功率 100%，采集完成或异常后 debugger 无残留。
+- 连续切换 20 个包，session、Storage、Cookie、Cache、Service Worker 和报告不串包。
+- 同一正常包固定流程重复 5 次，retained heap 和 working set 的变异可解释并低于约定门槛。
+- 已知泄漏包在连续轮次出现稳定单调增长，正常状态缓存包不会被误判为泄漏。
+- OOM/crash fixture 能产生结构化 `render-process-gone` 事故并上报 APM。
+- 未真实完成核心操作、锚点不足或进程归属不可靠时只能得到 `unscorable`，不能出看似精确的分数。
+- APM 能按 app/version/业务线/Electron 版本/策略版本查询样本、事故和结果，measurement 不含 boolean。
 
-- 创建 `webview` 容器。
-- 加载小应用 URL。
-- 派发 `load`、`error`、`navigation`、`console`、`capture` 事件。
+## 11. 官方参考
 
-最终审核结论不在 SDK 内完成，应由审核规则和审核服务承接。
+- [Electron Debugger：DevTools 与 debugger 的互斥行为](https://www.electronjs.org/docs/latest/api/debugger)
+- [Electron webContents：getOSProcessId 与 renderer 生命周期](https://www.electronjs.org/docs/latest/api/web-contents)
+- [Electron app.getAppMetrics](https://www.electronjs.org/docs/latest/api/app#appgetappmetrics)
+- [Electron ProcessMetric](https://www.electronjs.org/docs/latest/api/structures/process-metric)
+- [Electron MemoryInfo](https://www.electronjs.org/docs/latest/api/structures/memory-info/)
+- [Electron webview tag 与 render-process-gone](https://www.electronjs.org/docs/latest/api/webview-tag)
+- [CDP Runtime.getHeapUsage](https://chromedevtools.github.io/devtools-protocol/tot/Runtime/#method-getHeapUsage)
+- [CDP HeapProfiler.collectGarbage](https://chromedevtools.github.io/devtools-protocol/tot/HeapProfiler/#method-collectGarbage)
+- [CDP Memory.forciblyPurgeJavaScriptMemory](https://chromedevtools.github.io/devtools-protocol/tot/Memory/#method-forciblyPurgeJavaScriptMemory)

package/docs/quality-evaluation-redoc.xml

@@ -0,0 +1,163 @@
+<h2>1. 背景与产品目标</h2>
+<p>小工具的质量不仅取决于能否打开，还取决于用户要等多久才能看到内容、主要功能能否顺利完成，以及连续使用时是否出现卡顿或中断。审核需要一套可解释的体验评价，帮助审核员定位问题，也帮助开发者知道优先优化什么。</p>
+<p><b>一期定位：在 Mars 审核队列中试跑，收集真实使用过程中的体验数据，验证采集质量、指标解释力和评分合理性。</b>评测分数、风险提示和报告状态用于观察分析与策略校准，不作为审核强卡口，不自动驳回、不强制转审，也不阻止审核员提交当前项或进入下一项。审核按现有业务规则执行。</p>
+<p>质量评测在审核员真实使用小工具的过程中同步采集证据。评价顺序为：<b>首屏加载体验（LCP、FCP）→ 资源体积 → 操作流畅度 → 稳定性 → 内存与持续运行风险</b>。总分用于观察分布和分析样本，分项用于解释原因，风险提示用于记录异常线索，帮助后续抽样复测和指标校准。</p>
+<table header-row="true"><colgroup><col width="150"/><col width="310"/><col width="310"/></colgroup><tbody>
+<tr><td><p>使用者</p></td><td><p>需要回答的问题</p></td><td><p>产品提供的结果</p></td></tr>
+<tr><td><p>审核员</p></td><td><p>实际操作中有哪些体验问题？本轮采集覆盖了哪些场景？</p></td><td><p>优先展示加载、资源和风险，记录实际体验反馈；评测结果不增加强制审核条件。</p></td></tr>
+<tr><td><p>开发者</p></td><td><p>问题出在首屏、资源、交互还是运行稳定性？</p></td><td><p>可追溯的分项证据和优化方向，避免只反馈一个分数。</p></td></tr>
+<tr><td><p>产品与质量运营</p></td><td><p>哪些问题最普遍？评分是否符合真实体验？阈值如何调整？</p></td><td><p>按形态、包版本和评测策略分析指标分布，并结合人工复核反馈校准。</p></td></tr>
+</tbody></table>
+<h3>1.1 业界参考与设计依据</h3>
+<p>本方案借鉴微信开发者工具 Audits 的分类评价、规则加权和提示项设计，结合 Google 的页面加载指标与 Lighthouse 评分方法，形成面向小工具审核的评价体系。小工具的核心问题是：主要内容出现得是否及时、资源负担是否合理、真实操作能否顺利完成，以及游戏和复杂交互能否持续运行。</p>
+<table header-row="true"><colgroup><col width="165"/><col width="300"/><col width="330"/></colgroup><tbody>
+<tr><td><p>参考来源</p></td><td><p>业界做法</p></td><td><p>本方案的产品决策</p></td></tr>
+<tr><td><p><a href="https://developers.weixin.qq.com/miniprogram/dev/framework/audits/audits.html">微信：体验评分</a></p></td><td><p>按性能、体验、最佳实践组织规则，单项按满足条件与否计 100 或 0 分，再依据权重和公式汇总；权重 0 的规则只作提示。</p></td><td><p>提供总分、分类明细和优化建议；对证据有限或依赖操作路径的指标保留观察状态。审核员据实际功能表现完成判断。</p></td></tr>
+<tr><td><p><a href="https://web.dev/articles/lcp">Google：LCP</a>、<a href="https://web.dev/articles/fcp">FCP</a> 与 <a href="https://developer.chrome.com/docs/lighthouse/performance/performance-scoring">Lighthouse 评分</a></p></td><td><p>用用户可感知的绘制时间衡量加载体验，并通过连续曲线区分性能表现。</p></td><td><p>将 LCP、FCP 放在报告首位，分别解释主要内容等待和首次白屏等待；以连续分数呈现优化收益。</p></td></tr>
+<tr><td><p><a href="https://web.dev/articles/performance-budgets-101">Performance budgets</a> 与微信的图片、缓存、资源冗余检查</p></td><td><p>围绕资源成本与使用场景设置预算，关注资源是否必要、尺寸是否适配以及能否复用。</p></td><td><p>资源评价以 ZIP 压缩体积为首，其次是解压后体积，再定位单图和 JS 文件。ZIP 上限为 10MB；结合真实包分布、使用场景和人工反馈校准评分预算。</p></td></tr>
+</tbody></table>
+<p>业界经验提供评价框架与优化方向，小工具的资源形态和审核方式决定具体策略：一次队列审核围绕真实使用采集；游戏重点观察主循环和场景变化；短时采集未覆盖的持续运行问题记录为后续专项复测线索。</p>
+<h2>2. 首要指标：加载体验与资源体积</h2>
+<h3>2.1 LCP、FCP 分别衡量什么</h3>
+<table header-row="true"><colgroup><col width="135"/><col width="220"/><col width="245"/><col width="230"/></colgroup><tbody>
+<tr><td><p>指标</p></td><td><p>用户感知与采集口径</p></td><td><p>业界参考分档</p></td><td><p>本方案的解读与优化方向</p></td></tr>
+<tr><td><p><b>LCP</b><br/>最大内容绘制</p></td><td><p>主要内容何时出现。记录小工具页面导航开始后，首屏最大有效内容元素的绘制时间。</p></td><td><p>良好：≤ 2.5 秒<br/>需要改善：&gt; 2.5 且 ≤ 4 秒<br/>较差：&gt; 4 秒</p></td><td><p>加载体验的重点指标。优先排查主图、字体、关键资源及渲染阻塞；低值不代表核心功能已经可用。</p></td></tr>
+<tr><td><p><b>FCP</b><br/>首次内容绘制</p></td><td><p>何时摆脱白屏。记录小工具页面首次绘制文字、图片等有效内容的时间。</p></td><td><p>良好：≤ 1.8 秒<br/>需要改善：&gt; 1.8 且 ≤ 3 秒<br/>较差：&gt; 3 秒</p></td><td><p>反映初始响应。优先排查阻塞脚本、样式和初始化；加载提示很早出现，也可能伴随主要内容迟迟未到。</p></td></tr>
+</tbody></table>
+<p>分档依据：<a href="https://web.dev/articles/lcp">Google web.dev：LCP</a>、<a href="https://web.dev/articles/fcp">Google web.dev：FCP</a>。业界评价站点体验时通常按移动端、桌面端分别观察页面加载的第 75 百分位（P75）；单次模拟器结果用于定位问题，不能替代真实用户的分布结论。</p>
+<p>LCP 是 Core Web Vitals 指标，FCP 是补充的加载体验指标。本方案采集小工具内部页面导航的绘制时间，不包含选择 ZIP、解压和模拟器准备的全部耗时。因此报告应称“页面绘制耗时”，不能称“从打开小工具到可用的总耗时”。</p>
+<p><b>微信参考：</b>微信将“打开小程序到看到第一屏主要内容”的首屏时间列为性能规则，得分条件为不超过 5 秒、规则权重为 6，体现了优先评价内容等待的思路。本方案用浏览器可观测的 LCP、FCP 细分加载问题，采用上述 Google 分档；微信首屏时间与浏览器绘制指标的起点、终点不同，5 秒不能直接作为 LCP 或 FCP 的得分线。</p>
+<h3>2.2 怎样的加载耗时可以得到好分数</h3>
+<p>单项采用 0–100 分的连续曲线，参考 Lighthouse 的对数正态评分方法：FCP 1.8 秒、LCP 2.5 秒对应约 90 分；FCP 3 秒、LCP 4 秒对应 50 分。耗时越短得分越高，超过边界逐步扣分，不在边界处突然从满分跳到零分。分数取整可能产生边界附近的细微差异。</p>
+<table header-row="true"><colgroup><col width="150"/><col width="190"/><col width="190"/><col width="240"/></colgroup><tbody>
+<tr><td><p>单项</p></td><td><p>良好控制点</p></td><td><p>50 分控制点</p></td><td><p>评分作用</p></td></tr>
+<tr><td><p>LCP</p></td><td><p>2,500ms → 约 90 分</p></td><td><p>4,000ms → 50 分</p></td><td><p>权重 10；优先分析主要内容出现过慢的问题。</p></td></tr>
+<tr><td><p>FCP</p></td><td><p>1,800ms → 约 90 分</p></td><td><p>3,000ms → 50 分</p></td><td><p>权重 4；辅助识别白屏等待。</p></td></tr>
+</tbody></table>
+<p>方法参考：<a href="https://developer.chrome.com/docs/lighthouse/performance/performance-scoring">Lighthouse 性能评分说明</a>。本方案只借鉴单项曲线，不是完整 Lighthouse 跑分；模拟器的设备、网络与 CPU 环境也不同于 Lighthouse 移动端模拟条件。</p>
+<h3>2.3 资源体积</h3>
+<p>资源评价顺序为：<b>ZIP 压缩体积 → 解压后总体积 → 最大单图与大 JS 文件</b>。ZIP 体积是包体评分的首要指标、资源维度中的最高权重项，解压后体积作为次要评分项，两项分别展示、分别上报。小工具 ZIP 包上限为 10MB，该上限约束压缩包，不是解压后体积或运行内存。</p>
+<table header-row="true"><colgroup><col width="155"/><col width="240"/><col width="230"/><col width="230"/></colgroup><tbody>
+<tr><td><p>指标</p></td><td><p>统计口径</p></td><td><p>评分定位与依据</p></td><td><p>产品解释与建议</p></td></tr>
+<tr><td><p><b>ZIP 压缩体积</b></p></td><td><p>实际 ZIP 文件的字节数；所有业务形态统一遵守 10MB 包上限。</p></td><td><p>包体评分第一位，权重 5。初始评分线为 ≤2MiB 得 100 分，5MiB 得 60 分，≥10MiB 得 0 分，区间内线性评分；由 Apollo 的 size.zip 配置并通过试跑校准。</p></td><td><p>优先评价交付包负担，检查素材压缩、重复依赖与无用文件。包小不代表展开后的资源也小，需结合解压体积判断。</p></td></tr>
+<tr><td><p>解压后总体积</p></td><td><p>解压后包内文件字节数求和，与 ZIP 字节数独立记录。</p></td><td><p>包体评分第二位，权重 3。工具类 2/4/9MiB、2D 游戏 6/12/24MiB、3D 游戏 12/20/32MiB 分别对应 100/60/0 分，区间线性评分；由 Apollo 各形态的 size 配置。</p></td><td><p>用于识别压缩后较小、展开后仍较重的资源包；排查冗余素材与重复依赖。它不是运行期内存占用。</p></td></tr>
+<tr><td><p>最大单图</p></td><td><p>包内最大图片文件大小，不是解码后的像素内存。</p></td><td><p>≤ 300KiB 为 100 分；300–1,200KiB 线性扣分；≥ 1,200KiB 为 0 分。权重 1。</p></td><td><p>检查尺寸、格式与压缩；结合首屏用途判断是否需要优化，不能只看文件大就判功能失败。</p></td></tr>
+<tr><td><p>大 JS 文件</p></td><td><p>统计单文件超过 1MiB 的 JS 体积之和。面板“未压缩 JS”字段实际采用此启发式口径，并未检查源码是否压缩。</p></td><td><p>没有超线文件为 100 分；超线文件总量按 0–4MiB 线性计分，达到 4MiB 为 0 分。权重 1。</p></td><td><p>引导拆包与依赖治理；不能据此认定开发者没有压缩代码。</p></td></tr>
+</tbody></table>
+<p>资源预算方法参考 <a href="https://web.dev/articles/performance-budgets-101">web.dev：Performance budgets</a>。10MB ZIP 上限和 2MB 优化建议来自小工具交付规范；具体评分分档由本产品试跑数据校准，不作为行业统一阈值。APM 保留两种体积的原始字节数，展示时明确标注 ZIP 或解压后体积；MiB、KiB 按 1024 进制计算。资源用途用于解释负担，不能仅凭 WebGL 特征认定内容是 3D 游戏并放宽包上限。</p>
+<p><b>微信参考：</b>微信的图片大小规则关注原图像素面积是否超过显示面积 × 设备像素比²，图片缓存规则关注 HTTP 缓存，资源冗余规则关注不可访问页面和未使用样式。这些做法支持从“资源是否有效使用”解释成本。本方案依次评价 ZIP 体积、解压体积和单项资源；图片尺寸利用率、缓存和资源使用率可作为后续诊断方向。微信的像素面积规则与本方案的文件字节阈值分别衡量不同成本。</p>
+<h2>3. 运行过程：流畅度、稳定性与内存</h2>
+<h3>3.1 流畅度与稳定性分开评价</h3>
+<p><b>运行过程的相对权重：FPS 5 &gt; 长任务 1 &gt; JS 异常 0.5。</b>FPS 是流畅度的主要评分项；长任务低权重反映阻塞，普通 JS 异常以更低权重反映稳定性。各项按有效指标权重归一化汇总，这些数值是本方案的试跑配置，不是固定扣分值或业界统一权重。</p>
+<table header-row="true"><colgroup><col width="140"/><col width="250"/><col width="230"/><col width="250"/></colgroup><tbody>
+<tr><td><p>指标</p></td><td><p>观察内容</p></td><td><p>本方案初始规则</p></td><td><p>审核解释</p></td></tr>
+<tr><td><p><b>FPS／帧率</b></p></td><td><p>实际交互、滚动、动画或游戏主循环中的页面动画回调帧率；中位数用于评分，P5 低分位及连续低帧区间用于解释卡顿。</p></td><td><p><b>权重 5。</b>初始参考：≥ 50fps 为 100 分，20–50fps 线性计分，≤ 20fps 为 0 分；通过真实操作反馈校准阈值。</p></td><td><p>优先观察画面连续性。仅使用前台可见、有效操作场景的样本；静态停留、暂停或无有效场景时标注不适用或证据不足，不按低帧率扣分。rAF 帧率不等于引擎实际渲染帧率，需同时保留体感反馈。</p></td></tr>
+<tr><td><p>最长任务</p></td><td><p>采集窗口内最长的一次主线程长任务，同时保留长任务次数。</p></td><td><p>≤ 500ms 为 100 分；500–3,000ms 线性扣分；≥ 3,000ms 为 0 分。权重 1。</p></td><td><p>用于发现明显阻塞，保持低扣分影响。一次短暂初始化不应掩盖整体可用性；频繁短卡顿需要结合操作反馈。</p></td></tr>
+<tr><td><p>JS 异常</p></td><td><p>运行期未捕获异常与未处理的 Promise 拒绝；稳定性单独展示。</p></td><td><p>0 次为 100 分；1–4 次逐级扣分；≥ 5 次为 0 分。<b>权重 0.5。</b>不因普通 JS 异常单独判定不可用。</p></td><td><p>异常可能来自非关键功能，保持三项中最低扣分影响。需结合触发动作和功能结果判断；计数低不能证明所有功能都正确。</p></td></tr>
+</tbody></table>
+<p>帧率采集参考 <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame">MDN：requestAnimationFrame</a>：回调通常随屏幕刷新率运行，后台页面可能暂停。报告需记录采样场景和可见性，在相近环境下比较；高刷新率不额外加分，低分位和卡顿区间与中位数并列分析。</p>
+<p><a href="https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming">Long Tasks API</a> 将持续 50ms 及以上的主线程任务记录为长任务，这是<b>采集定义</b>，不是本方案的扣分起点。本方案的 500ms 是低权重评分预算，不是业界“流畅”的通用判定线；最长任务也不等于 Lighthouse 的总阻塞时间（TBT）。</p>
+<p><b>微信参考：</b>微信分别检查单次同步脚本执行不超过 1 秒、页面渲染不超过 500ms，对应规则权重为 7 和 6。它关注的是造成交互等待的具体环节。本方案围绕小工具的真实操作，以 FPS 作为主要流畅度评分，长任务和次数辅助解释阻塞，普通 JS 异常保持更低权重；这些测量口径与微信不同，具体阈值和权重按试跑数据校准。</p>
+<h3>3.2 内存用于发现持续风险</h3>
+<table header-row="true"><colgroup><col width="155"/><col width="290"/><col width="320"/></colgroup><tbody>
+<tr><td><p>指标</p></td><td><p>口径与用途</p></td><td><p>阅读边界</p></td></tr>
+<tr><td><p>JS 堆水位与增长</p></td><td><p>观察堆高水位和稳定阶段的增长趋势。高水位按 P95 并结合基线处理；增长率由连续样本估算。</p></td><td><p>不是进程总内存。基线、垃圾回收和采样阶段影响读数；显示 0 不代表零内存占用，短时间上升也不能证明必然泄漏。</p></td></tr>
+<tr><td><p>图形与图片资源</p></td><td><p>估算 WebGL 纹理、缓冲资源、Canvas 后备缓冲和图片解码内存，发现超预算积累。</p></td><td><p>不是 GPU 驱动或系统实测内存。探针记账达到上限时应显示不可用，不能把截断读数当安全值。</p></td></tr>
+<tr><td><p>WASM、Worker</p></td><td><p>记录适用能力的内存或存活数量，辅助定位后台资源负担。</p></td><td><p>能力未使用时标注不适用，不因为没有该能力扣分。</p></td></tr>
+<tr><td><p>中断与图形丢失</p></td><td><p>记录画面上下文丢失、运行失联、保护中断等风险，并保留已采集证据。</p></td><td><p>说明本轮出现了异常信号，需结合画面和操作复核原因；不能直接把所有 context lost 都归因为 OOM。</p></td></tr>
+</tbody></table>
+<p>内存评分用于风险排序和排查，桌面浏览器没有发生 OOM 不能证明移动端安全。场景切换、资源反复创建、长时间游戏或重复播放产生的疑点，由质量分析阶段选择样本进行更长的专项观察和代表性真机复测。</p>
+<h2>4. 审核队列中的使用流程</h2>
+<p>审核员按现有流程逐项处理小工具，评测在队列中伴随试跑。每进入下一项，<b>完整刷新模拟器</b>并开始独立采集；报告只对应当前包和当前操作过程。评测证据不足、低分或出现风险提示均不阻断审核提交与队列流转。</p>
+<table header-row="true"><colgroup><col width="120"/><col width="280"/><col width="350"/></colgroup><tbody>
+<tr><td><p>阶段</p></td><td><p>审核员操作</p></td><td><p>界面与系统反馈</p></td></tr>
+<tr><td><p>进入队列项</p></td><td><p>确认当前小工具和包版本，开始审核。</p></td><td><p>刷新模拟器、初始化本轮采集；加载指标从页面启动阶段开始记录。</p></td></tr>
+<tr><td><p>实际使用</p></td><td><p>按业务类型执行主要操作，检查预期结果；游戏需进入关卡并实际操作。</p></td><td><p>自动记录采集时长、样本数和操作次数。操作次数只说明输入发生，不替代业务正确性判断。</p></td></tr>
+<tr><td><p>结束与记录</p></td><td><p>点击“停止评测”结束本轮，记录已观察到的体验问题。面板只提供这一个评测操作按钮。</p></td><td><p>结束采集、生成报告并通过 APM 上报。证据满足时出分；不足时保留原因和已有数据。停止仅表示采集结束，不代表功能或审核通过。</p></td></tr>
+<tr><td><p>下一项</p></td><td><p>按现有业务规则提交审核并进入下一包，无需等待评测达标。</p></td><td><p>报告关联当前队列项；整页刷新隔离采集会话，评测状态不限制下一项。</p></td></tr>
+</tbody></table>
+<h3>4.1 各类小工具的最低操作路径</h3>
+<table header-row="true"><colgroup><col width="160"/><col width="360"/><col width="250"/></colgroup><tbody>
+<tr><td><p>类型</p></td><td><p>有效操作路径</p></td><td><p>重点观察</p></td></tr>
+<tr><td><p>表单、计算、问卷</p></td><td><p>输入或选择 → 提交主要操作 → 检查结果；存在结果页、错题页时继续浏览。</p></td><td><p>按钮是否生效、结果是否更新、长列表能否滚动。</p></td></tr>
+<tr><td><p>内容、搜索、图片</p></td><td><p>打开内容 → 搜索或切换分类 → 翻页、展开或继续阅读。</p></td><td><p>主内容呈现、图片加载、连续浏览与返回。</p></td></tr>
+<tr><td><p>创作、生成</p></td><td><p>创建测试内容 → 编辑 → 预览结果 → 保存本地草稿。</p></td><td><p>主要产物是否生成，预览是否完整；无需真实发布或付费。</p></td></tr>
+<tr><td><p>游戏、交互图形</p></td><td><p>进入实际关卡 → 移动、射击或核心交互 → 触发状态变化；按需暂停、重开或切场景。</p></td><td><p>输入响应、画面连续性、资源积累；不能停留在菜单等待出分。</p></td></tr>
+</tbody></table>
+<h3>4.2 时长与效率</h3>
+<p>平均每项约一分钟是工作节奏。报告出分的初始证据要求为：采集完整、至少 30 秒有效采集、30 个样本、至少 1 次到达小工具的真实输入、适用指标覆盖度不低于 60%，且没有评测基础设施异常。这些条件只决定本轮是否具备出分证据，不决定能否提交审核；未达到时记录“证据不足”并保留数据，审核员可继续下一项。</p>
+<p>常规评测默认最长采集 2 分钟，审核员无需为等待出分额外停留。复杂流程未走完、持续增长或晚发异常等情况保留场景信息，供后续抽样复测。看不到数据或采集中断时记录原因，不能填零，也不能把达到采集时限视为业务流程完成。</p>
+<p>Mars 接入时可将结束评测绑定到现有“提交审核／下一条”动作，由系统收集当前报告、触发上报后刷新模拟器。审核员按原有流程提交即可；报告缺失或上报失败只记录原因，不阻塞业务审核和队列流转。</p>
+<h2>5. 评分与报告设计</h2>
+<h3>5.1 总分、分项和风险各司其职</h3>
+<p>每个可评价指标先得到 0–100 分，再按权重计算加权平均。只对本轮适用且采到数据的指标计入分数；同时展示覆盖度，防止缺少关键证据时产生“高分即优质”的误解。权重是相对系数，不是固定总分百分比；业务能力与数据缺失会改变本轮分母。</p>
+<table header-row="true"><colgroup><col width="145"/><col width="290"/><col width="335"/></colgroup><tbody>
+<tr><td><p>结果层</p></td><td><p>展示内容</p></td><td><p>审核员怎样使用</p></td></tr>
+<tr><td><p>总分</p></td><td><p>本轮采集指标的综合表现，并展示业务形态、覆盖度。</p></td><td><p>观察相同形态、策略和相近环境下的分数分布，筛选分析样本；一期不设置审核通过分数线。</p></td></tr>
+<tr><td><p>分项</p></td><td><p>先展示加载性能与资源，再展示稳定性和内存；逐项提供值、单位、参考线与得分。</p></td><td><p>找出最值得处理的问题，避免内存明细淹没首屏与资源问题。</p></td></tr>
+<tr><td><p>风险提示</p></td><td><p>画面上下文丢失、失联、资源超预算、持续增长或保护中断等。</p></td><td><p>保留异常现象和操作证据，供后续分析；风险提示本身不触发驳回、强制转审或队列阻断。</p></td></tr>
+<tr><td><p>证据质量</p></td><td><p>时长、样本、真实操作次数、首次操作时间、缺失项和中断原因。</p></td><td><p>判断采集覆盖了哪些证据；主要功能是否完成和结果是否正确由审核员按 SOP 检查，系统不凭点击次数推断业务完成。</p></td></tr>
+</tbody></table>
+<h3>5.2 三种结果状态</h3>
+<table header-row="true"><colgroup><col width="150"/><col width="300"/><col width="330"/></colgroup><tbody>
+<tr><td><p>状态</p></td><td><p>产品含义</p></td><td><p>处理方式</p></td></tr>
+<tr><td><p>已出分</p></td><td><p>本轮满足出分证据要求，可以展示综合分与分项。风险提示独立保留。</p></td><td><p>保存分数、原始指标和体验反馈，用于观察评分有效性；分数不决定审核通过与否。</p></td></tr>
+<tr><td><p>证据不足</p></td><td><p>未采到真实输入、采集时长或样本不足、关键数据缺失、评测基础设施异常，或采集被中断。</p></td><td><p>记录缺失原因和已有数据，不强制等待或补测；审核员可按现有流程提交并继续下一项。</p></td></tr>
+<tr><td><p>加载或运行失败</p></td><td><p>小工具无法正常启动，或运行失去响应，不能完成本轮评价。</p></td><td><p>保留失败阶段与原因供分析；是否影响业务审核按现有规则判断，评测状态不自动触发驳回或转审。</p></td></tr>
+</tbody></table>
+<p>JS 异常只在稳定性分项低权重计分。按钮点了是否生效、结果是否正确、核心玩法能否进行，仍由真实操作确认；异常次数不能替代功能判断，少量异常也不应造成过度扣分。</p>
+<h3>5.3 微信经验在小工具场景中的采用方式</h3>
+<table header-row="true"><colgroup><col width="145"/><col width="315"/><col width="350"/></colgroup><tbody>
+<tr><td><p>设计问题</p></td><td><p>微信体验评分的参考做法</p></td><td><p>本方案的取舍与理由</p></td></tr>
+<tr><td><p>如何解释分数</p></td><td><p>同时呈现总分、性能、体验和最佳实践分类分，分类下展开检查项；每条规则给出得分条件及优化方向。</p></td><td><p>按小工具问题组织为运行性能、包体积、稳定性、内存；LCP/FCP 和资源优先展示。每项同时说明实测值、参考线、得分与优化方向，便于审核员定位问题。</p></td></tr>
+<tr><td><p>如何控制异常扣分</p></td><td><p>“避免 JS 异常”属于最佳实践，零异常得分，规则权重为 3；首屏时间和脚本执行时间的规则权重分别为 6、7。</p></td><td><p>借鉴分类加权的思路。运行过程按 FPS 5、长任务 1、JS 异常 0.5 设置相对权重；普通异常按数量渐进扣分，并结合触发动作判断功能影响。微信权重的实际总分影响取决于其汇总公式，本方案按小工具体验确定权重。</p></td></tr>
+<tr><td><p>哪些信息只作提示</p></td><td><p>合理颜色搭配、最低基础库版本、不可访问页面、WXSS 使用率和定时器回收等规则权重为 0。部分规则因依赖开发者操作路径而只提示。</p></td><td><p>资源使用率、缓存和定时器回收等诊断候选用于补充线索；FPS 在有效动态场景中参与流畅度评分。报告保留操作路径与适用性，未进入的场景不据此判断为通过。</p></td></tr>
+<tr><td><p>怎样评价视觉与交互</p></td><td><p>检查惯性滚动、点击态、图片比例、点击区域、安全区与窗口适配。示例规则包括点击区域宽高均不小于 20px、图片显示比例偏差不超过 15%。</p></td><td><p>审核操作同时关注点击是否容易命中、图片是否变形、长内容能否滚动、底部操作是否被遮挡。作为人工体验检查点和自动化扩展候选，当前技术分不代表这些检查均已通过。</p></td></tr>
+<tr><td><p>怎样定位网络等待</p></td><td><p>检查请求耗时、并发、缓存与失败，例如请求在 1 秒内返回；网络请求异常单独列为最佳实践规则。</p></td><td><p>LCP/FCP 反映加载结果；对于依赖远程接口或图片的小工具，网络耗时、缓存与失败信息是补充归因方向。网络专项采集与覆盖充分后再评估是否进入总分。</p></td></tr>
+<tr><td><p>怎样处理资源积累</p></td><td><p>定时器回收规则关注跨页面运行的回调；资源冗余规则提示无效包内容，相关判断依赖访问路径。</p></td><td><p>游戏与复杂工具增加重复操作、场景切换和长会话观察，关注 JS 堆与图形资源是否持续积累。定时器回收检查、资源使用率与内存趋势分别提供证据，不能互相替代。</p></td></tr>
+<tr><td><p>怎样保证结果可解释</p></td><td><p>示例报告展示设备类型、网络类型和基础库版本；官方说明规则得分条件可能随版本调整。</p></td><td><p>报告与分析保留运行环境、包版本及策略版本，在相近条件下比较；通过 APM 的原始指标和人工反馈评估调参效果。</p></td></tr>
+</tbody></table>
+<p>参考：<a href="https://developers.weixin.qq.com/miniprogram/dev/framework/audits/audits.html">微信开放文档：体验评分——评分方法、性能、体验与最佳实践</a>。微信的 setData、WXML、WXSS 与基础库兼容规则针对其运行框架；Web 小工具按浏览器加载、资源和运行行为选择对应的评价证据。</p>
+<image url="https://xhs-doc-i1.xhscdn.com/1040g4dg326gmabcjka000000004l0s96i667a38?sign=1793102013-ZjU5NWRhNTYtMmJmZS00NTJkLTg2MTItYjg1M2E3ZDg1MjI4-7e14f80bbd26343fa06ae5e51856bb2c-c5382524de43b57f58759a4ca9068914" width="840" height="535" align="center"/>
+<note>微信 Audits 体验评分示例：总分与分类分并列，报告显示设备和网络环境，分类下可展开检查项；示例以红、黄、绿区分 0–59、60–89、90–100 分。本方案借鉴这种可解释的报告结构，具体指标与评分策略围绕小工具体验制定。</note>
+<h2>6. 游戏评测的适用边界</h2>
+<p>游戏应同时看“加载进来”和“玩起来”。Canvas、WebGL 画面未必成为浏览器 LCP 候选，标题或启动菜单可能很早就完成绘制。因此游戏的 LCP/FCP 主要说明加载阶段，必须结合进入关卡、持续控制、画面反馈与场景切换评价。</p>
+<table header-row="true"><colgroup><col width="190"/><col width="300"/><col width="300"/></colgroup><tbody>
+<tr><td><p>容易误读的现象</p></td><td><p>正确解释</p></td><td><p>审核动作</p></td></tr>
+<tr><td><p>首屏很快、总分很高</p></td><td><p>只说明已覆盖指标表现较好，可能尚未覆盖重场景。</p></td><td><p>进入实际玩法，触发主要操作，观察一段连续运行。</p></td></tr>
+<tr><td><p>帧率高但体感卡顿</p></td><td><p>动画回调频率不能完全反映引擎渲染、输入延迟和帧时间波动。</p></td><td><p>保留具体卡顿步骤、场景和画面，不用帧率数值否定人工反馈。</p></td></tr>
+<tr><td><p>桌面正常，低端机异常</p></td><td><p>设备性能、系统和 WebView 的差异不由桌面采集覆盖。</p></td><td><p>将对应包与操作路径纳入真机复核，不合并不同环境分数。</p></td></tr>
+<tr><td><p>短时无异常</p></td><td><p>不能排除重复切换或长会话才出现的内存积累、晚发错误。</p></td><td><p>对重图形、反复加载和用户反馈问题包增加专项时长与循环路径。</p></td></tr>
+</tbody></table>
+<p>游戏专项增强应围绕核心场景到达、帧时间波动、操作响应、重复场景切换和长会话积累扩展证据。此类专项结果应单独说明场景和观察时长，不能把未覆盖的内容并入常规审核总分。</p>
+<h2>7. 数据观察与指标校准</h2>
+<p>一期试跑重点验证采集数据是否可靠、指标能否解释实际体验、评分是否存在明显偏差，以及采集对审核效率的影响。分析低分但功能正常、高分但体感较差、风险提示与实际现象不一致等样本，据此调整阈值、权重、形态识别和采集策略。</p>
+<p>所有评测数据通过 APM 收集。重点观察 LCP、FCP 的原始耗时、采集状态、分项得分与覆盖率，同时关联包版本、业务形态、策略版本、操作过程与报告状态。缺失值保留原因，不作为 0ms 进入统计。</p>
+<table header-row="true"><colgroup><col width="185"/><col width="300"/><col width="310"/></colgroup><tbody>
+<tr><td><p>分析视角</p></td><td><p>需要观察的数据</p></td><td><p>用于什么产品决策</p></td></tr>
+<tr><td><p>首屏体验</p></td><td><p>LCP/FCP 分布、良好占比、缺失率；按环境与形态分组。</p></td><td><p>判断首屏问题是否普遍，检查阈值是否能识别明显等待。</p></td></tr>
+<tr><td><p>资源预算</p></td><td><p>优先观察 ZIP 体积分布，其次是解压后体积、单图和大 JS 文件；关联包版本、资源用途与人工反馈。</p></td><td><p>校准 ZIP 与解压后体积各自的评分曲线，保持 ZIP 评分优先，并区分必要资源与冗余资源。</p></td></tr>
+<tr><td><p>运行流畅度</p></td><td><p>有效交互场景的 FPS 中位数、P5、低帧区间，长任务及 JS 异常；关联可见性、操作路径和体感卡顿反馈。</p></td><td><p>验证 FPS 对真实卡顿的解释力，保持 FPS &gt; 长任务 &gt; JS 异常的权重顺序，避免静态或后台样本误扣分。</p></td></tr>
+<tr><td><p>评分有效性</p></td><td><p>高分但体验差、低分但功能正常、风险误报和证据不足原因。</p></td><td><p>优先补齐遗漏的体验维度，再评估权重，避免只为了分数好看而放宽阈值。</p></td></tr>
+<tr><td><p>审核效率</p></td><td><p>有效评测占比、证据不足原因、审核耗时分布、核心操作覆盖、风险提示占比。</p></td><td><p>衡量数据收集价值及额外操作成本，优化采集与提示，保证试跑不形成审核等待。</p></td></tr>
+</tbody></table>
+<p>采用“收集真实操作证据 → 分组观察 → 对照人工反馈 → 回放候选规则 → 小范围观察”的校准闭环。Apollo 配置用于调整评分曲线、预算、权重及证据门槛；远端配置命中后整体覆盖本地默认配置。每轮结果关联所用策略版本，保证调参前后的数据可解释。</p>
+<p>需要持续保留的体验反馈包括：中秋赏月“实际卡顿但分数高”、深夜读信人“低端机卡顿，PC 采集不准确”、编钟“实际体验并无太多异常”。这些是人工校准线索，应结合复现环境和操作路径分析，不能用一次桌面高分覆盖。</p>
+<h2>8. 体验案例与实际界面</h2>
+<p>以下案例用于说明如何阅读报告。数据采集于 2026-10-19，使用本地真实 ZIP，在 Mars 模式模拟器中实际操作；每个包之间完整刷新模拟器。环境为 macOS 桌面浏览器、iPhone 15 Pro 模拟视口，并非真实 iPhone 或移动网络测试。</p>
+<table header-row="true"><colgroup><col width="150"/><col width="260"/><col width="290"/><col width="255"/></colgroup><tbody>
+<tr><td><p>体验案例</p></td><td><p>真实操作</p></td><td><p>本轮证据</p></td><td><p>产品上怎样解读</p></td></tr>
+<tr><td><p>MBTI 问卷</p></td><td><p>完成 28 题并查看 ESTJ 结果页；有效采集 55 秒。</p></td><td><p>LCP 80ms、FCP 72ms；解压体积 5.7MiB，最大单图 1,513KiB；综合 88 分。</p></td><td><p>加载快、流程可完成；主要优化机会是资源体积，而非 JS 稳定性。</p></td></tr>
+<tr><td><p>瀑布流页面</p></td><td><p>搜索、切换古风分类、连续翻页；有效采集 49 秒。</p></td><td><p>FCP 72ms、LCP 13,040ms；综合 77 分。</p></td><td><p>首次有内容不代表主内容已到。较慢 LCP 应进一步复测并定位候选内容，不能仅凭单次耗时认定所有用户都会慢。</p></td></tr>
+<tr><td><p>生化危机</p></td><td><p>进入餐厅场景，执行移动、转向、举枪与攻击；有效采集 46 秒。</p></td><td><p>LCP/FCP 均为 104ms；最长任务 604ms；综合 99 分，同时记录 context lost。</p></td><td><p>分数用于解释已覆盖指标，风险提示独立存在；高分不能覆盖异常信号。</p></td></tr>
+<tr><td><p>魂斗罗·性能</p></td><td><p>进入游戏并尝试移动，后续操作因内存保护中断。</p></td><td><p>LCP/FCP 均为 92ms；约 25 秒有效采集，JS 堆触发 3GiB 保护；不出总分。</p></td><td><p>保留运行中断证据，纳入后续问题分析与复测样本；本轮评测状态不自动触发审核驳回。</p></td></tr>
+</tbody></table>
+<h3>8.1 首屏快、资源有优化空间</h3>
+<image url="https://xhs-doc-i1.xhscdn.com/1040g4dg326glp9j446000000004l0s96m8quheg?sign=1793100895-NGI2ODQzODktNGZjMC00MmE4LTk2OTYtNmEyMzA2YmUwODA1-7e14f80bbd26343fa06ae5e51856bb2c-5a7c7e4c5191028ed9105011b88237c6" width="764" height="659" align="center"/>
+<note>问卷完成后的实际界面：运行性能、包体积、稳定性、内存分区展示；资源扣分可单独解释。</note>
+<h3>8.2 高分与风险并列</h3>
+<image url="https://xhs-doc-i1.xhscdn.com/1040g4dg326glp9j4ka000000004l0s9625urqbo?sign=1793100895-Mzk5ZjZlNWMtOTM3Ni00NDEyLWI2NWEtNjRjMzYxZTEzZTRk-7e14f80bbd26343fa06ae5e51856bb2c-aa4a0c252533ce0cd0908bb63331739d" width="764" height="659" align="center"/>
+<note>游戏完成移动、举枪与攻击后的报告局部。高分与风险信号同时记录，供后续分析；风险提示不构成一期审核强卡口。</note>
+<h3>8.3 运行中断也必须有明确结果</h3>
+<image url="https://xhs-doc-i1.xhscdn.com/1040g4dg326glp9jakc000000004l0s96cabc93g?sign=1793100895-YTNjOWJkY2YtMmE4ZC00MjgzLThmMWQtYmVhOGYyYzg2YjJj-7e14f80bbd26343fa06ae5e51856bb2c-f44b9c97254cac095f276101d4c33625" width="764" height="659" align="center"/>
+<note>魂斗罗包的内存保护提示：当前会话无法继续完整采集，产品应展示中断原因和已有风险，而不是给一个看似正常的总分。</note>

package/docs/tracker.md

@@ -53,8 +53,9 @@ createMiniAppSimulator({
   });
   ```
 
-- **批量上报**：打点先进缓冲，满 10 条或最多 10s 后合并成一次请求发送；页面隐藏（`visibilitychange`）
-  与 `destroy()` 时立即冲刷，避免关闭前丢数据。
+- **批量上报**：打点先进缓冲，满 10 条或最多 10s 后触发发送。每个请求最多 10 条，50 条分为
+  5 个请求，尾批按实际条数发送。同一 SDK 模块内的 tracker 共用有序队列；一批完成（含重试）后发送下一批。
+  每次尝试最多等待 5 秒；网络错误、超时及 5xx 最多尝试三次，4xx 结束该批。页面隐藏（`visibilitychange`）与 `destroy()` 时立即冲刷。
 - **本地开发**：`localhost` / `127.0.0.1` 默认上报到测试 APM；需要只看 console 时显式传 `debug: true`。
 
 ## 字段说明