7.4 KiB
7.4 KiB
TOP10 线上耗时函数后续修复
修复提交
| 仓库 | 分支 | Commit ID | 说明 |
|---|---|---|---|
harmony-ths-futures |
work-20260818-clz-FUHM-1979-apm-appfreeze |
0d10cf71a01c8c5d875ca4c950d6d2fd71d3fd42 |
挂单请求合并、套利开关缓存、通信队列索引、行情表格延迟合并 |
ohos_mobile_lib_communication |
work-freeze-lib-communication-1.1.1 |
031d4cf221b4da6d9aaf2db443ba293559a0d4a5 |
QueueManagement 队列索引(instanceId→client / companion) |
问题来源
基于 2026-08-21 TOP10耗时函数列表.md 的线上采样,继续处理仍有明确优化空间的主线程热点:
@b2b/hq_tableTableDataSource:1 次故障、10 次调用、总耗时 3000ms。@kernel/lib_communicationQueueManagement:1 次故障、2 次调用、总耗时 600ms。biz_tradeTradeCustomTabManager.isArbitrageEnabled():1 次故障、4 次调用、总耗时 1200ms。biz_tradeTradeGuaDanListView.onForeground():1 次故障、10 次调用、总耗时 3000ms。
TOP20 线上数据补充
同日 /Users/clz/Downloads/TOP20耗时函数列表.md 汇总数据如下:故障出现次数 1134,调用次数 11340,记录总耗时 3402000ms。所有记录的单个故障最大耗时均为 3000ms。这些数值是采样记录的分层汇总,不代表一次冻屏实际耗时,不能直接相加计算收益。
TOP20 主要归并为以下调用链:
| 调用链 | TOP | 故障/调用 | 总耗时 | 当前判断 |
|---|---|---|---|---|
| 重登录复用 IP 与 Native 锁 | 1–4、19–20 | 75/750;44/440 | 900000ms;132000ms/项 | 锁优化 SO 已接入,应用侧仍有同步查询边界,待新包复采 |
| 交易请求拦截与发送 | 5–6、11–18 | 47–67/470–670 | 141000–201000ms/项 | 已移除拦截器同步状态检查,通用请求仍需观察并发放大 |
| 通信响应回调转发 | 7–10 | 58–59/580–590 | 174000–177000ms/项 | 属同一管线分层采样,Worker/索引优化已接入,待新包复采 |
TOP20 显示的交易 SDK 与通信库版本分别为旧版 1.0.11/1.1.1 和 1.1.1-beta.1;当前工程依赖已更新为交易 SDK 1.0.13/1.2.0 及 Worker 优化通信 HAR。因此本表用于记录线上问题来源和修复映射,不能作为当前版本仍全部复现的证据。
修复内容
GuaDanViewModel.sendRequest()增加进行中请求合并:挂单查询未返回时,后续前台/刷新触发只记录一次尾随刷新,避免短时间重复进入 SDK 查询链路。TradeCustomTabManager.isArbitrageGrayOpened()增加当前账号维度缓存;TradeSettingEvents.SETTING_UPDATE触发时失效,避免列表构建高频进入GrayTestManager.isFeatureEnable()的日志和配置序列化路径。- 通信 SDK
QueueManagement增加instanceId -> client和 companion 映射索引,getNetworkClient()从全量扫描改为按索引取主请求和 companion 请求。 hq_table_20260616.har内TableDataSource对非可见区SendableRow做延迟合并:当前刷新只合并可见行,非可见行缓存到pendingSendableRows,滚动取数时再落到RowData。- 重新构建通信 HAR,并替换当前工程
libs/lib_communication20250903-worker-opt.har;hq_table无相邻源码仓库,本次直接以最小差异更新现有 HAR。
影响范围
- 挂单列表前台恢复、手动刷新和交易推送叠加时的请求频率。
- 独立交易页期权/套利 Tab 显示判断。
- 通信响应分发中的请求匹配。
- 行情表格 Sendable 数据进入主线程后的行合并时机。
业务协议、接口签名、表格展示数据结构和交易请求返回处理不变。挂单请求合并保留尾随刷新,避免丢掉进行中期间发生的最后一次刷新诉求。
验证与压测
node claude_tool/subthread-import-guard/check-subthread-imports.mjs:PASS。- 通信 SDK:
devecocli build --modules lib_communication@default:BUILD SUCCESSFUL。 - 主工程:
./claude_tool/claude_compile.sh:BUILD_SUCCESS。 - 模拟器:Pura 90,
127.0.0.1:5555,HarmonyOS 6.1.1(24)。devecocli run --module entry --device 127.0.0.1:5555 --product default --build-mode debug --skip-build:安装并启动成功。- 应用进程
com.hexin.plat.hmn.futures存活,前台任务EntryAbility存在。 - 前后台压力:Home/重新拉起 20 轮完成,无 crash、无
APPFREEZE日志。 - UI 基础场景:行情 Tab 切换、行情页上下滑动 8 轮、交易 Tab 切换、交易入口前后台 5 轮完成,无 crash、无
APPFREEZE日志。 - 备注:未登录交易账号,挂单真实请求返回链路未覆盖;本轮覆盖交易入口页加载和前台恢复基础路径。
- 临时 stdin 压测脚本未落盘,覆盖 100000 个通信实例索引查询、100000 行表格 Sendable 延迟合并、1000 次挂单刷新触发合并:
queueIndexedMs: 4mstableDeferredMs: 4msrequestRealSendAfter1000Triggers: 2
新模拟器真实账户验证
- 设备:Mate X7,
127.0.0.1:5557,HarmonyOS 6.1.1(24);通过devecocli ui完成控件树检查和交互。 - 真实账户登录成功,交易首页权益、可用资金和行情盘口加载完成。
- 进入当日委托/挂单页面,连续 10 轮切换挂单、委托、成交并触发刷新;页面保持响应,无
APPFREEZE,无应用 crash。 - 该轮未执行下单、撤单或改价,避免产生真实资金业务副作用。
- 设备网络不可用时出现 DNS/监控上传错误;同时观察到已有 SQLite 空表名查询错误,均未导致应用退出或冻屏,不纳入本次 TOP 修复结论。
- 最后一次误触打开交易时间提醒 WebView,页面仍正常展示;该路径不属于本次交易 SDK 压测范围。
Wukong 滑动压力验证
- 设备:Mate X7,
127.0.0.1:5557;仅允许com.hexin.plat.hmn.futures,固定种子20260821。 - Wukong 随机测试报告:
task status=success、task time=149s、task count=100,事件为 100 次滑动;点击、键盘、旋转和应用切换比例均为 0。 - Wukong 异常统计为空;设备
APPFREEZE查询为空,应用 crash 查询为空。 - 报告目录:
/data/local/tmp/wukong/report/20260821_152309/。该轮未执行交易点击,真实账户无资金业务副作用。
按修改点专项复验
hq_table:国内行情大表执行 Wukong 50 次纯滑动,报告task status=success、task count=50、滑动事件 50 次、异常为空;页面仍可正常进入合约详情。- Worker 解码:合约详情连续 8 轮切换分时、日 K、1/5/15 分钟,图表和行情数据正常,无
APPFREEZE或 crash。 GuaDanViewModel与QueueManagement:真实账户交易页在设置更新后重新进入当日委托,连续 5 轮切换挂单/委托并刷新;页面正常,无APPFREEZE或 crash。TradeCustomTabManager:当前真实账户和灰度环境未展示期权/套利独立下单 Tab,仅触发交易设置更新事件并返回交易页验证回退/重建路径;期权/套利 Tab 的直接专项验证待灰度开放后补测。
后续验证
需要用新包重新采集线上或真机冻屏采样,确认 TableDataSource、QueueManagement、isArbitrageEnabled、TradeGuaDanListView.onForeground 不再进入 TOP 耗时函数。短函数如 ColorUtils.transFormServerColor()、StringUtil.isNumber() 和 BaseView 绘制闭包仍应结合完整栈判断,不单独做微调。