【第2169期】盒马中后台跨端方案探索

前言

看本文之前可以先了解下 Design Tokens，【第2043期】Design Tokens —— 设计与开发碰撞的火花。今日前端早读课文章由阿里@景庄授权，公号:Alibaba F2E授权分享。

正文从这开始~~

开始前，我们首先来看一下，业界在移动化办公与多平台设计上的一些趋势。随着无线网络和云计算等基础设施的成熟，移动设备呈现爆发式增长。已经有越来越多的企业级产品开始拥抱多平台设计，移动化办公的概念已经深入人心。

华为在 2019 年发布了鸿蒙操作系统，希望借助鸿蒙系统打造以人为核心，万物互联的流畅体验。鸿蒙设备支持多终端的能力共享；应用只需一次开发，就可以多端部署；让用户能够实现跨设备和场景的一致交互和智能协同。

苹果早在 iOS 8 上就发布了一个称为 Hand-Off 的功能，通过 Hand-Off 功能，用户可以在苹果设备间实现跨设备的任务协同，例如用户可以直接在 Macbook 编辑的文档里，选择插入将刚刚使用 iPhone 拍摄的照片。

在企业应用领域，SAP 的 SaaS 产品支持跨平台使用。SAP 构建了一套智能化的多端设计体系 Fiori，可以低成本的面向多种类型的设备设计、开发、交付现代企业应用，但遗憾的是，它的方案比较封闭，并没有开放给外部使用。

同样，在实体零售数字化的背景下，盒马面临的是全新的 to B 体验命题。盒马尝试在人货场数字化的基础上，面向消费者，提供精准的人货匹配与全新的消费体验；面向作业者，则是构建全新的数字化流程，借助于多类型的智能化作业设备，为员工在多样化的业务场景下提供简单高效的作业体验。因此，我们需要重新思考和定义中后台的体验边界。

在盒马，我们面临的是更加多元化的中后台场景，既包括总部营运管理，门店经营管理，还包括配送作业，仓储作业等等。在这些多元化的作业场景中，得益于数字化作业体系的建设，员工可以借助，多类型的智能作业设备的各项能力，来辅助完成工作，例如大屏，打印，通知，定位等等。所以，我们认为新型作业场景下，作业人员将更多的依赖多类型的智能设备的协同，辅助完成作业任务。

盒马多端作业任务的主要载体是盒马工作台，盒马的各类作业角色围绕工作台来展开工作。因此盒马工作台就是一个庞大的新零售操作系统，面向不同的角色提供不同的能力，例如仓储管理，物流管理，CRM等等。依托于多端工作台，体验技术团队需要做的就是让各类作业角色简单高效一致的完成作业任务。

因此，我们首先要解决的是，如何面向多端工作台选择设计研发交付方案。通常有两种选择，要么是面向多端分别提供独立的方案，要么是多端统一方案。对于多端多套方案而言，无需考虑多端的差异化，但会导致开发维护成本高，交付效率低；对于多端统一方案而言，需要解决多端的差异化适配，但在此基础上可以获得一致的开发体验，并且交付效率高。考虑到业务上普遍的跨端协同作业需求，以及开发者常常需要同时负责多端的开发。我们选择的是多端统一的设计研发交付方案，从而为工作台用户提供简单高效一致的跨端作业体验。

对于建设多端统一的方案，我们需要解决三大问题

• 首先是，如何用一套设计系统支持差异化的设备与场景

• 其次是，如何用一套组件架构支持组件的跨端复用

• 最后是，如何用一套应用架构支持应用的跨端联动

从而形成，一码多端，多端体验一致的中后台跨端体验解决方案。

下面，具体来看一下我们是如何思考和解决这些问题的。

问题1：如何用一套设计系统系统支持差异化的设备与场景

首先来看第一个问题，如何用一套设计系统支持差异化的设备与场景。

传统设计系统大多解决单一设备的体验需求，跨设备的设计系统方案往往是独立的，例如国内社区主要的中后台开源设计系统AntD 和 Fusion， 都分别提供了独立的 PC 和 Mobile 的设计系统方案，并且不同的端通常由不同的设计开发团队支持，在 Design Token 的命名和组件 API 设计方面都存在较大的差异。导致跨端应用开发成本高，跨设备体验难以统一。

这种面向单一设备提供设计系统的方案，带来了跨端体验分裂。随着新型作业设备的出现，就需要不断的投入额外的设计开发资源，一方面带来了多端设计体系的分裂，另一方面导致开发投入大幅提高，并且难以保障跨端一致的用户体验。因此，我们认为中后台场景需要有统一的跨端设计系统方案。

