69 lines
7.0 KiB
Markdown
69 lines
7.0 KiB
Markdown
# STEP-119 RCRR 多配置实机与验证矩阵 v1
|
||
|
||
日期：2026-10-11（JST）。执行入口：Mac.lan RDC，Particle `particle/main`。状态：**一组真机完成；三组新配置已实现、静态核对通过但未构建/上机**。非最终验收。
|
||
|
||
## 1. 场景与边界
|
||
|
||
本轮沿用 STEP-119 源码 APK（commit `3d989a00a822989339a6d7cb4d23acc04396670e`，SHA-256 `57d68800770d431a2ce9247406f636e7a01cc19fccaf4c59f5eb3a7c99128135`），不重复已通过的 Android 原生完整编译。设备 `192.168.200.139:5555`，x86_64。当前远端 HEAD 起点为 `46c88b0209474376225b54ae0ad701881673743d`，其与 APK commit 的后续差异为已有报告/Step 文档，而非新 Android 源码。
|
||
|
||
不改正式 PBF/Sprite/Glyph、Source 接口、Shared Core、24 Gate、发布版本，不清理 STEP-110/111 两份未跟踪任务书。保留原 `PARTIAL_RCRR`、原 `STATIC_RC` 与 `STATIC_RC_NO_TIDE`，后续新场景只在测试副本中排除唯一 `tide-spots→tide` 孤立 Symbol 层，并恢复空 Annotation 辅助层的正常生命周期。
|
||
|
||
## 2. 已执行：原 PARTIAL_RCRR
|
||
|
||
- 80.007 秒实机，PID `28169`，完整摘要 3 份，同源 APK/设备 SHA 一致。
|
||
- 原始 Native 图层 66，原 63 PBF + 2 天气 + 1 SDK Annotation；R[0,3)、C[3,39)、R[39,64)、R[64,66)。
|
||
- R0：Build 0、Reuse 0、Fallback 595、missingSourceIds=[tide]；R2：Build 1、Reuse 536；R3：Build 1、Reuse 536。
|
||
- 观测区间：FastDelta=0、FullDelta=596，最后 120 帧 Full=119、Fast=0，decisionMismatch=0。
|
||
- Native 24 Gate 累计 `unsupported-continuous-layer=599`、`unsupported-scene=599`、`cache-invalid=595`；这些是场景累计，**不是**对应原因的独立帧数。
|
||
- 结论：**全帧 Fast 安全拒绝通过；局部 R2/R3 的 Build/Reuse 已实际观察到**。这不构成 RCRR 加速性能通过。
|
||
|
||
原证据：
|
||
`artifacts/maplibre-particle/android-validation/step119-rcrr-observe-20261011_172720/partial_rcrr/result.json`，同目录有 `logcat.txt` 与 `screen.png`。
|
||
|
||
## 3. 基于真实设备 Style Manifest 校准分段
|
||
|
||
从设备 `run-as` 只读提取的 `step113-STATIC_RC-324220201.json`，包含当前实际 63 层 `baseLayerManifest`；其 PBF 指纹 `e0f9c2d1df38ae5d5953b561c52efe2f8590336de80b988e1d2935580d30b996` 与已通过 Fast 的场景一致。
|
||
|
||
原基础层：background=0、base-raster=1、tide-spots=2、sea-area-fill=3、clip-outline=31、special-pattern-line-754=37、最后的 place-labels-land-ja=62。天气插在 clip-outline **之后**。因此原 R0 是前三层（包括 tide），天气并未落入 R0；原 C1 是宽 C，包含天气与普通静态 PBF 层。禁止再用此前错误的“天气在 R0”解释原负例。
|
||
|
||
新增 Test App 变体（全部保留其余 62 原图层、天气数据与顺序；移除 SDK 空 Annotation 辅助层；Native 总层数预期 64）：
|
||
|
||
| 场景 | 期望 R/C 索引 | 主要目标 |
|
||
|---|---|---|
|
||
| `RCRR_C_NARROW_NO_TIDE` | R[0,31)、C[31,33)、R[33,63)、R[63,64) | C 仅含 WeatherColor/Particle；检验所有 R 缓存与整帧 Fast 能否真实通过 |
|
||
| `RCRR_C_WIDE_NO_TIDE` | R[0,2)、C[2,38)、R[38,63)、R[63,64) | C 混入普通 PBF；验证不支持的连续图层是否安全拒绝整帧 Fast |
|
||
| `RCRR_R_DYNAMIC_NO_TIDE` | R[0,33)、C[33,38)、R[38,63)、R[63,64) | 故意将动态天气放入 R；检验版本/连续输入不允许错误静态复用 |
|
||
|
||
源级校准证据：
|
||
`artifacts/maplibre-particle/android-validation/step119_rcrr_style_structure.json`。该结果是**实际设备导出数据上的静态切分核对，不是新 APK GPU 验证**。Mac 通过 Python 直接 GET 正式 Style 曾收到 HTTP 403，因此优先复用了相同 Style 指纹的设备导出 Manifest；没有修改服务器资源。
|
||
|
||
## 4. 静态测试与当前缺口
|
||
|
||
新增 `tools/particle_android_validation/test_step119_rcrr_scenarios.py`，四项 Python unittest 全部 PASS：三种索引互相排斥、缺 tide/缺 Annotation 清理不得通过、范围尾部和段数不对必须拒绝、原 STATIC_RC_NO_TIDE 不回退为错误结构。验证器 `scene_parity_valid` 对 64 层 RCRR 三 R 段改用精确区间校验；原 63 层判断、90 秒观察、24 Gate 和 Fast 判据不放宽。`git diff --check` PASS。
|
||
|
||
**没有对新 Kotlin 场景做 Android 编译/安装**（遵守用户手工 Android 编译及本轮不重复已有完整编译限制）。新增三场景的 Kotlin 可编译性与 Native 真机结果必须记 `NOT VERIFIED`。新增 13 项 STEP-119 GTest 仍未运行；Mac Metal CMake 被既有 libuv 缺失阻塞，本轮不安装或升级工具链；iOS Metal/实体机亦未验证。
|
||
|
||
## 5. 下次同一次人工 APK 构建后的串行设备验收
|
||
|
||
源码 scoped commit/push 完成后，由用户按已有标准在 Mac 手工构建**新 HEAD** 的 x86_64 Android OpenGL Test APK，不得使用旧 `3d989a` APK冒充新场景；验证 build-info commit、APK SHA、设备 base.apk SHA 一致后，逐一运行：
|
||
|
||
```bash
|
||
cd /Users/tei/dev/MapLibreParticleLab
|
||
./tools/particle_android_validation/build_validation_apk.sh
|
||
adb -s 192.168.200.139:5555 install -r artifacts/maplibre-particle/android-validation/MapLibreAndroidTestApp-validation-opengl-debug-x86_64.apk
|
||
python3 -B tools/particle_android_validation/verify_step113_fast_path.py --serial 192.168.200.139:5555 --preflight-only
|
||
python3 -B tools/particle_android_validation/verify_step113_fast_path.py --serial 192.168.200.139:5555 --scenario RCRR_C_NARROW_NO_TIDE --seconds 90
|
||
python3 -B tools/particle_android_validation/verify_step113_fast_path.py --serial 192.168.200.139:5555 --scenario RCRR_C_WIDE_NO_TIDE --seconds 90
|
||
python3 -B tools/particle_android_validation/verify_step113_fast_path.py --serial 192.168.200.139:5555 --scenario RCRR_R_DYNAMIC_NO_TIDE --seconds 90
|
||
```
|
||
|
||
每步独立读取退出码与 result.json：完整 R/C、Source/Tile、R0/R2/R3 Build/Reuse/Invalidate、Fast/Full 差分、24 Gate、120 帧、生命周期/判定一致性。正向窄 C 必须先 Full 建立证书，再 Build 和成功 Reuse 后 Fast；若失败记录真实 gate，而不是降阈值。宽 C 和动态 R 是安全负例，`NO_FAST_OBSERVED/exit2` 若符合完整原因和分段预期属于负例通过，而非直接整体失败。禁止直接用这些负例宣称 Fast 不可用。
|
||
|
||
之后须补：静止视觉 Full/RCRR 同资源同视角人工航标、文字、Symbol、层序对照；Camera/Source/Style/Tile/Annotation/Context/cache toggle 的瞬时失效、Full 回退、重新稳定后的 Build/Reuse；13 GTest 真实执行和 Mac Metal/iOS 独立验证。视觉比对时动态粒子会造成像素差异，不能简单拿整屏逐像素一致作为静态 Symbol 结论。
|
||
|
||
## 6. 当前判定
|
||
|
||
`ANDROID_RCRR_FAIL_CLOSED_OBSERVED / NEW_VARIANTS_SOURCE_READY / STEP119_PARTIAL`。
|
||
|
||
主要已确认局限：多 R 缓存复用并不代表全帧 Fast；含缺源 R 会阻断、过宽 C 中非支持类型的连续层触发拒绝；未实测新窄 C 前，不能推断 RCRR 性能收益。待验证风险：多 RenderTarget/Composite 成本、全局 Symbol Placement/Atlas 证书联动、局部更新导致跨 R 全局失效、上层标记/文字的层序与图像等价、iOS/Metal 一致性。
|