鸿蒙开发套件，打造鸿蒙世界技术底座

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 的答案是理念牵引，实干支撑。华为终端 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 类的自有类，通过这种方式拉起相关的服务。鸿蒙开发套件总览最后，我们想说的是，做开发工具不容易，做覆盖开发全生命周期的全链路开发工具更不容易。更进一步，能同时做操作系统和全链路开发工具的，放眼全球，更是屈指可数。鸿蒙操作系统+开发工具双轮驱动的鸿蒙生态的未来，值得期待。