有赞零售移动收银商品实践
文 | Alex、Siam
面对线下收银场景，针对商品收银业务，如何提升商家收银的效率？如何保证即使在弱网或无网条件下商家正常的收银？如何设计大量商品时搜索方案？如何对业务模块进行解耦和各种复杂的业务场景交互？都是在设计零售收银业务时，需要去认真思考的问题。 有赞零售移动团队在业务快速地迭代中，沉淀出商品收银的一套可行方案。
- 模块化设计
- 得益于零售移动的组件化框架，对业务线划分为店铺、交易、商品、营销等模块
- 路由负责页面跳转与组件间通信
- 私有化商品模块数据，商品模块提供查询接口
- 离线商品数据
- 客户端本地存储商品商品，即使在无网时，商家仍可正常收银
- 提供商品名拼音搜索、扫码枪的商品条码扫码能力
- 商品收银与营销活动
- 支持门店商品收银时营销活动的数据组装
- 支持不同营销活动时门店商品页面数据渲染
- 硬件支持
- 扫码枪、电子秤等多种硬件设备支持，提升商品搜索与收银效率
一、模块化设计
最初的零售移动多业务线共用本地数据库，调用时业务方式直接访问数据库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。 - 不支持多音字，两端均是取字库中的默认音。
一个理想的拼音库应该满足以下条件：
- 多端结果一致
- 转换速度快
- 内存占用低
- 转换结果长度可控
- 字库、词库可动态下发
基于JS引擎的汉字转拼音方案
在跨平台技术选型上，零售移动选择JS引擎解决两端数据一致性问题。JS引擎能够解析执行JS脚本，帮助移动端进行跨平台开发。业界流行的移动端跨平台方案如Facebook的ReactNative、阿里的Weex均是依赖V8（Android）与JSCore（iOS）的JS引擎实现的跨平台前端动态方案。iOS曾流行的JSPatch补丁库，亦归功于JSCore的优秀的动态化。
在执行速度上， V8引擎 将JS代码变为机器码并进行优化，加快执行速度。对于垃圾回收，V8 使用一种传统的分代式标记清除的方式去清除老生代的数据。
一个简化的汉字转拼音的流程 
流程中遍历商品名称，根据字在汉字拼音表中对应的拼音数量，判断是否为多音字。如果是多音字则查找字在多音字词语中的精准读音。
汉字拼音表
汉字与拼音的对应关系表。如果是多音字，则对应多个拼音。如
dict[0x96f6] = "ling"; /* 零 */ dict[0x91cd] = "zhong,chong"; /* 重 */
对于声调不同的多音字，如 扇 有 shàn 和 shān 两种声调，汉字拼音表只维护一个无声调的拼音 shan 。
dict[0x6247] = "shan"; /* 扇 */
因为拼音搜索时，不区分声调不同导致的多音字。
多音字词表
常见的多音词表格式
"阿Ｑ": [["ā"], ["Ｑ"]], "阿爸": [["ā"], ["bà"]], "阿鼻": [["ā"], ["bí"]], ...
使用上面格式的多音词表来判断多音字的正确读音时，要遍历整张多音字表，汉字常用有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 。
在确定多音字的读音时，只要找到多音字词表中该多音字对应的多音字读音即可。
多音字拼音的判断流程
现实生活瞬息万变，一个字的读音亦可能会发生变更，尤其是在互联网。多音字词表不能保证维护多音字的全部读音。在汉字的不同语境又是强上下文关联，也不能保证多音字拼音转换的准确性。
针对这种情况，多音字的拼音转换考虑笛卡尔积的形式生成拼音。 如 重庆的咖喱牛肉 ，假定多音字词表未收录 重庆 对应的拼音，根据 重 在汉字拼音表的中的多个读音进行拼装
chongqingdegaliniurou|zhongqingdegaliniurou|..
笛卡尔积的方式解决了多音字词表未匹配的问题。但是相应的增加了最终生成的多音字拼音的长度，对搜索速度会有影响。所以限制生成的拼音字符的最大长度的阈值。在使用笛卡尔积形式时判断生成的字符串是否超过指定的长度阈值，若有超过阈值的问题，则多音使用汉字拼音表中默认的拼音。
商品名拼音首字母
搜索除了拼音全拼，拼音首字母也是很常见的场景。不过有了全拼的解决方案后，拼音首字母相对来简单很多，只须在获取获取汉字拼音时，取到拼音的首字母后组合即可。
解决了商品名中文转拼音问题后，就可以愉快地进行搜索本地商品啦。
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 扫码枪搜索
扫码枪的场景
收银员在收银界面，使用扫码枪扫描商品条码或条码秤的 PLU 码，通过条码查找到商品，添加到购物车。
商品条码由一组规则排列的条、空及其对应代码组成，表示商品代码的条码符号。
与商品模糊搜索场景不同，条码可以确定唯一商品，所以扫码枪的场景为
- 扫码枪精确匹配对应条码的商品
- 相同商品不同厂商会多个条码（一品多码）
设计上采用商品搜索表满足扫码枪的快速搜索与 一品多码 的业务需求
商品搜索表设计
- 条码与商品ID映射
- 以条码字段创建索引
扫码枪的商品搜索流程 
商品未同步时的补偿机制
因为扫码枪搜索的是本地商品数据，在门店初次启动零售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" : ""
}
展望
零售移动商品商品只是零售商品业务的部分，对于移动来说收银又是非常重要的一环。作为基础模块，经历两年的业务与技术沉淀，已基本覆盖线下门店商品管理、收银场景。后续重点在快速业务迭代同时，保证核心功能稳定；探索如何提升商家经营效率；完善商品的日志，问题快速响应。
欢迎关注我们的公众号
About The Author
