类型	使用场景	调用层	特征
GN 原生规则（不带前缀） shared_library、static_library、executable	L1/Lite 系统（如轻量内核、Hi3861、Hi3516DV300 小系统）	GN 内置	直接生成 .a、.so、可执行文件，无 OpenHarmony 扩展逻辑
OHOS 扩展规则（带 ohos_ 前缀） ohos_shared_library、ohos_static_library	L2/L3 标准系统（如带 Linux 内核或 AOSP 基座的系统）	由 build/ohos/ohos_var.gni 定义	除 GN 原生行为外，还会执行 OHOS 特定逻辑（如 bundle 输出路径、部件依赖、签名、模块打包等）

 

二、规则区别详细分析
     

                                  shared_library vs ohos_shared_library

         在 L1 系统中：
                       由于没有 bundle.json / 子系统模块化体系，也没有 system/vendor 分区概念，因此只需要使用原生 shared_library 即可。

 

                                  static_library vs ohos_static_library

 

                 lite_component 与 lite_library 这两个是 LiteOS / L1 专用规则，由 build/lite 下的模板定义，

                 作用类似于 ohos_xxx，但针对小系统裁剪过。

 

          举例：

lite_library("wifiservice") {
    sources = [ "wifi_service.c" ]
    deps = [ "//foundation/communication/wifi_lite:core" ]
}

表示构建一个 L1 环境可用的轻量库。

 

三、为什么 L1 系统都用不带 ohos 前缀的？

因为 L1 系统不依赖 HAP/Bundle 框架，也没有完整的部件描述系统（bundle.json、external_deps、part_name 等），
而 ohos_shared_library / ohos_static_library 的模板内部强依赖这些全量系统机制。
在 L1 中，只需纯 GN 构建逻辑 + LiteOS 驱动/服务注册体系

 

OpenHarmony 官方文档：https://gitee.com/openharmony/build    构建系统主仓