有赞零售移动端收银商品实践

面对线下收银场景，针对商品收银业务，如何提升商家收银的效率？如何保证即使在弱网或无网条件下商家正常的收银？如何设计大量商品时搜索方案？如何对业务模块进行解耦和各种复杂的业务场景交互？都是在设计零售收银业务时，需要去认真思考的问题。

有赞零售移动团队在业务快速地迭代中，沉淀出商品收银的一套可行方案。

• 模块化设计

• 得益于零售移动的组件化框架，对业务线划分为店铺、交易、商品、营销等模块

• 路由负责页面跳转与组件间通信

• 私有化商品模块数据，商品模块提供查询接口

• 离线商品数据

• 客户端本地存储商品商品，即使在无网时，商家仍可正常收银

• 提供商品名拼音搜索、扫码枪的商品条码扫码能力

• 商品收银与营销活动

• 支持门店商品收银时营销活动的数据组装

• 支持不同营销活动时门店商品页面数据渲染

• 硬件支持

• 扫码枪、电子秤等多种硬件设备支持，提升商品搜索与收银效率

一、模块化设计

最初的零售移动多业务线共用本地数据库，调用时业务方式直接访问数据库 DAO 类查询数据，虽然使用上来说各个业务 Module 无须重新定义 DAO 数据类，但是业务之间耦合反而加重，违背了业务组件化的初衷。因此决定对数据库进行拆库：

1. 按照业务线将数据库进行拆库

2. 业务 Module 统一数据访问的入口

3. 路由调用方法

上图是商品模块进行数据库拆分之后的基本模型。拆分之后：

1. 单个数据库职责更单一，清晰明了，耦合降低

2. 商品模块统一各个业务线访问商品数据的入口。

3. 商品业务或底层数据变更时，其他业务线无须关心数据模型变更

4. 各个业务组件之间数据通过 JSON 或商定好的协议进行数据传递

模块化设计把与业务强耦合的数据封装到业务模块内，调用方无须关心具体的业务细节；同时业务有变更或重构时，只要能够保证接口新旧一致性，上层业务方做到无感知，业务变更影响面减少，代码便于维护，一举两得。

业务模块化解决了业务模块间的耦合问题，那么如何设计商品离线数据同步机制？先思考一个问题：为什么要做商品离线同步？答案很显然：

1. 线下门店与线上网店不同，在弱网或无网条件时，仍需要保证商品收银可用。

2. 本地商品搜索效率上来说要比只依赖与网络接口请求要高效很多

3. 门店收银要涉及到对接硬件的场景，在这些场景下，离线数据也有天然的优势

那么回到问题上如何设计商品离线数据的同步机制？应该至少考虑以下几个要求：

1. 保证尽可能少的数据传输量

2. 同步任务启动时机：网络重连后要进行数据同步等

3. 同步任务尽可能地简单高效，便于维护

4. 服务端数据变更后能够实时同步到客户端

5. 同步数据的一致性与稳定性

二、离线商品同步设计

2.1 全量同步还是增量同步？

从设计复杂角度来说，全量同步是最容易实现的，数据的一致性容易保证。然而随着数据量的增加，每次全量同步消耗的资源和同步时间会越来越多，而且服务端数据变更后都要进行一次全量更新。与增量同步相比缺点比较明显。

相比于全量数据同步，增量同步只在初始时批量拉取服务端的商品数据。在本地已有商品时，通过本地最新的同步时间拉取商品，在数据传输量亦比全量同步更少，降低同步时间与流量消耗。

在选型上零售移动采用后者作为商品离线数据方案，通过同步时间来进行增量更新拉取最新的门店商品数据。

同步任务采用 单任务方式（即同步时只有一个同步任务在执行）减少多线程带来的并发问题维护成本，数据的一致性得到保证。

基本的同步过程：

1. 移动端读取本地最新同步时间，根据时间请求服务端

2. 服务端下发增量数据

3. 客户端对比本地时间和增量数据的时间，判断是否已拉取最新数据

4. 如果本地已是最新数据，停止同步；否则继续增量拉取数据，重复步骤 1

忽略掉各种边界条件和异常状况，一个简化的增量拉取流程可以抽象为下图：

