主要应用场景

根据华为官方提供的方舟运行时指南，可以在Linux环境下运行方舟运行时。开发者可以使用此运行时系统调试代码等，提高调试效率，不需要每次调试都烧录到设备。
方舟运行时官方指南的内容简洁，对于新手来说理解成本较高。以下通过分析运行时指南整理了ArkCompiler运行时平台的功能，帮助初学者构建更清晰的学习路径。
本文主要包括以下内容：

• 运行时功能：直接说明你可以使用ArkCompiler进行的一些活动。
• 运行时使用指南解析：如果你希望详细了解ArkCompiler的使用细节，可以阅读这部分。对于官方指南进行进一步解析，对于一些细节和知识点进行具体的解释。
  注意：本地运行时通常不包含完整的UI组件、系统硬件API（如蓝牙、传感器）的模拟，主要用于验证纯逻辑、计算、数据结构和核心运行时行为。对于强依赖系统服务的功能，仍需在真机或模拟器上验证。

注：

1. 本人并无嵌入式开发经验，该文章只是对于文档的一些分析。期望未来有真实使用体验该工具的开发者进行分享。
2. 本文主要面向一些和本人一样此前未接触过嵌入式开发的人，包含一些比较基础且详细的介绍内容（文末的两个附录），目的是降低由方舟进行时开始了解相关概念的难度。

运行时功能

1.丰富调试工具带来的深度调试

比烧录更高效的调试循环：

# 传统烧录调试：修改→编译→烧录→重启→测试
# 方舟运行时调试：修改→编译→运行测试
./build.sh --product-name rk3568 --build-target ark_js_host_linux_tools_packages
./out/rk3568/clang_x64/arkcompiler/ets_runtime/ark_js_vm test.abc

丰富的调试工具：

• 字节码级调试（反汇编器）
• 性能分析（PGO profiling）
• 内存行为分析
• 标准符合性验证（Test262）

2. 面对设备的定制开发

架构适配：

• 为不同的CPU架构（ARM32/ARM64）生成优化后的运行时
• 针对特定设备的性能特征进行调优
  功能裁剪：
• 根据设备能力选择性地包含运行时组件
• 为资源受限设备生成最小化运行时

运行时使用指南解析

环境配置

建议另外参考ArkCompiler开发指导，在编译前安装编译器及二进制工具。

编译

全量编译（首次编译）

./build.sh --product-name rk3568

增量编译（文档中给出的4个编译选项）

1. 编译linux-x86版本：

./build.sh --product-name rk3568 --build-target ark_js_host_linux_tools_packages

2. 编译oh-arm64版本：

./build.sh --product-name rk3568 --gn-args use_musl=true --target-cpu arm64 --build-target ark_js_packages

3. 编译oh-arm32版本:

./build.sh --product-name rk3568 --build-target  ark_js_packages

前三个针对不同版本的编译命令，使得运行时能够适配x86和ARM两个不同架构。

4. 编译方舟前端：

./build.sh --product-name rk3568 --build-target ets_frontend_build

方舟前端可以/需要单独增量编译的原因：
这个指令可以单独更新ArkTS到字节码的前端编译器。
前端编译器与运行时是独立开发的，可以分别更新测试

注：虽然指南文档中有关于更多编译指令的链接，但是该链接文章中并无任何关于编译指令的内容。应该是链接错误。
更多编译指令可以参考以下两个文档（主要是第一个）：
arkcompiler_ets_runtime/docs /using-the-toolchain.md : https://gitee.com/openharmony/arkcompiler_ets_runtime/blob/master/docs/using-the-toolchain.md
ark_js_runtime/docs/using-the-toolchain-zh.md: https://gitee.com/openharmony/ark_js_runtime/blob/OpenHarmony-v3.1-Release/docs/using-the-toolchain-zh.md

Release和Debug版本

