docs: add stability remediation evidence
This commit is contained in:
@@ -0,0 +1,39 @@
|
||||
# 通信 Worker A/B 性能验证
|
||||
## 验证对象(对应修复)
|
||||
|
||||
该验证针对 `HXZip` 解压与曲线解析迁移至 Worker 的收益,属于笔记 `03`、`04` 的量化回放,完整修复提交见 `03`/`04`(`ohos_mobile_lib_communication` `031d4cf221b4da6d9aaf2db443ba293559a0d4a5`、`harmony-ths-futures` `ce0719178530b5ca64272c6c1e90b5bcdb8297fc`)。
|
||||
|
||||
## 验证目标
|
||||
|
||||
对比 `lib_communication` `1.1.1-beta.1` 在同步解压/曲线解析与 Worker 异步处理下的主线程负载。测试只评价通信解压和曲线解析改造,不包含 XML、交易 SDK 或图表绘制优化。
|
||||
|
||||
## 测试方法
|
||||
|
||||
- 时间:2026-08-18
|
||||
- 设备:Pura 90 手机模拟器,`127.0.0.1:5555`
|
||||
- 页面:国内行情“乙二醇2609”详情页
|
||||
- 操作:依次点击 `1分 -> 5分 -> 15分 -> 日K -> 分时`,连续执行 3 组,共 15 次切换
|
||||
- 轮次:旧同步版和 Worker 新版各 3 轮;每轮重新启动应用进程并采集 20 秒 hitrace
|
||||
- 分析:使用 DevEco `trace_streamer` 转换为 SQLite,统计目标进程 `lat.hmn.futures` 的主线程调度片段
|
||||
|
||||
## 测试结果
|
||||
|
||||
下表使用三轮中位数,括号内为三轮范围。
|
||||
|
||||
| 指标 | 旧同步版 | Worker 新版 | 变化 |
|
||||
| --- | ---: | ---: | ---: |
|
||||
| 主线程 CPU 时间 | 2959 ms(2923~3309) | 2361 ms(2330~2512) | -20.2% |
|
||||
| 进程总 CPU 时间 | 3765 ms(3731~4201) | 3075 ms(3069~3250) | -18.3% |
|
||||
| 主线程 `>= 8 ms` 连续运行片段 | 30 次(23~36) | 14 次(14~17) | -53.3% |
|
||||
| 主线程调度片段 P99 | 5.747 ms(5.304~5.865) | 4.644 ms(4.452~4.692) | -19.2% |
|
||||
| 主线程最大连续运行片段 | 23.698 ms(13.252~31.006) | 19.360 ms(12.924~24.345) | -18.3% |
|
||||
|
||||
## 结论与限制
|
||||
|
||||
Worker 改造使主线程计算量下降约 20%,8 ms 以上连续运行片段减少一半以上,主要收益是降低大包解压和曲线解析占用主线程导致的冻屏风险。
|
||||
|
||||
`CurveView` 刷新总耗时中位数由 221.5 ms 变为 236.0 ms,没有稳定改善。超过 16.67 ms 的帧中位数由 9 次变为 13 次,帧尾部数据也未呈现一致收益。因此本次结果不能解释为整体帧率提升,优化范围仅限通信解析阶段。
|
||||
|
||||
自动框架识别未生成应用绘帧记录,因此未套用 ArkUI 丢帧分类结果。后续建议在真机上使用固定响应包、增加解压和曲线解析起止 trace 点,并扩大轮次,以进一步隔离网络波动、模拟器调度和图表渲染噪声。
|
||||
|
||||
原始 trace 和 SQLite 数据未纳入仓库,测试时临时保存在 `/tmp/sdk-worker-ab.psA7Sp/`。
|
||||
Reference in New Issue
Block a user