OpenHarmony设备开发基础产品信息配置本文将详细阐述产品信息配置，引入config.json中的信息，根据产品信息配置和构建配置梳理组件和模块依赖关系，增加大家在设备开发过程中对产品构建的理解.2.产品信息配置这里我们以hispark_pegasus产品为例进行介绍。下图为hispark_pegasus产品解决方案的目录结构。BUILD.gn和config.json在上一节中已经初步介绍过了。接下来，让我们看一下config.json文件。仍然以hispark_pegasus产品为例，配置文件如下：{"product_name":"wifiiot_hispark_pegasus",#Productname"type":"mini",#Systemtype,optional【mini,small,standard】"version":"3.0",#config.json版本号，固定"3.0""ohos_version":"OpenHarmony1.0",#selectedOSversion"device_company":"hisilicon",#chipmanufacturer"board":"hispark_pegasus",#开发板名称"kernel_type":"liteos_m",#selectedkerneltype"kernel_is_prebuilt":true,#kernel_version:",#selectedkernelversion"subsystems":[#Selectedsubsystem{"subsystem":"applications","components":[{"component":"wifi_iot_sample_app","features":[]}]},{...#MoreMultiplesubsystemsandcomponents}],"third_party_dir":"//device/soc/hisilicon/hi3861v100/sdk_liteos/third_party","product_adapter_dir":"//vendor/hisilicon/hispark_pegasus/hals"}为了防止过多的注释影响文件本身的数据载体，根据JSON规范（http://www.json.org,RFC4627,RFC7159),json不支持注释，这里的注释是我在截取的代码旁边加的，为了更直观的解释，config.json是编译构建的入口，上面的代码约定了产品名称和芯片manufacturer.name，开发板名称，内核类型，内核版本号，子系统，适配路径等，在上一篇介绍芯片方案的时候提到，一个开发板支持多种内核配置，可以支持同一个内核的不同版本,也可以支持不同内核的配置，修改内核类型kernel_type和内核版本kernel_version来切换开发板适配的内核，产品可以换厂家anddevelopmentversion通过修改芯片厂商名称和开发版本名称来选择芯片方案。除了芯片相关配置外，config.json中还配置了元器件信息。它一一定义了需要的子系统子系统。对于每一个子系统，它都一一定义了它所包含的组件，以及每个组件特性所附带的编译。即配置产品所依赖的系统能力，通过子系统、组件、目标等信息设置具体的依赖对象。通过该功能，OpenHarmony支持根据实际需要裁剪一些非必需的子系统或功能/模块，可以通过子系统“组合”系统功能，添加或删除一些子系统或组件。当我们构建一个产品时，构建工具hb会根据芯片方案的命名规则和config.json中配置的内核类型和内核版本信息去查找开发板内核配置信息。那么产品信息配置与芯片方案有什么关系呢？3、产品信息配置与芯片方案的关系根据源码路径的规则，产品配置信息在vendor目录下，方案在device目录下。首先根据命名规则，结合config.json中配置的device_company和board信息，编译工具可以找到hispark_pegasusk产品配置的开发板路径。修改这些信息可以在不同的芯片方案之间切换。比如通过config.json中的hisilicon+hispark_pegasus可以知道芯片方案位置//device/hisilicon/hispark_pegasus。其次，在芯片方案目录下，BUILD.gn配置了SDK开发板的编译信息。子目录分别存放其他SDK相关的组件信息。开发板支持的每个内核版本都需要存放在一个独立的目录下。推荐的命名方式是“_”连接kernel_type和kernel_version组成一个文件夹名。而目录下的config.gni文件配置了开发板相关的编译配置。当config.gni中的kernel_type和kernel_version与产品构建配置文件config.json中的配置匹配时，将选择config.gni中的配置作为产品对应的板级配置。比如你可以通过config.json中的liteos_m选择//device/hisilicon/hispark_pegasus/liteos_m/config.gni。一般来说，你可以找到对应的kernel_type_kernel_version/config.gni。综上所述，将hispark_pegasus产品配置以图形方式展开后，我们可以直观的看到组件之间的依赖关系：BUILD.gn配置了产品方案的相关配置，包括依赖模块等，但是在hispark_pegasus中只有一个空build产品代码中设置objectgroup:#Copyright(C)2020海思（上海）科技有限公司版权所有.group("hispark_pegasus"){}非空构建对象如图hispark_taurus构建.gn。比如在关系图中通过虚线添加一个init_configs依赖，这样依赖的模块就会一起参与编译。另外，config.json。里面配置的芯片和系统组件会按照我前面说的添加到构建中（关系图中红色的步骤1和2）。4.两种引入芯片方案的方式Hispark将芯片SDK配置到vendor子系统中，config.json通过子系统和组件配置形成对芯片SDK的依赖，最终共同编译出产品。从流程上看，产品构建时，首先加载产品构建信息，从config.json中解析子系统、组件、芯片等相关信息，识别模块的依赖关系。然后，从产品中编译条目BUILD.gn。开始编译，使用gn生成ninja文件，使用ninja编译构建。这是芯片解决方案引入的方式之一——默认编译，隐式依赖。该方法不需要在config.json中配置对芯片SDK的依赖。第二种方法是指通过子系统配置显式依赖芯片组件目录，按照模块划分配置各个组件的构建信息。一般在vendor子系统中配置SDK组件信息，例如：hi3861_sdk。可以配置多个可组合组件。在config.json中的vendor子系统中配置对SDK的依赖，例如下面摘自vendor/hisilicon/hispark_pegasus/config.json的代码：{"subsystem":"vendor","components":[{"component":"hi3861_sdk","target":"//device/soc/hisilicon/hi3861v100/sdk_liteos:wifiiot_sdk","features":[]}]}，在指向的target中可以看到对应的芯片以上代码解决。该方案需要在vendor子系统中配置芯片SDK组件，然后在config.json中添加对vendor子系统SDK组件的依赖。这种显式依赖可以清楚地看到产品解决方案所依赖的具体子系统和具体组件。如果SDK提供的组件较多（如上图所示），您可以在vendor子系统中配置多个独立的组件，对不同的系统能力进行拆分和组合。了解更多开源知识，请访问：开源基础软件社区https://ost.51cto.com。