对于商品数据新增和更新，上面的同步能够保证，那么数据的删除操作呢？

零售商品数据对删除操作只做逻辑删除，这样删除操作也可以归为数据更新。从而解决商品删除操作的问题。

商品数据同步任务确定后，需要考虑同步任务的触发时机。

2.2 同步任务触发时机

未接入长连接消息前，采用客户端主动触发同步任务：

1. APP 在用户登录后

2. 断网重连后

3. 用户在商品页，手动触发同步

基本上满足那些商品数据基本不怎么变更的商家，但不能符合大多数的商家的使用场景。如：在 PC 后台创建一个门店商品或更改门店商品价格，移动端需要保证本地的商品数据实时更新，才是一个比较合理的设计。

2.3 长连接同步

长连接，这里所说的是 TCP 协议经过三次握手建立的连接。IM（即时通讯）的实现方案亦是维护 Socket 长连接作为消息通道，进行收发消息。

IM 消息接收流程

• 发送方发送消息，经过服务器转发；

• 对于在线的接收方，选择推送消息；

• 在线推送失败或离线接收方，消息持久化到离线库；

• 当接收方重新连接时，主动拉取去离线消息；

IM 形式的长连接方式，消息数据通过推送发送给接收方，接收方解析消息数据，本地做持久化存储。需要考虑消息去重、消息丢失等多种复杂的场景处理。

从业务方角度来说，实现和维护 IM 的功能成本较大。零售业务线对接有赞 IM SDK 收发消息。商品数据的同步采用 轻消息的方式来保证数据变更的实时性。

所谓 轻消息，消息不包含具体的业务线数据，仅有业务线类型。移动端解析业务线类型数据，判断数据变更类型如：商品更新、商品删除、商品创建等，触发数据同步任务。

一个简化的商品长连接同步时序图：

个端（APP/前端）在对商品操作后，商品后端发送商品变更的消息给消息中心，消息中心推送商品变更消息，移动端接收到消息解析，同步商品数据。

好处

• 商品数据变更实时性能够保证

• 业务线只关心消息类型，无须处理复杂消息长连接的问题

• 商品数据持久化一致性能够得到保证

不足

• 实时性依赖消息长连接的稳定性

场景增量同步+长连接推送满足零售商品离线数据满足线下商品收银，基本需求能够得到保证。但面对千上万的商品数据如何提升商家的收银效率呢？因此商品搜索场景必不可少。

三、门店商品搜索

考虑线下门店商品数量，需要设计可行的搜索方案。方案需要考虑的问题：

1. 门店商品的模糊搜索。在商品页面可以根据商品的拼音全拼或首字母模糊匹配商品数据

2. 门店使用扫码枪设备时，支持商品扫码的精确匹配

由于要对接扫码枪，而扫码枪属于特殊的硬件键盘，而在 APP 页面存在输入框在获取焦点时，会拦截掉扫码枪的输入事件。所以：

• 在页面设计时，对于输入框使用 TextView(Android)替换。

• 自定义支持英文字母和特殊符号的软件盘

在设计层面规避输入框的存在造成扫码枪事件被拦截的问题。但也导致无法使用系统软键盘或中文输入法，只能够使用商品名的拼音进行模糊搜索。

增量下发的门店商品没有拼音字段，要求移动端在持久数据时，对商品的中文转换为对应的拼音。

3.1 商品名中文转拼音

对于中文转拼音，App 层都现成的转换方案，Android 端有 Pinyin4J 库，iOS 端系统提供了汉字转拼音的 API。但都有大大小小的问题：

• iOS 与 Android 的转换的拼音不一致，如 女：Android 转换为 nv；iOS 转为 nu
  

• 不支持多音字，两端均是取字库中的默认音

一个理想的拼音库应该满足以下条件：

1. 多端结果一致

2. 转换速度快

3. 内存占用低

4. 转换结果长度可控

5. 字库、词库可动态下发

3.1.1 基于 JS 引擎的汉字转拼音方案

