2019 年，华为 HarmonyOS 横空出世，历经4年千锤百炼，面向智能家居、智慧办公、智慧出行、运动健康、影音娱乐 5 大场景，自研代码量从 492 万行增长到 2396 万行，API 从 3493 个增长到 16000 个，几乎同步实现了近 4 倍的增长。

华为终端 BG 软件部总裁龚体发布鸿蒙开发套件

HarmonyOS Design：为 HarmonyOS 应用开发提供一致的体验设计规范及高效设计工具；设计资源免费开放，支持开发者快速调用；ArkTS：全新声明式开发语言，兼容 JS/TS 语言生态、扩展了声明式 UI 语法和轻量化并发机制，简洁高效，进一步降低跨端应用开发代码量，开发效率提升 30%；ArkCompiler：优化编译运行机制，缩短动态类型语言应用启动时间；多种源码保护技术，保障动态类型语言源码安全；ArkUI：升级渲染机制，简化界面渲染算法；创新 Stage 开发模型，避免了后台进程无序侵占系统资源；逻辑和 UI 分离技术，提升流转开发效率；开发（DevEco Studio）、测试（DevEco Testing）及应用上架（AppGallery Connect）工具：配套声明式开发体系全面升级，实现高效开发、快速测试、一键上架分发。

这其中，最能让开发者眼前一亮的有三个字“声明式”，对，就是那个开发者梦寐以求的开发模式。

声明式 UI 范式

可以看出，“声明式”开发更接近人类语言，具备更高的可读性、易学习性，并且代码简洁可重用、编码高效好测试。

举例来说，要炒一道菜，“命令式”要一步步地指挥洗菜、切菜、放油、下锅、加料、翻炒、盛盘；而“声明式”要表达的是想炒一道菜，程序便自动调用相关的 API，寻找这道菜的最佳工艺并执行。

随着 AI 驱动的自动化编程技术的发展，“声明式”从理想成为现实，并且正在成为趋势。

正是看到了这样的趋势，结合自身的积累，HarmonyOS 向“声明式”开发，正式开拔。

要进行“声明式”开发，根在编程语言。在最关键的编程语言转型为“声明式”后，与之配套的应用开发全生命周期的工具，自然要同步转型，遵循同样的语法规则，方能形成合力。

此次发布的声明式开发语言 ArkTS 是 HarmonyOS 的主力应用开发语言，它基于 TypeScript 语言体系扩展了声明式 UI 语法和轻量化并发机制，增加了一些语法糖的能力，让跨端界面开发和并行化任务开发，高效简洁，使应用开发效率提升 30%。目前，基于 ArkTS 语言的 API 已达 10000 ，基本能满足当前应用开发场景的使用需求。

事实上，ArkTS 语言并非一门全新的语言，而是作为 TypeScript 语言的增强型语言，因此兼容 JS 语言和 TS 语言的生态。总体来说，ArkTS 主要增强了这几个方面的能力。

实现了简洁自然的描述机制：ArkTS 做了一些自定义能力的增强，比如可以自定义组件，实现了组件化机制。自定义组件，可以被别的自定义组件所引用，形成新的更高级的组合型组件，这样我们就可以把业务应用中使用频次高的复杂的几个组件，直接定义成一个组件去重复利用，这对开发效率的提升显而易见。响应式多维状态管理：通过定义一个状态，实现在组件级、页面级甚至全局的状态触发。这就方便了在应用编程时，根据需要再进行触发，因为 ArkTS 提供的是响应式 UI（声明式 UI 本质上也是响应式 UI），而响应式 UI 的界面刷新是根据状态来进行触发的。这种模式有利于进行状态管理和定制。动态组合：可以在运行时进行动态创建、组合内容，并且可以直接引用到另外的运行时中。

在这里，分享一个数字：相比传统的 HTML CSS JS 的类 Web 范式，同样的任务，ArkTS 代码量有超过 50% 的减少。

Stage：全新的规范化进程管理开发模型

在声明式之外，还有一点吸引到我了——Stage 开发模型，可谓是 ArkUI 中的一大创新。

ArkUI 的本意实现“一次开发，多端部署”，提升开发效率和设备性能。具体的实现方式有三。

一是跨设备界面开发能力，这是鸿蒙一直在持续构建的能力，不再赘述。

二是升级了整体渲染框架。传统的渲染，由三棵树来完成，经过反复的尝试后，鸿蒙实现了一棵树来完成，同时把多节点组合模型变成了单节点 属性组合模型。这些架构的调整，对应用开发者来说，是不可见、透明的。这顿操作之后，ArkUI 提升了界面加载性能——渲染速度提升 20%，渲染内存降低 30%，渲染指令降低 20%。

三就是 Stage 这个“新生儿”。

之所以推出 Stage 模型，是因为在上一代移动操作系统中，大多数的设备后台管理比较混乱。Stage 模型提供了系统对进程数量配置、后台服务定义、后台服务拉起等的统一纳管，从而使应用能够更好地组织在一起。目前，Stage 模型支持两种模式，一种是 JS 语言层的实体类 UIAbility，另一种是鸿蒙提供的一组系统类 Extention Ability。应用如果希望调用系统提供类似服务的话，不再需要自己写一个 Service，而是自己继承派生出一个基于 Extention 类的自有类，通过这种方式拉起相关的服务。

Stage 模型

这样管理起来之后，后台的常驻程序可大幅减少，从使系统资源更加有序。

同时，Stage 模型实现了将逻辑与UI解耦。意思是，使用 Stage 模型时，可以让逻辑段代码和 UI 段代码在分离的物理设备上运行，这无疑强化了鸿蒙程序流转的能力。

多设备应用模型归一、Stage 内置的框架可以实现秒级的自动恢复，则进一步强化了 Stage 模型在进程管理方面的优势。

与传统的编程开发模式相比，Stage 模型实现了碾压，预计后续会逐渐成为鸿蒙的主流模式。

鸿蒙开发套件，还有非常多值得深挖的地方，受限于篇幅，我们这次对鸿蒙开发套件的初步观察就先到这里。

鸿蒙开发套件总览

最后，我们想说的是，做开发工具不容易，做覆盖开发全生命周期的全链路开发工具更不容易。更进一步，能同时做操作系统和全链路开发工具的，放眼全球，更是屈指可数。

鸿蒙操作系统 开发工具双轮驱动的鸿蒙生态的未来，值得期待。