之前给出的编译命令为release版本，编译debug版本需增加编译选项：--gn-args is_debug=true。
关于开发过程中两种版本的选择，可以参考文末附录一 编译为Release版本和Debug版本的区别。

编译结果：二进制文件

out/rk3568/arkcompiler/runtime_core/
out/rk3568/arkcompiler/ets_frontend/
out/rk3568/arkcompiler/ets_runtime/
out/rk3568/clang_x64/arkcompiler/runtime_core/
out/rk3568/clang_x64/arkcompiler/ets_frontend/
out/rk3568/clang_x64/arkcompiler/ets_runtime

• runtime_core/：运行时核心组件（虚拟机、AOT编译器）
• ets_frontend/：ArkTS到字节码的编译工具
• ets_runtime/：完整的运行时环境
• clang_x64/：x86主机版本的工具链

rk3568：

见文末附录二 rk3568芯片。

rk3568/arkcompiler/…(目标平台输出)：

这些是要部署到rk3568设备上运行的二进制文件，在rk3568芯片（ARM64架构）的硬件上实际运行。

rk3568/clang_x64/arkcompiler/…（主机工具链）：

这些是在x86-64开发机上运行的编译工具，在开发机上编译ArkTS源代码，生成可在rk3568上运行的字节码/二进制。
作用：解决“开发者通常使用x86-64的电脑开发，但目标设备是ARM64”带来的问题。

开发实例

HelloWorld

使用方舟运行时和方舟前端，运行一个简单的js文件；反汇编由方舟前端生成的abc文件。

• 作用：验证工具链完整性，提供最简开发流程
• 面向：新手上手、环境验证、基础调试

Test262测试套件

• 作用：确保JavaScript/ECMAScript标准兼容性
• 面向：
  • 运行时开发者验证标准符合度
  • 比较不同引擎（d8, hermes, jsc等）的行为差异
  • 回归测试确保新版本不破坏现有功能

AOT执行流程

• 作用：展示性能优化全流程（解释执行→PGO profiling→AOT编译）
• 面向：性能敏感场景的深度优化

工具链使用

源文档中有完整的使用选项。

es2abc（前端编译器）：

• 作用：将ArkTS/JavaScript源码编译为字节码
• 关键选项：
  • --module：支持ES模块系统
  • --opt-level：控制编译优化级别
  • --dump-ast：输出抽象语法树（用于语言特性调试）

ark_disasm（反汇编器）：

• 作用：字节码↔可读汇编的双向转换
• 面向：虚拟机开发者调试字节码生成问题

ark_aot_compiler（AOT编译器）：

• 作用：将字节码编译为原生机器码
• 关键能力：基于PGO信息的智能编译决策

PGO工具链：

• 作用：通过运行时分析识别热点代码，指导AOT编译优化
• 价值：在编译时间、包大小、运行性能间取得平衡

附记与致谢

本文是笔者在南京大学本科三年级课程《移动互联网应用开发》中完成的作业结果之一。通过对ArkCompiler运行时指南的分析，以及对工具的一些简单使用，尝试简单分析华为方舟运行时的主要功能。感谢OpenHarmony开源项目提供的学习机会，也感谢课程老师的指导。文中观点仅为个人基于公开内容的分析，如有理解偏颇之处，欢迎指正和补充。本文已同步发布在华为开发者社区。

附录1 编译为Release版本和Debug版本的区别

在华为方舟运行时指南中，给出了可以修改编译release版本或debug版本的编译指令。这里解释了两种不同版本的主要区别，以及两种版本分别的应用场景。

Release（发布）和Debug（调试）版本

参考资料：
https://blog.csdn.net/macpander/article/details/153124554
https://soft.zhiding.cn/software_zone/2008/0709/970120.shtml

