ArkUI,更高效的框架设计

HarmonyOS开发者社区 2022-12-21 10:44:53

 原文:ArkUI,更高效的框架设计,点击链接查看更多技术内容。

 

 上期文章我们讲到了ArkUI的三大特性,同时提到了ArkUI是一套用于构建HarmonyOS应用界面的UI开发框架,本期我们将从架构设计上来聊聊ArkUI的设计理念。

 

ArkUI架构图

 

从架构图可以看出,ArkUI的设计理念是在端到端整条技术路径设计上建立了一整套完整的分层机制。接下来我们依次分层为大家介绍。

 

ArkUI框架的“前驱”——【前端层】

 

前端层

 

架构的第一层【前端层】又称【声明式UI前端】,这一层包含了上期文章介绍的极简的UI信息语法规范,UI组件以及ArkTS语言特有的状态管理机制。

 

 独立的封装

 

此外,ArkUI对常用的UI组件的结构、样式、事件三大属性进行了独立的封装,内置于SDK中。开发人员可以根据项目设计需求,调用与设计匹配的组件函数,传入相应的参数来完成UI描述。

 

声明式UI信息语法

 

同时使用声明式UI信息语法,可以让数据和View进行联动更新,华为自研语言ArkTS为这种联动刷新提供了多维度的状态管理机制,开发人员通过对数据进行注释标记,合理控制数据对应View的更新作用范围。

 

 三种更新方式

 

如: 只单独更新、父子单向更新,父子双向同步更新等。

 

到这里,第一层【前端层】就介绍完毕了。

 

ArkUI框架的“核心部分”——【核心层】

 

接下来我们来到了框架的第二层【核心层】。

 

核心层

 

这一层主要包含两部分【方舟编译运行时】和【声明式UI后端引擎】。

 

方舟编译运行时

 

【核心层】的第一部分是【方舟编译运行时】,它涉及到开发环境和终端环境

 

运行流程图

 

【方舟编译运行时】的流程包含4步

 

跨语言调用

 

第1步是跨语言调用

 

ArkUI在开发项目时支持多语言开发,为不同的开发语言相互通信提供了通道,例如:提供了JS/TS与C/ C++交互的NAPI机制。

 

新语言ArkTS

 

而在ArkUI支持的多种语言中,ArkTS是以TS为语法基础的应用编程语言。

 

类型系统

 

在预编译的过程中,数据的静态类型信息会携带在生成的统一字节码中,后端编译的时候能直接利用这种类型信息加速机器码的执行,避免了运行时收集对象造成的额外开销,同时这些类型信息被用于AOT编译过程,使得应用启动时就可以执行AOT生成的优化机器码获得高性能运行体验。

 

统一字节码

 

第2步是统一字节码

 

完成项目开发将项目进行打包时,方舟编译器将编写的高级编程语言通过内置的工具链,编译为一种与运行设备和系统无关的可移植介质,这种介质就叫统一字节码(又称方舟码,abc文件),这个过程也称为字节码预编译。

 

统一字节码

 

第3步是机器码和安装包

 

字节码在设备上可以通过解释执行或者编译后执行的方式运行,对于执行性能要求高的部分字节码调用AOT生成机器码。

 

最后,应用经历了开发、字节码预编译、AOT静态优化编译、打包签名就形成了一个完整安装包,这样一来就终于可以在设备上运行预览了。

 

GC机制

 

第4步是GC(Garbage Collection)机制

 

搭载HarmonyOS系统的设备

 

对比其他设备,搭载HarmonyOS系统的设备上运行应用时会显得特别流畅,这里的秘密是什么呢?

 

GC机制技术问题

 

由于在传统的操作系统中,基于Tracing的GC存在着STW(Stop The World)阶段暂停时间较长的问题。

 

STW

 

当手机内存资源不够用的时候,传统操作系统虚拟机就会召唤GC(Garbage Collection)封锁公路,暂停手机运行的所有线程,等待它回收内存空间。

 

 STW暂停时间较长

 

而且STW(Stop The World)阶段的暂停时间段较长,开发者无法精确控制和干预,在性能较差的手机上会表现出较强的“间歇性”卡顿。这就好比行驶在市区道路的车辆,在经过每个路口都遇到了较长时间的红灯等待,一路走走停停,行驶体验感较差。

 

HPP GC

 