在跨平台技术选型上，零售移动选择 JS 引擎解决两端数据一致性问题。JS 引擎能够解析执行 JS 脚本，帮助移动端进行跨平台开发。业界流行的移动端跨平台方案如 Facebook 的 ReactNative、阿里的 Weex 均是依赖 V8（Android）与 JSCore（iOS）的 JS 引擎实现的跨平台前端动态方案。iOS 曾流行的 JSPatch 补丁库，亦归功于 JSCore 的优秀的动态化。

在执行速度上，V8 引擎将 JS 代码变为机器码并进行优化，加快执行速度。对于垃圾回收，V8 使用一种传统的分代式标记清除的方式去清除老生代的数据。

一个简化的汉字转拼音的流程：

流程中遍历商品名称，根据字在汉字拼音表中对应的拼音数量，判断是否为多音字。如果是多音字则查找字在多音字词语中的精准读音。

3.1.2 汉字拼音表

汉字与拼音的对应关系表。如果是多音字，则对应多个拼音。如：

dict[0x96f6] = "ling"; /* 零 */
dict[0x91cd] = "zhong,chong"; /* 重 */

对于声调不同的多音字，如 扇有 shàn和 shān两种声调，汉字拼音表只维护一个无声调的拼音 shan。

dict[0x6247] = "shan"; /* 扇 */

因为拼音搜索时，不区分声调不同导致的多音字。

3.1.3 多音字词表

常见的多音词表格式

"阿Ｑ": [["ā"], ["Ｑ"]],
"阿爸": [["ā"], ["bà"]],
"阿鼻": [["ā"], ["bí"]],
...

使用上面格式的多音词表来判断多音字的正确读音时，要遍历整张多音字表，汉字常用有 4 万+多音字词，遍历效果并不理想。因此需要对原有的多音字词表进行改造优化。

3.1.4 改造后的多音字词表

...
dict[0x62d7] = ["拗断,ao,0","拗口,ao,0","违拗,ao,1","执拗,niu,1","拗不过,niu,0",
"拗口令,ao,0","强嘴拗舌,niu,2","三不拗六,niu,2","四不拗六,niu,2"];
...

多音字在不同词语或邻词中的读音关系映射。如 "拗断,ao,0"表示 拗在 拗断中的正确读音为 ao且 拗在分词中的索引位置为 0。

在确定多音字的读音时，只要找到多音字词表中该多音字对应的多音字读音即可。

3.1.5 多音字拼音的判断流程

现实生活瞬息万变，一个字的读音亦可能会发生变更，尤其是在互联网。多音字词表不能保证维护多音字的全部读音。在汉字的不同语境又是强上下文关联，也不能保证多音字拼音转换的准确性。

针对这种情况，多音字的拼音转换考虑笛卡尔积的形式生成拼音。如 重庆的咖喱牛肉，假定多音字词表未收录 重庆对应的拼音，根据 重在汉字拼音表的中的多个读音进行拼装。

chongqingdegaliniurou|zhongqingdegaliniurou|..

笛卡尔积的方式解决了多音字词表未匹配的问题。但是相应的增加了最终生成的多音字拼音的长度，对搜索速度会有影响。所以限制生成的拼音字符的最大长度的阈值。在使用笛卡尔积形式时判断生成的字符串是否超过指定的长度阈值，若有超过阈值的问题，则多音使用汉字拼音表中默认的拼音。

3.1.6 商品名拼音首字母

搜索除了拼音全拼，拼音首字母也是很常见的场景。不过有了全拼的解决方案后，拼音首字母相对来简单很多，只须在获取获取汉字拼音时，取到拼音的首字母后组合即可。

解决了商品名中文转拼音问题后，就可以愉快地进行搜索本地商品啦。

3.2 商品模糊搜索

应用场景：收银也拼音模糊匹配，搜索商品。

商品搜索逻辑相对比较简单：搜索时模糊匹配商品的拼音或条码。输入内容时，调用商品模块提供的搜索接口，匹配本地商品的拼音中含有指定文本的门店商品。可以方便快速查找商品，节省时间。

简单的 SQL 搜索语句

SELECT title, price, code, pinyin, pinyinletter
FROM goods
WHERE pinyin LIKE '%xx%'
    OR pinyinletter LIKE '%xx%'
    OR code LIKE '%xx%'
    AND shopid = '店铺id'
ORDER BY 'sortName'
OFFSET 'pageNo'
LIMIT 'pageSize'

