94 lines
8.1 KiB
Markdown
94 lines
8.1 KiB
Markdown
# STEP-119 RCRR 粒子独占 C 与 CPU 效率测试矩阵 v2
|
||
|
||
日期：2026-10-11 JST。状态：**TEST SOURCE PREPARED / ANDROID NOT RUN / STEP-119 PARTIAL**。本 v2 取代 v1 对“窄 C 包含 WeatherColor+Particle”的测试建议；v1 保留为历史证据，不改写当时实机事实。
|
||
|
||
## 一、目标与核心原则
|
||
|
||
原则：**一个 Continuous 段只放 RasterParticleLayer**。WeatherColorLayer 不是逐帧运动图层，正常预测/颜色不变化期间可作为 R 候选，但数据提交、forecast time、色阶、Opacity、Style、Camera、Source/Tile/Atlas 等发生实际结果变化时必须安全撤销旧缓存并 Full，再重 Build/Reuse。这些具体动态失效条件仍需真机证明，不能因为分段配置正确而提前视为 PASS。
|
||
|
||
Native 当前代码以 `singleContinuousSegment(plan)` 选择唯一 C；快路只在这个 C 范围执行 tweaker/upload/postRender，全部 R 需具备有效缓存、Revision 与 Symbol 结果证书；现有 24 Gate 不能放宽。因而“一个 C + 多个 R”符合技术实现边界，但不是任意 R 划分都必然适合 Fast。
|
||
|
||
## 二、可比 Style 与真实图层顺序
|
||
|
||
正式原 PBF Style 63 层、测试副本只排除无源 `tide-spots`，其余 62 层定义和次序完全保留，WeatherColor / Particle **按原插入点顺序**位于 `clip-outline` 之后，Native 预计总 64 层。基于设备导出与原正向成功相同指纹的 Style Manifest：
|
||
|
||
- R 下部 [0,32)：含基础海图 [0,31)，并在索引31绘制 `rn-weather-color`；WeatherColor 留在 R 中。
|
||
- Particle C 唯一图层 [32,33)：`rn-weather-particles`。
|
||
- 上部 R [33,64)：各类静态海图、Symbol 和文字。按测试目的拆成 1/2/3 个 R 片段，不改实际图层顺序。
|
||
|
||
**不要在 NavSea 产品中按本测试索引硬编码**；生产实际 Style 上应按图层 ID 验证真实边界。
|
||
|
||
## 三、新一轮候选与负对照
|
||
|
||
| 场景 | 预期分段 | 目的 |
|
||
|---|---|---|
|
||
| `RCRR_FULL_CONTROL_NO_TIDE` | R[0,32) C[32,33) R[33,63) R[63,64) | 与主 RCRR 相同 Style/Plan/Field，但关闭 Retained 缓存，取得 Full CPU 基线 |
|
||
| `RCRR_C_NARROW_NO_TIDE` | R[0,32) C[32,33) R[33,63) R[63,64) | 主 RCRR 正向，仅粒子进入 C；3 个 R |
|
||
| `RCR_PARTICLE_ONLY_NO_TIDE` | R[0,32) C[32,33) R[33,64) | 仅 2 个 R，测缓存片段数量收益/开销 |
|
||
| `RCRRR_PARTICLE_ONLY_NO_TIDE` | R[0,32) C[32,33) R[33,38) R[38,63) R[63,64) | 4 个 R，测额外 RenderTarget/Composite/缓存生命周期成本 |
|
||
| `RCRR_C_WIDE_NO_TIDE` | R[0,2) C[2,38) R[38,63) R[63,64) | 历史宽 C 错误配置，继续作为负对照，不作为性能候选 |
|
||
| `RCRR_R_DYNAMIC_NO_TIDE` | R[0,33) C[33,38) R[38,63) R[63,64) | Particle 在 R 内的错误配置，必须 Fail-Closed |
|
||
| 原 `PARTIAL_RCRR` | R[0,3) C[3,39) R[39,64) R[64,66) | **已经实测**：R0 缺 tide、R2/R3 各 Build1/Reuse536、FastDelta0/FullDelta596、decisionMismatch0 |
|
||
|
||
旧正向 `STATIC_RC_NO_TIDE` 用于证明原有 FastPath（FastDelta1819），但天气层位置与粒子独占 C 的四个 A/B 场景不相同，**不能直接拿其 CPU 数据得出 RCRR 快慢结论**。
|
||
|
||
## 四、CPU 指标及可比性
|
||
|
||
使用 Android `/proc/<PID>/stat` 同一进程的 `utime+stime`（含 App 主线程与原生工作线程），以设备实际 `getconf CLK_TCK` 转换为 CPU 秒。记录该进程在观察期内消耗的累计 CPU 核秒。设备实测此接口可访问且 `CLK_TCK=100`，此预检不是新 APK 实测。
|
||
|
||
每场景冷启动不同 PID，固定设备、x86_64 OpenGL APK、Style URL/PBF fingerprint、中心/zoom/rotation、1920×1200 设备条件、Weather 数据、forecast pause、1024 粒子和目标 FPS30。先 Warmup35 秒（等待载入/Placement/Cache settle），再观察至少 90 秒；每 6 秒读取一次 CPU 累计值，场景 Native summary 同样按 6 秒采样，最多允许 CPU/Native 边界时间差 9 秒，否则记测量不完整。
|
||
|
||
同时必须记录：
|
||
|
||
- `CPU 核秒/秒 = Δ(utime+stime)/CLK_TCK/观察秒数`；乘100为**相对单核的进程 CPU%**，多线程时可超过100%。
|
||
- `Native FPS = (ΔFast+ΔFull)/Native摘要实际区间秒数`。
|
||
- `估算 CPU ms/完成帧 = (CPU核秒/秒) × 1000 / Native FPS`；这是进程级近似值，不是 C++ 单次 render 函数的精确 CPU 耗时。
|
||
- FastFraction、Full/Fast 增量、R Build/Reuse/Invalidate、24 Gate mismatch、源指纹、生命周期、帧率、帧率波动及进程 PID。
|
||
- Full→Fast→Full（A-B-A）控制热机/网络缓存时序偏差；Full 前后的 CPU 核秒/秒漂移超过15%则需要复测，不凭一次高速帧数下性能结论。
|
||
- 如果 Fast FPS 比 Full 高而 CPU/秒也提高，必须同时呈报“每帧成本下降”和“整机持续负载未必下降”。`CPUms/frame`改善不等于省电或 GPU time 已改善。
|
||
|
||
## 五、顺序执行（用户手工编译一次，其余通过 RDC）
|
||
|
||
必须先将本轮 Test App 修正提交/Push，**由用户手工使用当前 HEAD** 进行 Android APK 构建/安装；禁止用旧 `3d989a...` APK 冒充新场景。完成后 RDC 检查 build-info commit、SHA-256、设备 base.apk SHA 和目标 ABI。
|
||
|
||
```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
|
||
|
||
# 每条命令执行完读取状态/result.json，再进入下一条；A-B-A:
|
||
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCRR_FULL_CONTROL_NO_TIDE --seconds 90 --warmup 35
|
||
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCRR_C_NARROW_NO_TIDE --seconds 90 --warmup 35
|
||
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCRR_FULL_CONTROL_NO_TIDE --seconds 90 --warmup 35
|
||
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCR_PARTICLE_ONLY_NO_TIDE --seconds 90 --warmup 35
|
||
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCRRR_PARTICLE_ONLY_NO_TIDE --seconds 90 --warmup 35
|
||
```
|
||
|
||
每次自动写入 Git 忽略目录：
|
||
`artifacts/maplibre-particle/android-validation/step119-rcrr-cpu/<时间>-<场景>/result.json`；同目录保存日志和启动记录。脚本全程真实读取现有 Native 摘要，不改 Gate、不执行 Gradle。验证器 Fast 场景须稳定 Fast 比例≥95%，Full 对照须 FastDelta=0、FullDelta>0。未满足时标记 `MIXED_OR_NO_FAST` 或 `NO_EXPECTED_FRAMES`，**不把回退帧混入 Fast 成本声称速度提升**。
|
||
|
||
在取得相应结果路径后使用：
|
||
|
||
```bash
|
||
python3 -B tools/particle_android_validation/compare_step119_cpu.py \
|
||
--full-before '<第1次Full/result.json>' \
|
||
--fast '<RCRR正向/result.json>' \
|
||
--full-after '<第2次Full/result.json>' \
|
||
--rcr '<RCR/result.json>' \
|
||
--rcrrr '<RCRRR/result.json>'
|
||
```
|
||
|
||
结果自动核验同 SHA/设备/Style 指纹、Native窗口、失配、Full控制与顺序漂移，输出 CPU per frame 节省比例、CPU 核秒/秒和 FPS 对照。若主 RCRR 尚不能稳定 Fast，不执行“有性能提升”的结论，只报告准确的 Gate 和成本。
|
||
|
||
## 六、其他 STEP-119 待验
|
||
|
||
相同视角的 Full/Fast 截图与 Symbol/文字/航标图层层序人工对比；Camera pan/zoom/rotate、Source/Style/Tile/Annotation/context/forecast 变更导致的证书失效和 Full → Build → Reuse 恢复；13 项新增 C++ GTest 真实运行和 macOS Metal/iOS 独立验证，均保持 NOT VERIFIED。Mac 现存 libuv CMake 配置缺口不授权升级第三方系统工具。全任务 STEP119 仍是 `PARTIAL`，本批仅准备测试能力，没有 Android 编译或新数据。
|
||
|
||
## 七、保护
|
||
|
||
- 不改变 Shared Core 公开 API、24 Gate、Renderer 行为、正式远端 PBF Style、发行 Tag/SOURCE_LOCK。
|
||
- 原 `STATIC_RC` 63 层与历史 RCRR/负对照保留。
|
||
- 不清理两份 STEP110/111 未跟踪文档。
|
||
- 本阶段只把 Test App/CPU 工具/中文报告/Step/开发记录按 Git 任务范围提交到已有 `particle/main`，Push后回读远端 HEAD。
|