简要了解ArkTS的底层，ECMAScript版本、ArkCompiler、JS运行时

初识ArkTS语言

基于/兼容JS

在API version 11上，OpenHarmony SDK中的TypeScript版本为4.9.5，target字段为es2017。在应用中，开发者可以使用ECMA2017+的语法进行TS/JS开发。
(怀疑文档更新不够及时，目前的版本信息可能已经不对，因为目前2025年2月12日，OpenHarmony SDK已经到API version 13了)

目前的ArkTS 可以视为与TS存在一定交集的语言，ArkTS 在UI描述上有独立的ArkUI声明式语言进行实现，以及与此相配合的各种装饰器。
对于除去ArKUI部分的ArkTS，与TS也有很多不同之处，因为进一步作出更为严格的约束，实现了完全静态的类型，便于编译优化。具体的规范详见下面的链接：
从TypeScript到ArkTS的适配规则

ArkCompliler

方舟编译器(ArkCompiler)是为支持多种编程语言、多种芯片平台的联合编译、运行而设计的统一编译运行时平台。

• ArkCompiler主要分成两个部分：编译工具链与运行时。
• ArkCompiler eTS Runtime主要由四个子系统组成：Core Subsystem、Execution Subsystem、Compiler Subsystem、Runtime subsystem。
• ArkCompiler 的设计特点：原生支持类型、并发模型优化与并发API、安全。

目前ArkCompliler主要支持ArkTS/TS/JS语言的编译
ArkCompiler的编译工具链以ArkTS/TS/JS源码作为输入，将其编译生成为abc(ArkCompiler Bytecode，即方舟字节码)文件。

ArkCompiler eTS Runtime

能够运行abc文件的运行时，是一个JSVM

未来可能会支持的AOT功能，提供更高的性能

根据目前项目文档中的描述，AOT还处于实验阶段，存在一定的不稳定性，目前所有的应用仅在开发阶段可以使用AOT，不支持AOT编译产物上架应用市场。

目前主流的观点是动态类型语言（如JS、Python）做AOT优化并没有太大的优化效果（支持动态类型这一性质，与能够被静态编译本质上是存在矛盾的，TS只能尽量约束类型，但是仍然不能确保完全的类型安全）。因此，AOT在应用方面更加适合一些非动态类型特性的的应用，例如嵌入式应用（智能可穿戴设备）而不是移动端上层应用。