如何打造移动端布局动态化
一、前言
在《如何打造移动端Hybrid框架》一篇中我阐述了四类移动端动态化方案。
动态化方案对比
其中布局动态化是一种应对交互不算复杂，对性能要求比较高的实现方案，接下来我们展开聊一聊这个话题，下面我将以问答的形式来层层剥开布局动态化的面纱。
二、问与答
问题一：为什么是布局动态化？
答：布局动态化主要应用为重展现，轻交互的场景，与RN或Flutter相比它给整个App带来的负担会更小，更稳定，而且性能也较高，实现的技术复杂度也适中，对于很多核心场景都适用。
问题二：为什么是Flexbox？
答：Web界的布局标杆，可适应各种复杂场景，已在Web界得到了充分的验证。
问题三：为什么是JSON？
答：JSON天生就是结构化的语言，看过RN源码的同学肯定知道，JSON和RN是浑然天成的，从实现的角度会极大缩减成本。
问题四：如何设计和实现？
答：我们可以把布局动态化拆分为对外接口层（创建和销毁逻辑的处理逻辑）、界面描述层（DSL的定义和数据绑定的实现）、界面展示层（界面适配的实现和事件交互的实现）、基础渲染层（布局管理的实现，渲染管理的实现和动画管理的实现）。
如何实现布局动态化
对外接口层
【1】创建和销毁的处理逻辑
我们在一个App里可能会有多处地方使用到布局动态化，首先我们需要在业务入口处增加RootView，并且和一个ViewManager的实例进行绑定，后续都由这个ViewManager实例来管理RootView的创建和销毁，从实践的角度来看建议一个ViewManager实例对应一个RootView实例。
界面描述层
【1】DSL的定义
DSL的定义首先要保障双端统一，一种取巧的方案是将RN的DSL定义迁移过来，但这里有一个不大不小的坑，就是RN在实现的时候，选择在JS层抹平双端的差异，这就导致我们需要将迁移过来的JSON定义双端抹平，我们选择的是遵照iOS的定义去抹平Android。
【2】数据绑定的实现
在实现的过程中，我们需要布局模板+业务数据+解析规则=布局和渲染的数据。
1）布局模板，一个JSON文件，会预置在客户端内并随包管理平台进行动态更新，它里边主要描述了这个界面的布局以及渲染的样式。
2）规则解析，布局模板里的JSON是无法被布局引擎和渲染引擎理解的，因为很多属性的值是依赖业务数据传过来的，这个时候需要使用递归，按照布局模板属性值里定义的a.b.c，在业务数据里按照层次关系进行查找，查找到值后再填充到布局模板的属性值里，进而得到一个布局引擎和渲染引擎能理解的JSON。
3）业务数据，就是我们平时业务开发中，服务器返回的JSON数据。
界面展示层
【1】界面适配的实现
1）长度，依赖系统原生机制，Android使用dp，iOS使用pt。
2）字号，依赖系统原生机制，Android使用sp，iOS使用pt。
3）图片，依赖系统原生的适配机制，Android适配mdpi/hdpi/xhdpi，iOS适配1x/2x/3x。
【2】事件交互的实现
客观上讲，布局动态化在事件交互上的动态性是比较弱的，需要预先定义好一些事件行文，如单击，双击等，RN的内部实现了大量的事件交互行为，我们可以直接复用，但需要自己定义行为，比如点击一个按钮要跳转到什么链接。
基础渲染层
【1】布局管理的实现
上边提到布局规范选择Flexbox，在实现上双端我们都选择了Yoga，各种Flexbox的属性支持的都比较好。
【2】渲染管理的实现
布局管理只能计算出view在界面的位置大小，真正显示出来要依赖渲染引擎，使用平台自身的渲染是最佳的，我们借鉴RN的思想选择使用系统原生view的渲染方式进行渲染。
【3】动画管理的实现
借鉴RN的思想实现并支持Frame动画，Spring动画，Decay动画。
三、结语
布局动态化的实现已经不是什么稀奇的技术，在行业内有比较成熟的做法，在设计和实现的过程中借鉴和参考RN的很多思想和实现，这既可以保障稳定性也可以高效快速开发，最后非常感谢Meta工程师们开源出RN这么优秀的框架，在过程中有一些代码思考和大家分享下。
1）RN的一个NativeView会和一个Manager进行绑定，在Manager中会清晰的找到NativeView的各种属性，包括重命名的属性，Android使用标注的方式，iOS使用宏的方式，个人觉着这样的好处是不用使用繁琐的文档来记录一个NativeView到底都有什么属性，有改动都在代码里呈现，也非常便于查找。
2）RN选择在JS层抹平双端JSON描述的差异是可以理解的，Android和iOS本来就是存在差异化的，有JS层必然会在这一层抹平，但如果能把JSON的描述也保持一致，在Android和iOS端做差异化处理，感觉这样会更好一些。
3）RN双端代码一致性还是很高的，这一点还是能看出Meta工程师站在更高角度去实现代码的功力。
