前言

OpenHarmony是由开放原子开源基金会（OpenAtom Foundation）孵化及运营的开源项目，目标是面向全场景、全连接、全智能时代、基于开源的方式，搭建一个智能终端设备操作系统的框架和平台，促进万物互联产业的繁荣发展。最近在学习OpenHarmony源代码，个人认为学习有三个阶段，分别是看、实操、写（归纳总结），本着追求学习的终极目标，因此有了这篇文章。
一、OpenHarmony编译框架特点
OpenHarmony编译框架是基于模块化的，从大到小依次划分为产品、子系统集（或领域）、子系统、部件、模块、特性。这种模块化的树状编译框架，非常方便根据目标产品硬件资源的大小进行灵活的裁剪，从而实现“统一OS，弹性部署”的目标。
1.产品（product）
产品是基于解决方案为基于开发板的完整产品，主要包含产品对OS的适配、部件拼装配置、启动配置和文件系统配置等。build.sh编译的时候通过--product-name编译选项指定；hb编译的时候通过hb set进行设置。

#适用于标准(即L2或standard)系统编译
./build.sh --product-name rk3568 --ccache

cd build #进入源码下build目录
hb set   #执行hb set命令，选择对应的产品名称
hb build #执行hb build命令，进行编译

 2.子系统集（domain）
OpenHarmony技术架构中有四大子系统集：“系统基本能力子系统集”、“基础软件服务子系统集”、“增强软件服务子系统集”、“硬件服务子系统集”。四大子系统不会直接出现在编译选项或者参数中，而是有对应的一级源代码文件夹：“系统基本能力子系统集”对应源码foundation文件夹；“基础软件服务子系统集”和“硬件服务子系统集”对应源码base文件夹；“增强软件服务子系统集”对应源码domains文件夹。

.
├── applications //应用程序
├── arkcompiler  //ark编译器
├── base         //“基础软件服务子系统集”和“硬件服务子系统集”
├── build        //编译目录
├── build.py -> build/lite/build.py //软链接
├── build.sh -> build/build_scripts/build.sh //软链接，标准系统编译入口
├── commonlibrary  //通用库
├── developtools   //开发工具
├── device         //芯片相关
├── docs           //文档md文件目录
├── drivers        //驱动文件
├── foundation     //“系统基本能力子系统集”
├── ide            //ide
├── interface      //接口
├── kernel         //内核，liteos-m，liteos-a，linux，uniproton
├── napi_generator //native api相关
├── prebuilts      //编译工具路径
├── productdefine  //产品定义
├── qemu-run -> vendor/ohemu/common/qemu-run //qemu模拟器运行脚本
├── test           //测试用例
├── third_party    //三方库
└── vendor         //产品

3.子系统（subsystem）
子系统是一个逻辑概念，它具体由对应的部件构成。在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或部件。在build/subsystem_config.json中定义。

{
  "arkui": {
    "path": "foundation/arkui", //子系统源码路径
    "name": "arkui"             //子系统名称
  },
  "ai": {
    "path": "foundation/ai",
    "name": "ai"
  },
  "distributeddatamgr": {
    "path": "foundation/distributeddatamgr",
    "name": "distributeddatamgr"
  },
  "security": {
    "path": "base/security",
    "name": "security"
  },
  "startup": {
    "path": "base/startup",
    "name": "startup"
  },
  "hiviewdfx": {
    "path": "base/hiviewdfx",
    "name": "hiviewdfx"
  },
  "kernel": {
    "path": "kernel",
    "name": "kernel"
  },
  "thirdparty": {
    "path": "third_party",
    "name": "thirdparty"
  }
  ...
}

 4.部件（component）
部件对子系统的进一步拆分，可复用的软件单元，它包含源码、配置文件、资源文件和编译脚本；能独立构建，以二进制方式集成，具备独立验证能力的二进制单元。部件由对应源码文件夹下的bundle.json文件进行定义。以napi部件为例foundation/arkui/napi/bundle.json

