使用Taro开发鸿蒙原生应用——当Taro遇到纯血鸿蒙

Tech

01 纯血鸿蒙即将到来

在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！

在2023年8月的「2023年华为开发者大会（HDC.Together）」上，华为正式官宣「鸿蒙Next」，这个更新的版本将移除所有的 AOSP 代码，彻底与 Android 切割，使其成为一个完全自主研发的操作系统，这将去掉 40%左右多余的代码，使系统变得更加简洁、流畅。同时，会上也预告了将在明年 1 月份发布面向所有开发者的预览版，意味着还有一个多月纯血的鸿蒙就要与所有开发者见面了，这不禁令人热血沸腾，分外期待。

而近期关于鸿蒙的消息不断，各大互联网厂商，如阿里、美团、去哪儿、小红书等等，都已经官宣开展了开发 ArkUI 版原生鸿蒙应用的消息，同时也都在各个招聘渠道公开高薪招聘鸿蒙工程师和专家，仿佛偌大的鸿蒙生态即将全面铺开，这对于对鸿蒙适配呈观望态度的开发者来说无疑是巨大的强心剂，鸿蒙应用开发，似乎真的行了。

02   鸿蒙ArkUI是怎么个事儿？  

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

好了，吹了一波鸿蒙的彩虹屁，让我们来看看，鸿蒙应用开发是个怎么个事儿。

从鸿蒙官网我们可以了解到，鸿蒙应用开发使用方舟框架，即 ArkUI 框架，它支持两种方式，一种是使用 ArkTS，也就是声明式的开发范式，另一种是使用 JS，即类 Web 的开发范式，让我们来看看这两种开发范式的区别。

•声明式开发范式：采用基于 TypeScript 声明式UI语法扩展而来的 ArkTS 语言，从组件、动画和状态管理三个维度提供 UI 绘制能力。

•类Web开发范式：采用经典的 HML、CSS、JavaScript 三段式开发方式，即使用 HML 标签文件搭建布局、使用 CSS 文件描述样式、使用 JavaScript 文件处理逻辑。该范式更符合于 Web 前端开发者的使用习惯，便于快速将已有的 Web 应用改造成方舟开发框架应用。

可以看出，显然，Web式的开发范式较贴近Web前端开发者的习惯，不过，它更适用于开发简单的卡片应用，Taro框架已经提供了对这种开发范式的支持，可以查看 Taro && 鸿蒙、OpenHarmony开发文档，然而，对于大型应用的开发，声明式开发范式可能更为合适。

你会在下文的语法介绍中发现，声明式开发范式类似于 Flutter 和 Compose 的开发方式，它对 Web前端开发者来说可能需要一定的学习成本。但鉴于其适用于构建更高复杂度的应用，并且理论上的性能优于Web 式开发范式，鸿蒙将主要推广这种开发范式。

因此，对于我们这些有志于前端开发的青年来说，更应该关注鸿蒙的ArkTS——即声明式开发范式。

从声明式范式的架构图中可以看出，该架构主要采用了前后端分离的形式。在这个体系中，前端主要负责处理语法基础规范和 UI 组件等内容，这部分主要体现在 DSL 层。另一方面，后端则使用 C++ 进行开发，主要负责支持前端的语法范式、组件以及渲染管线。

此外，语言运行时则使用了华为自研的方舟编译器，支持 JS、ArkTS 和 C++ 的混写。值得注意的是，方舟编译器具备 AOT（Ahead-Of-Time，即预编译）处理能力，这使得它能够将应用代码转化为统一的字节码，然后再通过 AOT 转化为机器码，从而提升应用的性能。

在架构的下一层，系统会对接基于 Skia 的自绘渲染引擎。在这个过程中，终端的所有渲染需求都会统一提交给渲染引擎，从而使得渲染效果得到提升，这种设计理念不仅使系统在处理渲染任务时更加高效，同时也保证了渲染结果的高质量。

前面提到，声明式范式与类 Web 的开发范式大有不同，我们可以从下面这段代码感受一下。

