STEP-119 RCRR 粒子独占 C 与 CPU 实机对照阶段报告 v2

日期：2026-10-11（JST）。实际执行：Mac.lan RDC，Android FZG1-2 x86_64 / 192.168.200.139:5555，后端 OpenGL。本报告为真实 Android 固定相机稳态验证，不是 STEP-119 全量 CLOSED/PASS。

一、执行结论

粒子独占 C 的 RCR、RCRR、RCRRR 三种分段均已在 Native 真正执行 FastPath（观测窗口 Fast 100%）；同一 PBF/天气场/相机条件下，两个 R 段的 RCR 平均 CPU 工作量显著低于三 R/四 R。宽 C 混入海图或 Particle 放入 R 的两项负对照均安全拒绝 Fast，24 Gate 没有误判。

CPU 为 Android App 整个进程的 utime+stime，不是某个 Native render() 调用的精确耗时；CPU毫秒/帧是实测进程 CPU 核秒/秒除以同段 Native 帧率的估算值，不证明 GPU、功耗、动画视觉等价或动态天气切换安全。

二、来源锁与步骤执行返回

Integration main 通过 Mac RDC fetch + --ff-only，HEAD 80667d6c343411d03a760425438e3d292f452118。
Particle 分支 particle/main，本次真机 APK 对应源码 Commit：32ac795fc4abd04006673bf644f87a711329e78f，完整 SHA256：2bbd1cb4dc9e03ec56d8404363970e56f76b03819f6f2b50c8aee6dbb6fa43d2。
构建 PASS，exit0：RDC 经用户本轮明确授权在 Mac 执行 build_validation_apk.sh，Java17、Android x86_64 OpenGL Kotlin/Native Build Success；APK 66,702,127 bytes，libmaplibre.so 40,138,024 bytes。只是现有弃用 API 警告。
传输/安装 PASS：adb install -r 因网络慢无终态而终止，非编译失败；改为临时 Mac LAN HTTP→设备 curl 下载无损 gzip（31,582,202 bytes）→SHA-256校验→设备解压成原 APK再校验→pm install -r 返回 Success exit0。临时 HTTP 已停止。最终 verify_step113_fast_path.py --preflight-only exit0：源码 HEAD、build-info、Mac APK SHA、已安装设备 base.apk SHA、x86_64 全匹配。
采样器第一次试跑 BLOCKED，exit3：ADB sh -c 参数转义阻塞读取进程 /proc；已停止，不计 RCRR 缺陷。临时忽略目录的测量器按同一 APK 修复为单个 ADB shell 命令，并在温机期保存日志避免 logcat 轮转；原记录1次 SUMMARY_ALIGNMENT_LIMIT exit2，明确排除 CPU 比较。
有效 CPU Benchmark 8 次，exit0：2次 Full、3次 RCRR、2次 RCR、1次 RCRRR。均同一 Commit/APK SHA/正式Style指纹 e0f9c2d1df38ae5d5953b561c52efe2f8590336de80b988e1d2935580d30b996；每次 24 Gate、decisionMismatch 0、Native/CPU 时间边界误差≤9秒、Lifecycle不变、真实分段/无 tide / 空 Annotation 受控。
负例各 90 秒观察，命令 exit2（预期负例状态），安全验收 PASS：RCRR_C_WIDE_NO_TIDE FastDelta0 FullDelta339，unsupported-continuous-layer；RCRR_R_DYNAMIC_NO_TIDE FastDelta0 FullDelta322，unsupported-continuous-layer+动态粒子 R0 的反复 static-unstable/cache-invalid；两项 decisionMismatch=0、24 Gate完整。此 exit2 是严格验证器的 NO_FAST_OBSERVED，不是 GPU 测试崩溃。
Python 现有非 Jest 合约/CPU比较测试 12项 PASS；修正后的正式 CPU 工具源代码仅为测试 Python（不改 Native/Test APK）。使用原 APK 的实测仍以旧源码 SHA 32ac... 为准；仓库后续 Git 文档/测试器提交不倒写至 APK 来源。

三、实测 CPU / Fast 帧效率

每次独立冷启动，35秒 warmup，再约90秒稳定 CPU 采样，间隔6秒。相机固定（33.45,129.97、zoom10.5、bearing0、tilt0），场输入/forecast暂停/目标 FPS设置相同；Native FPS 实际值不等于目标 FPS，不得使用设定值算 CPUms/帧。

模式	R数量	有效轮数	Native FPS（实测）	进程 CPU / 单核	估算 CPU ms/完成帧
Full，缓存关闭	3	2	9.98、10.61	61.6%、63.3%	61.74、59.61；中位 60.67
RCR，Particle独占C	2	2	59.67、59.40	19.7%、22.0%	3.30、3.70；中位 3.50
RCRR，Particle独占C	3	3	53.93、55.03、54.22	37.6%、38.7%、39.9%	6.96、7.04、7.37；中位 7.04
RCRRR，Particle独占C	4	1	48.94	38.3%	7.82

