From 1ce54d60adf495288b37cde9ae8b1f1aedcb4744 Mon Sep 17 00:00:00 2001 From: hhj Date: Fri, 2 Jun 2023 08:24:00 +0000 Subject: [PATCH] update zh-cn/application-dev/reference/native-api-intro.md. Signed-off-by: hhj --- .../reference/native-api-intro.md | 28 +++++++++---------- .../reference/native-lib/Readme-CN.md | 2 +- .../native-lib/third_party_libc/cpp.md | 21 ++++++++++++++ .../native-lib/third_party_libc/cxx.md | 21 -------------- .../native-lib/third_party_libc/musl.md | 12 ++++---- 5 files changed, 42 insertions(+), 42 deletions(-) create mode 100644 zh-cn/application-dev/reference/native-lib/third_party_libc/cpp.md delete mode 100644 zh-cn/application-dev/reference/native-lib/third_party_libc/cxx.md diff --git a/zh-cn/application-dev/reference/native-api-intro.md b/zh-cn/application-dev/reference/native-api-intro.md index 4ead881738..8cfa3e0c5b 100644 --- a/zh-cn/application-dev/reference/native-api-intro.md +++ b/zh-cn/application-dev/reference/native-api-intro.md @@ -1,15 +1,15 @@ # Native API（NDK）入门 -Native API是OHOS SDK上提供的一组native开发接口与工具集合（也称为NDK），方便开发者使用C或者C++语言实现应用的关键功能。Native API只覆盖了OHOS基础的一些底层能力，如libc，图形库，窗口系统，多媒体，压缩库等，并没有完全提供类似于JS API上的完整的OHOS 平台能力。在应用中使用Native API会编译成动态库打包到应用中。 +Native API是OpenHarmony SDK上提供的一组native开发接口与工具集合（也称为NDK），方便开发者使用C或者C++语言实现应用的关键功能。Native API只覆盖了OpenHarmony基础的一些底层能力，如libc，图形库，窗口系统，多媒体，压缩库等，并没有完全提供类似于JS API上的完整的OpenHarmony 平台能力。在应用中使用Native API会编译成动态库打包到应用中。 ## 名词概念 |名词|名词解释| |--|--| -|Native API|OHOS SDK里面native包提供的，面向三方应用开发的Native 接口以及相应编译脚本，编译工具链。包括C运行时基础库libc，3D图形库opengl，面向JS与C跨语言的接口Node-API等，具体内容详见下表。| -|NDK|Native Develop Kit的缩写，在OHOS上就是Native API；Native API是官方名字，NDK指代相同意思。| -|SDK CAPI|OHOS Native API中的C语言接口，以及工具链部分，当前OHOS的Native API里面只包含C语言接口，因此Native API与CAPI意思一样，建议交流的时候使用CAPI，防止Native API与napi缩写混用。| -|Node-API|曾用名napi，是OHOS中提供JS与C跨语言调用的接口，是Native API接口中的一部分. 该接口在Node.js提供的Node-API基础上扩展而来，但不完全与Node.js中的Node-API完全兼容。 | -|napi|Node-API的曾用名，当前Node-API头文件中的接口仍然以napi_开头，但是为了防止与Native API误用，不建议使用。| +|Native API|OpenHarmony SDK里面native包提供的，面向三方应用开发的Native 接口以及相应编译脚本，编译工具链。包括C运行时基础库libc，3D图形库opengl，面向JS与C跨语言的接口Node-API等，具体内容详见下表。| +|NDK|Native Develop Kit的缩写，在OpenHarmony上就是Native API；Native API是官方名字，NDK指代相同意思。| +|SDK CAPI|OpenHarmony Native API中的C语言接口，以及工具链部分，当前OpenHarmony的Native API里面只包含C语言接口，因此Native API与CAPI意思一样，建议交流的时候使用CAPI，防止Native API与napi缩写混用。| +|Node-API|曾用名napi，是OpenHarmony中提供JS与C跨语言调用的接口，是Native API接口中的一部分. 该接口在Node.js提供的Node-API基础上扩展而来，但不完全与Node.js中的Node-API完全兼容。 | +|napi|Node-API的曾用名，当前Node-API头文件中的接口仍然以napi_开头，在OpenHarmony中统一用Node-API替换napi。| ## Native API构成介绍 ### Native API目录结构 @@ -18,10 +18,10 @@ Native API在SDK包的位置为$(SDK_ROOT)/native目录，主要有以下几个 |目录|功能说明| |--|--| -|build|应用中编译动态库的toolchain cmake脚本；这个目录下ohos.toolchain.cmake文件定义了给OHOS交叉编译选项| +|build|应用中编译动态库的toolchain cmake脚本；这个目录下ohos.toolchain.cmake文件定义了给OpenHarmony交叉编译选项| |build-tools|放置编译构建的工具，如cmake| |docs|Native API接口参考文档，通过doxgen从头文件中提取出来| -|llvm|支持OHOS ABI的llvm交叉编译器| +|llvm|支持OpenHarmony ABI的llvm交叉编译器| |sysroot|放置编译链接的依赖文件目录，包含头文件，动态库等| ### Native API接口 @@ -47,7 +47,7 @@ Native API在SDK包的位置为$(SDK_ROOT)/native目录，主要有以下几个 * 《[Native API参考手册](./native-apis/Readme-CN.md)》，介绍各个API参考手册 * 《[Native API中支持的标准库](../reference/native-lib/Readme-CN.md)》，介绍Native API支持的开源标准库 * 《[Native API开发指南](../napi/Readme-CN.md)》，结合具体的例子，场景介绍各类接口的使用 -* 《[使用NDK编译一个Cmake C/C++工程文档](../quick-start/howto-migrate-cmake-with-ohosndk.md)》，介绍如何使用使用Native API开发一个Cmake工程 +* 《[使用NDK编译一个CMake C/C++工程文档](../quick-start/howto-migrate-cmake-with-ohosndk.md)》，介绍如何使用使用Native API开发一个CMake工程 * 《[Node-API在应用工程中的使用指导](../napi/napi-guidelines.md)》, 如何使用Node-API接口 @@ -63,10 +63,10 @@ Native API在SDK包的位置为$(SDK_ROOT)/native目录，主要有以下几个 ### 不建议使用Native API的场景 -1. 写一个纯native的的OHOS应用 -2. 希望在尽可能多的OHOS设备上保持兼容的应用 +1. 写一个纯native的的OpenHarmony应用 +2. 希望在尽可能多的OpenHarmony设备上保持兼容的应用 -## 维测能力 +## 调试能力 -1. OHOS官方提供lldb remote方式代码调试，详细参看《[lldb参考手册](https://gitee.com/openharmony/third_party_llvm-project/blob/master/lldb/README_zh.md)》 -2. musl库的log维测能力，请参看[libc库](./native-lib/third_party_libc/musl.md)维测章节 +1. OpenHarmony官方提供lldb remote方式代码调试，详细参看《[lldb参考手册](https://gitee.com/openharmony/third_party_llvm-project/blob/master/lldb/README_zh.md)》 +2. musl库的log维测能力，请参看[libc库](./native-lib/third_party_libc/musl.md)调试能力章节 diff --git a/zh-cn/application-dev/reference/native-lib/Readme-CN.md b/zh-cn/application-dev/reference/native-lib/Readme-CN.md index 4f013995f6..287cdba8c3 100644 --- a/zh-cn/application-dev/reference/native-lib/Readme-CN.md +++ b/zh-cn/application-dev/reference/native-lib/Readme-CN.md @@ -1,6 +1,6 @@ # Native API标准库 - [libc标准库](third_party_libc/musl.md) -- [c++标准库](third_party_libc/cxx.md) +- [c++标准库](third_party_libc/cpp.md) - [Node-API](third_party_napi/napi.md) - [libuv](third_party_libuv/libuv.md) - [OpenSL ES](third_party_opensles/opensles.md) diff --git a/zh-cn/application-dev/reference/native-lib/third_party_libc/cpp.md b/zh-cn/application-dev/reference/native-lib/third_party_libc/cpp.md new file mode 100644 index 0000000000..97e22f264b --- /dev/null +++ b/zh-cn/application-dev/reference/native-lib/third_party_libc/cpp.md @@ -0,0 +1,21 @@ + +# 标准C++库 + +OpenHarmony当前使用的是llvm项目的C++标准库实现[libc++](https://libcxx.llvm.org/)。 + +## 版本 + +10.0.1 + +从OpenHarmony 3.2开始，libc++升级到clang/llvm 12.0.1版本 + +从OpenHarmony 4.0开始，libc++升级到clang/llvm 15.0.4版本 + +## 支持的能力 + +C++11、C++14标准已完全支持，C++17和C++20标准正在完善。具体语言特性支持标准可以参考[https://libcxx.llvm.org/](https://libcxx.llvm.org/)网站对应的ReleaseNotes。 + +## ABI兼容 +在OpenHarmony系统中，系统框架与应用Native库都在使用C++标准库，两部分依赖的版本是不一样的。系统框架依赖的C++标准库随镜像版本升级，而应用依赖的C++标准库随编译使用的SDK版本升级，两部分依赖的C++基础库会跨多个大版本，会产生ABI兼容性。为了解决此问题，OpenHarmony上把两部分依赖的C++标准库进行了区分，系统库使用libc++.so，应用使用应用包内提供的libc++_shared.so；两个库使用的C++命名空间不一样，libc++_shared.so使用__n1作为C++符号的命名空间，libc++.so使用__h作为C++符号的命名空间。 + +两边使用的C++标准库不能进行混用，Native API接口当前只能是C接口，可以通过这个接口隔离两边的C++运行环境。 \ No newline at end of file diff --git a/zh-cn/application-dev/reference/native-lib/third_party_libc/cxx.md b/zh-cn/application-dev/reference/native-lib/third_party_libc/cxx.md deleted file mode 100644 index b57bbd5532..0000000000 --- a/zh-cn/application-dev/reference/native-lib/third_party_libc/cxx.md +++ /dev/null @@ -1,21 +0,0 @@ - -# 标准C++库 - -OHOS当前使用的是llvm项目的C++标准库实现[libc++](https://libcxx.llvm.org/)。 - -## 版本 - -10.0.1 - -从OHOS 3.2开始，libc++升级到clang/llvm 12.0.1版本 - -从OHOS 4.0开始，libc++升级到clang/llvm 15.0.4版本 - -## 支持的能力 - -C++11、C++14标准已完全支持，C++17和C++20标准正在完善。具体语言特性支持标准可以参考[https://libcxx.llvm.org/](https://libcxx.llvm.org/)网站对应的ReleaseNotes。 - -## ABI兼容 -在OHOS系统中，系统框架与应用Native库都在使用C++标准库，两部分依赖的版本是不一样的。系统框架依赖的C++标准库随镜像版本升级，而应用依赖的C++标准库随编译使用的SDK版本升级，两部分依赖的C++基础库会跨多个大版本，要保证双方ABI兼容性是非常困难的。因此在OHOS上我们把两部分依赖的C++标准库进行了区分，随系统镜像携带的是libc++.so，应用自己提供的库携带的是libc++_shared.so；两个库使用的C++命名空间不一样，libc++_shared.so使用__n1作为c++符号的命名空间，libc++.so使用__h作为c++符号的命名空间。 - -两边使用的c++标准库不能进行混用，Native API接口当前只能是C接口，可以通过这个接口隔离两边的C++运行环境。 \ No newline at end of file diff --git a/zh-cn/application-dev/reference/native-lib/third_party_libc/musl.md b/zh-cn/application-dev/reference/native-lib/third_party_libc/musl.md index d92efd9450..e6959ba06d 100644 --- a/zh-cn/application-dev/reference/native-lib/third_party_libc/musl.md +++ b/zh-cn/application-dev/reference/native-lib/third_party_libc/musl.md @@ -3,7 +3,7 @@ ## 简介 C标准函数库在C语言程序设计中，提供符合标准的头文件，以及常用的库函数实现（如I/O输入输出和字符串控制）。 -OHOS采用musl作为C标准库，musl库是一个轻量，快速，简单，免费的开源libc库，详细介绍参考[musl官方参考手册](http://musl.libc.org/manual.html)。 +OpenHarmony采用musl作为C标准库，musl库是一个轻量，快速，简单，免费的开源libc库，详细介绍参考[musl官方参考手册](http://musl.libc.org/manual.html)。 musl与glibc的差异点请参考[wiki](https://wiki.musl-libc.org/functional-differences-from-glibc.html)。 @@ -13,20 +13,20 @@ musl与glibc的差异点请参考[wiki](https://wiki.musl-libc.org/functional-di libc：包含线程相关接口，以及大部分标准接口。 -libm：数学库函数接口，当前在OHOS中是一个链接，实际都在libc中定义。 +libm：数学库函数接口，当前在OpenHarmony中是一个链接，实际都在libc中定义。 -libdl：dlopen等动态链接器接口，当前在OHOS中是一个链接，实际都在libc中定义。 +libdl：dlopen等动态链接器接口，当前在OpenHarmony中是一个链接，实际都在libc中定义。 ## musl版本号 1.2.0 -从OHOS4.0开始，版本升级到1.2.3 +从OpenHarmony4.0开始，版本升级到1.2.3 ## 支持的能力 提供兼容C99,C11,POSIX标准的头文件，以及库函数接口，但不是完全兼容；支持armv7a，arm64, x86_64三种架构的支持； -为了更好的适配OHOS设备的高性能，低内存，高安全，轻量化，支持多种形态设备的基本特征；在musl开源库的基础上进行了优化，增强，对不适用嵌入式设备的接口进行了裁剪。 +为了更好的适配OpenHarmony设备的高性能，低内存，高安全，轻量化，支持多种形态设备的基本特征；在musl开源库的基础上进行了优化，增强，对不适用嵌入式设备的接口进行了裁剪。 ### 新增能力 1. 动态加载器支持命名空间隔离能力，应用可以dlopen加载的动态库受系统命名空间限制（比如，无法打开系统侧动态库）。 @@ -34,7 +34,7 @@ libdl：dlopen等动态链接器接口，当前在OHOS中是一个链接，实 3. 支持symbol-versioning功能。 4. dlopen支持直接加载zip包中未压缩的文件。 -### 维测能力 +### 调试能力 提供了基础的log调试能力，方便开发者需要查看libc库内部异常。维测log的提供动态开关功能，不需要重新编译。在正式发布版本中，不建议使用，会影响运行性能。 #### 1. musl.log功能 -- GitLab