3.3.1 扫码枪的场景

收银员在收银界面，使用扫码枪扫描商品条码或条码秤的 PLU码，通过条码查找到商品，添加到购物车。

商品条码由一组规则排列的条、空及其对应代码组成，表示商品代码的条码符号。

与商品模糊搜索场景不同，条码可以确定唯一商品，所以扫码枪的场景为

• 扫码枪精确匹配对应条码的商品

• 相同商品不同厂商会多个条码（一品多码）

设计上采用商品搜索表满足扫码枪的快速搜索与 一品多码的业务需求

3.3.2 商品搜索表设计

1. 条码与商品 ID 映射

2. 以条码字段创建索引

扫码枪的商品搜索流程：

3.3.3 商品未同步时的补偿机制

因为扫码枪搜索的是本地商品数据，在门店初次启动零售 APP，使用扫码枪扫码时商品可能尚未同步到本地，影响门店的收银效率。

所以在扫码枪的使用场景，需要加上商品搜索的补偿机制：在扫码枪未在本地搜索到对应条码的商品，则调用后端接口获取商品信息。考虑到网络不稳定，对接口调用做 2 秒的超时限制，超过 2 秒则取消请求，并给出提示文案。

在无网时，本地若未搜索到则直接给出 未搜索到指定商品的提示。

四、收银与营销活动

4.1 商品、收银、营销

零售商品属于基础业务，要为收银、营销等业务提供数据。若抛开其他业务线，只谈商品是没有任何价值的。

最初有赞零售业务线尚未成形，营销活动与商品、收银互相耦合。随着营销业务增长，业务耦合的现状不能够满足的业务迭代与维护，因此进行了业务重构

• 划分商品、收银、营销活动业务为三个模块

• 离线数据库按照业务线进行划分并封装到业务模块内部

• 数据模型依赖关系解除

• 业务模块之间通信通过路由方法调用

一个解耦后的商品、收银、营销的业务模型

营销 -> 商品

营销唤起商品页面时，传入营销活动。商品页解析营销参数，调用营销模块远程接口，获取页面渲染数据与交互样式。

商品 -> 收银

在商品页选中商品后，判断是否有营销活动数据。若有营销相关信息，传回商品数据模型给营销页面。营销在商品模型基础上，添加营销详细数据，传给收银模块（购物车）。

收银 -> 营销

收银模块收到添加商品的请求，无营销数据则解析商品数据，组成为购物车数据模型。若有营销活动信息则通过营销数据请求营销接口，计算详细的营销信息，组装购物车数据模型。

4.2 营销活动组合门店商品

门店的营销活动与门店商品业务解耦，商品模块需要给营销活动模块提供门店商品查询的能力，营销活动模块组合门店商品与营销信息展示。

营销模块组装商品流程：

营销活动请求指定门店商品信息时，可能会存在门店商品尚未离线到本地。如果门店商品未拉取到本地，则请求服务器对应的门店商品数据，存储到本地后返回给统一返回给营销模块。

4.3 门店商品渲染营销 UI

在营销活动模块，启动商品模块的商品规格选择页面时。规格选择页通过不同的活动类型来渲染展示。

请求：商品信息、营销活动信息

{
  "pain_type" : "活动类型",
  "activity_value" : "活动信息json",
  "goods_value": {
    "price": 0,
    "property_price": 1,
    "amount": 0,
    "unit": "件",
    ...
  }
}

返回：营销渲染数据

{
    "sku_price" : "¥12.00",
    "total_price" : "¥12.00",
    "available_skus" : [12980,12121],
    "limited_amount" : 0,
    "info_content" : ""
`}`

五、展望

零售移动商品商品只是零售商品业务的部分，对于移动来说收银又是非常重要的一环。作为基础模块，经历两年的业务与技术沉淀，已基本覆盖线下门店商品管理、收银场景。后续重点在快速业务迭代同时，保证核心功能稳定；探索如何提升商家经营效率；完善商品的日志，问题快速响应。

本文转载自公众号有赞 coder（ID：youzan_coder）。

原文链接：

https://mp.weixin.qq.com/s/KUIoCuc5NsvlVe31cXvazw