熟悉 Flutter 和 Compose 的朋友们可以发现，声明式范式的 ArkTS 在 UI 描述上的写法与他们非常相似，而这段 ArkTS 代码也体现出与 Web 前端熟悉的 JS/TS 语言的不同，如定义自定义组件的 struct 关键字等等，在官方的解释中，ArkTS 是基于 TS 进行扩展的超集，所以这不就是最熟悉的陌生人么，这不禁让我们前端觉得”我又行了“。

03   Taro与ArkTS的联动  

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

由于声明式范式与类 Web 范式天然的不同，对 Web 前端来说学习成本还是有的，而且，相应的研发生态也得从零开始建设，之前我们沉淀的大量 Web 生态肯定是没法直接使用了，这对于前端转型 ArkTS 开发来说还是存在挑战的，那么有没有办法可以使用 Web 的开发范式，来开发 ArkTS 应用呢？这似乎就进入了 Taro 最熟悉的领域了，以 Web 的开发范式来统一各端开发。

前文提到，当前 Taro 已经支持了ArkUI 类 Web 的开发范式，这为我们沉淀了很多的经验，当然，ArkTS 是一种全新的语法，为了实现对它的适配，我还是有不少的工作需要去做。

经过对 ArkTS 语法的分析，其 UI 描述结构让人联想到 Flutter 三棵树中的 Widget Tree，那么我们首先想到的解决方案就是，将 React/Vue 运行时产生的虚拟 DOM，以某种形式递归映射为 ArkTS 的自定义组件树。基于 Taro 3.0 中适配小程序的经验，我们想到可以在 ArkTS 环境中模拟 DOM/BOM API，将虚拟 DOM 基于 DOM/BOM API 构建为 Taro DOM 树，然后再递归映射为自定义组件树，接着再走鸿蒙渲染。

在今年 8 月的「2023年华为开发者大会（HDC.Together）」上，Taro 团队受邀分享了 Taro 适配鸿蒙 ArkUI 的技术方案，整体技术路线是受到认可的，同时在后续的适配过程中也得到了来自华为的技术支持，让我们的适配工作得以顺利进行。

目前，基于上述思路，Taro React 适配鸿蒙 ArkTS 的工作已经进入收尾阶段，预计将在 12 月下旬发布可用版本，想要了解进展的朋友可以查看这篇文档，根据相应分支来 follow 我们的进展，有条件的朋友也可以自行尝试调试。

04   总结与展望  

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。    

是不是有种突然结束，戛然而止的感觉？哈哈哈，本文是 「Taro 适配鸿蒙 ArkTS」系列文章的第一篇，算是先导预告片，在后续我们会陆续释出其他文章，例如详解 Taro 适配鸿蒙 ArkTS 原理、Taro 开发 ArkTS 应用最佳实践、Taro 性能优化利器-半编译技术介绍等等，向社区介绍 Taro 的最新成果。

鸿蒙 ArkUI 的整体设计笔者觉得是超前的，声明式范式、自绘渲染等等，吸收了近几年业界移动端技术的优点，如果开发调试、研发生态等配套设施能够跟上业界领先的移动端开发解决方案，还是大有可为的，期待鸿蒙 Next 为国产操作系统书写新的篇章。

推荐阅读京东流水线——满足你对工作流编排的一切幻想
Java浅拷贝BeanUtils.copyProperties引发的RPC异常京东广告算法架构体系建设——高性能计算方案最佳实践|京东零售广告技术团队大文件上传实践分享

求分享

求点赞

求在看

打造SAAS化服务的会员徽章体系，可以作为标准的产品化方案统一对外输出。结合现有平台的通用能力，实现会员行为全路径覆盖，并能结合企业自身业务特点，规划相应的会员精准营销活动，提升会员忠诚度和业务的持续增长。▪底层能力：维护用户基础数据、行为数据建模、用户画像分析、精准营销策略的制定

▪功能支撑：会员成长体系、等级计算策略、权益体系、营销底层能力支持

▪用户活跃：会员关怀、用户触达、活跃活动、业务线交叉获客、拉新促活