近年来，移动互联网的发展日新月异，各种新技术如雨后春笋般出现在我们面前。这促使我们不断学习和吸收，以赶上移动互联网的浪潮。在这里，我们想和大家分享一下JD.COM上海移动团队在动态解决方案上的一些探索经验和实践经验。
前言
随着原生业务的不断增加，各端需要不断投入人力进行开发迭代，尤其是6.18、11.11等时期。当电子商务的需求蓬勃发展时，人力也日益捉襟见肘。而且原生客户端的包大小会随着服务的增加而不断增加，一些低权重的服务会因为客户端的包大小限制而继续下线，在H5或者RN实现。同时，需求方对用户体验的要求也很高，不接受体验降级的情况时有发生。此外，原生开发需要遵循版本，导致在线业务周期长。考虑到以上因素，我们在2018年底开始研究如何让业务在线独立于分销，在多个平台上快速动态上线，尽可能接近原生体验，减少各端人力的持续投入，遏制套餐规模的过度增长。带着这一系列问题，我们开始了对整个客户端框架的一步一步的探索、调查和构想。并与项目、产品、前端、后端协同，追求风格灵活组装、动态数据绑定、高性能渲染的目标。
设计思路
本章主要从以下几个方面介绍：为什么要定制语言协议，控件，模板是什么，分析三步走的流程，整体看基本完整的流程。
01
为什么要定制语言协议？
首先，我们要做一个能满足以下三点的框架：
*跨平台：同时支持iOS、安卓和H5。
*动态发布：发布活动不需要更新客户端版本，通过拖拽可视化界面和后台数据进行绑定，三个终端可以直接获取页面数据并显示。
*低成本：发布或修改页面可以使用可视化平台配置样式和绑定数据，无需开发干预。
然后，我们对技术的选择做了大量的研究。现在我们来分析一下流行的ReactNative和Flutter是否能满足我们的要求。
反应性的
由JS和React编写，SDK翻译成原生页面，定位是为了提高开发效率，支持动态发布，但是需要开发人员的介入，通过一个完整的开发周期来开发和修改页面需要很长时间。同样，Flutter也需要开发和编写代码，目前Flutter还没有更好的动态发布方案。
综上所述，上述框架并不适合我们的需求。因此，我们首先放弃了使用开发语言编写活动页面，考虑了定制语言协议的方案(使用JSON数据交互语言描述视图结构)。最后，我们开发了一套构建块定制语言协议(Domain
特定语言
以下简称DSL)，它可以清晰地表达布局的交互，视图、文本、图片等控件的显示，让非技术人员在GUI页面上统一操作视图界面，生成协议结构，然后发布活动，可以直接在手机上显示。
* Control:表示控件的类型，用于抽象对应的虚拟树节点。
*布局：表达空间布局的方式。例如：绝对布局、线性布局、灵活布局等。
*样式：表示控件样式，决定当前控件对应的坐标、背景色、边框、字体颜色、字体大小。
*事件：表示当前控件绑定的事件，如点击、双击、长按等。
*寻址：指示与控件关联的数据。为了将样式与数据分开，控件和数据之间的连接是通过寻址建立的，相应的数据占位符逻辑也反映在这个属性中。寻址后的数据传输规则将根据具体的控制类型来确定。
02
控制
我们将所有显示单元称为控件。对于可以控制交互和布局的容器控件，
原子的可表示单位称为元素控制(如文本、图片等)。)，可以容纳容器、视图或元素的载体称为视图控件。控制的值是从数据寻址字段到数据层获取的，从而实现了DSL和数据的分离(下面的每个节点都是我们的控制)。
03
模板是什么？
我们称之为可重用显示单元模板。是模板DSL的子集，模板被提取并放置在模板集中，从而确保高效的重用并减少DSL的发布。(上图红色虚线环绕模板，三个区域复用同一个模板)。
04
“三步走”过程分析
页面或楼层的显示需要DSL和数据。为了更好地表达DSL和数据的分离，我们首先从大结构中确定根、图和数据，其中根代表默认样式占位符，图代表模板的集合，数据代表DSL关联。
的数据，最终统一由root，data，map确定一个页面、楼层显示的最主要结构。上面的图示是我们框架的主要解析流程，可以简单的称之为“三步走流程”。第一步首先明确容器控件类型（平铺、滑动、轮播等）；第二步根据数据寻址向data获取容器对应的多帧数据，然后开始遍历每一帧数据，通过每一帧数据对象内的模板标示符向模板集合找到对应的模板；第三步对模板进行逐层递归扫描，对每一个控件进行数据寻址、绑定，生成虚拟对象。
05
整体看积木的完整流程
运营和产品使用可视化界面配置活动，拖拽控件，生成DSL；通过后台解析DSL和数据绑定,生成页面数据；三端获取页面数据，经过三端渲染引擎框架viewkit解析，再通过上面介绍的“三步走“解析流程进行抽象生成虚拟对象，然后对虚拟对象解析渲染，生成对应的视图，最后显示到手机端。
架构设计
* 业务层：该层次是对外沟通的一个媒介，可以根据当前页面的业务形式替换相应的控件，实现一系列接口便于处理埋点、统一跳转、网络请求、图片下载等事件（接入方APP对接viewkit SDK的时候，注册进来对应的回调组件，当有相应的事件触发的时候分发到对应的回调组件去处理）。
* 逻辑层：提供注册组件管理、模板处理、生命周期触发、复用、版本管理降级、网络和图片的统一处理等，通过以上管理模块，可以做到样式和楼层的复用，模板的增删改查操作，视图的初始化、销毁等，数据的寻址。
* 抽象层：DSL和数据分别分发到模板管理和数据层管理之后，开始虚拟抽象，通过数据寻址找到对应的模板，之后逐层递归扫描生成布局、容器、视图和元素控件，并通过寻址找到数据，解析绑定，进而抽象生成虚拟树。
* 显示层：主要对虚拟树内的结点进行压缩合并，虚拟对象转换成实体控件，创建生成图层，和整个视图的复用更新服务。
01
模板的管理策略
为了能够更好的管理模板，我们把模板统一存储管理，可以直接增删改查，供虚拟抽象使用，然后讲一下具体的管理方法。
* 虚拟抽象层通过模板标示符获取模板时，首先通过模板标示符到内存中查找对应的模板，如果找到则直接返回，找不到则去本地模板库去查找。
* 本地模板库会初始化一些常用的模板和控件等，当运行内存中没有找到就到本地库去查找，找到后和版本做对比，如果匹配则返回模板，并保存在内存中，方便下次再次获取该模板，如果模板没有找到或者没有匹配版本，则去服务器拉取，成功则本地库保存，然后输出模板，否则直接返回错误。
* 为了防止内存过快的增长，我们制定了一套垃圾回收规则（当接收到内存不足、程序进入后台、程序关闭的通知时，我们会把缓存都清除掉）。
02
事件是怎么处理和分发的
事件需要寄托在控件上，抽象虚拟控件的时候，同时对事件就行抽象，当对虚拟控件转换视图的时候，虚拟事件也会在这个时候进行相应的转换添加，下面就对一份事件的处理和分发流程做下分解。
* 首先我们对事件结构信息和对应的数据信息进行校验，不符合标准直接返回失败，此事件不再添加到对应的虚拟控件上。
* 如果校验成功，则对事件进行抽象生成虚拟事件，同时绑定到对应的虚拟控件上。
* 当遇到用户触发（点击、双击、长按等事件），则把对应的事件信息分发到业务层注册的组件上进行处理；如果需要进行页面更新则回调给积木SDK。
03
DSL和数据解耦
为了将DSL中的模板进行复用，我们把相同模板抽取一份，然后统一放到模板集合里，使业务数据与模板进行解耦分离。而解耦之后随之而来的问题是我们如何在业务数据中寻找装填模板所需要的数据。对于模板中每个节点需要的数据，我们通过数据寻址来标记在数据中的寻址路径。而不同业务展示的相同信息存在字段不一致的情况，所以这个路径必须是与业务无关的值，这样可以达到模板的高度复用。为了解决字段不一致这个问题，需要后台进行处理，来解决这个差异。例：一个商品详情模板所需展示数据为商品图片、商品名称及商品价格。
在可视化平台需要将二者映射关系配置说明，由后台将业务数据进行加工，得到前端展示所需要的数据。映射关系如下：
04
如何优化性能
* 高复用：大部分跨平台技术方案拥有动态性、研发效率、多端一致性等优势，但是性能方面都会比原生要差些，所以往往跨平台技术的性能优劣便成为核心指标。在不同的iOS和Android设备上，要显示成千上万个楼层和区域视图，如果不停的创建则生成千上万个对应的视图对象，内存很快会被耗尽，要想保证在有限的内存上高效的运行，就是最大限度的去复用。我们分别从楼层、DSL几个维度去做复用，页面内的楼层复用则采用楼层级别的复用池去公用不在当前页面显示的楼层，如果通过DSL生成的视图，就用DSL复用管理类依照页面复用的原理去管理DSL公用视图，这样就能做到区域视图的复用，当需要获取视图进行页面显示时，将虚拟视图传入到复用池中，复用池根据虚拟视图中的标识符判断内存缓存中是否有该视图，有则直接返回视图，无则创建视图，传入内存缓存，然后返回视图，对视图复用池的内存缓存采用垃圾回收机制，当超过设置的触发临界点(内存缓存大小超过设置值)，则进行视图的释放操作，需要移除的视图用LRU和LFU算法综合进行判断。（LRU算法：最近最少使用算法，使用时间距离现在最久的那个被移除。LFU算法：最不常用算法，一定时间段内使用【次数（频率）】最少的那个被移除。）
* 降流量：通过DSL和数据解耦，能够更大程度的去复用公用的DSL，避免重复的样式下发，减小用户流量的损耗，缩短了从下载数据、解析、渲染、页面呈现给用户的时间。
* 优化节点：现阶段，积木的样式是通过拖拽和配置产生的，因为视图可以嵌套，会遇到嵌套层级过多的问题，为此，我们进行了相应的优化。我们在初始化视图阶段，将去除不影响显示的视图过滤（如设置了透明背景的View），减少视图的层级，从而减少了渲染时间和复用后重绘视图的时间。
05
降级容灾
在建站初期，我们采用“渐进增强”的开发策略，先使用SPA的技术方案引入viewkit-
react包的方式实现快速交付。随后在初代版本上“添砖加瓦”，逐步完善功能。
在 APP 侧带给用户积木原生展示的同时，我们也同时在 H5
端实现同样一套积本解析流程，做到了“一处配置，三端可用”的活动配置体验，当线上原生SDK出现问题或者随着版本的迭代老版本的SDK包不能满足最新功能时，H5能够快递的上线，从而达到了快捷的降级容灾。
应用案例
经过积木团队和上下游团队的共同努力，当前积木已使用于京东主站和国际站项目。
积木在京东主站使用楼层方式接入，即积木楼层和原生楼层混合使用，国际站使用全页面方式接入，接入方有泰国站和印尼站。
结束语
以上是我们在移动端探索实践的动态化方案，已经在商城通天塔和国际站(印尼、泰国)平台得到了落地和实施，未来我们继续努力不断追求创新，和业界同行们一同探索，摸索出更适合电商平台的动态化布局方案。
