承接上一篇Openharmony的编译构建--进阶篇1中说明了在Openharmony V3.1的如何在标准系统即L2设备一个模块的两种情况，此篇对第三种情况进行说明。

四、新建子系统并在该子系统的部件下添加模块

1.在模块目录下配置BUILD.gn,根据类型选择对应的模板

2.新建包含该模块所属部件的bundle.json

此前两步与前面介绍的两种方式并无区别。

3.修改//build/subsystem_config.json

比如：在foundation目录下新建test_subsystem，将第一步与第二步新建的bundle.json与BUILD.gn移入。

修改bundle.json中"subsystem": "test_subsystem",并且BUILD.gn中的subsystem_name = "test_subsystem"，part_name = ""进行修改。

{
  "ace": {
    "path": "foundation/ace",
    "name": "ace"
  },
  "ai": {
    "path": "foundation/ai",
    "name": "ai"
  },
  "account": {					# 子系统
    "path": "base/account",		# 子系统目录
    "name": "account"			# 子系统名称
  },
  # 新增示例如下:
  "test_subsystem": {
    "path": "foundation/test_subsystem",
    "name": "test_subsystem"
  }, 
...
}

4.//productdefine/common/products/rk3568.json文件添加部件"account:os_account_test":{}

不再赘述。

Openharmony里执行

./build.sh --product-name rk3568

编译完成后，在//out/rk3568/test_subsystem/目录下可以找到编译完成的可执行文件与动态库。

五、BUILD.gn的其它模板

一些常用的模板类型：

# 生成系统hap
ohos_hap	
# 拷贝文件
ohos_copy
# 源目标集合
ohos_source_set
# 执行脚本，支持shell、python
action
# 工作集
group
# 配置集合
config

ohos_hap例子：

ohos_hap("clock")
  hap_profile = "./src/main/config.json" # config.json
  js_assets = ["./src/main/js/defaults"]
  raw_assets = ["./raw_assets"]
  resources = ["./src/main/resources"]
  shared_libraries = ["//third_party/libpng:libpng"] # native库
  certificate_profile = "../signature/systemui.p7b"	 # Cer文件
  hap_name = "SystemUI-NavigationBar" 	# hap包名字
  part_name = "prebuilt_hap"
  subsystem_name = "application"
}

• 声明一个hap目标，该目标会生成一个hap包，最终将会打包到system镜像中
• 支持的变量

1.hap_profile:hap包的config.json

2.js_assets:js资源，编译后放置在assets/js/default目录下

3.raw_assets:原始assets,这些assets会直接拷贝到hap包的assets目录下

4.resources:资源文件，编译后放置在assets/entry/resources目录下

5.deps:当前目标的依赖

6.shared_libraries:当前目标依赖的native库

7.hap_name:hap包的名字，可选，默认为目标名

8.final_hap_path:用户可以制定生成的hap的位置，可选，final_hap_path中会覆盖hap_name

9.subsystem_name: hap包从属的子系统名，需要和bundle.json中的名字对应，否则将导致无法安装 到system镜像中

10.part_name: hap包从属的部件名。同subsystem_name

11.js2abc: 是否需要将该hap包转换为ARK的字节码

12.certificate_profile: hap对应的授权文件，用于签名

13.certificate_file: 证书文件，证书文件和授权文件，应用开发者需要去openharmony官网申请

14.keystore_path: keystore文件，用于签名

15.keystore_password: keystore的密码，用于签名

16.key_alias: key的别名

17.module_install_name: 安装时的hap包名称

18.module_install_dir: 安装到system中的位置，默认安装在system/app目录下

ohos_source_set例子：

ohos_source_set("glib_source") {
  source = [
  	"glib/deprecated/gallocator.c",
  	"glib/deprecated/gcache.c",
  	"glib/deprecated/grel.c",
  	...
  ]
  configs = [ ":glib_config"]
}

ohos_shared_library("glib") {
  deps = [ ":glib_source"]
  part_name = "multimedia_media_standard"
  subsystem_name = "multimedia"
}

action例子：

action("gen_config_header") {
  script = "//third_party/ffmpeg/ohos_config.sh"
  
  args = [
    rebase_path("//third_party/ffmpeg", root_build_dir),
    rebase_path("${target_gen_dir}/include/", root_build_dir),
  ]
  
  outputs = [ "${target_gen_dir}/include/config.h"]
}

六、Openharmony编译构建的运行机制

Openharmony侧的编译构建流程主要包含编译命令行解析，调用gn,执行ninja:

• 命令行解析：解析待编译的产品名称，加载相关配置
• 调用gn:根据命令行解析的产品名称和编译类型，配置编译工具链和全局的编译选项
• 执行ninja：启动编译并生成对应的产品版本。

后续更精彩

1.L0与L1的编译构建过程以及后续V3.2版本的构建流程稍有不同，但是如果了解了Openharmony的编译构建的运行机制，可以理解相应的产品的编译过程。如果在技术朋友在此方面有疑惑时，可以留言与私信，或者如果提问的朋友相对较多时，再开一篇进行解析说明。

2.各位朋友和技术爱好者有想了解Openharmony的相关子系统或者框架的，可以留言或私信。