ArkUI，更高效的架构设计

山青咏芝 / 2024-10-16 / 原文

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
➤微信公众号：山青咏芝（MaoistLearning）
➤博客园地址：为敢技术（https://www.cnblogs.com/strengthen/ ）
➤GitHub地址：https://github.com/strengthen
➤原文地址：https://www.cnblogs.com/strengthen/p/18466665
➤如果链接不是为敢技术的博客园地址，则可能是爬取作者的文章。
➤原文已修改更新！强烈建议点击原文地址阅读！支持作者！支持原创！
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

ArkUI是在端到端整条技术路径上设计了一整套完整的分层机制。

一、前端层：

ArkUI对常用的UI组件的结构、样式、事件三大属性进行了独立的封装，内置于SDK中。

ArkTS为这种联动刷新提供了多维度的状态管理机制，开发人员可以通过对数据进行注释标记，合理控制数据对应View的更新作用范围。

比如，单独更新：@State父组件、@State子组件

父子单向更新：@State父组件、@Prop子组件

父子双向更新：@State父组件、@Link子组件

状态变量全景：

二、核心层：

编译技术：

【方舟编译运行时】涉及到开发环境和终端环境。整个流程包含4步：

ArkUI支持多语言开发，为不同的开发语言相互通信提供了通道。

例如提供了JS/TS与C/C++交互的NAPI机制。

ArkTS是以TS语法基础的应用编程语言：

第一步：工程源码。

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

第二步：统一字节码

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

第三步：机器码

统一字节码可屏蔽适配设备的差异，进行跨平台移植。统一字节码预编译的过程中也可以利用开发环境的计算能力优化源程序，从而减少终端运行时的开销。

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

应用经历了：开发、字节码预编译、AOT静态优化编译、打包签名，就形成了一个完整的安装包。

第四步：GC（Garbage Collection）机制

传统操作系统在GC机制上存在着两种技术问题：

（1）、基于Tracing的GC存在着STW（Stop The World）阶段暂停时间较长的问题。

（2）、基于RC（引用计数）的GC存在着循环引用不容易释放的问题。

传统操作系统是怎么做的呢？

（1）当手机内存资源不够用的时候，传统操作系统虚拟机就会召唤GC（Carbage Collection）封锁公路，让手机运行的所有线程“Stop The World”，全部暂停，等待它回收内存空间。

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

（2）、而在基于RC的垃圾回收实现上，存在着循环引用问题，最终导致内存泄漏，占用居高不下。

方舟GC机制：方舟编译运行时在内存回收方面重新设计，基于Tracing GC推出了：高性能内存回收技术 HPP GC（High Performance Partial Garbage Collection）,而且HPP GC综合了多种Tracing GC算法，根据不同对象区域。采用不同的回收方式。这种GC机制，可以缩短STW阶段的时长，就是缩短了车辆在路口红灯等待的时间，增加了行驶的体验感。而对于循环引用，HPP GC机制从根源上也解决了难以回收的问题，让循环引用的垃圾最终得以清除。