鸿蒙HarmonyOS应用开发之C/C++标准库机制

OpenHarmony NDK提供业界标准库 libc标准库、 C++标准库 ，本文用于介绍C/C++标准库在OpenHarmony中的机制，开发者了解这些机制有助于在NDK开发过程中避免相关问题。

1. C++兼容性

在OpenHarmony系统中，系统库与应用Native库都在使用C++标准库（参考 libc++版本 ），系统库依赖的C++标准库随镜像版本升级，而应用Native库依赖的C++标准库随编译使用的SDK版本升级，两部分依赖的C++基础库会跨多个大版本，产生ABI兼容性问题。为了解决此问题，OpenHarmony上把两部分依赖的C++标准库进行了区分。

• 系统库：使用libc++.so， 随系统镜像发布。
• 应用Native库：使用libc++_shared.so，随应用发布。

两个库使用的C++命名空间不一样，libc++.so使用__h作为C++符号的命名空间，libc++_shared.so使用__n1作为C++符号的命名空间。

注意：系统和应用使用的C++标准库不能进行混用，Native API接口当前只能是C接口，可以通过这个接口隔离两边的C++运行环境。因此在使用共享库HAR包构建应用时，如果HAR包含的libc++_shared.so不同于应用使用的libc++_shared.so版本，那么只有其中一个版本会安装到应用里，可能会导致不兼容问题，可以使用相同的SDK版本更新HAR包解决此问题。

已知C++兼容性问题：应用启动或者dlopen时hilog报错symbol not found, s=__emutls_get_address，原因是OpenHarmony 3.2及之前版本SDK中的libc++_shared.so无此符号，而OpenHarmony4.0之后版本SDK的libc++_shared.so是有此符号的。解决此问题需要更新应用或者共享库HAR包的SDK版本。

2. musl libc动态链接器

2.1 动态库加载命名空间隔离

动态库加载命名空间（namespace，下面统称为ns）是动态链接器设计的一个概念（区别于C++语言中的命名空间），其设计的主要目的是为了在进程中做native库资源访问的管控，以达到安全隔离的目的。例如系统native库允许加载系统目录（/system/lib64;/vendor/lib64等）下的native库，但是普通应用native库仅允许加载普通应用native库和ndk库，而不允许直接加载系统native库。

动态链接器无论是在加载编译依赖（DT_NEEDED）中指定的共享库，还是调用dlopen加载指定的共享库，都需要关联到具体的ns。

OpenHarmony中动态库加载namespace配置的情况

• default ns：动态链接器启动时默认创建的ns，它可以搜索/system/lib{abi};/vendor/lib{abi}等系统目录路径下的so。
• ndk ns：动态链接器启动时默认创建的ns，它可以搜索/system/lib{abi}/ndk目录下的so，主要是暴露了NDK接口的so。
• app ns: 应用启动时创建的ns，它的搜索路径一般是应用的安装路径(可能为沙箱路径)，即可加载应用的so。

当前这一套命名空间机制主要限制了应用native库和系统native库之间的调用，如图所示，具体规则为

1. default ns和ndk ns可以互相访问全部so，不能访问app ns的so。
2. app ns能访问ndk ns的全部so，不能访问default ns的so。

2.2 rpath机制

rpath（run-time path）是在运行时指定共享库搜索路径的机制。该机制允许在可执行文件或共享库中嵌入一个用于在运行时指定库的搜索路径的信息。

由于上文介绍的命名空间隔离机制，应用仅允许加载对应安装目录拼接native库路径下（例如arm64平台上为libs/arm64）的应用native库，当应用程序涉及加载较多的native库，期望创建多个native库加载路径方便管理，但是会导致无法加载新创建目录下的native库，这种情况可以通过rpath机制编译时指定搜索路径。

例如，应用安装目录lib/arm64下的libhello.so依赖新创建路径lib/arm64/module下的libworld.so，那么在应用的CMakeList.txt里设置上rpath编译选项后编译，使用readelf查看libhello.so的rpath配置如图所示，$ORIGIN为libhello.so所在路径，运行时即可正常加载module目录下的libworld.so。

SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH "\${ORIGIN}/module")

2.3 支持dlclose

支持使用dlclose真实卸载动态库的能力。

2.4 支持symbol-version机制

symbol-version是libc在动态链接-符号重定位阶段的符号检索机制，支持不同版本的符号重定位，也可以帮助解决重复符号的问题。可参考 LD Version Scripts (GNU Gnulib)

总是有很多小伙伴反馈说：鸿蒙开发不知道学习哪些技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？ 为了解决大家这些学习烦恼。在这准备了一份很实用的鸿蒙（HarmonyOS NEXT）学习路线与学习文档给大家用来跟着学习。

针对一些列因素，整理了一套纯血版鸿蒙（HarmonyOS Next）全栈开发技术的学习路线，包含了鸿蒙开发必掌握的核心知识要点，内容有（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、WebGL、元服务、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony驱动开发、系统定制移植等等）鸿蒙（HarmonyOS NEXT）技术知识点。

《鸿蒙 (Harmony OS)开发学习手册》（共计892页）:https://gitcode.com/HarmonyOS_MN

如何快速入门？

1.基本概念
2.构建第一个ArkTS应用
3.……

开发基础知识

1.应用基础知识
2.配置文件
3.应用数据管理
4.应用安全管理
5.应用隐私保护
6.三方应用调用管控机制
7.资源分类与访问
8.学习ArkTS语言
9.……

基于ArkTS 开发

1.Ability开发
2.UI开发
3.公共事件与通知
4.窗口管理
5.媒体
6.安全
7.网络与链接
8.电话服务
9.数据管理
10.后台任务(Background Task)管理
11.设备管理
12.设备使用信息统计
13.DFX
14.国际化开发
15.折叠屏系列
16.……

鸿蒙开发面试真题（含参考答案）:https://gitcode.com/HarmonyOS_MN

OpenHarmony 开发环境搭建:https://gitcode.com/HarmonyOS_MN

《OpenHarmony源码解析》:https://gitcode.com/HarmonyOS_MN

搭建开发环境
系统架构分析

• 构建子系统
• 启动流程
• 子系统
• 分布式任务调度子系统
• 分布式通信子系统
• 驱动子系统
• ……

OpenHarmony 设备开发学习手册:https://gitcode.com/HarmonyOS_MN