!2809 Update ArkCompiler's docs

Merge pull request !2809 from DaiHN/docM
This commit is contained in:
openharmony_ci 2022-11-10 09:20:13 +00:00 committed by Gitee
commit a91a419770
No known key found for this signature in database
GPG Key ID: 173E9B9CA92EEF8F
5 changed files with 21 additions and 21 deletions

View File

@ -42,7 +42,7 @@ For more information, see [ArkCompiler JS Runtime](https://gitee.com/openharmony
## Constraints
* Only the ArkCompiler bytecode files generated by ts2abc, which is the ArkCompiler JS frontend toolchain, can be run.
* Only the ES2015 standard and strict modes are supported.
* Only the ES2021 standard and strict modes are supported.
* Functions cannot be dynamically created using strings, such as new Function("console.log(1);")).
## Building

View File

@ -54,7 +54,7 @@
## 约束<a name="section119744591305"></a>
* 仅支持运行方舟eTS编译器\(ts2abc或es2abc\)生成的方舟字节码文件
* 只支持ES2015标准和严格模式use strict)
* 只支持ES2021标准和严格模式use strict)
* 不支持通过字符串动态创建函数(比如new Function("console.log(1);"))
## 编译构建<a name="section137768191623"></a>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 23 KiB

After

Width:  |  Height:  |  Size: 110 KiB

View File

