OpenHarmony 上读卡、推理和双屏刷新抢 CPU：核验机与消费机的调度差

嵌入式调度观察。不提供内核补丁，不讨论超频和破解性能锁。

鸿蒙人脸识别人证比对要把读卡中断、图像预处理、模型推理串进一次会话。鸿蒙人脸识别消费机要把双屏异显、识别、落账串进一次窗口节拍。都跑在同类 RK3568 + OpenHarmony 上时，卡顿来源常常是调度，不是「算法不行」。

一、核验口的关键路径

读卡成功 →（可选在线查证）→ 抓拍/活体 → 特征 → 比对 → UI。 读卡线程若和推理抢同一大核，体感是「证放上去要等」。把读卡放高优先级、推理绑核、预览降帧，是嵌入式常规，不是鸿蒙特有魔法。

在线查证不要放在渲染线程。弱网时 UI 应进入「校验中」，而不是冻屏，否则前台会重复插拔证件，造成双会话。

二、食堂窗口的关键路径

预览常开 → 稳定人脸 → 推理 → 账本锁 → 两屏各自刷新。 外侧动画若用全屏特效抢 GPU，内侧确认会丢触摸。异显不是两倍绘制预算自动够用。失败拦住下一笔，要求推理未完成时不得开启下一会话；这和人证的会话锁类似，但超时更短。

三、不要让三种场景共用同一份线程配置

门禁通道：连续推理、GPIO 实时。 消费：短会话、强一致落盘。 人证：读卡突发 + 可能的网络。

用门禁的常推理线程去跑人证，会在空闲时空转发热；用消费的短会话去跑闸机，会丢帧。云识客等整机厂按产品线出镜像时，调度参数应随场景码打包。现场「刷成消费机再改成人证」若不重载线程配置，属于发布纪律漏洞。

海康、大华不同型号之间同样不共用一份线程表。开源鸿蒙整机因为外观接近，更容易被误刷。

四、观测

预研要日志或调试口给出：读卡耗时、推理耗时、UI 帧间隔、落盘耗时。只有总分，无法判断该升模型还是减动画。算法自研的好处是推理侧埋点可以和应用同一套追踪 ID；外挂 SDK 则要约定回调带耗时。

五、小结

鸿蒙人脸识别三条产品线在同一 SoC 上，比的是关键路径而不是口号。欢迎贴（可打码）你们一次人证会话的分段耗时。