鸿蒙与Rust(15)——原生开发动态链接库

在 HarmonyOS（鸿蒙系统）和 OpenHarmony 的原生开发（C/C++ NDK 开发）中，系统提供了丰富的动态链接库（Dynamic Linked Libraries）。

动态链接库

鸿蒙的系统级动态库主要涵盖了 ArkTS/JS 交互、UI 渲染、图形图像、多媒体、数据存储、底层基础通信** 等模块。

以下是常用且核心的系统级动态链接库分类及功能介绍：

核心与语言绑定层 (Core & Language Bindings)

这些库是 Native 开发最基础的依赖，主要用于跨语言交互和底层系统调用。

• libace_napi.z.so (Node-API / NAPI)
• 作用： 负责 ArkTS/JS 与 C/C++ 之间的相互调用。几乎所有需要将 C/C++ 暴露给前端的代码都需要链接此库。
• libhilog_ndk.z.so
• 作用： 原生日志打印库。提供了 OH_LOG_Print 等接口，用于在 C/C++ 层输出日志到系统的 Hilog 中。
• libc.so / libc++.so / libm.so
• 作用： 标准的 C 库、C++ 标准库和数学库（这些通常是标准的 .so 后缀，遵循 POSIX 标准）。

UI 与应用框架层 (UI & Framework)

用于在 C/C++ 层直接控制 UI 组件或访问应用资源。

• libace_ndk.z.so (ArkUI NDK)
• 作用： 提供了 ArkUI 的 C 语言 API。允许开发者在纯 C/C++ 层创建、更新和销毁 ArkUI 组件，实现高性能的自定义 UI 控制（HarmonyOS NEXT 引入的重要特性）。
• libohinputmethod.so (IME Kit)
• 作用： IME Kit 负责建立编辑框所在应用与输入法应用之间的通信通道，确保两者可以共同协作提供文本输入功能，也为系统应用提供管理输入法应用的能力。。
• librawfile.z.so
• 作用： 提供读取应用安装包（HAP）内 rawfile 目录下原生资源文件的能力。常用于游戏引擎或播放器读取本地资产。
• libbundle_ndk.z.so
• 作用： 包管理 NDK 接口，用于在 Native 层获取应用的包信息、应用版本等。

图形与窗口系统 (Graphics & Windowing)

图形渲染和游戏开发的核心库。

• libnative_window.so
• 作用： 提供原生窗口（Native Window）的管理能力。通常与 XComponent 结合使用，为 EGL/Vulkan 提供渲染表面（Surface）。
• libnative_drawing.so
• 作用： 鸿蒙原生的 2D 绘制引擎（基于 Skia 封装），提供高性能的 2D 图形、文本绘制能力。
• libnative_vsync.so
• 作用： 提供获取系统垂直同步信号（Vsync）的能力，用于实现平滑的动画和渲染帧率控制。
• libEGL.so / libGLESv2.so / libGLESv3.so / libvulkan.so
• 作用： 标准的 3D 图形渲染 API 库。

多媒体与相机 (Media & Camera)

音视频处理和硬件访问。

• libohaudio.so
• 作用： 鸿蒙原生的音频处理 NDK（OHAudio），提供低延迟的音频采集和播放能力（推荐替代老旧的 OpenSLES）。
• libohcamera.so
• 作用： 相机 NDK，允许在 C/C++ 层直接控制相机硬件、配置流数据、获取预览帧等。
• 多媒体编解码系列库：
• libnative_media_core.so (媒体核心基础类型)
• libnative_media_vdec.so / libnative_media_venc.so (视频硬件编解码)
• libnative_media_avmuxer.so / libnative_media_avdemuxer.so (音视频封装/解封装)

数据存储与共享 (Data & Storage)

• libnative_rdb.so
• 作用： 关系型数据库（Relational Database）的 Native 接口。允许 C/C++ 代码直接执行 SQL 语句，进行高效的本地数据持久化。
• libohpreferences.so
• 作用： 用户首选项（Preferences）的 Native 接口，用于存储轻量级的 Key-Value 数据。

设备与传感器 (Device & Sensors)

• libohsensor.so
• 作用： 提供在 Native 层访问设备传感器（如加速度计、陀螺仪、环境光等）的能力。

(注：HarmonyOS 系统的动态库通常带有 .z.so 后缀表示经过 zlib 压缩优化，部分标准通用库保留 .so 后缀。在 CMake 配置中一般直接写库名即可)

如何在开发中使用它们？

如果你想在纯血鸿蒙应用中知道到底有哪些 .so 可以用，可以通过以下方式查看： 在 DevEco Studio 安装目录的鸿蒙 SDK 路径下：[SDK路径]/default/openharmony/native/sysroot/usr/lib/[架构(如aarch64-linux-ohos)]/

在这个目录中，你能看到所有官方公开给 NDK 开发者的动态链接库。

使用示例（CMakeLists.txt）：

如果你在写一个同时需要与 ArkTS 交互、打印日志、并读取 Rawfile 的原生模块，你的 CMakeLists.txt 会这样写：

# 找到或者直接链接系统库target_link_libraries(my_native_lib PUBLIC    libace_napi.z.so    libhilog_ndk.z.so    librawfile.z.so    libc++.so)

总结

很多人觉得 HarmonyOS / OpenHarmony 原生开发难，是因为代码底层、接口多、工程复杂。但实际上，真正让人迷糊的，往往不是代码本身，而是：对系统能力边界还没有建立起完整认知。

当你知道每个 so 是干什么的、为什么要链接、运行时由谁提供，原生开发就不再神秘。它并不是更难，只是比上层开发更接近系统。

参考资料

• HarmonyOS指南>NDK开发>NDK开发导读 https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/ndk-development-overview