登录社区云,与社区用户共同成长
邀请您加入社区
摘要: 鸿蒙系统中Qt编辑器与系统剪贴板的兼容性问题导致复制粘贴失效,原因是Qt的QClipboard与鸿蒙的Pasteboard服务未完全打通或MIME类型不匹配。解决方案采用混合编程桥接:通过ArkTS调用鸿蒙原生Pasteboard接口,C++层同步处理Qt剪贴板操作,确保跨应用粘贴功能。拖拽功能因协议支持不足暂推荐使用系统分享机制。此方案通过少量NAPI代码快速修复用户体验痛点。
Lycium++是基于 OpenHarmony PC C/C++ 编译框架Lycium的增强版本,提供更强大的自动化构建能力和依赖管理功能。HNP (HarmonyOS Native Package) 是 HarmonyOS 的原生包格式,可以直接在 HarmonyOS 系统上安装和使用。
使用 AtomCode + Skills 自动完成Protobuf鸿蒙化适配。
本文介绍了将硬件拓扑检测库hwloc 2.14.0适配到鸿蒙PC平台的完整流程。主要内容包括: 通过AtomCode Skills工作流快速生成autoconf类项目的HPKBUILD骨架 解决关键编译问题: 安装缺失的libtool工具链 修补config.sub文件以识别OpenHarmony操作系统 详细记录了从环境检查、构建引导到最终安装的全过程 提供了适配后的仓库地址和构建文档资源 该适
开源鸿蒙PC社区邀请开发者共建鸿蒙生态,助力C/C++三方库移植。文章介绍了LuaJIT(Lua的JIT编译器)在鸿蒙PC平台的适配过程,重点展示了如何使用AtomCode Skills工具链简化移植工作流。主要内容包括:1)通过/new-package自动生成HPKBUILD构建脚本;2)利用/build-check验证交叉编译环境;3)通过/porting-reviewer审查构建问题,如解决
鸿蒙PC应用集成libhv三方库的AI辅助实践 摘要:本文介绍了基于AtomCode智能编码助手和lycium系列Skills,在鸿蒙PC(2in1)设备上高效集成libhv网络库的全流程解决方案。通过对比传统集成方式(耗时170-200分钟)与AI辅助方案,重点展示了如何利用"lycium-app-integration"等技能模板自动完成工程创建、三方库部署、CMake配置、NAPI桥接等关键
开源鸿蒙PC社区SDL3适配实践摘要 本文介绍了将跨平台多媒体库SDL3(v3.4.10)适配到鸿蒙PC平台的全过程,重点解决NAPI桥接、ArkTS语法合规及平台差异等核心问题。通过AtomCode Skills工具链优化传统适配流程,实现了SDL3 C API与鸿蒙ArkTS的高效互操作。关键步骤包括: NAPI桥接设计:通过C++层封装7个SDL3测试函数,采用统一字符串格式返回结果(含✅/
开源鸿蒙三方库移植与生态构建实践 本文以libhv网络库为例,详细介绍了基于AtomCode Skills的开源鸿蒙(OpenHarmony)C/C++三方库适配全流程。通过/new-package自动生成HPKBUILD构建脚本,结合/porting-reviewer分析musl libc兼容性问题,展示了从环境检查到最终构建的完整移植路径。重点解决了CMake交叉编译配置、musl API差异
鸿蒙应用集成 spdlog 鸿蒙化三方库 —— 使用 AtomCode + Skills 提升集成效率实践
开源鸿蒙PC社区邀请开发者共建C/C++三方库生态 本文介绍了HTTP基准测试工具wrk v4.2.0在鸿蒙PC平台的适配过程。主要内容包括: 技术背景:wrk是高性能HTTP压测工具,依赖LuaJIT和OpenSSL,需处理musl libc与glibc的兼容性问题 适配流程: 使用AtomCode Skills工具自动生成HPKBUILD构建脚本 解决交叉编译环境配置问题 处理LuaJIT和O
本文介绍了如何通过AtomCode和Skills工具将libuv库集成到HarmonyOS NEXT应用中,包括工程创建、三方库部署、CMake配置、NAPI桥接、类型声明和ArkUI验证等全流程。重点解决了跨平台异步I/O库集成中的编译链接和NAPI桥接等关键问题,并提供了自动化的CMake配置和NAPI代码生成方案,显著提升了开发效率。通过实际示例展示了libuv版本查询、功能测试等接口的Ar
不知道你有没有这种经历:交叉编译通过了,libsodium 的 806KB 静态库也部署到项目里了,结果写 NAPI 桥接时发现需要为 50 多个头文件的加密库写上百个函数封装——从到,每一个都要手动处理 napi_typeof、napi_create_string_utf8……libsodium 是一个现代、可移植、易用的加密库,提供对称加密、公钥加密、数字签名、密码哈希等全方位加密能力,API
本文介绍了将加密库 libsodium 适配到鸿蒙 PC 平台的完整流程。libsodium 是一个轻量级、易用的现代加密库,相比 OpenSSL 具有更简洁的 API 设计。适配过程基于 lycium_plusplus 框架,主要步骤包括:生成 HPKBUILD 构建脚本骨架、配置交叉编译环境、解决平台兼容性问题、验证构建结果。文章详细说明了 autotools 项目在鸿蒙平台的特殊处理方式,并
libuv在鸿蒙PC平台的适配实践 本文详细记录了libuv 1.52.1在鸿蒙PC平台的完整适配过程,包括: 使用AtomCode Skills自动化工作流生成HPKBUILD构建脚本 配置OHOS SDK交叉编译工具链和musl libc环境 解决平台差异性问题(如cpu_set_t未定义等) 通过CMake工具链文件指定鸿蒙专用编译选项 构建验证和问题修复的全流程 关键点: 使用/new-p
摘要: 本文介绍了如何在鸿蒙应用中集成11Zip压缩库的完整流程,借助AtomCode AI编码助手及其Skills系统自动完成NAPI集成。内容包括工程初始化、CMake配置、NAPI桥接、ArkTS适配验证,以及解决std::filesystem沙箱兼容性问题等关键步骤。同时提供了资源链接和实战中遇到的undefined symbol问题的排查与解决方案。 关键词: 鸿蒙应用、11Zip、At
本文介绍了如何使用 AtomCode Skills 工具链高效地将 spdlog C++ 日志库适配到 OpenHarmony 平台。spdlog 是一个高性能的 C++17 日志库,通过自动化工具链可大幅简化移植流程。文章详细展示了从生成 HPKBUILD 骨架、环境检查、问题审查到最终构建验证的全过程,重点突出了 AtomCode Skills 在自动生成构建脚本、检测环境依赖和审查潜在问题方
本文介绍了如何将SDL3(Simple Directmedia Layer 3)跨平台多媒体库适配到鸿蒙PC平台。主要内容包括: 背景与挑战:OpenHarmony使用musl libc和自有工具链,需要解决API差异、平台检测等问题 适配工作流: 使用AtomCode Skills工具自动生成HPKBUILD构建脚本 配置20+个CMake选项,关闭不必要的图形后端 通过环境检查、问题定位、构建
摘要 本文介绍了将高性能JSON解析库simdjson适配到OpenHarmony平台的全过程。simdjson利用CPU的SIMD指令实现每秒GB级JSON解析性能,但需要针对OpenHarmony的musl libc和OHOS SDK工具链进行适配。 适配工作采用AtomCode Skills工具链,通过自动化流程显著提升效率: 使用/new-package一键生成HPKBUILD构建脚本骨架
本文介绍了如何利用AtomCode智能编码助手和lycium系列工具链,高效集成simdjson高性能JSON解析库到鸿蒙PC应用中。文章首先分析了simdjson在鸿蒙生态中的必要性,指出其在处理大文件、高频数据交换等场景的性能优势。随后详细说明了集成过程中的特殊挑战,包括单头文件编译耗时、SIMD指令集依赖等问题。通过与传统手工集成方式的耗时对比(200-245分钟),展示了AtomCode结
本文是Lycium适配系列的第六篇,总结了适配过程中的关键注意事项与最佳实践。主要内容包括:1)依赖管理规则,强调依赖名称精确匹配和架构超集要求;2)架构超集规则的必要性和常见配置方案;3)鸿蒙本机构建(DevBox)的使用场景、特性及与交叉编译的区别;4)SHA512SUM校验机制流程及最佳实践。文章旨在帮助开发者避免常见陷阱,确保库适配的顺利进行。
摘要: 本文是Lycium适配系列的第一篇,介绍了Lycium框架的核心概念与交叉编译环境搭建。Lycium是OpenHarmony官方提供的C/C++三方库交叉编译框架,采用类似Arch Linux PKGBUILD的设计,通过HPKBUILD文件描述库的元数据和构建流程。文章详细说明了构建机环境要求(Ubuntu/macOS/WSL)和必备工具链,并解析了OpenHarmony SDK的关键组
本文是Lycium适配系列的第五篇,通过流程图详细解析了适配者、Lycium框架和OHOS SDK三方的协作机制。适配者负责编写HPKBUILD定义构建逻辑,Lycium框架自动化执行多架构构建流程,OHOS SDK提供交叉编译工具链等基础设施。文章总结了各角色的具体职责:适配者需完成环境搭建、代码适配等8项核心工作;Lycium框架承担环境加载、依赖解析等8项自动化任务;OHOS SDK则提供编
有些项目的# 安装库文件# 安装头文件# 安装 pkg-config 文件cd $OLDPWDLycium 构建系统为 OpenHarmony PC 平台的第三方库适配提供了标准化、自动化的解决方案。通过正确编写HPKBUILD✅快速移植:标准化流程减少重复工作✅依赖管理:自动处理库之间的依赖关系✅质量保证:SHA512 校验和测试框架确保质量✅社区协作:统一的格式便于代码审查和维护。
编译工具优先选择clang++/毕昇C++编译器,避免g++的兼容性问题;代码层面需解决LINE_MAX未定义、ARM架构关键字适配、STL标准库依赖等问题;编译命令添加宏,确保POSIX接口正常使用,指定C++11+标准以支持现代C++特性;工程化开发可使用CMake管理多文件项目,静态编译简化分发流程,GDB调试定位问题。
不依赖设备上的 Python 或任何运行时,安装即用;上游 kiwi 头文件一行未改,适配逻辑全部集中在;Native 层直接求解,没有子进程、没有 ABI 风险;求解核心与 N-API 解耦,开发机上用普通 C++ 编译器就能先测对;三个模块普通用户和开发者都能直接上手;DevEco / hvigor 构建通过,真机实测三个模块都正常。从这次适配可以总结出一条和 Python 库不一样的接入思路
以 libmediainfo 为例,从零开始讲解如何在鸿蒙应用中集成和使用 C/C++ 三方动态库。
本文介绍了如何在OpenHarmony系统中适配GIF处理工具gifsicle。主要内容包括:1)遵循tpc_c_cplusplus标准规范,使用Lycium工具链进行交叉编译;2)针对gifsicle需要bootstrap生成configure脚本的特点,在prepare阶段处理;3)提供了完整的HPKBUILD配置文件示例,包含多架构支持、编译参数优化等关键配置;4)说明了设备端测试验证的规范
一套脚本:定位 NDK → 拉源码 → 自底向上编依赖 → 编主库 → 装产物;几个静态库合并进一个,NAPI 只做“路径进、文字出”的桥接;ArkTS 负责选图、沙箱中转、结果展示;上游 Tesseract 源码一行未改,适配全部集中在ohos/。和 header-only 的 kiwi 相比,Tesseract 这类库的难点全在“依赖链”。先用 NDK 工具链把依赖自底向上编成静态库(PIC)
错误信息原因分析;但Jamroot中没有定义项目。解决方案在Jamroot中添加# 在 build_ohos.sh 中添加if!then/a\# 备用方法:在文件末尾添加EOFfi对应的Jamroot使用空版本号: 在中使用空版本号,让 Boost.Build 使用完整路径工具集名称: 使用而不是编译器路径: 在中指定完整的交叉编译器路径A:中定义了隐式依赖,但Jamroot中没有定义这个项目。添
设备:我使用的MateBook Pro已经升级到6.0.0.115版本,建议升级到该版本以上代码管理工具GitNext,作为代码管理工具下载管理三方库等,下载后可在系统终端中使用(个人推荐),也可以使用界面管理编译工具链DevBox,包含了llvmclangautoconfbashcmakemakeninjahdchnpclim4等编译基础工具,安装后可在系统的终端中使用Python环境Pytho
我将对这块内容做一个科普,并通过“造轮子”的方式,用 100 行代码自己实现一个运行时,带大家体会其中的原理。
众所周知,操作系统的大部分关键能力都是实现在内核中。那么操作系统是如何把内核的能力提供给应用程序使用呢?是通过一个叫做“系统调用”(system call,简称 syscall)的机制。
man page 是 Unix 和类 Unix 操作系统上的一种软件文档形式。涵盖的主题包括程序、系统库、系统调用,有时还包括本机系统详细信息。
所谓 JIT 技术,说的是即时编译技术(英文全称为 Just-in-Time Compilation)。
lycium_plusplus(lycium++)提供高效的,支持外部仓导入的鸿蒙三方库交叉编译框架
元对象系统运行时类型信息(RTTI)信号槽机制属性系统对象间通信Q_OBJECT// 只读属性// 可读写属性// 可重置属性// 常量属性CONSTANT)public:// 只读属性// 可读写属性// 可重置属性= size) {// 默认值// 常量属性signals:private:// 注册枚举Q_OBJECTpublic:Q_ENUM(TimeFormat) // 注册枚举// QM
✅ 应用启动和生命周期问题✅ UI显示相关问题✅ C++与QML集成问题✅ 构建编译问题✅ 性能优化问题✅ 实用的调试技巧从简单版本开始,逐步添加功能遇到问题先看日志使用调试输出定位问题参考官方文档和示例代码坚果派2025-11-08Qt for HarmonyOS 实战指南。