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

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

模块化设计
1. 得益于零售移动的组件化框架，对业务线划分为店铺、交易、商品、营销等模块
2. 路由负责页面跳转与组件间通信
3. 私有化商品模块数据，商品模块提供查询接口
离线商品数据
1. 客户端本地存储商品商品，即使在无网时，商家仍可正常收银
2. 提供商品名拼音搜索、扫码枪的商品条码扫码能力
商品收银与营销活动
1. 支持门店商品收银时营销活动的数据组装
2. 支持不同营销活动时门店商品页面数据渲染
  硬件支持
  扫码枪、电子秤等多种硬件设备支持，提升商品搜索与收银效率

一、模块化设计

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

按照业务线将数据库进行拆库
业务 Module 统一数据访问的入口
路由调用方法

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

单个数据库职责更单一，清晰明了，耦合降低
商品模块统一各个业务线访问商品数据的入口。
商品业务或底层数据变更时，其他业务线无须关心数据模型变更
各个业务组件之间数据通过 JSON 或商定好的协议进行数据传递

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

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

线下门店与线上网店不同，在弱网或无网条件时，仍需要保证商品收银可用。
本地商品搜索效率上来说要比只依赖与网络接口请求要高效很多
门店收银要涉及到对接硬件的场景，在这些场景下，离线数据也有天然的优势

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

保证尽可能少的数据传输量
同步任务启动时机：网络重连后要进行数据同步等
同步任务尽可能地简单高效，便于维护
服务端数据变更后能够实时同步到客户端
同步数据的一致性与稳定性

二、离线商品同步设计

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

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

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

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

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

基本的同步过程：

移动端读取本地最新同步时间，根据时间请求服务端
服务端下发增量数据
客户端对比本地时间和增量数据的时间，判断是否已拉取最新数据
如果本地已是最新数据，停止同步；否则继续增量拉取数据，重复步骤1

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

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

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

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

2.2 同步任务触发时机

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

APP在用户登录后
断网重连后
用户在商品页，手动触发同步

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

2.3 长连接同步

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

IM 消息接收流程

发送方发送消息，经过服务器转发；
对于在线的接收方，选择推送消息；
在线推送失败或离线接收方，消息持久化到离线库；
当接收方重新连接时，主动拉取去离线消息；

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

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

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

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

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

好处

商品数据变更实时性能够保证
业务线只关心消息类型，无须处理复杂消息长连接的问题
商品数据持久化一致性能够得到保证

不足

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

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

三、门店商品搜索

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

门店商品的模糊搜索。在商品页面可以根据商品的拼音全拼或首字母模糊匹配商品数据
门店使用扫码枪设备时，支持商品扫码的精确匹配

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

在页面设计时，对于输入框使用 TextView(Android)替换。
自定义支持英文字母和特殊符号的软件盘

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

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

3.1 商品名中文转拼音

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

iOS 与 Android 的转换的拼音不一致，如 女：Android 转换为 nv；iOS 转为 nu
不支持多音字，两端均是取字库中的默认音

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

多端结果一致
转换速度快
内存占用低
转换结果长度可控
字库、词库可动态下发

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 商品搜索表设计

条码与商品 ID 映射
以条码字段创建索引

扫码枪的商品搜索流程：

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

创作场景

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