对先 Full → Fast RCRR → 后 Full 的严格同源 A-B-A：

Full CPU ms/帧基线取中位 60.6716，RCRR Fast 7.0396：估算降低 88.40%；Fast比率100%；Full前后 CPU/秒漂移 2.70%，未达15%复测阈值。
同基线计算 RCR 3.2996：估算降低 94.56%；RCRRR 7.8212：估算降低 87.11%。RCR/RCRRR 不在严格 Full-Fast-Full 的相邻三次中，属于同 Style/设备基准横向对照，不能赋予与 A-B-A 完全相同的控制力度。
RCR 3.30/3.70 与 RCRR 7.04/7.37 的交叉重复稳定支持本场景两 R 优于三 R。不能据此把差距直接归因为 FBO 合成或强称“R数越多必然越慢”：四 R 一次 CPU/秒略低于三 R，且缺少 GPU 渲染链 Profiling。
Fast组全部在稳定观察窗口 FullDelta=0、FastFraction=1.0、windowCount=120、最后120帧 Fast=119/Full=0，每个 R 原先真实 Build1，观测窗口内 BuildDelta=0、InvalidateDelta=0、Reuse大量增长。这验证稳态 Cache Reuse，不验证主动变更后安全重建。

四、证据坐标

Git 忽略的本地设备证据目录： artifacts/maplibre-particle/android-validation/step119-rcrr-cpu/

A-B-A 综合 compare-20261011_193224.json。
包含全部三种 Fast 结构的比较 compare-20261011_193724.json。
Full 有效：20261011_184647-rcrr_full_control_no_tide/result.json、20261011_193006-rcrr_full_control_no_tide/result.json。
RCR：20261011_193242-rcr_particle_only_no_tide/result.json、20261011_194206-rcr_particle_only_no_tide/result.json。
RCRR：20261011_184406-rcrr_c_narrow_no_tide/result.json、20261011_192746-rcrr_c_narrow_no_tide/result.json、20261011_194427-rcrr_c_narrow_no_tide/result.json。
RCRRR：20261011_193504-rcrrr_particle_only_no_tide/result.json。
无效首轮 Full（仅保留排障）：20261011_184029-rcrr_full_control_no_tide/result.json。
负对照：artifacts/maplibre-particle/android-validation/step113-retest-20261011_193754/rcrr_c_wide_no_tide/result.json、step113-retest-20261011_194000/rcrr_r_dynamic_no_tide/result.json。

原始数据/Logcat 没有加入 Git，以上路径仅在执行 Mac 本地工作树中。正式报告记录事实和 Hash，不能把本报告当作已发布或 Source-Locked APK。

五、性能和架构局限 / 后续验收

C 单独 Particle 是当前强准入边界：宽 C 含普通海图会拒绝 Fast；把实时粒子错放 R 会频繁失效。不得为跑分降低24 Gate。
R 数量不是越多越好：本次两 R 性能最好，RCRR/RCRRR 受更多缓存、RenderTarget和合成/上传等成本影响的原因尚需 CPU/GPU 分项 Profiling，不得越证据结论。
WeatherColor 在 R：固定 forecast 的稳态 Build1/Reuse 大量通过；field 更新、插值时间、颜色表、可见度、Opacity、Source/Tile变化是否触发正确的失效、Full、重 Build/Reuse，未验证。
视觉等价未通过：航标、字体、跨段 Symbol Placement/遮挡、层次和色彩需同视角 Full/RC/RCR/RCRR 人工真实屏幕验收；尤其两 R 不允许以牺牲 Symbol 语义换速度。
动态地图与错误恢复未通过：Camera移动缩放旋转、Style、Source、Tile、Annotation、Context丢失以及反复切换的 Full→Fast恢复、无旧图闪现，未经过系统测试。
跨平台与低层证明未通过：Mac Metal/iOS、13项 STEP119新增 C++ GTest 真跑、GPU 时间/温度/电量未确认。Android APK 为测试 Debug x86_64，不能外推产品 ABI 或真机温度。
长期运行/网络压力未通过：设备网络传输约 48KiB/s，使用 gzip+LAN HTTP转移大APK完成安装；不能把安装网络瓶颈归咎于 FastPath，也不能用静态场证明运行稳定性。

阶段裁定：ANDROID_RCRR_STEADY_FAST_CPU_PASS / TWO_NEGATIVES_FAIL_CLOSED_PASS / STEP119_PARTIAL。建议后续优先 RCR 两 R 方案做动态/视觉/生命周期长时间测试，不修改正式生产配置，不在此报告直接决定采用。

8.1 KiB Raw Blame History Unescape Escape