此外，传统设计系统通常只考虑单一场景下的用户体验，不考虑环境的影响。但在盒马，还有门店档口，配送站，大仓等多样化的作业场景，不同作业场景在空间、光线、湿度、使用者姿势方面存在较大差异，统一的标准化 UI 已经不能满足用户在差异化环境下的作业体验诉求。因此我们认为，设计系统还需要综合考虑作业场景下的环境因素的影响，以改善不同作业场景下的实际作业体验。

我们来看一个盒马门店营运作业中的多端体验问题的例子。在门店作业中，营运 Pad 和 餐饮 Pos 是两个主要的作业设备，两者屏幕尺寸均为 11 寸，分辨率均为 1920 * 1080，均为手势操作。对于跨端设计系统而言，我们可以依据屏幕的尺寸和交互方式来确定不同设备中界面元素的大小，但是，我们发现，在实际的作业场景中，餐饮 Pos 的界面元素往往比营运Pad大出很多。那么，是什么导致了这种系统界面的设计差异。

我们不妨来分析一下原因：营运 Pad 一般在门店作业中为手持移动操作，作业视距通常在 50-60cm，主要的作业用途是经营管理和数据看板。而餐饮 Pos 一般则为静止摆放，不可移动，小二为站立姿势操作，作业视距通常为 70-80cm，主要作业用途为餐饮结算等。在这种情况中，餐饮 Pos 上往往会需要更大的可操作区域，以便进行更舒适的操作。所以，跨端设计系统需要综合考虑到实际的作业姿态，作业视距，和作业意图。

我们再来看一个配送站叫号屏在不同空间环境下的体验问题的例子。叫号屏在配送站中用于展示配送的队列信息，配送员根据叫号信息领取包裹进行配送。通常叫号屏的最佳阅读视距为 1.2m - 3.6m，但盒马有 200+ 的门店配送站，在光线条件和可读范围上存在一定的差异，很多配送站无法满足标准视距的要求，导致相同 UI 在不同空间环境下的信息的传达效率和用户体验存在差异；所以，我们需要具体分析一下空间环境对用户体验的影响。

我们可以选择两个配送站点进行具体的空间环境差异分析。例如亲橙里店配送站，其空间为狭长型，正常视距为 1.2m - 4m，地下室无窗，环境偏暗；星光大道店配送站为四方形，正常视距为 1m - 3m，有窗，光线条件正常。那么，我们是否可以基于视距范围和光线条件，为不同类型的配送站提供差异化的 UI 方案，具体包括可调整的布局，可调整的栅格尺寸，可调整的字号序列，可调整的色彩模式等。所以我们认为设计系统需要能够基于差异化的空间环境因素进行适配调整。

综合上面两个例子，我们可以从场景环境中解构环境变量。具体包括：设备类型差异，例如屏幕尺寸、使用视距等；作业类型的差异，例如信息密度，反馈模式等；使用环境的差异，例如光照湿度等；以及系统类型的差异。进而我们可以基于环境变量推导和计算设计变量，通过设计变量映射视图变化。

加公式这样，我们就可以建立基于环境变量的 Design Tokens 计算流程。这个计算过程其实就是对设计师的经验的数字化，并通过拟合公式化的设计规则函数来计算 Design Tokens 在不同设备或场景下的具体值。

在此基础上，我们开发了跨端 Design Token 的配置与生成系统，用于面向具体的设备和场景做验证和优化。用户可以输入设备类型、屏幕尺寸、使用视距、信息密度等等参数来生成整个设计系统的 Design Tokens 值，还可以便捷的预览跨端组件的变化。

基于这套跨端设计的思考路径，我们面向盒马中后台构建了全场景的跨端设计系统。它包括基于环境变量的 Design Token 计算逻辑；支持面向不同场景下的设备输出主题包；并面向应用层提供高对比模式，宽松模式，弱光模式等等设计系统模式。从而建立差异化场景和设备上的一致用户体验基础。

问题2：如何用一套组件架构支持跨端复用

第二个问题是，如何用一套组件架构支持跨端复用。

