上期文章咱们讲到了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的设计理念有了根底的意识。完整版的内容可查看上方的视频，咱们下期再见~