Wukong 动态化组件能力实践

导读

在哈啰的APP中，活动、大促、周年庆等都需要我们能够拥有更快捷的响应速度、更高效的人力来缩短试错周期，而且流量区域运营位为了能够做到千人千面，又迫切的需要有一种可以根据不同的人群达到展示不同效果的目的。UI 可定制化、快速迭代、高性能体验一直以来都是移动端开发领域的核心诉求，随着哈啰业务的不断拓展，越来越多的业务线对上述三点提出了更高的要求，但由于移动端 App 发版的天然限制，无法很好满足业务方的诉求。

基于以上一些业务痛点，我们结合 Native 黄金流量业务区域对于性能极高的要求，输出了一套 Native 局部动态化方案 Wukong（悟空），截止到目前，已在App内部多个业务模块中得到验证。

Wukong 是什么

悟空动态卡片 (Wukong) 最初是为哈啰投放系统定制的 Native 高性能渲染引擎，是一套完整的跨端原生局部卡片动态展示的技术解决方案，以业务赋能为中心，致力于解决UI定制化、逻辑动态化、缩短试错周期、提升人效等相关问题，使得业务可以基于 Wukong 做到一次开发，随时上线，多端复用的效果。

技术优势

Wukong 在标准UI组件、JS 动态能力、样式支持等方面提供多种功能加持，同时支持自定义组件、自定义 JS Bridge的能力以满足更复杂、更加定制化的业务场景。

• 支持 UI & 逻辑 动态发布，提高研发&运营效率
• 原生页面内嵌动态化视图的接入方式，接入成本低
• Android / iOS 双端侧表现一致，支持实时预览，所见即所得
• UI渲染纯 Native 实现，体积小、性能好、内存少

系统介绍

Wukong 遵循了 CSS3 中提出的 Flexbox 布局规范，旨在磨平多平台在布局系统上的差异，为了达到一套模板双端一致的效果，对 Android 和 iOS 端组件样式的表现也进行了尽可能的统一，在开发方式上我们选择 XML 作为视图 DSL 的语言格式，同时定义了一整套的 xsd 规范来约束 XML 的编写，辅助开发编写过程中提前规避一些语法问题的同时也能更加容易进行入门使用。

如上图所示，在开发的过程中主要处理的是业务层相关的逻辑，模版的下载、缓存、校验，在 Wukong 内部有一套默认的实现，但并不是必须的，接入方完全可以根据自己的业务场景来进行覆盖重写，对于模版产物的管理是一个相对隐私的操作，为了达到最大化的灵活度，需要由业务接入方来扩展。

其中 SDK 内部我们设计了协议层，在初始化的时候来对接各种可插拔的能力，比如：自定义组件、自定义Bridge，同时将 SDK 内部的一些基础能力如：网络、埋点、路由、位置信息、设备信息等进行接口抽象，使得业务接入时可以方便的代替为自定义的通用基础能力。

实现原理

如果用比较通俗易懂的方式来介绍 Wukong 的大致实现原理，可以简单的理解为按照一定的约束规范编写的样式描述映射为 Native 的布局，从而达到样式逻辑动态化的效果。

通过 SDK 加载的流程如上图所示：

首先需要输入一个产物的链接地址和业务数据源，SDK 内部会通过模版管理模块来下载保存在服务端的模版，同时会对相关数据进行缓存（包括磁盘缓存和内存缓存），在拿到产物之后，通过解析器的处理会被映射为 VM（ViewModel） 对象，VM对象中包含了所有原始信息以及需要解析的 JS 表达式，为了将 VM 和 具体的View进行解耦，在 VM 和 View 之间还增加了一层 VNode 虚拟节点层，此时在生成 VNode tree 的时候，JS引擎会参与工作执行并获取 JS 表达式的结果，最终再将生成的 VNode tree 通过 Render 渲染为 Native 的 View tree。以上流程为初次加载的过程，当二次加载的时候，会优先使用缓存模版（包括磁盘缓存和内存缓存），同时，VNode tree 中通过 diff 计算差异来进行局部的更新，以达到性能的最大化。

