2019 年，华为 HarmonyOS 横空出世，历经4年千锤百炼，面向智能家居、智慧办公、智慧出行、运动健康、影音娱乐 5 大场景，自研代码量从 492 万行增长到 2396 万行，API 从 3493 个增长到 16000 个，几乎同步实现了近 4 倍的增长。
HarmonyOS 自研代码量和 API 增长数据
如果说代码量衡量的是 HarmonyOS 自身研发实力，开发工具则意味着对开发者的赋能功力。
在日前举行的 HDC 华为开发者大会 2022 上，HarmonyOS 的多项举措，让我们看到了华为的那股子“向上捅破天，向下扎到根”的精神，通过打造自研开发工具和“根技术”能力，描绘出了鸿蒙世界的蓝图。
开发者四大痛点
从 HDC 现场分享的数据里，可以看到，2019-2022 这四年里，HarmonyOS 已累计收集到 10 万余条开发者问题反馈。这个数字显示出开发者对 HarmonyOS 的期待与改进。
投我以桃，报之以李。我们欣喜地看到，HarmonyOS 也以极大的表现回报开发者的热情。
首先，HarmonyOS 将这些千头万绪的问题分析归类，最后归结为效率、性能、成本、安全四个方面。
· 效率方面：跨端应⽤开发代码能否进⼀步简化；跨端应⽤调试能否更⽅便……
· 性能方面：JS/TS 应⽤性能容易受硬件资源限制；进程⾃拉起持续存在，容易引发应⽤卡顿……
· 成本方面：⼤型应⽤多⼯程管理成本⾼；多设备应⽤⼯程开发成本⾼……
· 安全方面：JS/TS 源码容易被反编译，安全度低……
问题摆在这儿了，HarmonyOS 要如何解决呢？
理念+实干，HarmonyOS 开发套件解忧开发者
HarmonyOS 的答案是理念牵引，实干支撑。
HarmonyOS 生态理念
理念只有区区 24 个字：“⼀次开发，多端部署”“可分可合，⾃由流转”“统⼀⽣态，原⽣智能”，却蕴藏着大内涵。
万物互联时代，设备终端数以百亿计，每个终端都是一个节点，但开发者并没有必要为每个终端单独开发应用和服务。“⼀次开发，多端部署”就意味着通过一套工程、多端部署，同一特性、多端运行，一套界面、多端适配，就以意味着在最大程度地帮助开发者提升效率和获得回报。
而如今的大型应用，其代码量动辄上千万行。把所有要修改的地方都开发完，再去测试和上架，周期之长，可想而知。于是，小步快跑、渐进迭代成为开发者的首选项。在鸿蒙看来，在开发态，“可分”即为应用按照优先级拆分为 HarmonyOS 原子化服务，每个服务都可以独立开发和上架；“可合”让 HarmonyOS 原子化服务按需组合成为 HarmonyOS 应用，而且每个原子化服务可以共享生命周期管理，这样做对开发效率的提升有目共睹。同时，在运营态，可以做到跨端迁移、“自由流转”，比如手机接听的电话在上车以后可以无缝流转到车机上，跑步时手机播放的音乐可以无缝流转到智能手表上，这才是真正做到应用的自由流转了。
HarmonyOS 统一了华为的硬件设备底座，同时还兼容 OpenHarmony 生态，做到统一建设一个大的鸿蒙生态。不仅如此，开发者也能选择原生的开发框架或者第三方框架开发，与第三方生态共建共荣。同时，依托华为在智能方面的积淀，在芯片层，HarmonyOS 帮助应用提升性能、降低功耗；在应用能力开放层，HarmonyOS 将自然语言交互、计算视觉、情景感知等能力以 SDK 的方式开放出来，开箱即用；在服务能力开放层，帮助开发者精准触达用户，实现商业闭环。这一切，我们看到的是“统⼀⽣态，原⽣智能”。
在这三大理念的牵引下，HarmonyOS 对设计、开发、测试、分发 4 个阶段的应用开发全生命周期，进行了彻头彻尾的改进和提升，一口气推出了包括设计工具、编程语言、编程框架、编译器、IDE 等“鸿蒙开发套件”七件套大礼包，诚意满满。
华为终端 BG 软件部总裁龚体发布鸿蒙开发套件
· 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，自主设计执行路径，以达到预期的结果。可以看出，“声明式”让程序具备一定的智能，开发起来能有效降低门槛，提升效率。
声明式 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 模型实现了碾压，预计后续会逐渐成为鸿蒙的主流模式。
鸿蒙开发套件，还有非常多值得深挖的地方，受限于篇幅，我们这次对鸿蒙开发套件的初步观察就先到这里。
鸿蒙开发套件总览
最后，我们想说的是，做开发工具不容易，做覆盖开发全生命周期的全链路开发工具更不容易。更进一步，能同时做操作系统和全链路开发工具的，放眼全球，更是屈指可数。
鸿蒙操作系统+开发工具双轮驱动的鸿蒙生态的未来，值得期待。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