{
    "name": "@ohos/napi",
    "description": "Node-API (formerly N-API) is an API for build native Addons",
    "version": "3.1",
    "license": "Apache 2.0",
    "publishAs": "code-segment",
    "segment": {
        "destPath": "foundation/arkui/napi"
    },
    "dirs": {},
    "scripts": {},
    "component": {
        "name": "napi",       //部件名称
        "subsystem": "arkui", //所属子系统
        "syscap": [
            "SystemCapability.ArkUI.ArkUI.Napi",
            "SystemCapability.ArkUI.ArkUI.Libuv"
        ],
        "features": ["napi_enable_container_scope"], //部件特性
        "adapted_system_type": [
            "standard"
        ],
        "rom": "5120KB", //部件rom大小
        "ram": "10240KB",//部件ram大小
        "deps": {        //部件依赖
            "components": [ //部件依赖的部件
                "hiviewdfx_hilog_native",
                "hilog"
            ],
            "third_party": [//部件依赖的三方库
                "jerryscript",
                "libuv",
                "node",
                "bounds_checking_function",
                "v8"
            ]
        },
        "build": {
            "group_type": {
                "base_group": [
                    "//foundation/arkui/napi:napi_packages",
                    "//foundation/arkui/napi:napi_packages_ndk"
                ],
                "fwk_group": [],
                "service_group": []
            },
            "inner_kits": [//部件对外暴露的接口，用于其它部件或者模块进行引用
                {
                    "header": {
                      "header_base": "//foundation/arkui/napi/interfaces/kits",
                      "header_files": [
                          "napi/native_api.h"
                      ]
                    },
                    "name": "//foundation/arkui/napi:ace_napi"
                  },
                  {
                    "header": {
                      "header_base": "//foundation/arkui/napi/interfaces/inner_api",
                      "header_files": [
                          "napi/native_common.h",
                          "napi/native_node_api.h"
                      ]
                    },
                    "name": "//foundation/arkui/napi:ace_napi"
                  },
                  {
                    "header": {
                      "header_base": "//foundation/arkui/ace_engine/frameworks/core/common/",
                      "header_files": [
                          "container_scope.h"
                      ]
                    },
                    "name": "//foundation/arkui/napi:ace_container_scope"
                  }
            ],
            "test": [
                "//foundation/arkui/napi:napi_packages_test",
                "//foundation/arkui/napi/sample/native_module_systemtest:systemtest",
                "//foundation/arkui/napi/test/unittest:unittest"
            ]
        }
    }
}

5.模块（module）
模块就是编译子系统的一个编译目标，部件也可以是编译目标。模块属于哪个部件，在gn文件中由part_name指定。

ohos_shared_library("ace_napi") { //ace_napi为模块名，同时也是编译目标
    deps = [ ":ace_napi_static" ] //模块的依赖，被依赖的对象即使没有被subsystem显式包含，也会被编译
    public_configs = [ ":ace_napi_config" ] //模块配置参数，比如cflag
    if (!is_cross_platform_build) {
        public_deps = [ "//third_party/libuv:uv" ]
    }
    subsystem_name = "arkui" //模块所属部件所属子系统名称
    part_name = "napi"       //模块所属部件名称，一个模块只能属于一个部件
}

6.特性（feature）
特性是部件用于体现不同产品之间的差异。通常不同特性可以定义不同编译宏或者代码，从而影响到源代码中define的特性。
vender/hihope/rk3568_mini_system/config.json

{
  "subsystem": "communication",
  "components": [
     { "component": "ipc", "features":[] },
     { "component": "dsoftbus", "features":["dsoftbus_get_devicename=false"] }
    ]
},

foundation/communication/dsoftbus/bundle.json