其中有两个较为重要的环节：布局系统和JS引擎。对于布局系统来说，从能力、性能等多方面的对比考量，同时考虑到两端布局一致性以及降低开发者的学习成本，决定选择使用实现了 FlexBox 规范的三方库 Yoga作为我们的布局引擎，Yoga 作为一个通用的布局系统，来代替 iOS 上的 AutoLayout 和 Android 的 FlexBoxLayout，以此来保证既能拥有前端亲和性，也能达到多端表现一致性。由于 iOS 本身已经支持 JavaScriptCore，而 Android 则需要同时兼顾性能以及对于包体积的影响，所以采用 QuickJS 作为 SDK 底层的 JS 引擎。

研发工具

为了方便开发者快速的入门、开发、调试，同时保证模板的正确性和一致性， Wukong 为开发者提供了多个开发提效配套工具。在开发过程中采用的是工程化的管理方式，每一个工程都会包含一个 build 目录，用来存放生成的产物，通过脚本工具，可以初始化工程、解析工程、开启实时预览 Server，在一个工程中同时可以包含多个子工程，以便于在不同的动态卡片模版中快速实时的切换。

开发工具采用 VSCode，通过 xsd 和 lib.wukong.ts 的约束，更加便捷的做到代码补全和联想功能，配合实时预览工具，大大的提升整体的研发效率和研发体验。实时预览可以做到边开发边看效果的能力，在达到所见即所得的同时，其中的相关日志调试信息，也会同步的输出到控制台中，以便于研发人员跟踪排查问题。

研发流程

基于以上工具，我们将整个的研发流程尽可能的做到简单化、标准化：首先通过脚本来创建标准的项目工程或子工程，以防止代码管理上的混乱。在 VSCode 中编写模版代码，通过约束工具来达到代码解析前的合规化校验。使用脚本工具在工程中启动 Server，同时控制台中会输出当前链接到 Server的设备 log 日志信息。客户端通过预览工具连接 Server 达到实时预览的能力。修改相关代码后，再次通过脚本重新解析指定工程或子工程，预览工具会同步更新为最新的样式。最后一步就是将 build 目录中生成的产物配置到自己的管理后台，从而达到在线发布的能力。

发布流程

在正常的 APP 迭代节奏中，需要 Android / iOS 各一名研发人员参与其中，同时还需要经过联调、测试、验收、接口发布、APP发布、数据回收等一系列的流程，周期过长，同时如果发布之后线上发现问题，还有可能会延迟到下个版本的发布周期，响应速度慢，无法很好的承接运营业务诉求。通过局部动态化能力，首先对于客户端来说相比之下仅需要一名研发参与需求模版的开发，减少了研发人力，其次也无需等待APP的发布周期，验收完成之后，可以在线实时更新，在保证原生用户体验的基础上不依赖发版、高效支撑业务需求，大大缩短业务研发和数据回收的时间周期，新功能也可在任意线上版本中生效，产品验证和推广更高效。

总结和展望

Wukong 从创建之初到现在历经一年多的开发维护时间，中间遇到过各种不同的需求和技术问题，在团队伙伴的集思广益之下才逐渐成型，再次表示由衷的感谢。目前 SDK 在哈啰APP首页、钱包、个人中心、搜索等业务中广泛使用，业务研发整体提效 50%，尤其对于投放系统，在高流量运营区域位活动研发提效达 80%，随着 Wukong 使用场景的逐渐增多，在技术上我们会不断丰富能力，持续优化整体性能，进一步降低学习和使用成本，提供更完善的配套设施，同时也希望各领域的专家，能够提出宝贵的建议共建共创，协助我们通力打造一个更加稳定、易用且完整的局部动态化能力技术生态。

相关链接：

• GitHub: https://github.com/hellof2e/Wukong
• Wukong DOC：https://hellobike.yuque.com/org-wiki-nlsyth/hec0gc/mput57lpnz...
• layout：https://yogalayout.com/
• quickjs：https://bellard.org/quickjs/