而方舟编译运行时在内存回收方面重新设计,基于Tracing GC推出了高性能内存回收技术——HPP GC(High Performance Partial Garbage Collection)。HPP GC综合了多种Tracing GC算法,根据不同对象区域,采用不同的回收方式。这种GC机制可以缩短STW阶段的时长,用在市区驾驶车辆来比喻,就是缩短了车辆在路口红灯等待的时间,增加了行驶的体验感。

 

HPP GC

 

接下来我们来看核心层的第二部分——声明式UI后端引擎。

 

它在HarmonyOS系统终端运行时,由C++编写UI的基本组件、布局、动效和事件组成。供UI前端开发人员调用。

 

渲染管线

 

渲染管线是位于运行时内部的一个独立的渲染线程,它负责支配CPU多线程地去工作,让CPU为GPU提供更多的渲染数据,最大额度的调取GPU的能力。

 

到此,【核心层】已全部介绍完毕。

 

通过本期ArkUI架构的学习,相信大家已经了解方舟编译运行时的技术和流程,也对ArkUI的设计理念有了基础的认识。完整版的内容可查看上方的视频,我们下期再见~

...全文
8138 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
内容概要:本文详细介绍了鸿蒙系统的ArkUI框架及其组件状态管理机制,旨在帮助开发者掌握如何利用ArkUI实现丰富的交互效果。ArkUI作为鸿蒙系统的核心UI开发框架,提供了简洁的UI语法、多态组件、灵活的布局方式、强大的动画机制和丰富的交互事件。文章重点阐述了改变组件状态的重要性,通过状态管理机制(如@State、@Prop、@Link、@Provide和@Consume装饰器)实现组件内部、父子组件间以及跨组件层级的状态同步。实际应用案例展示了如何使用这些机制构建可交互的任务列表和登录页面。最后,针对常见问题提供了解决方案,并展望了ArkUI未来的发展方向。 适合人群:具备一定编程基础,尤其是对鸿蒙系统开发感兴趣的前端开发者和UI设计师。 使用场景及目标:①学习如何使用ArkUI框架构建用户界面,实现组件状态的动态管理;②掌握状态管理机制,如@State、@Prop、@Link、@Provide和@Consume装饰器的具体用法;③解决状态变化未触发UI新、父子组件状态同步异常等常见问题;④通过实际案例提升开发技能,实现复杂的交互逻辑。 阅读建议:ArkUI的状态管理机制是实现高效、流畅用户交互的基础。在学习过程中,建议读者结合实际项目进行练习,尤其关注状态变量的声明与初始化、父子组件间的双向数据绑定以及跨组件层级的状态管理。同时,注意理解每个装饰器的使用场景和局限性,以便在实际开发中灵活运用。
内容概要:本文详细介绍了ArkUI框架及其核心组件Button在鸿蒙应用开发中的重要性。ArkUI框架作为鸿蒙系统应用界面的核心开发工具,提供了简洁自然的UI信息语法、多维状态管理和实时界面预览功能,支持多种布局方式和强大的绘制能力,满足了现代应用开发对于简洁性、高效性和灵活性的要求。Button组件作为ArkUI框架的重要组成部分,通过绑定onClick事件,实现了从简单的数据操作到复杂的业务流程处理,从页面间的无缝导航到各类功能的高效触发。此外,文章还探讨了Button组件在未来智能化、交互体验多样化以及跨设备应用中的潜力和发展趋势。 适合人群:具备一定编程基础,尤其是对鸿蒙应用开发感兴趣的开发人员和设计师。 使用场景及目标:①理解ArkUI框架的基本特性和优势;②掌握Button组件的使用方法,包括基本绑定、复杂逻辑处理和事件传参;③熟悉Button组件在表单提交、页面导航和功能触发等场景下的具体应用;④展望Button组件在智能化、虚拟现实、增强现实和物联网等新兴技术中的未来发展。 阅读建议:由于本文内容涵盖了从基础概念到高级应用的广泛主题,建议读者先了解ArkUI框架的基本特性,再逐步深入学习Button组件的具体使用方法。同时,结合实际案例进行实践操作,有助于好地理解和掌握相关知识。

5,344

社区成员

发帖
与我相关
我的任务
社区描述
HarmonyOS是一款“面向未来”、面向全场景的分布式操作系统。在传统的单设备系统能力的基础上,HarmonyOS提出了基于同一套系统能力、适配多种终端形态的分布式理念,能够支持多种终端设备。
分布式学习 企业社区
社区管理员
  • HarmonyOS技术社区
  • Edice
  • BaoWei
加入社区
  • 近7日
  • 近30日
  • 至今

试试用AI创作助手写篇文章吧