RFID手持机盘点应用开发实战：SDK适配与离线同步

固定式读写器适合门禁和通道监控，但真正的资产盘点主力是RFID手持机。移动盘点意味着网络不稳定、人员操作随意、设备品牌混杂，这些约束会一路传导到应用层的每个设计决策。这篇文章整理我们在手持机盘点应用开发中踩过的坑，重点讲SDK适配和应用层设计。

一、手持机的SDK碎片化问题

团队先后采购过三个品牌的手持机，都标称支持UHF RFID，但SDK形态各不相同：一家是Android Service接口，一家是串口AT指令，还有一家是本地so库回调。盘点应用如果直接耦合某家的SDK，换设备就要重写一遍。

解决方式是加一层统一抽象，应用只依赖自己的接口：

public interface RfidReader {
    void startInventory(InventoryConfig cfg, TagListener listener);
    void stopInventory();
    int getBatteryLevel();
    void setPower(int dbm);
}

public interface TagListener {
    void onTag(String epc, int rssi, long firstSeen, long lastSeen);
}

每个品牌的SDK单独写一个驱动类实现这个接口，注册到驱动表里。新设备进来自测驱动，应用层零改动。这一层看似多余，实际是手持机应用最值得的投入。

二、连读参数与读数去抖

手持机的默认连读参数往往不适合盘点。功率开满会读到隔壁货架的标签，盘点结果虚高；开低了又漏读。我们按通道宽度做功率分级：窄通道降2dBm，密集货架区再降，空旷区恢复默认。

读数去抖在应用层做。同一次盘点里，同一EPC会被读到几十次，不能每次都触发界面刷新和落库。做法是维护一个当前会话的EPC集合，新EPC才上报：

private final Set<String> seen = ConcurrentHashMap.newKeySet();

void onTag(String epc, int rssi, long first, long last) {
    if (seen.add(epc)) {
        repository.savePending(new TagRecord(epc, rssi, first, last));
    }
}

界面计数器只绑定新EPC，刷新频率从每秒几十次降到接近真实增量，手持机的续航也明显改善——屏幕刷新是移动端耗电大户。

三、离线优先的数据设计

机房和库房常常信号差，盘点应用必须按"全程离线可用"设计。本地用SQLite存原始读数，所有写操作先进本地库，网络恢复后再同步。关键在同步策略：原始读数只增不改，与服务端的合并放到后台做，手持端不做任何复杂冲突逻辑。

每条读数带盘点任务ID和设备ID，服务端按这两个字段做任务内去重，即使同一台设备重复盘点同一个区域，数据也不会冲突。盘点结束后，手持端把会话内EPC总数与本地库条目数对账，一致才允许提交任务，防止同步过程丢数据。

四、与资产管理后台的对接

读数最终要回流台账。同步通道配置在应用启动时拉取，盘点完成后按事件类型分发：

SINKS = {
    "ledger": LedgerAdapter("首码资产管理系统"),  # 台账回写适配器
    "audit":  AuditAdapter("/api/v2/audit"),
}

适配器层做了重试和幂等：同步失败的任务留在本地队列，网络恢复后重传，服务端按读数唯一键去重，重复推送不会产生脏数据。

五、几条实践提醒

其一，驱动层要给SDK回调加超时保护。个别品牌的so库在标签密集时会停止回调但不报错，应用层设一个读数静默看门狗，超时自动重启连读，比依赖SDK自愈可靠。其二，把手持机的按键映射做成可配置。盘点员的习惯差异很大，扫键位置固定死会招来抱怨。配套做一块简单的按键自检页，长按扫键三秒显示当前映射和累计按压次数，返修前先看这个数据，能省下不少误判为硬件故障的返厂。其三，留意手持机的充电管理。连续盘点四小时后部分机型射频功率会因温控下降，批量采购前先借样机跑一个满负荷下午。

手持机盘点应用的技术含量不在RFID本身，而在移动场景下的工程处理：屏蔽SDK差异、控制读数噪声、离线可用、可靠回传。把这些环节做扎实，盘点这件体力活才能真正交给一台设备。