我们认为中后台跨端场景面临的是更加复杂的组件适配问题。对于移动端跨端场景而言，通常解决的是多类型的移动设备的跨端适配问题，需要面对的是多尺寸的手机屏幕，系统主要是跨 iOS 和 Android，在设备能力上也通常较为相近。但对于中后台的跨端场景而言，面对的是更加多样化的作业设备，屏幕尺寸的差异化范围更大，从 1.5 寸的 watch 到 55 寸的 tv 屏都有，系统平台更加多样化，设备能力难以对齐。为此，在建立了统一的跨端设计系统的基础上，我们还需要解决的是如何面向多类型作业设备，提供更加可扩展可复用的跨端组件方案。

跨端组件还需要解决差异化设备的交互适配问题。传统中后台场景以键鼠设备为主，但在盒马，触摸类设备已成为线下场景中的主要作业设备，例如我们前面提到的营运 Pad 和 餐饮 Pos 等。此时，我们就需要考虑组件在不同设备上的交互适配问题，例如选择器组件，在传统的键鼠设备上通常是局部区域的下拉弹层，使用鼠标点选；而在触摸设备上，则会采用全局弹层，支持用户进行手势滑动操作。因此，跨端组件需要解决面向设备的交互方式的自适应问题。

我们尝试对组件实现进行分层拆解。通常可以拆分为三个部分：视图样式层，用来提供组件的视图结构与外观样式；行为逻辑层，处理用户行为，例如鼠标键盘手势事件等等；状态逻辑层，管理组件内部的状态，通常是多端一致的，不涉及到跨端的适配问题。因此我们认为，组件跨端的重点应该是在复用状态逻辑基础上，实现视图样式与行为逻辑的跨端可用。

对于跨端组件的实现方案而言。通常大部分的组件实现都是以视图为中心，在视图代码中同时耦合状态管理和行为管理的代码逻辑，当功能变的复杂，并且需要处理跨端多重事件机制时，组件实现中就会耦合大量的事件处理代码，以及多重的视图判断逻辑，这个时候，组件的可扩展性和可维护性就会受到挑战。此时，我们可以将状态管理和行为管理逻辑中视图逻辑中解耦出来，建立以模型为中心的组件实现方案。

对于面向模型的跨端组件实现方案，我们可以通过拆解组件实现中的视图代码，行为逻辑代码，状态管理代码来解耦组件跨端实现的复杂度，在复用状态管理代码的基础上，进一步扩展视图代码和行为管理代码的跨端表达能力。例如图中的 Select 组件，我们通过将其拆分为多个独立的 Hooks，来重新组合实现组件的跨端逻辑；最终形成行为驱动状态，状态映射多端视图的组件实现方案。

我们可以具体来看一下面向模型的跨端选择器组件的实现。useStyleProps 为样式 Hook，用来计算和返回样式相关的属性值；useSelectState 为状态 Hook，用来管理组件的内部状态；useDevice 为设备 Hook，用来进行设备类型的探测；useSelect 为行为 Hook，用来处理行为，计算视图层的属性值；最终组件返回响应式视图。这样，我们就可以通过分层 Hooks 的组合来构建可扩展可维护的跨端组件集。

在确定了面向模型的组件实现方案的基础上，我们还需要更加轻量灵活的响应式视图方案。传统的视图代码，通常以值为中心进行样式实现，并且需要编写复杂的媒体查询代码。为此我们在 HTML Elements 基础上扩展了 System Elements， 用来提供原子化的视图层跨端表达能力。之所以叫 System Elements，是因为它遵循了社区的 System UI 规范进行样式命名空间的定义。System Elements 以 design token 为中心，提供了标准化的样式属性集，内置支持 Design Token 传值，还可以便捷的声明元素的响应式变化。

并且这套响应式视图方案还可以支持按需生成 CSS 代码，与传统的全量生成 CSS 代码相比，没有类名覆盖与优先级顾虑，这种原子化 CSS 的方案为应用层代码提供了更多的优化空间。

考虑到与应用层结合，组件层提供了基于 React Context 的组件跨端自适应方案 -- SystemProvider。SystemProvider 由几部分构成，分别是：用于支持主题自定义的 ThemeProvider，用于支持设备上下文感知和获取的 DeviceProvider，用于实现色彩模式切换的 ColorModeProvider 构成。借助于 SystemProvider，应用层可以快捷的控制内部组件的跨端表现。

简单总结下跨端组件方案，我们认为可复用的组件实现 = 视图 + 行为 + 状态。在视图方案上，提供了System elements 响应式视图方案；在行为方案，封装了 usePress 等屏蔽端的事件差异的行为 Hooks。在状态管理方案上，封装了 useListSate 等支持跨组件复用的状态管理 Hooks。在此基础上去构建一套代码，多端可用的跨端组件方案。

