共计 14586 个字符，预计需要花费 37 分钟才能阅读完成。
原文：https://mp.weixin.qq.com/s/tH1WcAhWwxmfU2FxKnT4ew，点击链接查看更多技术内容。
利用框架，是操作系统连贯开发者生态，实现用户体验的要害基础设施。其中，开发效率和运行体验是永恒的诉求，业界也在继续一直的倒退和演进。
本文重点围绕挪动利用框架，梳理其要害倒退脉络，并剖析其背地的技术演进思路以及目前的局限；同时，进一步联合万物智联的新场景和新生态，围绕相应的利用框架的设计和演进，分享集体在这个畛域的思考，实际，以及下一步摸索。
“万物皆有裂缝，那是光照进来的中央”– 莱昂纳德 · 科恩
1、具体案例剖析：ArkUI 开发框架的实际，摸索和演进
2019 年，咱们开始思考如何构建新一代利用框架，重点围绕极简开发，高能效比，跨设施以及跨平台这几个要害的设计指标，逐渐演进出 ArkUI 以及相配套的语言，API 等能力，并造成了鸿蒙生态主推的开发框架。接下来的内容将以 ArkUI 作为一个具体案例，来阐明这块相干的实际，摸索和演进。
1.1 整体概览
ArkUI 是一套申明式开发框架，它具备简洁天然的 UI 信息语法、丰盛的 UI 组件、多维状态治理，以及实时多维度预览等能力，帮忙开发者晋升利用开发效率，并能在多种设施实现活泼而晦涩的用户体验。同时可进一步扩大到多个 OS 平台。下图形容了 ArkUI 开发框架的整体视图：
Figure 1 ArkUI 开发框架整体视图
ArkUI 的要害特色如下所示：
a. 简洁天然的申明式语法；
b. 高效的渲染管线以及平台一致性的渲染机制；
c. 高效的方舟编译器以及运行时；
d. 对立的跨平台 API 能力集以及扩大机制。
1.2 要害组成
ArkUI 的要害组成包含以下几个方面：ArkTS 语言以及相应的申明式范式；UI 要害能力（布局、组件、动效以及自适应、自定义能力）；渲染管线；ArkTS 编译器 & 运行时；可部署到轻量级设施的轻量化运行时；以及推动利用开发的生态交融设计。接下来别离开展阐明。
1.2.1 ArkTS 语言 & 申明式范式
ArkTS 在 TS(TypeScript) 的根底上，扩大了申明式 UI、状态治理等相应的能力，让开发者通过更简洁、更天然的形式开发高性能利用。
上面联合一个具体的示例，从利用开发的角度简要形容下基于 ArkTS 的申明式范式。
Figure 2 基于 ArkTS 的申明式范式的简要示例
上图所示的代码示例，UI 界面会显示一个“Hello World”的文本以及一个“Click me”按钮。当用户点击“Click me”按钮时，字符串变量 myText 的值会从“World”变为“ACE”，文本最终显示为“Hello ACE”。
这个示例中所蕴含的 ArkUI 申明式开发范式的根本组成阐明如下：
装璜器：用来装璜类、构造体、办法以及变量，赋予其非凡的含意，如上述示例中 @Entry、@Component、@State 都是装璜器。具体而言，@Component 示意这是个自定义组件；@Entry 则示意这是个入口组件；@State 示意组件中的状态变量，这个状态变动会引起相应的 UI 的主动刷新。
自定义组件：可复用的 UI 单元，可组合其它组件，如上述被 @Component 装璜的 Struct Hello。
UI 形容：申明式的形式来形容 UI 的构造，如上述 build() 办法外部的代码块。
内置组件：框架中默认内置的根底和布局组件，可间接被开发者调用，比方示例中的 Column、Text、Divider、Button。
事件办法：用于增加组件对事件的响应逻辑，对立通过事件办法进行设置，如追随在 Button 前面的 onClick()。
属性办法：用于组件属性的配置，对立通过属性办法进行设置，如 fontSize()、width()、height()、color() 等，可通过链式调用的形式设置多项属性。
具体而言，ArkTS 在 TS 的根底上，做了以下几个方面的加强：
3.2.1.1 简洁天然的组件化形容机制
这里次要包含通过 Struct 定义的自定义组件名字；通过 build()办法提供的自定义组件的内容（可基于零碎的内置组件，或其余自定义组件来自由组合）；以及通用的装璜器机制（以 @开始的描述符）。具体到自定义组件而言，则是通过 @Component 装璜器来装璜的自定义组件类型，以便其余组件来应用。同时，还定义了组件的生命周期相干的回调函数。这些独特定义了自定义组件的基础设施。
3.2.1.2 多维状态管理机制
状态治理次要是实现数据到 UI 的主动映射，以实现数据驱动 UI 的主动变更。下面例子中的通过 @State 装璜的 myText 即是状态治理的最简略的一种状况。理论利用开发中，则是须要多维度的状态治理。下图显示了 ArkTS 所波及的状态治理的整体视图，次要也是通过相干的装璜器来实现。
Figure 3 多维状态治理
一个利用能够有多个页面，每个页面能够有多个组件，不同组件之间能够有互相关联。另外，数据的起源以及影响范畴也能够有所不同。为此咱们定义了不同维度的状态治理，来解决不同的场景。
状态治理的范畴能够是组件内，组件间，页面级(LocalStorage)，利用级(AppStorage)；组件间能够是父子组件间的逐层传递，也能够是爷孙组件间跨层传递；传递形式能够单向传递（@Prop）或是双向传递（@Link）; 数据的类型能够是简略类型，也能够是简单类型；数据的起源 / 存储能够来自内存，长久化存储，环境参数，还能够是跨设施的分布式数据。这些构建了利用开发中所需的状态治理的基础设施，并简化了跨设施场景下的利用开发。
3.2.1.3 动静扩大组合机制
后面的组件化形容，状态管理机制，再配合内置组件构建了 UI 的基础设施。某些场景下，还须要 UI 形容可能动静扩大以及组合，比方基于自定义 DSL（Domain Specific Language）动静的内容构建以及刷新场景，典型的案例是京东的 MCube, 阿里巴巴的手淘的 DynamicX 等。为此，咱们进一步扩大了 ArkTS 的语义，通过 @Extend 装璜器依据具体场景来动静增加 / 扩大组件的属性，通过 @Builder 装璜器来动静组合不同的组件，从而实现运行时动静构建 UI 视图的指标。
具体案例剖析细节，可看参考资料: 京东 APP Open-Harmony 化的跨端开发摸索：https://www.51cto.com/article/715754.html
另外，无关 ArkTS 的起源和演进，能够看参考资料: 浅析 eTS 的起源和演进 (注：eTS 是 ArkTS 的前称)https://mp.weixin.qq.com/s/N2RPeboN8Fj0-8wBMZJ-7w
1.2.2 内置组件、自定义机制、动效、多设施适配
上述的 ArkTS 以及申明式范式的根底介绍只是形容了申明式 UI 的根底语法以及根底框架，如果要实现残缺的 UI 能力则还须要其余要害组成，包含各种内置组件（容器组件、根底组件等），动效，以及自适应，自定义能力等。ArkUI 在根底的图形 Surface 之上，构建了一整套的 UI 体系。
1.2.2.1 内置组件（容器组件，根底组件等）
ArkUI 内置组件大抵分为以下几种类型：
容器组件类：包含横向布局，纵向布局，重叠布局，绝对布局容器，二维的网格类型布局等；以及罕用的滚动列表（横向，纵向），侧边栏容器等；
根底组件类：包含按钮，文本，查看框，抉择框，进度条，导航等；
画布组件类：蕴含根底画布，各类线条形态门路等；
媒体 & 高级组件类：蕴含图片，视频等；富文本，Web 组件，xComponent 自绘制组件等；
通过这些内置组件以及相应的属性、事件处理能力的不同设置和组合，来笼罩利用开发中 UI 的典型场景。
3.2.2.2 自定义机制
ArkTS 的组件化形容机制，动静扩大组合机制，加上各种内置组件，形成了自定义组件的根底，再配合根底画布 /xComponent 等自绘制能力，能够构建出罕用场景的组件。不过，某些场景下，开发者还须要更细粒度的定制化能力，比方自定义测量 / 布局以实现任意形态的布局，以及在现有组件进一步定制化和扩大等。下图形容了 ArkUI 的自定义布局的根本流程：
Figure 4 ArkUI 自定义布局流程
如图所示，其中的 onMeasure 以及 onLayout 是框架层提供给利用开发者的接口，供开发者自定义具体的组件测量方法以及基于测量后果的布局机制，以实现任何的布局，比方瀑布流布局，环状布局等等。整体运行时流程大抵如下：渲染管线触发渲染流程 -> 触动员效 -> 触发布局 -> 调用开发者实现 OnMeasure 函数，由开发者实现测量逻辑，由 ArkTS 侧调用框架层相应子组件 measure 接口 -> 调用开发者实现 OnLayout 函数，开发者实现布局逻辑，设置所有子组件地位，由 ArkTS 侧调用框架层相应子组件 layout 接口 -> 触发渲染。
不过，更灵便的自定义能力，比方在现有组件实现办法 / 属性级的定制化和扩大，更便捷的自绘制能力等方面还需进一步欠缺。
3.2.2.3 动效
动效，即动画成果，实质上它也是一种状态驱动的 UI 变更。具体而言，动效是在起始状态和终止状态之间，退出了基于工夫的显示成果的平滑过渡。
从作用的对象角度，动效个别包含组件自身的动效（比方各种属性变动引起的动效），转场动效（组件增减 / 挪动，页面之间转场，共享元素在页面间转场）；从开发的形式角度，包含隐式动效（通过设置相应的参数主动触发），显式动效（通过显示调用动画接口来指定因为闭包代码导致的状态变动插入过渡动效）。
ArkUI 提供了上述场景所需的动效能力，通过联合相应的状态变量，相关联的 UI 组件 / 页面，以及相应的时序曲线算法函数来共同完成。
利用通过提供的申明式动画接口，进行动画业务逻辑组织；通过状态更新监听器，监听绑定动画的属性；动画对象提供动画参数存储能力的数据结构，包含动画持续时间、动画曲线、延迟时间等。组件树提供实在组件渲染节点，蕴含平移、旋转、缩放等成果渲染节点。动画引擎提供动画驱动能力。最终触发节点的从新绘制，通过渲染引擎进行界面更新。
ArkUI 动效相干能力目前还比拟根底，相干时序 / 成果算法的丰盛度，以及动效的细粒度管制 / 自定义能力等都在继续加强演进中。
3.2.2.4 多设施适配（界面自适应，交互自适应等）
ArkUI 围绕多设施适配提供了系统化的多层次的解决方案。下图显示了其中的要害内容。
Figure 5 ArkUI 多设施适配
如图所示，UI 维度的多设施适配从上到下分为三个档次：
场景样例，布局能力，视觉交互：场景样例：联结用户体验设计对罕用组件的组合场景作出定义和输入样例代码，蕴含：顶部、入口、分栏、瀑布流、Banner、视频列表、视频宫格、图文、图片详情等；
布局能力：蕴含响应式能力：响应式组件（List、Navigation、Grid、Swiper、Tabs、栅格布局组件），响应式能力（栅格零碎、自定义断点零碎、媒体查问）；以及自适应能力：罕用自适应组件 + 自适应能力（暗藏、延长、缩放、均分、占比、拉伸、折行）等；
视觉交互：蕴含分层参数 / 主题格调：反对多设施上采纳不同的主题格调，深浅主题，自定义主题款式等，满足利用的个性化皮肤; 多态组件：反对对立的组件形容，不同的设施出现成果；交互归一：屏蔽设施差别对立交互逻辑，把不同的设施的交互输出汇合进行对立的事件归类定义，而后控件实现对应的对立响应。
在配套开发工具方面，通过 DevEco IDE（Integrated Development Environment）的实时多设施预览等相干能力，进一步升高多设施开发成本。
当然，残缺的利用的多设施适配还需联合相应零碎的能力，比方零碎能力的运行期辨认判断，利用的模块化打包散发，以及面向不同设施的弹性部署等。
残缺内容，可看参考资料：鸿蒙生态利用开发白皮书 https://developer.huawei.com/consumer/cn/doc/harmonyos-bps?ha…
1.2.3 渲染管线
ArkUI 整体渲染管线流程次要包含 ArkTS 源代码通过相应的编译工具链编译成中间代码（其间会应用到 ArkUI 的框架 API），方舟运行时运行相应的字节码（也能够是 AOT 后的代码），最终通过 ArkUI 框架运行时实现残缺的渲染流程。
Figure 6 ArkUI 渲染管线流程
上图显示了次要的渲染流程，其中有几个要害特色：
1）扁平化的按需组合的渲染管线。通过申明式 UI 前后端的交融设计，开发范式中的 UI 形容根本能够间接映射到后端组件。同时，后端组件的相干属性基于组合式按需构建，进一步晋升构建速度并升高内存开销；
2）数据依赖的主动收集。开发者只需通过相干的装璜器润饰好状态变量，ArkUI 框架则会联合语言的相干个性（属性代理等机制）来自动识别并构建相应的依赖，实现相应的渲染刷新；
3）通过方舟编译器以及运行时基于类型的编译优化以及 AOT 机制，实现语言执行性能的进一步晋升。
在上述根底上，2022 年，ArkUI 渲染架构又做了进一步降级：
Figure 7 ArkUI 渲染架构进一步降级
如上图所示，渲染架构次要进行了以下三个方面的降级：
1）多节点按需组合模型→单节点 + 属性按需组合模型 原先架构下组件树构建时，同一组件的不同属性是通过根底节点叠加相应的分外属性的节点来按需构建，简单场景下这容易造成节点过多从而引起性能以及内存累赘。新的架构下实现了单节点模型，附加按需的属性汇合以及相应工作处理器，从而大幅升高节点树的层级。另外，通过对相干工作处理器的拆散，也为后续进一步的细粒度并行化革新打下了相应的根底。
2）数据依赖组件级更新→细粒度函数级更新 原先架构下数据依赖只是跟踪到了自定义组件层级。新的架构下引入了最小化更新机制，对自定义组件中的 build 函数进一步合成为细粒度的函数的组合，并实现了将数据依赖间接定位到相应的子节点上，从而实现更精细化的更新，进一步晋升 UI 更新效率。
3）三颗树→一颗树 原先架构下多棵树存在的次要目标是实现差量比拟更新。通过最小化更新机制的引入，差量比拟就不是必要的，同时，再联合数据结构重构，可在相干节点上生成渲染信息，这样原先的三颗树合并成了一棵树，进一步晋升了组件渲染速度并升高内存。
1.2.4 方舟编译器 & 运行时
方舟编译器 & 运行时的要害指标是要实现可对标动态类型语言（比方 Swift/Java/Kotlin）的性能体验，以及和申明式框架深度交融从而实现高效的申明式开发。
Figure 8 业界 JS/TS 的典型性能问题
上图形容了业界 JS/TS 引擎的典型性能问题，次要包含三个方面：
1）源代码运行时编译所带来的较多的启动开销；
2）无奈间接利用类型信息带来的优化；
3）须要运行时信息的热点，行为特色收集剖析所带来的预热开销。
Figure 9 方舟编译器 & 运行时解决方案
如上图所示，方舟编译器以及运行时重点通过以下形式解决上述问题：
1）引入带类型语言字节码，并将源码编译过程从运行时提前到编译时；
2）利用类型信息并联合 PGO 信息进行编译时综合优化；
3）反对动静类型语言类型对象长久化，并优化机器码的类型对象重绑。
另外，在并行化方面，传统的 Worker 机制因为各自独立，信息不共享，启动和资源开销都比拟大。方舟运行时引入了轻量化 Actor 机制，通过公共的基础设施以及不可变对象的共享，实现了性能和内存的进一步优化，如下图所示：
Figure 10 方舟轻量化 Actor 机制
同时，咱们也在进一步扩大 ArkTS，设计更轻量更简便的并发机制 – Taskpool，下图是个简要的示例：
Figure 11 Taskpool 示例
通过 Taskpool 机制，从开发者维度，开发者更易于开发并发工作：
简略直观，缩小代码编写量；无需关怀并发实例的生命周期；无需关怀场景下并发工作负载轻重。从运行时角度，方舟运行时会进行对立工作负载资源管理，升高系统资源耗费（注：缩小线程数，缩小线程的内存等资源耗费），并联合对立调度机制，晋升整体性能。
通过基于类型的编译优化，联合 PGO 信息的运行时优化，轻量并行化以及对立调度机制，ArkTS 以及相应的方舟编译器和运行时已具备了可对标动态类型语言性能的要害设施。另外方舟运行时也提供了兼容机制来反对相应的 ECMAScript 规范。后续会进一步围绕高性能以及高开发效率继续演进，包含进一步的共享对象的无锁并发机制，并行化编译 / 内存治理，规范库的欠缺，严格类型以及精细化类型，分布式类型等等。同时，也会逐渐通过 ECMAScript 标准化组织来独特推动和欠缺相干的语言规范。
1.2.5 轻量化框架运行时（可部署到百 K 级到 M 级内存级别的轻量化设施）
近年来，越来越多轻量化设施（百 K 级到 M 级内存）也逐渐智能化，其中一个典型的代表就是静止手表。这些对利用框架的进一步解耦和轻量化提出了十分高的要求。ArkUI 通过实现类 Web 范式的子集，联合预编译机制部署简化的 JS 语言子集的 Bytecode, 轻量化的 JS 引擎（定制化的 JerryScript 引擎），外围 JS 框架下沉到 C ++ 层，轻量化的 UIKit 以及图形引擎，实现了在轻量化设施的部署运行的能力。以华为的静止手表系列为例，ArkUI 撑持了手表零碎内置利用以及包含微信在内的三方利用的商用。整体架构如下图所示。
Figure 12 ArkUI 轻量化框架（类 Web 范式）
接下来，咱们会继续加强能力（比方轻量设施上的后盾运行能力），继续优化相干体验，并摸索如何将申明式开发范式也进一步轻量化，部署到相应设施。
1.3 生态交融设计（整体生态布局，分层对接，跨平台）
掂量一个利用框架最终是否胜利，要害还是要看它对利用开发者生态影响的深度和广度。下图形容了 ArkUI 生态构建思路概览。
Figure 13 ArkUI 生态构建思路概览
如图所示，自底向上，整体生态构建分为四个维度。
1）框架。这层次要是框架自身的个性齐备度以及竞争力，并可能满足要害利用的需要（包含要害自研利用和要害三方利用）。尤其是要通过要害垂类利用（比方电商，地图，游戏等）的冲破来进一步欠缺框架自身。另外，如之前所述，当多个支流 OS 平台会长工夫并存的状况下，跨 OS 平台是外围竞争力诉求。框架必须具备相应的能力来进一步晋升开发效率。
2）工具。这层次要是配套开发工具的齐备度以及三方支流开发工具的反对度。DevEco 作为 ArkUI 的外围配套工具，须要在整体开发工作流进一步欠缺，同步，也需逐步推进和三方开发工具的整合，包含 VSCode, 基于 Chrome 浏览器的调试等，进一步不便开发者。
3）社区。这层次要是通过相应的开源社区（凋谢原子开源基金会等），以及三方开源库，组件仓库等建设，以及联合支流的组件仓库 NPM（Node Package Manager）等推动 ArkUI 的三方组件的进一步欠缺。
4）规范。这层次要是通过标准化的参加，来构建中长线影响力。包含 W3C 相干的规范组织（ArkUI 类 Web 范式的进一步标准化，WebAssembly 的交融摸索等），ECMAScript 规范组织（ArkTS 的加强语言个性的进一步标准化等），软件绿色联盟（利用质量标准，原子化服务规范的欠缺 / 互通等）。
总之，ArkUI 的整体生态推动策略是以要害利用为牵引，逐渐夯实相应能力构建，通过工具、社区协同，并布局规范培养中长线影响力。
接下来，以 ArkUI 框架这层的生态分层接入接口设计，以及跨 OS 平台设计为例，来进一步开展阐明。
1.3.1 ArkUI 生态分层接入接口设计
下图形容了 ArkUI 的生态分层接入接口设计的整体视图。挪动利用生态倒退至今，尤其是简单的大型利用，存在着多种技术栈并存的状况。ArkUI 的生态分层接入接口设计的整体思路是在保障开发生态以及体验可控的前提下，提供必要的分层接口，不便相干技术栈的接入。
Figure 14 ArkUI 生态分层接入接口设计
如图所示，相干的技术栈可大抵分为 4 种类型：
Ⅰ、原生代码，以及各厂商自研的动态化模板引擎
这类代码通过规范的 ArkTS API 来接入。利用原来的原生代码通过 ArkUI 申明式开发范式来开发，以保障最优开发以及性能体验；三方的动态化模板引擎（比方后面章节提到的京东的 MCube），可通过 ArkTS 提供的动态化构建组合的 API 来适配接入。
更进一步，ArkUI 也在同步设计基于 ArkTS 的动态化内容部署机制，这样能够更高效的实现动态化内容接入。后续配合 ArkUI 跨 OS 平台我的项目，可实现基于对立的申明式开发范式来开发利用和动态化内容，以及相应的跨 OS 平台部署，进一步整体晋升开发效率以及性能体验。
Ⅱ、类 Web 前端框架
类 Web 前端框架包含 RAX/React/Vue 等，这类代码可通过 JS DOM API 来接入。不过，目前 JS DOM API 提供的接口范畴还绝对比拟无限，也不够规范。这块接口齐备性，标准化（包含 CSS 能力反对等）以及相干的渲染门路优化等方面，需进一步改良和欠缺。
Ⅲ、规范 HTML5
ArkUI 提供了合乎 W3C 规范的 Web 组件，底下是规范的 Web 运行时。规范 HTML5 的内容可间接通过相应的 Web 组件来接入。
Ⅳ、自绘制引擎 / 中间件
对于三方基于 C /C++ 实现的自绘制引擎 / 中间件，比方典型的游戏引擎、地图、直播等，ArkUI 提供了 xComponent 机制，通过提供基于 C Surface 的相干规范的 OpenGL ES 接口来帮忙开发者接口，能够独立显示，或嵌入在 ArkUI 的 UI 组件中交融显示。Cocos 游戏引擎以及相干的 IDE 基于 ArkUI 的 xComponent 接入框架，协同相应的编译工具链，语言运行时，零碎 API 能力等已实现了相应的适配接入，相干信息可看参考资料 – Cocos Creator 公布到 OpenHarmony：https://docs.cocos.com/creator/manual/zh/editor/publish/publi…
下图显示了 Cocos 游戏引擎接入 ArkUI xComponent 的示例，其它的游戏引擎 / 自绘制引擎的接入可参考相似计划。
Figure 15 Cocos 游戏引擎接入 ArkUI xComponent 示例
1.3.2 ArkUI 跨 OS 平台设计
ArkUI- X 是 ArkUI 跨 OS 平台项目名称，它基于 OpenHarmony 中的 ArkUI 以及相干 API，做了相应跨 OS 平台扩大。整体视图如下所示：
Figure 16 ArkUI 跨 OS 平台整体视图
ArkUI- X 聚焦在构建跨平台框架的外围设施，将 ArkUI 的能力扩大到 iOS 和 Android 平台上。开发者能够通过一份代码，联合相应的工具链，同时生成多个 OS 平台的利用工程，并可编译出相应的应用程序，在相应的平台上高效的运行。要害个性集包含以下几个方面(具体的个性范畴以理论的演进状况为准)：
Ⅰ、编译工具链
编译工具链提供了两类能力：一类是面向 ArkUI 框架开发者，它能够构建出相应平台的 ArkUI SDK（比方 iOS,Android），供给用打包散发应用(OpenHarmony 零碎因为内置了 ArkUI，则无需和利用一起打包）；另一类是面向利用开发者，它提供创立不同平台的利用工程，基于相干的 SDK 编译工程生成指标平台的利用，启动利用等相应性能。命令行工具反对的 PC 平台包含 Windows（通过 WSL – Windows Subsystem for Linux）, macOS, Linux。
Ⅱ、平台桥接
平台桥接提供了相应的平台能力桥接，包含指标平台的利用加载入口，生命周期，事件处理，窗口零碎，资源管理，剪切板，输入法，摄像头，以及其余高级组件接入等相干能力。
Ⅲ、UI 组件适配
UI 组件适配提供了 UI 组件在不同平台上的绘制成果的一致性。因为 ArkUI 架构上是通过自绘制能力实现相应成果，这块次要是以验证为主。
Ⅳ、根底 API 能力适配
根底 API 能力适配包含了两方面内容：API 扩大机制以及 API 的具体实现。API 的扩大机制基于 N -API 实现的，须要在不同的平台上做相应的适配；API 的实现次要包含 OpenHarmony 的平台能力 JS API，HMS（Huawei Mobile Service）的 JS API 等在不同平台上的实现。具体的 API 实现节奏会联合相应的利用需要来推动。
Ⅴ、利用嵌入集成
利用嵌入集成提供了指标平台利用和 ArkUI 集成的能力，指标平台利用能够一部分基于现有的平台代码实现，另一部分引入 ArkUI 的实现，这样有助于利用逐渐的平滑的迁徙到 ArkUI。
Ⅵ、调试能力
调试能力次要是指在非 OpenHarmony 平台上的调试能力，须要对 ArkUI 在不同平台上的调试能力做相应的适配和使能，后续也会包含相应的 IDE 插件能力的构建。
Ⅶ、XTS（X Test Suite）基础设施
XTS 基础设施次要是验证 ArkUI 框架能力在不同平台上的兼容性，通过同一套的 XTS 测试集（包含 UI 以及 API）在不同平台上使能，来保障 ArkUI 框架能力在不同 OS 平台实现成果的一致性。
Ⅷ、架构演进
架构演进次要包含可维护性的加强（架构解耦 - 组件以及能力 API 按需加载，分层形象 - 渲染后端的形象以便平滑过渡等），以及在性能、内存、包体积相干的优化等。这块会联合 Open-Harmony 上 ArkUI 自身的演进和跨平台的相干需要逐步推进。
ArkUI- X 我的项目在 2022 年以定向开源形式启动，先聚焦 iOS 以及 Android 平台。非常感谢咱们的合作伙伴 - 美的 IoT 挪动端技术团队，阿里巴巴闲鱼技术团队，深开鸿技术团队和咱们独特创立了 ArkUI 跨 OS 平台我的项目，并有了第一个初始版本。尽管目前版本还绝对简略，但整个跨平台框架的基础设施以及要害的根底能力已具备，后续逐渐会有相应 APP 商用落地。接下来咱们会继续围绕上述要害个性，联合更多典型场景继续打磨、欠缺。同时，咱们也在摸索 ArkUI 如何进一步扩大到 PC 平台以及 Web 平台。也欢送更多感兴趣的开发者退出进来，一起推动。
1.4 下一步摸索
无关 ArkUI 的下一步，其实在后面相干章节的设计形容中已有波及。这里进一步从要害竞争力以及生态建设的角度，来分享几个潜在的大颗粒的技术方向的一些想法。
1.4.1 精细化的异构并行减速 & 对立调度
目前越来越多的智能设施都具备多核能力（包含同一配置的多核以及不同配置的大小核），有些设施还会携带多种类型的计算芯片（GPU/NPU/…）。同时，对高端设施而言，简单酷炫的利用，联合需实时响应的用户交互解决等，都对计算性能提出了更高要求；而对低端设施而言，怎么基于较弱的芯片配置在典型场景也能达成 60 帧的晦涩体验。一个潜在的方向是进一步开掘整体利用解决、渲染过程中的并行化机会，并充分利用底层的多核能力，并联合对立的基于场景优先级的调度进一步晋升相干体验。另外，在申明式开发场景下，因为相干 UI 形容是独立的，只读的，相应的数据流也有相干应用束缚，是通过对立的数据起源来驱动（比方只能在事件处理等相干回调中扭转数据，而不是像传统的命令式开发那样开发者能够在任何中央批改数据），这些使得申明式开发在实践上比传统的命令式开发能够更容易也更有机会实现进一步的并行化。目前，现有的 ArkUI 的申明式渲染后端的数据结构已实现细粒度工作拆散的根底设计，咱们也在同步剖析相应的场景，尤其是简单的自定义布局、大量数据处理相干的场景，钻研基于场景优先级对立调度的细粒度的异构并行化的可行性以及潜在收益。
1.4.2 无缝的申明式 2D/3D 交融体验
3D 具备酷炫的出现成果以及全方位的交互体验。典型场景包含 3D 数字人，3D 模型商品，3D 动效，以及重度依赖 3D 的 VR（Virtual Reality）/AR（Augmented Reality）体验等。以电商为例，包含手淘，京东，以及新型平台比方得物等，基于 3D 模型的高端商品展现和交互是其中十分重要的一环。然而，面向 3D 的利用开发，存在以下几点挑战：
1）三方 3D 引擎 ROM 占用动辄几十兆起步，RAM 占用动辄百兆起步，资源累赘较重；
2）3D 引擎相干的 SDK 根本都是命令式编程接口，同时畛域技能要求较高，应用较为简单；如果再波及 2D、3D 交融编程，复杂度则进一步晋升；
3）只管 Apple 和 Google 都提供了各自的 3D 的 SDK，然而都还没有和申明式开发交融，开发者累赘较重，另外 Apple 和 Google 各自反对的规范和体验都不一样，难以实现统一的跨平台体验。这种状况下导致一些重度依赖 3D 的厂商甚至不采纳操作系统提供的原生计划，通过自行开发跨平台的绝对轻量的 3D 计划，或者应用比拟重度的三方 3D 引擎，以便升高 3D 相干的保护老本。但这样的话，开发门槛则变得十分之高，难以进一步推广。
如果利用框架层面可能提供简洁天然的申明式 3D 开发，并实现轻量化的可按需加载的资源占用，以及跨 OS 平台一致性的体验，集体认为，就具备十分强的竞争力，实现开发效率和用户体验的比拟大的飞跃。
咱们在这个畛域继续在做相应的摸索和钻研。目前，已初步实现了相应的原型，包含轻量化的 3D 引擎，以及交融了申明式 UI 的 API 设计和初步实现。
通过两三行简洁的申明式代码，就能够实现 2D 和 3D 内容交融渲染，并初步做到 3D 模型的操控（旋转、缩放等）。另外，在跨 OS 平台方面，也初步实现了 OpenHarmony 以及 Android 平台的一致性体验，以及在 PC 上的一致性预览体验。
集体认为这是十分重要的体验降级。咱们会继续打磨相干的根底性能，外围性能体验，以及按需加载的机制等要害个性。从中长期来看，后续会进一步联合 3D 手势交互，3D 立体化音效，以及联合 AR/VR 相干算法和能力做进一步欠缺和加强，实现更加实在天然的用户体验。
1.4.3 多设施场景下的 UI 智能构建
不同业务场景下 UI 复杂多变，而且变更频繁，相干的下层业务开发正逐渐由组件化模块化开发向无代码的智能化开发转变。
通过 UX(User eXperience)设计工具间接生成相应的 UI 代码，并可能在不同类型设施上的达成 UI 最佳适配（或能够提供实时反馈倡议让 UX 设计做相应调整），能够极大晋升相应的开发以及业务部署效率。目前业界有局部 UX 设计到代码的实现，但涵盖的能力还绝对无限，另外，如何进一步转换成不同设施的最佳适配，目前还没有绝对成熟的计划。
一个潜在的钻研方向是联合申明式 UI 框架，相应的 IDE(Integrated Development Environ-ment)，以及业界支流的 UX 设计工具，构建申明式 UI 和 UX 设计之间精确的对应关系，并可交融演进，通过 AI（Artificial Intelligence）等相干技术实现典型的 UX 设计场景到申明式 UI 代码的智能匹配，并能进一步扩大到多设施适配（支流的各种分辨率 / 大小的手机、折叠机、平板、车机，并逐渐延长到各类的智能 IoT 设施）；同步的，构建高效的多设施的屏幕模仿 & 检测算法，主动模仿各类不同设施上的 UX 成果并辨认有问题的场景，并给出相应的倡议或主动修改。
1.4.4 极简 Web 运行时
通过几十年的倒退，W3C Web 相干的规范在造成宽泛的利用生态的同时，也面临着规范以及绝对应的 Web 引擎越来越收缩，难以进一步优化的问题 – 宏大的体积和资源占用，再加上性能体验也和原生利用有较大差距，难以满足万物互联场景下不同类型设施的需要。
W3C 的 Web/HTML5 相干的规范是利用生态的重要组成，也造成了十分宽泛和沉闷的开发者社区。如果可能进一步解决好相干的规范以及性能体验问题，并能不便的部署到更多不同类型的设施上，对万物互联的跨设施的利用生态能够起到重要的促进作用。
传统的 Web 引擎架构因为历史累赘太重，难以基于现有架构实现较大的飞跃。须要另外一个角度 - 从 Web 规范子集和运行时维度思考整体架构的演进和实现。
1）从规范维度，依据 80/20 法令 (20% 性能决定了 80% 的需要)，联合挪动端 Web 的典型场景，钻研梳理出相应的 Web 规范子集，满足大多数典型场景的需要。
2）联合相应的规范子集，设计和实现满足该规范子集的极简的高性能的跨平台运行时，并达成以下几个要害指标：
a. 基于 Web 规范子集范畴，可不便对接典型的 Web 前端框架 / 类小程序；
b. 跨平台统一的渲染能力，以及对标原生框架的性能内存体验（典型场景性能内存差别在 5%-10% 以内）；
c. 极简的资源占用（5M-10M 以内的包大小以及 5M-10M 以内的根底运行时内存），同时架构上模块解耦，性能可积木式组合以及按需部署和加载。
另外，能够联合标准化的 WebAssembly（高效的语言两头格局和运行时），以及 WebGPU（高效的渲染 API）实现更优的利用体验。
2、总结
本文剖析了利用框架尤其是挪动端利用框架所面临的挑战，相应的演进，并联合万物智联场景下的利用框架所需的要害因素（开发效率 / 性能体验 / 跨设施 / 跨平台），给出了如何设计有竞争力的利用框架的系统化思考。而后联合 OpenHarmony 新一代开发框架 -ArkUI，开展阐明其具体实际以及演进门路。
咱们从 2019 年开始构思 ArkUI（过后的名字是 ACE），到目前为止，ArkUI 已撑持了静止手表，智能手表，智慧屏，手机，车机等多款产品，以及 OpenHarmony 设施上所有零碎利用和三方利用。ArkUI 通过系统化的形式，深度联合编程语言，编译器以及相应运行时，图形引擎，开发工具等相干的根技术联结翻新，逐渐构建具备可超过业界支流 OS 零碎原生框架能力的外围底座，指标三分天下有其一。这是一条充斥挑战的路，但同时我深信，这是一条正确的路。期待更多的同行者退出，共创万物智联的新生态！
————————- 抬望眼，星光满天；环周围，万物成长；将来已来！————————-
致谢：ArkUI 开发框架 & 方舟编译器等相干外围人员。
3、参考资料
SwiftUI 编程思维：https://objccn.io/products/thinking-in-swiftui Jetpack Compose 编程思维：https://developer.android.com/jetpack/compose/mental-model?hl…
Flutter 架构概览：https://flutter.cn/docs/resources/architectural-overview
京东 APP OpenHarmony 化的跨端开发摸索：https://www.51cto.com/article/715754.html
如何继续突破性能体现？| DX 研发模式：https://blog.csdn.net/Taobaojishu/article/details/125401406
Cocos Creator 公布到 Openharmony：http://docs.cocos.com/creator/manual/zh/editor/publish/publis…
HTML5、Web 引擎与跨平台挪动 App 开发：https://www.infoq.cn/article/html5-crosswalk
前端开发编程语言的过来、当初和将来：https://johnhax.net/2019/fe-lang/article1
浅析 eTS 的起源和演进：https://mp.weixin.qq.com/s/N2RPeboN8Fj0-8wBMZJ-7w
鸿蒙生态利用开发白皮书：https://developer.huawei.com/consumer/cn/doc/harmonyos-bps?ha…
ArkUI 开发文档：https://gitee.com/openharmony/docs/blob/master/zh-cn/applicat…
ArkUI-X: ArkUI 跨平台开源我的项目：https://gitee.com/arkui-x（目前是定向开源）