@ -1,52 +1,52 @@
# 概述<a name="ZH-CN_TOPIC_0000001174295771"></a>
方舟编译器\(ArkCompiler\)是OpenHarmony内置的组件化、可配置的多语言编译和运行平台包含编译器、工具链、运行时等核心部件支持高级编程语言在多种芯片平台上编译与运行。开源的ArkCompiler eTS Runtime提供的能力是在OpenHarmony操作系统中编译和运行ArkTS语言
方舟编译器\(ArkCompiler\)是为支持多种编程语言、多种芯片平台的联合编译、运行而设计的统一编译运行时平台。它支持包括动态类型和静态类型语言在内的多种编程语言如JS、TS、ArkTS它是支撑鸿蒙系统成为打通手机、PC、平板、电视、车机和智能穿戴等多种设备的操作系统的编译运行时底座
ArkCompiler eTS Runtime分成两个部分分别是方舟eTS编译器与方舟eTS运行时。eTS编译器将ArkTS源码编译成方舟字节码\(ArkCompiler Bytecode\)eTS运行时负责执行生成的方舟字节码\(后续如无特殊说明,字节码特指方舟字节码\)。
ArkCompiler主要分成两个部分编译工具链与运行时。
编译工具链架构如下:
**图1** 方舟eTS编译器架构
**图1** 编译工具链架构如下:
![](figures/zh-cn_image_0000001197967897.png)
ArkCompiler eTS Runtime的源码编译器接收ArkTS源码的输入再由ts2abc或es2abc\(将ArkTS文件转换为字节码的工具\)生成abc文件。
ArkCompiler的编译工具链以ArkTS/TS/JS源码作为输入将其编译生成为abc(ArkCompiler Bytecode即方舟字节码)文件。
运行时架构如下:
**图2** 方舟eTS运行时架构
**图2** ArkCompiler运行时架构
![](figures/zh-cn_image_ark-ts-arch.png)
方舟eTS运行时以方舟字节码文件作为输入并直接运行字节码文件实现对应的语义逻辑。
ArkCompiler运行时直接运行字节码文件实现对应语言规范的语义逻辑。
**ArkCompiler eTS Runtime主要由四个子系统组成**
- **Core Subsystem**
Core Subsystem主要由语言无关的基础运行库组成包括承载字节码的ArkCompiler File组件、支持Debugger的Tooling组件、负责对应系统调用的ArkCompiler Base库组件等。
Core Subsystem主要由语言无关的基础运行库组成包括承载字节码的File组件、支持Debugger的Tooling组件、负责适配系统调用的Base库组件等。
- **Execution Subsystem**
执行引擎包含执行字节码的解释器、缓存隐藏类和内联缓存、以及剖析记录运行时类型的Profiler。
Execution Subsystem包含执行字节码的解释器、快速路径内联缓存、以及抓取运行时信息的Profiler。
- **Compiler Subsystem**
编译子系统包含Stub编译器、基于Circuit IR的优化编译框架和代码生成器。
Compiler Subsystem包含Stub编译器、基于IR的编译优化框架和代码生成器。
- **Runtime subsystem**
运行时子系统包含了各种ArkTS运行相关的模块
Runtime Subsystem包含了ArkTS/TS/JS运行相关的模块
- 内存管理:对象分配器与垃圾回收器\(并发标记和部分内存压缩的CMS-GC和Partial-Compressing-GC\)
- 分析工具DFX工具、cpu和heap的profiling工具
- 并发管理actor并发模型中的abc文件管理器
- 标准库Ecmascript规范定义的标准库、高效的container容器库与对象模型
- 其他异步工作队列、TypeScript类型加载、跟C++交互的ArkTS NAPI接口等
**ArkCompiler eTS Runtime的设计特点:**
**ArkCompiler 的设计特点:**
- **ArkCompiler eTS Runtime的主要设计目标:** 是为OpenHarmony操作系统提供ArkTS应用程序执行引擎而不是作为浏览器中的JavaScript执行引擎
- **原生支持类型** 目前业界引擎执行TS的方式是先把TS转化为JS再运行JS源码来完成对应的语义逻辑。ArkCompiler的编译工具链编译TS源码时会分析推导TS的类型信息并将其传递给运行时。运行时直接使用类型信息在运行前预生成内联缓存Inline Cache以加速字节码执行。另外TSAOT (Ahead-of-Time) Compiler可以利用字节码文件中的类型信息直接编译生成优化机器码使得应用可以直接运行优化机器码获得高性能运行体验
- **为了提升应用的执行性能和安全性:** ArkCompiler eTS Runtime选择将ArkTS程序预先静态编译为方舟字节码\(带上静态类型信息\) 从而减少运行时的编译和类型信息收集开销。另外出于安全性和性能的考虑eTS Runtime选择不支持eval和只支持strict模式的代码。
- **原生支持TypeScript** 目前业界通用的执行方式是把TS转化为JS再通过JS运行时来执行。ArkCompiler eTS Runtime规划在ts2abc编译ArkTS源码时会推导分析ArkTS的类型信息并传递给ArkCompiler eTS运行时。运行时直接利用类型信息静态生成内联缓存\(inline caching\) 从而加速字节码执行。另外ArkCompiler eTS Runtime规划中的TSAOT \(Ahead-of-Time\) Compiler可以利用ts2abc传递的类型信息直接编译生成高质量的机器码使得应用可以直接以机器码形式运行提升运行性能。
- **轻量级Actor并发模型** ECMAScript没有提供并发规范业界JS引擎的实现中常用Actor并发模型。此模型下执行体之间不共享任何数据通过消息机制进行通信。业界当前实现的JS Actor模型\(web-worker\) 有启动速度慢、内存占用高这些缺陷。为了利用设备的多核能力获得更好的性能提升运行时需要提供启动快、内存占用少的Actor实现。目前ArkCompiler eTS Runtime已经实现在Actor内存隔离模型的基础上共享actor实例中的不可变或者不易变的对象\(方法和字节码\) 后续继续共享内建代码块、常量字符串等等来提升Actor的启动性能和节省内存开销达到实现轻量级Actor并发模型的目标。
- **ArkTS/C++的跨语言交互:** 在OpenHarmony操作系统平台API实现中通常需要面临C/C++代码访问和操作ArkTS对象的场景。对这个业务场景ArkCompiler eTS Runtime规划可以根据ArkTS程序中的class声明和运行时约定静态生成包含ArkTS对象布局描述的C/C++头文件以及操作这些对象的C/C++实现库。在C/C++代码中通过包含对象描述头文件以及链接对应实现库实现直接操作ArkTS对象的效果。由于ArkTS类型或其内在布局并非总是固定不变的因此在对象操作的代码实现中会插入类型检查如果对象类型或布局在运行时发生变化则回退执行通用的慢速路径。
- **并发并发模型优化与并发API**
ECMAScript规范没有提供并发语义表述业界引擎如浏览器或者Node.js通常会提供基于Actor并发模型的Worker API来支持多线程开发。Actor模型下执行体之间不共享任何数据对象通过消息机制进行通信。因此Web引擎或者Node.js引擎的Worker都有启动速度慢、内存占用高这些缺陷。
针对这些缺陷ArkCompiler的运行时已经实现了Actor实例中的不可变或者不易变的对象方法和字节码的共享较大程度地优化了Actor的启动性能和启动内存。
方舟编译运行时不只提供了业界通用的Worker API还提供了TaskPool作为并发API的增强。TaskPool是一个支持优先级调度、工作线程自动扩缩容的任务池功能库。开发者无需关心并发实例的生命周期也无需关心任务负载变化时需要创建或者销毁并发实例极大地简化了高性能多线程鸿蒙应用的开发。
- **安全** ArkCompiler前端编译工具链将ArkTS/TS/JS程序预先静态编译为方舟字节码并且还提供了多重混淆能力的增强有效地提升了开发者代码资产的安全强度。另外出于安全的考虑ArkCompiler不支持sloppy模式的JS代码也不支持eval等运行动态字符串的功能。