区别维度	Debug	Release
主要目标	便于开发调试，定位问题	追求运行速度、体积最小化和交付稳定
编译优化	关闭或最低，代码顺序与源码几乎一致，便于跟踪。	启用高级优化，编译器会调整代码以提升性能，但可能改变执行流程。
调试信息	包含完整调试信息，支持端点、单步调试、查看变量。	无调试信息，减小体积，同时防止代码被反汇编分析。
断言与日志	启用	禁用
运行时检查	可能包含额外的内存检查、栈堆保护等，以捕获错误。	移除。
性能与体积	运行慢，体积大。	运行快，体积小。 是优化后的产物。

注意：

1. Debug与Release的界限是灵活的：它们本质上是不同编译选项的集合，开发者可以按需调整选项，生成带部分调试信息的优化版本，以满足特定需求。
2. 开发中可能会发生 “Debug正常但Release出错”的情况：这通常是代码存在隐患的标志。因为Release版具有优化过程（如帧指针省略、变量优化）并去除了安全检查，可能会让一些在Debug版中被掩盖的问题（如内存越界、未初始化变量）暴露出来。例如，一个不严谨的内存访问可能在Release版中直接导致崩溃。

不同的使用场景

基于两个版本的使用目标和性能体积上的区别，可以区分出如下的使用场景。
可以看出实际的开发过程必然需要两种版本的搭配使用。

从开发阶段的角度考虑：

开发阶段	版本	原因与目的
功能开发与日常调试	Debug	需要频繁打断点、单步执行、查看变量内存状态。
修复复杂bug	Debug	面对复杂或诡异的Bug，Debug版本提供的断言、完整符号信息、未优化的代码流很有用。
自动化测试（部分）	Debug	用于进行静态分析、代码覆盖率测试等，这些工具依赖调试信息。也用于运行包含大量断言的单元测试。
自动化测试（部分）	Release	用于进行性能基准测试、压力与稳定性测试、安全扫描、安装/升级测试，以及最终的功能与兼容性验收测试，这些测试必须在无限接近用户实际环境的版本上进行。
性能调优与基准测试	Release	必须使用Release版本。因为Debug版本的性能与最终版本差异巨大，在其上的性能数据没有参考价值。需要在真实的优化环境下定位性能瓶颈。
内存与资源泄露检查	视情况	一些高级内存分析工具（如Valgrind）可能在Debug版本上工作得更好。但查看Release优化后的实际内存占用，也需要在Release版上测试。
发布前最终测试	Release	进行用户验收测试（UAT） 或生产环境模拟测试，确保应用在最终状态下的功能、性能和稳定性完全达标。
生成交付给用户的产物	Release	交付的必须是经过充分优化、体积最小、去除了调试信息的Release版本，符合最终用户的使用场景。

注意：在资源受限的设备上，全系统Debug镜像可能过大无法烧录。此时标准做法是编译 “Release版本的全系统” + “Debug版本的特定模块”，然后进行单模块替换和调试。（关于具体的OpenHarmony烧录流程(OpenHarmony开发-系统烧录-云社区-华为云)）

从开发人员角色的角度考虑：

开发人员	版本	原因与目的
应用功能开发者	以Debug为主	主要负责编码和调试业务逻辑，需要快速验证和修复问题。
系统底层/驱动开发者	混合使用	调试硬件交互、内核模块时极度依赖Debug版本。但在验证驱动效率、中断延迟时，必须切换到Release版本测试。
测试工程师	混合使用	白盒测试：使用Debug版本进行代码级测试。 黑盒/性能/压力测试：必须使用Release版本，以模拟真实用户环境。
性能优化工程师	以Release为主	其工作始于Release版本发现的性能问题，并最终需要在Release版本上验证优化成果。
持续集成(CI)工程师	混合使用	CI流水线中通常会配置两条并行编译链：一条编译Debug版运行单元测试，一条编译Release版进行打包和部署。

从开发产物的类型考虑：

