头图

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

依赖分类

image.png
如上图所示,主要分为部件内依赖(图左)和部件间依赖(图右)。

  • 部件内依赖: 现有模块module1属于部件part1,要添加一个属于部件part1的模块module2,module2依赖于module1,这种情况就属于部件内依赖。
  • 部件间依赖: 现有模块module1属于部件part1,要添加一个模块module2,module2依赖于module1,module2属于部件part2。模块module2与模块module1分属于两个不同的部件,这种情况就属于部件间依赖。
  • 部件内依赖示例:
import("//build/ohos.gni")
ohos_shared_library("module1") {
  ……
  part_name = "part1"   # 必选,所属部件名称
  ……
}
import("//build/ohos.gni")
ohos_shared_library("module2") {
  ……
  deps = [
    "module1的gn target",
  ……
 ]                        # 部件内模块依赖
part_name = "part1"       # 必选,所属部件名称
}

部件间依赖示例:

import("//build/ohos.gni")
ohos_shared_library("module1") {
  ……
  part_name = "part1"   # 必选,所属部件名称
  ……
}
import("//build/ohos.gni")
ohos_shared_library("module2") {
  ……
  external_deps = [
    "part1:module1",
  ……
  ]                      # 部件间模块依赖,这里依赖的模块必须是依赖的部件声明在inner_kits中的模块
  part_name = "part2"    # 必选,所属部件名称
}

注意:部件间依赖要写在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编译选项)

发布、调测模式

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

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

屏蔽名单

指定该模块中不受Sanitizer选项影响的函数或源程序文件名单,用于避免良性行为被识别为错误、热点函数产生了不合理、不可接受的开销;该名单需谨慎使用。名单示例如下所示:

[cfi]
fun:*([Tt]est|TEST)*
fun: main

[integer]
src:example/*.cpp

那么很多小伙伴肯定主要是查找一些鸿蒙开发相关的内容提升自己,在这里,我为大家准备了一套《Open Harmony4.0&Next》的学习导图,从入门到进阶再到南北向开发实战的一整套完整体系,想要学习了解更多鸿蒙开发的相关知识可以借鉴:《做鸿蒙应用开发到底学习些啥?
图片
除了以上的知识内容,我还为大家整理了一份《鸿蒙 (Harmony OS)开发学习手册》都是整理成PDF文档方式,分享给大家参考学习:《鸿蒙基础入门开发宝典!
《鸿蒙 (Harmony OS)开发学习手册》
一、入门必看
1.应用开发导读(ArkTS)
2.应用开发导读(Java)
3........
图片
二、HarmonyOS 概念
系统定义
技术架构
技术特性
系统安全
......
图片
三、如何快速入门?《鸿蒙开发学习指南
基本概念
构建第一个ArkTS应用
构建第一个JS应用
……
图片
四、开发基础知识
应用基础知识
配置文件
应用数据管理
应用安全管理
应用隐私保护
三方应用调用管控机制
资源分类与访问
学习ArkTS语言
……
图片
五、基于ArkTS 开发
Ability开发
开发
公共事件与通知
窗口管理
媒体
安全
网络与链接
电话服务
数据管理
后台任务(Background Task)管理
设备管理
设备使用信息统计
DFX
国际化开发
折叠屏系列
……
图片
更多了解更多鸿蒙开发的相关知识可以参考:《做鸿蒙应用开发到底学习些啥?


相见
6 声望4 粉丝