背景2022年7月27日，《开放原子全球开源峰会》-OpenHarmony分论坛上，京东作为分享嘉宾，为大家带来了一场精彩的分享。京东积极拥抱OpenHarmony，参与OpenHarmony应用生态建设。分享中介绍了京东APP适配OpenHarmony的探索，重点介绍了京东跨平台解决方案奥兔太郎和京东MCube在OpenHarmony上的实践。其中，傲兔太郎框架是业界领先的跨终端跨框架解决方案，OpenHarmony开源项目组牵头成立了CrossPlatformUI-SIG。通过傲兔太郎，非常方便的开发、调试、发布鸿蒙和OpenHarmony应用，帮助开发者快速构建Harmony和OpenHarmony应用。京东MCube框架是京东自研的原生动态框架，覆盖京东应用金流程业务，赋能集团其他应用。目前正在与京东内部力量联合打造，尚未开源。精彩回顾京东App技术架构总监盖旭田讲解了京东App适配的复杂性以及在OpenHarmony平台上的适配进度。由于论坛分享时间有限，很多细节无法展示。傲兔太郎目前是一个开源项目。欢迎社区参与共建。应众多听众的要求，本文将详细介绍尚未在OpenHarmony开源的JDMCube框架的适配进展。01京东App适配现状分析我们从业务和技术栈的角度分析了京东App对OpenHarmony系统的适配情况。1.1业务多元化目前，京东App年活跃用户5.8亿+，超过90%的用户通过客户端下单。京东APP作为京东的主力应用，承载着京东集团各BG\BU的业务需求。业务形态繁多，需求迭代频繁。每个迭代版本承接业务方3000+需求。相应的研发团队有数千人的规模。在北京、上海、深圳、成都、南京等工作场所。在功能上，涵盖用户可见的复杂服务、用户不可见的底层能力、支撑App的周边生态。整体来看，京东App适配OpenHarmony涉及的团队和业务较多，适配难度很大。1.2技术栈的多样性我们来看看京东App使用的技术栈。京东App使用的技术栈也很多，主要有原生、H5&小程序、跨端，分别占55%、40%、5%（其中RN和Flutter占比较小，所以我不会介绍它们）。从原生代码量来看，小程序和H5占了很大的比重，原生代码行数已经达到千万级，而H5和小程序在app中有百万级的代码行，所以通过重写code适配OpenHarmony在短期内几乎是不可能的。目前，在原生开发方式方面，我们自研的京东MCube原生动态框架业务占比近50%，未来还将继续增加京东MCube的占比；H5&小程序目前主要使用我们的傲兔太郎框架开发。据分析，将京东MCube&AotuTaro适配到OpenHarmony，可以大大减少整个APP的适配工作量。02JDMCube动态框架简介JDMCubepanorama简单来说，JDMCube使用一套统一的DSL来描述UI和事件，在各个平台上解析映射到各个平台的UI控件，最后进行渲染和展示。具体可以参考我们之前发布的文章京东AppMCube动态实践。03京东MCube适配OH探索我们期望将JDMCube适配OpenHarmony，为京东集团内部应用快速迁移到OpenHarmony平台提供解决方案。3.1技术方案对比在适配之前，先回顾一下现有的OpenHarmonyUI框架。现有的UI框架分为两类：类WebUI范式和声明式UI范式。（JavaUI后面不会更新维护，就不介绍了）。Web-likeUI开发范式主要使用HML+JS+CSS构建UI页面和处理相关逻辑；声明式UI开发范式基于扩展TS语言（Ets）开发，开发方式更类似于Flutter，通过改变数据来改变UI状态。然后我们根据我们的MCube实现原理和OpenHarmony的技术专家进行了技术交流。他们提供了额外的选择，使用更底层的UI框架，使用C++相关的API来完成UI的创建，然后通过ETSXComponent组件完成渲染。我们分析了这三种不同的解决方案应该如何实施。1.Web-likeUI：要使用这个方案，OpenHarmony需要提供DomApi，类似于React的JSX，用于动态创建和更新Views。当数据发生变化，需要更新View属性时，开发者需要实现一个Diff机制来实现增量更新。2.DeclarativeUI：要使用该方案，OpenHarmony需要提供相关的Ets命令式API，用于动态创建和更新View。当数据发生变化，需要更新View属性时，Views仍然可以基于现有的状态管理机制来实现。的自动更新，开发者无需额外处理。3、C++API：采用这种方案，由于这一层的API还没有暴露给开发者，OpenHarmony需要提供相应的开发环境。在View更新中，开发者需要实现状态管理。并且由于该方案使用了比较底层的API，OpenHarmony的技术专家担心会对App和系统造成不稳定，所以不推荐该方案。基于以上分析，我们综合比较了开发友好性、组件丰富性、UI更新方式以及OpenHarmony技术专家的建议，最终选择使用声明式UI开发范式作为实现方案。3.2实施情况及阶段性成果通过与OpenHarmony技术专家的密切合作，我们使用Ets命令式API在临时SDK上完成了JDMCube模板解析->数据绑定->视图映射->渲染过程，同时实现了通过修改数据源驱动视图更新的逻辑。主要流程如下：详细关键步骤：1、外层容器（Column）首先创建一个容器。这里我们使用Column组件向工作线程发送模板文件解析命令，在工作线程中解析模板文件并生成ViewNodeTree之后，回调到主线程。数据更新后，触发容器的构建，内部解析ViewNodeTree。2.解析ViewNode->View每个ViewNode的名称对应一个视图解析器，用于创建对应的View，解析相关属性。ViewNodeTree的解析入口会递归解析ViewNodeTree，根据缓存判断是创建View还是更新已有View的属性。创建一个View，其实就是先构建一个Row组件，在内部调用解析方法将构建好的View添加到Row组件中，同时也添加到最外层的Column中。3.创建\更新View，属性赋值以FlexboxLayout和TextView解析器为例，通过命令式API创建对应的Flex和Text组件并设置对应的属性。这里需要注意的是，创建和更新场景对应的代码是一样的，区别只是是否添加到外层容器中。效果我们通过上面的流程把xml模板文件+JSON数据传过去，最后在开发版上运行，渲染出一个列表项。目前在OpenHarmony平台上，我们已经通过Demo验证了JDMCube框架适配OpenHarmony平台的可行性。后续还有很多工作要做。在与Android\iOS平台功能对接方面，我们自研的表达式解析引擎、二进制编解码、事件处理、模板管理、生命周期监控等方面还需要进行改造适配OpenHarmony平台。在性能优化方面，模板文件的解析效率和使用命令式API创建和更新视图的效率也是我们努力的重点。3.3后续规划大规模APP适配OpenHarmony是北向应用生态面临的重要课题。在技??术方面，京东将继续推动自研原生动态框架JDMCube和跨终端跨框架解决方案傲兔Taro适配OpenHarmony的进展。OpenHarmony应用程序生态系统蓬勃发展。