开发产物	版本	原因与目的
最终用户手中的设备/软件	Release	这是软件交付的最终形态，保证用户体验（快、稳、省电）。
应用市场上架的应用	Release	所有应用商店（包括OpenHarmony应用商店）都要求上架包为Release版本。
预装在设备中的系统镜像	Release	设备出厂时预装的系统必须是经过充分优化的Release版本。
开发板上的测试镜像	通常是Release	为获得真实的性能表现和存储占用，提供给评测者或合作伙伴的镜像一般为Release版。
内部测试团队使用的测试包	视测试类型而定	功能测试包：可能是Debug版（便于提Bug时定位）。 性能/续航测试包：必须是Release版。
用于调试的本地构建	Debug	开发者在自己电脑或设备上为排查问题而临时编译运行的版本。
CI/CD流水线中的中间产物	两者皆有	流水线中既会产生Debug版用于分析，也会产生Release版用于归档和部署。

附录二

以下内容主要为AI生成。

RK3568 是瑞芯微（Rockchip）公司设计的一款高性能、高集成度的应用处理器芯片。
它对应的设备主要是中高端的嵌入式智能硬件和物联网设备，定位介于传统的单片机和高功耗的PC/服务器之间。

核心规格

• 架构： 四核 ARM Cortex-A55 核心。
• 位宽： 完全符合ARM64 架构。
• 制程： 22nm，在功耗和性能间取得了良好平衡。
• GPU： ARM Mali-G52 GPU，支持基础的图形和视频处理。
• 关键特性：
  • 内置独立的 0.8 TOPS 算力的 NPU，用于机器学习推理。
  • 支持丰富的接口：双千兆以太网、USB 3.0、PCIe、HDMI、eDP等。
  • 强大的多媒体能力：4K@60fps H.265/H.264 视频解码。

主要对应的设备类型

RK3568因其“全能”特性，被广泛应用于以下领域：

1. 智能网络设备 (NVR/IPC)：
   • 网络视频录像机：利用其强大的视频解码能力和双网口，非常适合作为家庭或中小企业的安防主机。
   • 网络摄像头：用于高端智能摄像头。
2. 工业控制与边缘计算网关：
   • 工控主机、HMI人机界面。
   • 工业网关，负责协议转换和边缘侧的数据处理。
3. 单板计算机与开发板：
   • 这是开发者最常接触的形态。例如：
     • 瑞芯微官方评估板
     • Firefly Station P2：一款非常流行的开源硬件平台。
     • 众多中小厂商生产的开发板和工控主板。
   • 开发者在其上运行 Linux、Android 或 OpenHarmony 等操作系统。
4. 商用与自助终端：
   • 广告机、数字标牌、POS收银机、自助售货机等。
5. 轻量级服务器/云终端：
   • 作为低功耗的轻量级家庭服务器（如NAS、软路由、家庭自动化中心）。

为什么编译输出目录以它命名？

在我们看到的编译环境中，rk3568/ 文件夹代表 目标设备的配置和编译输出。

• out/rk3568/arkcompiler/...：这里面的二进制文件，就是专门为 RK3568 这颗 ARM64 芯片编译的运行时库。它们只能运行在 RK3568 或相同架构的设备上。
• out/rk3568/clang_x64/...：这里面的工具，是为了开发 RK3568 应用，而在 x86 主机上运行的工具链。
  这种命名方式清晰地表明了：“这个构建配置的产物，最终是要在 RK3568 设备上运行的”。

总结

可以将 RK3568 理解为 嵌入式领域的“中坚力量”：
它不是手机芯片，不追求极致的移动性能和功耗，它也不是微控制器（如STM32），能力远超简单的控制。它是一个“应用处理器”，专注于在固定或低移动性场景下，提供足够的通用计算能力、多媒体处理能力和丰富的连接性，以运行完整的操作系统（如Linux）和复杂的应用程序。
当在OpenHarmony、Android或Linux的编译输出中看到以具体芯片（如rk3568, hi3516, rk3399）命名的目录时，几乎可以肯定那是指目标硬件平台。