您现在的位置是:首页 > IT基础架构 > 软件与服务 >

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

2022-11-07 13:45:22作者:来源:CSDN

摘要2019年,华为HarmonyOS横空出世,历经4年千锤百炼,面向智能家居、智慧办公、智慧出行、运动健康、影音娱乐5大场景,自研代码量从492万行增 ...

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 模型实现了碾压,预计后续会逐渐成为鸿蒙的主流模式。

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

鸿蒙开发套件总览

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

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

 


(本文不涉密)
责任编辑:wangyan

站点信息

  • 运营主体:中国信息化周报
  • 商务合作:赵瑞华 010-88559646
  • 微信公众号:扫描二维码,关注我们