{
  "name": "@openharmony/dsoftbus",
  "version": "3.1.0",
  "description": "dsoftbus",
  ...
  "component": {
     "name": "dsoftbus",
     "subsystem": "communication",
     "adapted_system_type": [
     "mini",
    "small",
     "standard"
  ],

  "features": [
    "dsoftbus_feature_conn_p2p",
    "dsoftbus_feature_disc_ble",
    "dsoftbus_feature_conn_br",
    "dsoftbus_feature_conn_ble",
    "dsoftbus_feature_lnn_net",
    "dsoftbus_feature_trans_udp_stream",
    "dsoftbus_feature_trans_udp_file",
    "dsoftbus_get_devicename",
    "dsoftbus_feature_product_config_path",
    "dsoftbus_feature_ifname_prefix",
    "dsoftbus_feature_lnn_wifiservice_dependence",
    "dsoftbus_standard_feature_dfinder_support_multi_nif",
    "dsoftbus_feature_protocol_newip"
  ],
},

foundation/communication/dsoftbus/core/adapter/core_adapter.gni

if (dsoftbus_get_devicename == false) {//特性取值不同，影响编译不同代码
  bus_center_core_adapter_src += [ "$dsoftbus_root_path/core/adapter/bus_center/src/lnn_settingdata_event_monitor_virtual.cpp" ]
  bus_center_core_adapter_inc +=[ "$dsoftbus_root_path/core/adapter/bus_center/include" ]
  bus_center_core_adapter_deps += []
} else {
  bus_center_core_adapter_src += ["$dsoftbus_root_path/core/adapter/bus_center/src/lnn_settingdata_event_monitor.cpp","$dsoftbus_root_path/core/adapter/bus_center/src/lnn_ohos_account.cpp",]
  bus_center_core_adapter_inc += ["$dsoftbus_root_path/adapter/common/bus_center/include","$dsoftbus_root_path/core/adapter/bus_center/include","//foundation/distributeddatamgr/relational_store/interfaces/inner_api/rdb/include","//foundation/distributeddatamgr/relational_store/interfaces/inner_api/dataability/include","//base/account/os_account/interfaces/innerkits/ohosaccount/native/include/",]
  bus_center_core_adapter_deps += ["${ability_base_path}:want","${ability_base_path}:zuri","${ability_runtime_inner_api_path}/dataobs_manager:dataobs_manager","${ability_runtime_path}/frameworks/native/ability/native:abilitykit_native","//base/account/os_account/frameworks/ohosaccount/native:libaccountkits","//base/account/os_account/frameworks/osaccount/native:os_account_innerkits","//foundation/distributeddatamgr/data_share/interfaces/inner_api:datashare_consumer","//foundation/distributeddatamgr/data_share/interfaces/inner_api/common:datashare_common","//foundation/distributeddatamgr/relational_store/interfaces/inner_api/dataability:native_dataability","//foundation/distributeddatamgr/relational_store/interfaces/inner_api/rdb:native_rdb",]
}

 7.各部分关系
一个**产品（product）** 可以包含 **1～n个子系统（subsystem）**，一个**子系统**可以包含**1～n个部件（component）**，一个**部件**可以包含**1～n个模块（module）**，不同产品的中的相同部件可以编译不同的**特性（feature）**，子系统集（domain）在源代码一级根目录有体现。
 

 

二、OpenHarmony构建工具介绍
OpenHarmony构建工具由shell脚本、python脚本、gn、ninjia、clang/llvm等构成。GN is “Generate Ninja” 一个用来生成.ninja 的工具，直接编写.ninja文件难度较大，且非常乏味。Ninja 原意是忍者的意思，它是一个专注于速度的小型构建工具，利用gn生成的.ninja文件作为输入。clang/llvm执行真正的编译和链接工作，clang负责编译前端，llvm负责编译优化和后端（通常编译工具分前端、优化、后端）。 GN的语法相对比较简单，有点面向对象编程语言的思想；Ninja号称比make编译速度更快，推测原因make编译过程有大量的延时变量和预置变量，需要在编译过程进行推导其值，因此需要消耗大量cpu资源进行计算，形如`$@，$^，$<，$*，$？`。补充一点：每个.c 和.c++文件是独立编译的，编译过程彼此之间并不进行通信，因此可进行并行编译。编译和链接过程及常见的问题如何解决，后续单独出一期，此处先挖个坑。

 

Ninja 手册 - [https://ninja-build.org/manual.html]

GN 手册- [https://gitee.com/hxdlj/gn-docs/blob/master/gn_reference.md]
三、OpenHarmony构建过程
Openharmony完整的编译构建流程主要可以分成以下五个大阶段：Preloder、Loader、GN、Ninja、Post build。Preloader和Loader阶段主要是执行python脚本preloader.py和loader.py，Preloader阶段根据vendor仓的产品配置config.json文件对产品配置进行解析，并将解析结果输出到out/preloader/{product_name}目录下；Loader阶段进行部件化配置的加载，将部件的编译gn文件，并将解析结果输出到out/{product_name}/build_configs文件夹下。GN阶段以.gn和.gni文件作为输入，通过GN工具生成.ninja文件，输出到out/{product_name}/obj目录下。Ninja阶段以.ninja文件作为输入，通过Ninja工具生调用clang/llvm编译工具链编译生成目标，如静态库out/{product_name}/obj目录下，共享库out/{product_name}/ {part_name}目录下，可执行程序。又可以分为10个小阶段：prebuild、preload、load、pre_target_generate、target_generate、post_target_generate、pre_target_compilation、target_compilation、post_target_compilation、post_build。

hb/modules/interface/build_module_interface.py

     def run(self):
         try:
             self._prebuild()
             self._preload()
             self._load()
             self._pre_target_generate()
             self._target_generate()
             self._post_target_generate()
             self._pre_target_compilation()
             self._target_compilation()
         except OHOSException as exception:
                      raise exception
         else:
             self._post_target_compilation()
         finally:
             self._post_build()

四、OpenHarmony构建过程逆向分析
存储中的镜像（如flash或emmc）一般由芯片厂家提供的烧录工具或者产线生产过程通过专用编程器写入相应分区。OpenHarmony编译完成后镜像img文件所在的目录out/{product_name}/package/phone/image。镜像img文件一般由打包工具按照一定的规则将输入文件夹（含文件夹目录层级）和文件夹下所有文件（如库文件、可执行文件、配置文件、启动脚本文件）整体打包而成，打包过程需要考虑文件系统格式，在产品启动过程中会使用mount进行挂载，因此需要考虑文件夹和文件的层级关系及文件夹、库文件、可执行文件、配置文件、启动脚本文件的权限。这些文件夹、文件从何而来？文件夹直接在宿主机采用mkdir创建，库文件、可执行文件编译完成以后直接copy到对应文件夹中，其它配置或者脚本也是提前准备或者编译过程生成，然后copy到对应文件夹中。

 out/rk3568/packages/phone# tree . -L 1

.
├── chip_prod
├── data
├── hisysevent
├── images
├── NOTICE_FILES
├── NOTICE_module_info.json
├── NOTICE.txt
├── NOTICE.txt.md5.stamp
├── notice_verify_result.out
├── NOTICE.xml
├── NOTICE.xml.gz
├── ramdisk
├── root
├── sa_profile
├── sys_prod
├── system
├── system_install_modules.json
├── system_install_parts.json
├── system_module_info.json
├── system_modules_list.txt
├── system_notice_files.zip
├── system.zip
├── updater
└── vendor

build/ohos/images/mkimage# tree . -L 1

.
├── chip_prod_image_conf.txt
├── dac.txt
├── debug
├── imkcovert.py
├── mkcpioimage.py
├── mkextimage.py
├── mkf2fsimage.py
├── mkimages.py
├── __pycache__
├── ramdisk_image_conf.txt
├── README.txt
├── sys_prod_image_conf.txt
├── system_image_conf.txt
├── updater_image_conf.txt
├── updater_ramdisk_image_conf.txt
├── userdata_image_conf.txt
└── vendor_image_conf.txt