背景&版本

OpenHarmony整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统 \> 子系统 \> 组件”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的组件。这里主要介绍如何裁剪resourceschedule子系统下的device_usage_statistics部件。

系统版本：OpenHarmony-4.1-Release

设备：RK3568

在裁剪resourceschedule子系统的device_usage_statistics部件时，遇到以下几个问题，根据编译提示的相关报错进行了修改，修改后成功编译并合入官方社区。

 

代码下载和编译命令

使用repo工具下载和同步代码

repo init -u https://gitee.com/openharmony/manifest -b OpenHarmony-4.1-Release --no-repo-verify

repo sync -c

repo forall -c 'git lfs pull'

下载编译工具链文件

build/prebuilts_download.sh --skip-ssl

编译rk3568镜像，这里以64位版本为例

./build.sh --product-name rk3568 --ccache --target-cpu arm64 --no-prebuilt-sdk

 

系统预编译

Openharmony完整的编译构建流程主要可以分成以下四个阶段：Preloader、Loader、GN以及Ninja过程。

 

预编译主要包括Preloader和Loader阶段，这两个阶段主要是执行python脚本build/hb/services/preloader.py和build/hb/services/loader.py。

• Preloader阶段根据vendor仓的产品配置config.json文件对产品配置进行解析，并将解析结果输出到out/preloader/{product_name}目录下

• loader阶段进行部件化配置的加载，并将解析结果输出到out/{product_name}/build_configs文件夹下。

out/preloader/{product_name}目录下的parts_config.json为Preloader阶段(preloader.py)解析(_generate_parts_config_json方法)的结果。

gn的宏变量定义主要有三种位置选择：

• BUILDCONFIG.gn 对于构建系统全局可见，一般定义工具链，cpu架构等变量，使用时不需要导入该文件

• ohos_var.gni 常规用于OpenHarmony构建多处使用的相关变量，使用变量需要导入该文件

• xxx.gni 各业务仓自定义文件，用于使用范围较小的相关变量，一般限制于单个代码仓内。使用变量需要导入该文件

在build/config/BUILDCONFIG.gn中，读取了parts_config.json的数据保存到global_parts_info全局变量中。因此global_parts_info可以在构建系统全局使用，每个部件的编译脚本中可以通过部件名称判断该部件是否被裁减，从而对不同的编译数据设置来对部件间的依赖关系解耦。如下：

declare_args() {
  "{partName}_feature_A" = true
  if (!defined(global_parts_info.{subsystem_O}_{partName_O})) {
    {partName}_feature_A = false
  }
}

 

裁剪操作

• 修改productdefine/common/inherit/rich.json文件，删除device_usage_statistics部件配置。

• 删除foundation/resourceschedule/device_usage_statistics目录。

 

问题一：编译时BUILD.gn报错

在//base/notification/distributed_notification_service/services/test/moduletest/BUILD.gn文件中提示Undefined identifier.

查看BUILD.gn文件，defines在82行定义，根据上面的报错可得出device_usage为false而distributed_notification_supported为true导致此问题。

在base/notification/distributed_notification_service/notification.gni文件中找到device_usage和distributed_notification_supported。

上面可以看到，distributed_notification_supported默认为true且无其他位置赋值，device_usage默认为true，在检测到resourceschedule_device_usage_statistics部件被裁剪后，设置device_usage值为false。

修改方案

在base/notification/distributed_notification_service/notification.gni文件的60行device_usage = false下添加一行：

distributed_notification_supported = false

 

问题二：在修改“问题一”之后继续编译advanced_notification_publish_service.cpp报错

报错提示distributed_screen_status_manager.h头文件未找到：

这是由于distributed_notification_supported部件代码移除，导致头文件distributed_screen_status_manager.h引入失败。

检查发现当其他位置引入这个头文件时，通过DISTRIBUTED_NOTIFICATION_SUPPORTED宏判断是否需要引入，而DISTRIBUTED_NOTIFICATION_SUPPORTED宏定义是由“问题一”中的配置处理的。

修改方案

在报错位置添加DISTRIBUTED_NOTIFICATION_SUPPORTED宏判断：

 

问题三：在修改“问题二”之后继续编译advanced_notification_service.cpp报错

修改方案：

对比发现，在其他位置的DistributedNotificationManager都是通过DISTRIBUTED_NOTIFICATION_SUPPORTED宏判断是否执行相关代码，因此在报错位置添加同样的判断即可。

 

问题四：在修改“问题三”之后继续编译advanced_notification_utils.cpp报错

与“问题二”一样，由于distributed_notification_supported部件代码移除，导致头文件distributed_database.h引入失败。

修改方案：

 在base/notification/distributed_notification_service/services/ans/src/advanced_notification_utils.cpp中发现，存在DISTRIBUTED_NOTIFICATION_SUPPORTED判断头文件的引入，因此将include "distributed_database.h移动位置即可。

 

在完成上述的四个问题修改后，裁剪device_usage_statistic后系统编译成功。社区issue和代码提交PR如下：

issue：https://gitee.com/openharmony/notification_distributed_notification_service/issues/IA9OIY

pr：https://gitee.com/openharmony/notification_distributed_notification_service/pulls/1861