2019 年，华为 HarmonyOS 横空出世，历经4年千锤百炼，面向智能家居、智慧办公、智慧出行、运动健康、影音娱乐 5 大场景，自研代码量从 492 万行增长到 2396 万行，API 从 3493 个增长到 16000 个，几乎同步实现了近 4 倍的增长。
如果说代码量衡量的是 HarmonyOS 自身研发实力，开发工具则意味着对开发者的赋能功力。
在日前举行的 HDC 华为开发者大会 2022 上，HarmonyOS 的多项举措，让我们看到了华为的那股子“向上捅破天，向下扎到根”的精神，通过打造自研开发工具和“根技术”能力，描绘出了鸿蒙世界的蓝图。
开发者四大痛点
从 HDC 现场分享的数据里，可以看到，2019-2022 这四年里，HarmonyOS 已累计收集到 10 万余条开发者问题反馈。这个数字显示出开发者对 HarmonyOS 的期待与改进。
投我以桃，报之以李。我们欣喜地看到，HarmonyOS 也以极大的表现回报开发者的热情。
首先，HarmonyOS 将这些千头万绪的问题分析归类，最后归结为效率、性能、成本、安全四个方面。
效率方面：跨端应⽤开发代码能否进⼀步简化；跨端应⽤调试能否更⽅便……
性能方面：JS/TS 应⽤性能容易受硬件资源限制；进程⾃拉起持续存在，容易引发应⽤卡顿……
成本方面：⼤型应⽤多⼯程管理成本⾼；多设备应⽤⼯程开发成本⾼……
安全方面：JS/TS 源码容易被反编译，安全度低……
问题摆在这儿了，HarmonyOS 要如何解决呢？
理念+实干，HarmonyOS 开发套件解忧开发者
HarmonyOS 的答案是理念牵引，实干支撑。
理念只有区区 24 个字：“⼀次开发，多端部署”“可分可合，⾃由流转”“统⼀⽣态，原⽣智能”，却蕴藏着大内涵。
万物互联时代，设备终端数以百亿计，每个终端都是一个节点，但开发者并没有必要为每个终端单独开发应用和服务。“⼀次开发，多端部署”就意味着通过一套工程、多端部署，同一特性、多端运行，一套界面、多端适配，就以意味着在最大程度地帮助开发者提升效率和获得回报。
而如今的大型应用，其代码量动辄上千万行。把所有要修改的地方都开发完，再去测试和上架，周期之长，可想而知。于是，小步快跑、渐进迭代成为开发者的首选项。在鸿蒙看来，在开发态，“可分”即为应用按照优先级拆分为 HarmonyOS 原子化服务，每个服务都可以独立开发和上架；“可合”让 HarmonyOS 原子化服务按需组合成为 HarmonyOS 应用，而且每个原子化服务可以共享生命周期管理，这样做对开发效率的提升有目共睹。同时，在运营态，可以做到跨端迁移、“自由流转”，比如手机接听的电话在上车以后可以无缝流转到车机上，跑步时手机播放的音乐可以无缝流转到智能手表上，这才是真正做到应用的自由流转了。
HarmonyOS 统一了华为的硬件设备底座，同时还兼容 OpenHarmony 生态，做到统一建设一个大的鸿蒙生态。不仅如此，开发者也能选择原生的开发框架或者第三方框架开发，与第三方生态共建共荣。同时，依托华为在智能方面的积淀，在芯片层，HarmonyOS 帮助应用提升性能、降低功耗；在应用能力开放层，HarmonyOS 将自然语言交互、计算视觉、情景感知等能力以 SDK 的方式开放出来，开箱即用；在服务能力开放层，帮助开发者精准触达用户，实现商业闭环。这一切，我们看到的是“统⼀⽣态，原⽣智能”。
在这三大理念的牵引下，HarmonyOS 对设计、开发、测试、分发 4 个阶段的应用开发全生命周期，进行了彻头彻尾的改进和提升，一口气推出了包括设计工具、编程语言、编程框架、编译器、IDE 等“鸿蒙开发套件”七件套大礼包，诚意满满。
HarmonyOS Design：为 HarmonyOS 应用开发提供一致的体验设计规范及高效设计工具；设计资源免费开放，支持开发者快速调用；
ArkTS：全新声明式开发语言，兼容 JS/TS 语言生态、扩展了声明式 UI 语法和轻量化并发机制，简洁高效，进一步降低跨端应用开发代码量，开发效率提升 30%；
ArkCompiler：优化编译运行机制，缩短动态类型语言应用启动时间；多种源码保护技术，保障动态类型语言源码安全；
ArkUI：升级渲染机制，简化界面渲染算法；创新 Stage 开发模型，避免了后台进程无序侵占系统资源；逻辑和 UI 分离技术，提升流转开发效率；
开发（DevEco Studio）、测试（DevEco Testing）及应用上架（AppGallery Connect）工具：配套声明式开发体系全面升级，实现高效开发、快速测试、一键上架分发。
这其中，最能让开发者眼前一亮的有三个字“声明式”，对，就是那个开发者梦寐以求的开发模式。
声明式开发：HarmonyOS 技术路线转型之基
HarmonyOS 从“命令式开发”全面转型“声明式开发”，意料之中。
对于“命令式”“声明式”，开发者们并不陌生。
所谓“命令式”，顾名思义，程序按部就班地听从“命令”去执行，没有自己的思想，不智能，只会遵循开发的规范，被动去执行。执行得好坏、效率高不高，与开发者本身的技术能力关联度很大，要写出让机器如何去做事情（how to do）的代码，也就是说基本取决于开发者的代码“水平”。现在大部分程序开发都是走的这条路。
而“声明式”则大有不同，是对开发模式的一次变革——比 GitHub 的 Cloplite 辅助工具通过函数注释生成代码的方式更进一步，只要“声明”我想要什么样的结果（what to do），程序就调用相关的 API，自主设计执行路径，以达到预期的结果。可以看出，“声明式”让程序具备一定的智能，开发起来能有效降低门槛，提升效率。
可以看出，“声明式”开发更接近人类语言，具备更高的可读性、易学习性，并且代码简洁可重用、编码高效好测试。
举例来说，要炒一道菜，“命令式”要一步步地指挥洗菜、切菜、放油、下锅、加料、翻炒、盛盘；而“声明式”要表达的是想炒一道菜，程序便自动调用相关的 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 模型实现了将逻辑与UI解耦。意思是，使用 Stage 模型时，可以让逻辑段代码和 UI 段代码在分离的物理设备上运行，这无疑强化了鸿蒙程序流转的能力。
多设备应用模型归一、Stage 内置的框架可以实现秒级的自动恢复，则进一步强化了 Stage 模型在进程管理方面的优势。
与传统的编程开发模式相比，Stage 模型实现了碾压，预计后续会逐渐成为鸿蒙的主流模式。
鸿蒙开发套件，还有非常多值得深挖的地方，受限于篇幅，我们这次对鸿蒙开发套件的初步观察就先到这里。
最后，我们想说的是，做开发工具不容易，做覆盖开发全生命周期的全链路开发工具更不容易。更进一步，能同时做操作系统和全链路开发工具的，放眼全球，更是屈指可数。
鸿蒙操作系统+开发工具双轮驱动的鸿蒙生态的未来，值得期待。
