- 博客(73)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 OpenHarmony Loader 流程深度逐行解析（以 rk3568 为例）
Loader是 OpenHarmony 构建系统的第二阶段，紧接 preloader 之后执行。out/preloader/rk3568/*.json (preloader 输出，作为 loader 输入)↓Loader（扫描 + 生成）↓out/rk3568/build_configs/ (loader 输出)├── BUILD.gn (顶层组)├── parts_list.gni (361 个部件)├── inner_kits_list.gni (跨部件接口)
2026-06-16 19:16:32
80
原创 OpenHarmony Preloader 流程深度逐行解析（以 rk3568 为例）
Preloader是 OpenHarmony 构建系统的第一阶段，负责把产品配置（）转换成 GN 可读的中间文件。vendor/hihope/rk3568/config.json (输入)↓Preloader↓out/preloader/rk3568/*.json (输出，14 个文件)核心目标：把 OpenHarmony 的"产品级配置"翻译成 GN 能理解的格式。self.__post_init__() # 1. 初始化关键设计：父类强制子类按这个顺序执行，子类不能改变。为什么有顺序？
2026-06-16 19:15:36
27
原创 OpenHarmony 四层架构深度解析：系统 → 子系统 → 部件 → 模块
系统是面向产品形态产品名称（如 rk3568、ohos-sdk）硬件平台（target_cpu、target_os）包含哪些子系统和部件各部件的 feature 开关vendor/<厂商>/<产品>/config.json示例子系统是功能领域的分组，按技术栈划分（而不是按组织架构）。这是全局唯一的子系统注册表。部件是可插拔的功能单元，是产品定制的最小粒度。<子系统路径>/<部件目录>/bundle.json示例模块是实际的编译目标，一个模块生成一个产物（.so / .elf / .a）。
2026-06-16 19:12:22
35
原创 OpenHarmony 构建失败调试指南
先看 log 末尾,后看其他错误码首位定阶段,具体值定原因GN 错误看ERROR at,Ninja 错误看隔离比全量更快定位问题(gn desc和是金钥匙不确定时,先排除残留改一处验证一次,不要批量修改错误码手册是地图,不是答案 — 答案在 log 里。
2026-06-16 19:12:09
27
原创 OpenHarmony 编译错误码完整手册
OpenHarmony 构建系统使用4 位错误码体系，定义于，由类抛出，装饰器捕获后输出。字段内容类型匹配模式解决方案1. 检查库或目标文件是否正确链接2. 检查函数名拼写3. 确保函数已定义和编译修复：在BUILD.gn中添加缺失的依赖。deps = [ "//foundation/libmy:my_func_lib" ] # ← 添加依赖分层分类：首位标识阶段，便于快速定位数据驱动：错误码定义集中在可扩展：新增错误只需修改 JSON + 抛出异常自动匹配：部分错误码通过pattern。
2026-06-15 09:22:46
27
原创 OpenHarmony 工具链定义和切换机制
lib_dir = "usr/lib/aarch64-linux-ohos" # 库路径current_cpu = "arm64" # 覆盖 current_cpu步骤工具链的本质封装平台差异：不同 CPU 架构的编译参数定义工具路径：clang、ar、ld 等工具的位置设置 sysroot：标准库和启动文件的路径支持多工具链：同一构建中可以有 target 和 host 两套工具链关键概念— GN 工具链定义— 设置全局工具链— 工具链内变量覆盖— 切换到宿主工具链。
2026-06-15 09:17:18
14
原创 OpenHarmony GN 调试技巧和常见问题
调试流程问题 → 定位层级 → 使用工具 → 验证修复定位层级：├── 产品配置？→ 检查 config.json→ 检查 parts.json├── loader？→ 检查 parts_list.gni├── GN 语法？└── 依赖错误？核心命令gn desc— 查看目标详情gn check— 检查依赖gn refs— 反向依赖gn path— 依赖路径— 查看参数。
2026-06-15 09:16:18
14
原创 OpenHarmony GN 模板体系深度解析
必需：sources_lists（多个源文件列表）# 把所有列表合并"deps",])使用GN 模板的本质封装：把通用逻辑（编译选项、依赖检查、安装注册）封装起来标准化：所有 OHOS 模块强制遵守相同规范元数据：自动生成模块元数据（用于 SBOM、打包）多目标：一个 ohos_executable 内部生成 10+ 个 GN 子目标关键设计模板组合（多个内部子目标）双下划线命名（避免冲突）Python 集成（action_with_pydeps）
2026-06-15 09:15:48
15
原创 OpenHarmony GN 如何生成 Ninja 文件（以 rk3568 为例）
本文是 GN → Ninja 转换机制*，基于 OpenHarmony rk3568 的真实文件进行逐行解析，揭示从BUILD.gn到的完整转换链路。defines关键宏含义宏含义-D__MUSL__使用 musl libc（轻量级 C 库）libc++ 适配 muslClang 编译 Linux 代码-DNDEBUG关闭 assert（Release 模式）组件化构建用户 BUILD.gn↓ GN 模板展开（ohos_executable）GN 内部表示（目标图）
2026-06-15 09:14:00
35
原创 OpenHarmony .gn 和 BUILDCONFIG.gn 深度解析
gn（30 行）— GN 的"引导程序"，告诉 GN 去哪里找配置（1195 行）— GN 的"全局配置"，定义所有全局变量这两个文件共同完成了 GN 的初始化和环境配置。.gn症状原因：在 BUILDCONFIG.gn 之前访问了该变量。解决：确保变量在 BUILDCONFIG.gn 中定义。.gn的作用指向 BUILDCONFIG.gn（全局配置）指向 root BUILD.gn（构建入口）设置脚本执行器和白名单（安全）BUILDCONFIG.gn 的作用。
2026-06-13 14:32:51
26
原创 OpenHarmony containers/status.py 深度逐行解析
职责实现说明统一异常捕获装饰器模式异常类型判断区分自定义和系统异常错误码体系4 位错误码首位标识阶段格式化输出结构化错误报告构建模式判断独立构建 vs 完整构建。
2026-06-13 14:22:45
54
原创 OpenHarmony containers/arg.py 深度逐行解析
是 OpenHarmony 构建系统中的参数容器和管理模块定义参数类型（bool、int、str、list、dict）解析命令行参数持久化参数到 JSON 文件管理构建阶段（prebuild、load、targetGenerate 等）↓↓ 读取默认参数↓ 解析命令行↓ 写入当前参数文件↓ 供后续阶段读取文件信息路径行数：421 行核心类Arg（参数容器）辅助类ModuleTypeArgTypeBuildPhaseCleanPhase职责方法说明参数定义__init__()
2026-06-13 14:21:38
30
原创 OpenHarmony hb/main.py 深度源码解析
空括号Main()等价于（Python 3 中所有类默认继承 object）。设计风格：Main 类只包含静态方法和实例方法（作为容器），不维护状态（无__init__hb/main.py是 OpenHarmony 新版构建系统的总控中心职责清晰：参数路由 + 模块初始化（不含具体逻辑）高度模块化：11 个子命令，每个对应独立模块依赖注入：所有服务对象在初始化时创建并注入装饰器增强：异常处理、构建跟踪代码质量：整体架构良好，但存在少量拼写错误和风格问题。push。
2026-06-13 14:18:59
53
原创 OpenHarmony tools_checker.py 深度源码解析
for pkg in _build_package_list: # ← 如果上面循环没有匹配，这里 NameError...问题：如果不匹配任何键，永远不会被赋值。后续会抛。触发场景如果 OS 版本不在 JSON 中（例如 Ubuntu 25.04 上线、JSON 没更新），且没拦下来（比如手动绕过），就会崩溃。但实际不出问题在 main 中先跑，过滤了不支持的版本所以走到这里时，host_version 一定能匹配 JSON 中的某个键但仍然是健壮性问题。改进。
2026-06-11 19:34:50
46
原创 OpenHarmony build.sh 调用的 Python 脚本全景分析
build.sh本身是 Bash 脚本，但真正的构建逻辑全部用 Python 实现。build.sh 直接调用的 Python 脚本（仅 3 处）这些 Python 脚本各自的职责和调用链间接被触发的 Python 脚本（GN action 阶段）整体调用链路的层级架构build.sh 调用 Python 脚本的核心原则shell 只做环境准备，真正的逻辑全部交给 Python三层入口：tools_checker（检查）+ entry.py（旧）+ hb/main.py（新）直接调用极少。
2026-06-11 19:16:46
55
原创 OpenHarmony build.sh 深度解析
pushd：进入目录并把旧目录压入栈，popd时回到旧位置。：隐藏 pushd 的默认输出（打印目录栈）。为什么要 pushd？后面和需要在特定目录执行，pushd/popd 是干净的进出目录方式（不污染全局 cwd）。
2026-06-11 19:14:53
187
原创 OpenHarmony Native C 应用开发指南
本文档以一个 “Hello World” 可执行程序为例，详细讲解如何在 OpenHarmony 标准系统（rk3568）上开发 Native C 应用。内容涵盖构建系统原理、GN 语法详解、bundle.json 字段说明、产品配置注册机制，以及完整的编译部署流程。
2026-06-10 16:07:55
62
原创 OpenHarmony RK3568 hdc 调试通道适配指南
OpenHarmony 使用hdc（HarmonyOS Device Connector）作为设备调试通道，对应 Android 的 adb。特性hdcadb协议OpenHarmony 自定义Android 自定义客户端服务端进程hdcdadbdUSB 类默认 VID/PID命令hdc shelladb shelladb push文件修改内容状态✅ 已修改usbdrd30✅ 已修改全部 status=disabled✅ 已修改（前置修复）vcc5v0_otg去 GPIO。
2026-06-08 17:07:11
73
原创 OpenHarmony RK3568 NPU 驱动适配指南
Module.symvers 中 CRC 字段固定为 0 是预期行为，不是 bug。采用独立 apply 脚本，遵循 OpenHarmony 内核模块的标准集成方式（与 newip、tzdriver、xpm 等模块一致）。目录（含 Kconfig、Makefile、11 个 .c 源文件），但。驱动先按名字查 IRQ 失败，再按索引查成功。如果重新编译内核，旧密钥失效，所有旧。选项，defconfig 中写了也不会生效。中包含了完整的 rknpu 驱动源码，但。），rknpu 驱动是为旧内核写的。
2026-06-08 17:06:40
273
原创 OpenHarmony RK3568 从 32 位切换到 64 位用户空间指南
修改了编译参数（如修复 Q5 后），但 ThinLTO 缓存中保留了旧参数编译的 bitcode。这是一种节省内存的设计（32 位指针占 4 字节 vs 64 位占 8 字节），但在某些场景下需要切换为纯 64 位。切换到 64 位用户空间后，CPU 全程运行在 AArch64 状态，不再需要 AArch32 兼容模式。内核本身已经是 64 位（aarch64），切换用户空间位数不影响内核。（32 位兼容层）在纯 64 位系统中不再需要，可以关闭以减小内核体积。这两个参数对 64 位编译毫无意义，配合。
2026-06-08 17:05:55
659
原创 OpenHarmony prebuilts_download.sh 原理详解
是 OpenHarmony 构建系统的预编译工具链管理器，负责从华为云镜像下载并部署构建所需的所有预编译工具（编译器、构建工具、SDK、npm 包等）。是一个高度自动化的预编译工具链管理系统声明式配置: JSON 统一管理所有工具,易于维护增量下载: SHA256 mark 文件避免重复下载并行加速: 多线程下载充分利用带宽平台适配: 自动识别 OS/CPU,下载对应版本幂等性: 可重复执行,失败后自动恢复按需过滤: 支持按 tag/build_type/part 精确控制核心优势。
2026-06-06 11:24:05
43
原创 OpenHarmony RK3568 完整编译流程深度详解
输入:vendor/hihope/rk3568/config.json (427 行)处理:├── _update_parts (合并 4 个数据源,共 ~500-800 个部件)输出:out/preloader/rk3568/*.json (~12 个文件)输入:各子系统目录下的 ohos.build / bundle.json (~500-800 个文件)处理:1. subsystem_info: 加载子系统映射表。
2026-06-06 11:23:44
250
原创 OpenHarmony 交叉编译深度解析
ohos_clang_toolchain("ohos_clang_arm") { ← RK3568 用这个ohos_clang_toolchain("ohos_clang_arm64") { ← ARM64 设备ohos_clang_toolchain("ohos_clang_x86_64") { ← x86_64 模拟器。
2026-06-06 11:23:10
27
原创 OpenHarmony 三种产品形态编译原理深度解析
OpenHarmony 通过 config.json中的type字段维度轻量级 (mini)小型 (small)标准 (standard)内核类型Linux典型 RAM> 128MB典型场景MCU、传感器、智能家居模组摄像头、可穿戴设备手机、平板、智慧屏工具链clangclang/LLVM构建链路构建配置入口(lite)(lite)(config)进程模型单进程多任务多进程完整 Linux 进程模型典型产品rk3568镜像格式.bin(固件)OHOS_Imagerootfs.img。
2026-06-06 11:22:32
28
原创 OpenHarmony RK3568 Windows 烧录完整指南
适用于: OpenHarmony v6.1-release目标设备: RK3568 (HiHope DAYU200 / Toybrick TB-RK3568X0)操作系统: Windows 10/11。
2026-06-06 11:22:00
77
原创 OpenHarmony prebuilts 目录详解
prebuilts/目录存放所有预编译的工具链和依赖，总计约 24GB。这些二进制文件不是从源码编译的，而是由脚本从远程仓库下载。它们为 OpenHarmony 构建系统提供编译器、链接器、运行时库、SDK 等基础设施。核心思想：开发者不需要自己编译 Clang、Rust、Node.js 等工具——直接下载预编译版本，保证所有人使用一致的工具链版本。编译对象使用的工具链路径用户空间 C/C++Linux 内核Rust 组件ArkTS/JS 应用tool/仓颉应用Windows 工具。
2026-06-05 12:05:08
92
原创 OpenHarmony 交叉编译深度解析
ohos_clang_toolchain("ohos_clang_arm") { ← RK3568 用这个ohos_clang_toolchain("ohos_clang_arm64") { ← ARM64 设备ohos_clang_toolchain("ohos_clang_x86_64") { ← x86_64 模拟器。
2026-06-05 12:04:22
312
原创 OpenHarmony 编译加速：ccache 使用指南
ccache（compiler cache）是一个编译缓存工具，通过缓存编译结果来加速重复编译。OpenHarmony 构建系统通过--ccache参数原生支持 ccache。结论说明默认就加--ccache除极少数场景外，加 ccache 只有好处首次编译略慢写缓存有 5-10% 开销，可忽略后续编译大幅加速命中率 80%+ 时，编译时间缩短 5-10 倍不影响编译正确性hash 严格匹配，不会返回错误的缓存与兼容缓存独立于编译产物目录。
2026-06-05 12:03:20
91
原创 OpenHarmony 编译资源复用指南
问题答案编译每个产品都要执行 prebuilts_download.sh 吗？不需要，整个 OpenHarmony 大版本只需执行一次编译每个产品都要重新编译 ohos-sdk 吗？不需要，同 API 版本下所有标准系统产品共用切换产品时需要做什么？只改参数即可。
2026-06-05 11:56:08
239
原创 OpenHarmony v6.1-release 编译指南
本文档记录在 Ubuntu 24.04 上编译 OpenHarmony v6.1-release（SDK 6.1.0.31，API 23）的完整流程，包括环境准备、依赖安装、编译步骤以及遇到的问题与解决方案。目标产品：RK3568 标准系统（ARM32）
2026-06-05 11:46:51
886
原创 virtual下Ubuntu24.04版本上配置网络与外网和宿主机之间互通
在VirtualBox 配置中，需要设置两个网络，第一网络用于与外网ping通，第二用于与宿主机ping通。
2025-05-19 13:52:40
718
原创 Ubuntu24.04版本解决RK3568编译器 libmpfr.so.4: cannot open shared object
之后到需要编译的应用程序目录重新编译即可。执行以下命令添加链接。
2025-05-15 11:17:40
507
原创 基于imx6ull平台opencv的图像采集和显示屏LCD显示功能（带Qt界面）
本文档是针对imx6ull平台opencv的图像采集和显示屏LCD显示功能，创建Qt工程，在工程里面通过点击按钮，实现opencv通过摄像头采集视频图像，将采集的视频图像送给显示屏LCD进行显示及拍照功能。
2024-09-14 21:11:21
732
3
原创 基于RK3568平台opencv的图像采集、ffmpeg推流和Windows端拉流(多线程)
本章节是针对ffmpeg移植到 Linux系统，运行在RK3568开发板上，首先创建一个线程opencv通过摄像头采集视频图像，接着再创建两个线程，其中一个线程获取采集的视频图像送给ffmpeg服务，另一个线程用于获取采集的视频图像并处理，详细的流程请参看如下。
2024-08-30 09:23:29
2244
1
原创 基于RK3568平台移植ffmpeg3.4.5及ffmpeg验证
本章节是针对ffmpeg移植到 Linux系统，运行在RK3568开发板上，ffmpeg验证主要包括http方式推流/拉流、rtsp方式进行推流/拉流，详细的移植流程及ffmpeg验证如下。
2024-08-29 11:03:07
1491
7
原创 基于imx6ull平台opencv的图像采集、ffmpeg推流和Windows端拉流(多线程)
本文档是针对imx6ull平台`opencv`的图像采集、ffmpeg推流和Windows端拉流。首先创建一个线程`opencv`通过摄像头采集视频图像，接着再创建两个线程，其中一个线程获取采集的视频图像送给ffmpeg服务，另一个线程用于获取采集的视频图像并处理，处理完并在显示屏上显示，详细的流程请参看如下。
2024-08-26 22:22:30
1580
1
原创 基于imx6ull平台opencv的图像采集和显示屏LCD显示功能（不带Qt界面）
本文档是针对imx6ull平台opencv的图像采集和显示屏LCD显示功能，opencv通过摄像头采集视频图像，将采集的视频图像送给显示屏LCD进行显示。
2024-08-25 17:52:04
1651
原创 基于imx6ull平台移植ffmpeg3.4.5及ffmpeg验证
本章节是针对ffmpeg移植到 Linux系统，运行在正点原子-I.MX6U ALPHA开发板上，ffmpeg验证主要包括http方式推流/拉流、rtsp方式进行推流/拉流，在ARM平台上RTP方式推流/拉流只能在ARM端进行，在Windows端无法进行，详细的移植流程及ffmpeg验证如下。
2024-08-25 16:01:10
969
原创 基于x86 平台移植ffmpeg3.4.5及ffmpeg验证
本章节是针对ffmpeg移植到 ubuntu系统，运行在虚拟机vmware上，ffmpeg验证主要包括http方式推流/拉流、rtp方式推流/拉流、rtsp方式进行推流/拉流，详细的移植流程及ffmpeg验证如下。
2024-08-25 11:53:13
453
HDMI TypeA多类型封装.PcbLib
2020-04-19
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人