鸿蒙南向开辟实战：关于deps、external_deps的利用

嚴華 · 2024-11-12 06:38:46

在添加一个模块的时候，必要在BUILD.gn中声明它的依赖，为了便于后续处理部件间依赖关系，我们将依赖分为两种——部件内依赖deps和部件间依赖external_deps。
依赖分类

如上图所示，重要分为部件内依赖（图左）和部件间依赖（图右）。

部件内依赖：现有模块module1属于部件part1，要添加一个属于部件part1的模块module2，module2依赖于module1，这种情况就属于部件内依赖。
部件间依赖：现有模块module1属于部件part1，要添加一个模块module2，module2依赖于module1，module2属于部件part2。模块module2与模块module1分属于两个差别的部件，这种情况就属于部件间依赖。
部件内依赖示例：
1. import("//build/ohos.gni")
2. ohos_shared_library("module1") {
3. ……
4. part_name = "part1" # 必选，所属部件名称
5. ……
6. }
复制代码
1. import("//build/ohos.gni")
2. ohos_shared_library("module2") {
3. ……
4. deps = [
5. "module1的gn target",
6. ……
7. ] # 部件内模块依赖
8. part_name = "part1" # 必选，所属部件名称
9. }
复制代码
部件间依赖示例：
1. import("//build/ohos.gni")
2. ohos_shared_library("module1") {
3. ……
4. part_name = "part1" # 必选，所属部件名称
5. ……
6. }
复制代码
1. import("//build/ohos.gni")
2. ohos_shared_library("module2") {
3. ……
4. external_deps = [
5. "part1:module1",
6. ……
7. ] # 部件间模块依赖，这里依赖的模块必须是依赖的部件声明在inner_kits中的模块
8. part_name = "part2" # 必选，所属部件名称
9. }
复制代码
留意：部件间依赖要写在external_deps内里，格式为”部件名:模块名"的情势，并且依赖的模块必须是依赖的部件声明在inner_kits中的模块。

Sanitizer利用分析

在添加模块时，可选地对该模块开启编译器提供的Sanitizer功能，包括整数溢出排错、控制流完整性检查等。设置的每一项都是可选的，如不指定默以为false或者空。Sanitizer设置示比方下所示：

ohos_shared_library("example") {
sanitize = {
cfi = true # 开启控制流完整性检测
cfi_cross_dso = true # 开启跨so调用的控制流完整性检测
integer_overflow = true # 开启整数溢出检测
boundary_sanitize = true # 开启边界检测
ubsan = true # 开启部分ubsan选项
all_ubsan = true # 开启全量ubsan选项
debug = true # 可选，调测模式，默认是不开启
blocklist = "./blocklist.txt" # 可选，屏蔽名单路径
}
...
}

复制代码

支持的Sanitizer类型
目前支持开启的Sanitizer：

整数溢出排错：unsigned_integer_overflow/signed_integer_overflow/integer_overflow(同时包括无符号和有符号整数溢出两种检查)
控制流完整性：cfi、cfi_cross_dso（跨so的cfi检查）
边界检测：boundary_sanitize
部分未定义举动检测：ubsan(bool,integer-divide-by-zero,return,returns-nonnull-attribute,shift-exponent,unreachable,vla-bound等编译选项)
全量未定义举动检测：all_ubsan(全量undefined behavior sanitizer编译选项)

发布、调测模式
通过选项控制利用发布模式还是调测模式，默以为发布模式，利用显式声明开启调测模式。选项仅对Sanitizer见效，且与模块是否编译为调试版本无关，但在模块发布版本的编译设置中不应带此选项，或显式地将设置为，使得Sanitizer处于发布模式。debugdebug = truedebugdebugfalse

调测模式：用于开辟时排查问题。该模式下会输出产生错误相关的丰富信息来辅助定位错误，并且在发生错误后并不会直接中断程序运行，而是会恢复程序运行进一步识别后续的错误。
发布模式：掩护程序不发生错误或被恶意攻击，在产生错误后直接中断程序不会继续执行。

屏蔽名单
指定该模块中不受Sanitizer选项影响的函数或源程序文件名单，用于制止良性举动被识别为错误、热点函数产生了不公道、不可接受的开销；该名单需谨慎利用。名单示比方下所示：