问题3：如何用一套应用架构实现设备间的跨端联动

最后一个问题是，如何用一套应用架构实现设备间的跨端联动。

在盒马的新型作业场景下，越来越多的需求，需要建立应用的跨端联动体验。例如对于门店小二而言，既需要在 PC 上进行数据录入，任务管理等；也需要通过手机进行移动审批，发起即时消息；还需要通过 RF 进行商品拣货，调拨，盘点等。所以对于这些跨设备的作业任务，不仅需要支持应用的跨端运行，还需要支持应用状态的跨端联动。

我们来看一个盒马门店巡检数字化的例子。对于传统的巡检流程而言，通常依赖人工检查，借助纸质清单逐条排查问题，例如商品陈列和员工操作规范等等，最后进行统一录入汇总。对于数字化巡检而言，巡检员可以在手机上即时接收任务，并通过手机摄像头对问题进行拍照验证；批量录入则可以切换回 PC ，同步手机应用的表单状态继续录入，这样可以极大提升巡检效率。所以，我们认为新型作业场景需要建立应用的跨端联动作业体验。

因此，基于业务上的诉求，我们构建了多端复用与跨端联动的应用架构。对有跨端需求的应用而言，其差异主要是在视图层上，多端视图依赖的业务数据模型通常是相同的。因此，可以将应用分为 应用容器层、数据模型层、跨端视图层 三层。应用容器层提供统一的容器 API，屏蔽底层差异；数据模型层包括业务数据服务和应用状态管理，并支持应用状态的远程持久化；跨端视图层则用来面向不同端提供差异化视图。总结而言，跨端应用方案提供了 应用视图的跨端可用，应用数据模型的跨端复用，和应用状态的跨端同步。

对于应用的跨端联动而言，数据模型层需要支持跨端复用与状态的跨端同步，可以借助具体的代码片段进行解释，图中 service 文件为多端共享的数据服务定义；store 文件为应用状态定义，可以进行数据服务的访问与状态的修改；还可以通过 App.sync 进行应用状态的远程持久化，而不再依赖于具体的业务后端去做应用的草稿态保存，从而支持多端视图的跨端联动。

跨端应用还需要支持跨设备的路由切换方式适配，提供与设备匹配的页面切换交互。以点击列表项打开详情视图为例，在 PC 页面上，通常采取的是侧滑打开详情页；而在手机上，受屏幕尺寸限制，通常为堆叠打开详情页面。对此，应用框架支持开发者通过响应式数组的方式快捷声明跨设备的视图切换方式，开发者可以通过响应式数组的方式快捷定义跨设备的路由切换方式；数组的第一个元素对应最小断点设备使用堆叠视图，数组的第二个元素则对应下一阶段断点开始使用侧滑视图。

我们不妨通过一个演示片段，对跨端组件和应用的方案做个一个简单的总结。跨端组件支持按照不同的设备类型进行 UI 和交互的自适应，跨端应用则可以支持跨设备的页面级交互的自适应。

总结

盒马中后台跨端体验解决方案内部的产品名为 ReX Design For OS，我们来回顾下产品的里程碑，我们最早在 18 年的 9 月推出了 1.0 版本，当时面向多端提供多套方案；此后，我们便开始考虑多端融合的一体化方案，在 20 年的 6 月发布了 2.0 版本，跨端组件支持 PC/Pad/Pos/Phone，以及跨端应用和容器方案；为了给中后台跨端作业场景提供极致作业体验，我们已经在着手打造全新升级跨端体验解决方案，并预计在 21 年 3 月发布，包括一码多端的组件和应用方案，以及完善的配套能力。

最后，我们通过一张图快速回顾下盒马中后台的跨端体验解决方案。主要包括 基于环境因子生成 Design Token 的设计系统部分；实现视图、行为、模型分层的跨端组件部分；以及多端视图共享数据模型和支持状态远程持久化的跨端应用部分。还包括工程基建，多端容器，消息中心，状态同步中心，和多端体验大脑等配套设施。

对了，最后还一件事！我们计划在 21 年 6 月，将盒马中后台一码多端的核心方案对外开源。

关于本文 作者：@景庄 原文：https://mp.weixin.qq.com/s/-1PpjJyKiA63SifRbr5swg

为你推荐

欢迎自荐投稿，前端早读课等你来