京东换肤系统赋能实践

原创李亚奇田创新京东零售技术

背景

京东换肤，经过两年的演进发展，多次支持11.11、618的大促，以及为用户提供个性化换肤，各项功能已趋近完善。业务发展的同时，我们也在考虑如何提升平台通用性，并且尽可能为其他APP提供相同的能力。为更进一步的发展，节效赋能也成为我们的重要任务。于是我们提出了对换肤PaaS化，为需要此项功能服务的站点提供平台服务，以减少重复搭建平台，避免资源浪费。

调研分析

提出构想后，我们进行了调研分析，首先需要判断目前的方案是否已经存在，并且目前存在的方案是否存在一定的弊端，我们是否可以进行优化互补。

一、我们首先对京东主站现有View更新技术方案进行梳理分析。目前的方式是接口动态下发，前端进行View的更换，各个模块使用自己单独的接口配置，主要用于业务处理。流程图如下：

这种方式主要用于各模块的个性化打标服务，且各个模块之间比较独立，当然这样的模式有一定的优势，会更加精细化，也方便独立模块的处理。服务端的压力也会被分散。但是缺少统一性，在大改版或者一些重要的节日氛围控制上不能形成统一，需要调动各个模块一起配合。

二、在我们调研其他APP时，发现其他站点目前并没有对应的系统来支持统一换肤服务。

在梳理现有服务及调研其他APP后，我们觉得提供统一换肤服务的必要性。

系统设计

了解到优缺点，我们决定在对应的方面进行互补，提供统一平台，对于样式统一且固定的View进行下发统一管理，并且进行本地缓存，当有新的View需要变更，我们就更新本地的缓存文件，然后通知业务进行更新操作。

仅仅是这样，并不能使我们的平台更加的通用。针对主站，我们依赖已有的基础功能可以轻松做到，但是，如果接入集团其他站点APP，我们目前已有的功能，并不能快速的接入。于是我们需要对现有的基础功进行梳理，进行SDK抽取，为集团其他站点接入提供便利。

总结以上：

针对不统一问题。我们以整套皮肤维度进行控制，方便整个UI的统一性。考虑到各个模块的个性化，皮肤又以模块维度进行分解，各模块相互独立，并针对各模块进行过权限划分，方便各模块管理。
针对其他站点接入问题。我们梳理现有换肤系统基础功能，并对现有功能进行SDK抽取，形成组件化，方便其他站点接入。
支持范围确定。梳理目前使用到的控件，对相关属性，背景，动画等基本属性都进行支持，确保覆盖到每个组件。
暗黑模式支持。随着暗黑模式的普及，主站也已经完成暗黑模式的开发工作，那我们的View属性也需要支持暗黑模式。
省流模式。数据本地化存储，用于提升系统UI更新速度，方便复用。接口的请求时机也需要考虑，当配置后台有新的数据配置时，重新下发数据。完善资源文件管理，不重复下载，清除无用资源文件。

在经过总结讨论，我们初步完成了整个换肤系统的整体设计：

我们来了解一下整体的架构：

首先CMS后台支持创建新应用，会分配新应用的唯一标识符code，我们使用code来区分不同站点的应用，应用创建成功后，会有一套默认的皮肤生成，默认皮肤就可认为是应用当前使用的皮肤，针对应用，我们可以创建出很多用途不同的素材，包括Text及属性、Image及属性、lottie、file文件等等。创建好素材后，会自动关联到每个皮肤，每个皮肤都可以使用已经创建出来的素材，设置好素材属性就可以在应用中使用对应素材code的数据了。如果你的应用想支持多个皮肤切换使用，你只需要再新建多个皮肤即可。

其次素材配置中，如果你的应用支持暗黑模式，你在配置素材的同时可以进行暗黑素材的配置，暗黑素材的配置会在你配置创建素材时自动生成，暗黑魔术素材数据会随着这套皮肤正常模式一块下发，同时也会存储到本地数据库中，方便暗黑模式和正常模式的快速切换。素材配置可以进行版本控制。

最后SDK的功能是支持个原生APP的换肤功能，SDK会根据CMS生成应用code进行请求皮肤数据，默认的皮肤可以使用生成的皮肤code，也可以使用0代替，在请求到数据后，会识别需要下载的文件下载并存储到本地，比如图标、lottie文件，下载完成后，统一进行数据库存储，然后通知各个模块的View更新操作。

至此，整个换肤流程设计完成。

具体实现

系统的整体规划已完成，但是具体到每个点仍然需要认真的考虑。既要满足操作者方便操作，又要优雅的完成客户端整体UI的替换。