[cfi]
fun:*([Tt]est|TEST)*
fun: main
[integer]
src:example/*.cpp

复制代码

开源软件Notice收集策略分析

开源软件Notice是与项目开源相关的文件，收集这些文件的目的是为了符合开源的规范。
收集目的
只收集打包到镜像内里的模块对应的License；不打包的都不收集，比如构建过程利用的工具（如clang、python、ninja等）都是不收集的。
静态库本身是不会被打包的，一般是作为动态库或者可执行程序的一部分被打包到体系中的，为了确保完备，静态库的都会收集。
终极合并的NOTICE.txt要体现出镜像中每个文件都是用了哪些License，模块和License要有对应关系。
终极合并的NOTICE.txt文件在/system/etc/ 目次下。
收集规则
按照优先级收集License，以下由1到4，优先级依次降低。

模块在BUILD.gn中直接声明本身利用的License文件，优先级最高。如下示例：
1. ohos_shared_library("example") {
2. ...
3. license_file = "path-to-license-file"
4. ...
5. }
复制代码
如果模块没有显式声明，那么编译脚本会在BUILD.gn所在的当前目次中查找Readme.OpenSource文件，分析该文件，找出该文件中声明的license，将其作为模块的License。如果Readme.OpenSource文件中设置的license文件不存在，直接报错。
如果Readme.OpenSource文件不存在，编译脚本会从当前目次开始，向上层目次寻找（不停找到源码的根目次），默认查找License、Copyright、Notice三个文件，如果找到，则将其作为模块的License。
如果上面三种方式都未找到license，则利用默认的license作为该模块的license；默认license是Apache2.0 License。

必要留意及检查的问题

三方的开源软件，比如openssl，icu等，这部分软件基本上在源码目次下都要求设置Readme.OpenSource，要检查Readme.OpenSource文件是否和BUILD.gn文件在同一个目次，以及Readme.OpenSource文件中设置的License文件是否存在以及真实有用。
代码目次下，如果代码利用的不是Apache2.0 License，必要在目次下提供对应的License文件，或者直接在模块中指定license_file。
如果BUILD.gn中添加的源码文件不是当前目次的，必要检查下源码文件所在仓下的license是否和BUILD.gn文件所在仓的一致。

加快本地编译的一些参数

编译时，得当选择添加以下的编译参数可以加快编译的过程。

添加--ccache参数:
- 原理：ccache会缓存c/c++编译的编译输出，下一次在编译输入稳定的情况下，直接复用缓存的产物。
- 安装：
  - 快速安装：执行sudo apt-get install ccache下令。
  - 官网下载，下载二进制文件，把ccache所在路径设置到环境变量。
- 利用：执行./build.sh --product-name 产物名 --ccache下令。
添加--fast-rebuild参数
- 原理：编译流程重要分为：preloader->loader->gn->ninja这四个过程，在本地没有修改gn和产物设置相关文件的前提下，添加--fast-rebuild会让你直接从ninja编译开始。
- 利用：执行./build.sh --product-name 产物名 --fast-rebuild下令。
添加enable_notice_collection=false参数
- 原理：省略掉收集开源软件模块的license的过程。
- 利用：执行./build.sh --product-name 产物名 --gn-args --enable_notice_collection=false --ccache下令。
添加--build-target参数
- 该参数用于指定编译模块，怎样找模块的名字：
  - 相关仓下BUILD.gn中关注group、ohos_shared_library、ohos_executable等关键字。
  - ./build.sh --product-name 产物名 --build-target 模块名 --build-only-gn天生build.ninja，然后去该文件中查找相关模块名。
- 利用：执行./build.sh --product-name 产物名 --build-target ark_js_host_linux_tools_packages下令。

查看NinjaTrace

out/rk3568/.ninja_log文件记录了每个模块编译的开始和结束时间(ms)，结束时间和开始时间隔断越短表现模块的编译时间越短，编译性能越高。
从左到右分别表现：start time|end time|mtime|command hash。

图形化表现编译时间。

本地打开ninja trace：解压out/rk3568/build.trace.gz，将build.trace拖到chrome的trace链接chrome://tracing/打开即可。
在CI网站ci.openharmony.cn/events上打开ninja trace： CI上每个编译的输出内里有build.trace.html可直接打开，具体方法是：
- 点击静态检查下的“乐成”；
- 点击输出列的“输出”即可在左侧的build_trace列看到build.trace.html文件，单击该文件即可打开。

定制打包chip_prod镜像利用分析

配景

针对同一个芯片解决方案下的子产物的定制能力，将差别能力放到 chip_prod 分区，因此必要支持对差别子产物天生对应的 chip_prod.img。
利用步骤

产物解决方案设置：
产物解决方案设置文件config.json中添加设置选项，即。其中子产物定义文件的文件名为，文件格式为：。
示例：
以MyProduct产物定制chipprod镜像为例，//vendor/产物厂商/MyProduct/config.json设置如下："chipprod_config_path""chipprod_config_path":"子产物定义文件所在的路径"chip_product_list.gnichip_product_list = ["productA", "productB", ...]
1. {
2. "product_name": "MyProduct", # 产品名称
3. "version": "3.0", # config.json的版本号, 固定"3.0"
4. "chipprod_config_path": "", # 存放chipprod配置文件路径，可选项
5. "subsystems": [
6. {
7. "subsystem": "arkui", # 选择的子系统
8. "components": [
9. {
10. "component": "ace_engine",
11. "features":[ "ace_engine_feature_enable_web = true",
12. "ace_engine_feature_enable_accessibility = true" ] }
13. ]
14. },
15. {
16. ......
17. }
18. ......
19. 更多子系统和部件
20. }
21. }
复制代码
模块编译设置：
某个设置文件在差别的子产物中有差别，比如要打包到productA对应的chip_prod.img中，则模块编译必要设置和。
以示例：install_imagesmodule_install_dirohos_prebuilt_executable
1. ohos_prebuilt_executable("moduleXXX"){
2. install_images = [ "chip_prod" ]
3. module_install_dir = "productA/etc/***" # module_install_dir指定的路径需要以productA开始。
4. }
复制代码

3.编译下令

./build.sh --product-name {product_name} --build-target chip_prod_image

复制代码

打包结果:
如果定义了子产物productA和productB，即并且有模块安装到了该产物下，则打包后镜像输出路径如下：chip_product_list = ["productA", "productB"],
1. images/productA/chip_prod.img
2. images/productB/chip_prod.img
复制代码

末了

有很多小伙伴不知道学习哪些鸿蒙开辟技能？不知道必要重点掌握哪些鸿蒙应用开辟知识点？而且学习时频繁踩坑，终极浪费大量时间。所以有一份实用的鸿蒙（HarmonyOS NEXT）资料用来跟着学习好坏常有必要的。
这份鸿蒙（HarmonyOS NEXT）资料包含了鸿蒙开辟必掌握的核心知识要点，内容包含了（ArkTS、ArkUI开辟组件、Stage模型、多端部署、分布式应用开辟、音频、视频、WebGL、OpenHarmony多媒体技能、Napi组件、OpenHarmony内核、Harmony南向开辟、鸿蒙项目实战等等）鸿蒙（HarmonyOS NEXT）技能知识点。
希望这一份鸿蒙学习资料能够给大家带来资助，有必要的小伙伴自行领取，限时开源，先到先得~无套路领取！！
如果你是一名有履历的资深Android移动开辟、Java开辟、前端开辟、对鸿蒙感兴趣以及转行职员，可以直接领取这份资料
获取这份完整版高清学习路线，请点击→纯血版全套鸿蒙HarmonyOS学习资料
鸿蒙（HarmonyOS NEXT）最新学习路线

HarmonOS基础技能

HarmonOS就业必备技能
HarmonOS多媒体技能

鸿蒙NaPi组件进阶

HarmonOS高级技能

初识HarmonOS内核
实战就业级设备开辟

有了路线图，怎么能没有学习资料呢，小编也预备了一份团结鸿蒙官方发布笔记整理收纳的一套体系性的鸿蒙（OpenHarmony ）学习手册（共计1236页）与鸿蒙（OpenHarmony ）开辟入门教学视频，内容包含：ArkTS、ArkUI、Web开辟、应用模型、资源分类…等知识点。
获取以上完整版高清学习路线，请点击→纯血版全套鸿蒙HarmonyOS学习资料
《鸿蒙 (OpenHarmony)开辟入门教学视频》