code-v1.1.1-LTS全量源码阅读（一）全量源码的目录结构

本篇内容为HarmonyOS设备开发需要使用到的全量源码阅读第一篇，不定期更新，咕咕咕。

在进行源码阅读之前，首先是获取源码，这里使用的源码是目前的1.1.1LTS版本源码，可从HarmonyOS设备开发官网获取，地址device.harmonyos.com，选择“开始”，“获取源码”，具体代码使用的是全量代码，如下图所示：

下载此份全量代码，在Linux环境下解压，可以查看到此份源码的目录结构大致如下：

在这里简要的介绍一下每个目录的子目录，以及目录的具体功能。按照顺序从上往下看，首先是.repo目录，这个目录下没有实质与代码编辑有关的内容，主要是与OpenHarmony源码仓库相关的各类文件，.repo目录展开如下：

application目录是比较重要的目录，是实质参与编译的，开发者的主要开发代码都会放在application当中。目前的application目录下仅有一个sample目录，进入此目录会看到有两个子目录，分别是camera与wifi-iot，这两个对应着HarmonyOS开发常用的三种芯片：camera对应的是Hi3516带屏幕设备与Hi3518摄像头设备，内核使用的是LiteOS-A；而wifi-iot项目对应的是Hi3861芯片，内核使用的是LiteOS-M。关于LiteOS-A内核与LiteOS-M内核的差异在这里不做过多展开，感兴趣的同学可以查看OpenHarmony上对两种内核的解释说明，地址如下 zh-cn/device-dev/kernel/kernel.md · OpenHarmony/docs - Gitee.com 。

继续深入application目录，在camera目录下，cameraApp用于相机应用内容的开发，communication是通话模块，figures这个目录进入之后只能看到两张图片“媒体子系统架构”，gallery里面源码内容较多用于图库应用开发，launcher用于桌面开发，media用于多媒体开发，具体包括相机拍照录像与音视频播放的开发，screensaver是屏保应用，setting是设置。

在wifi-iot目录下，主要关注app目录，此目录下的文件为开发内容，在进行Hi3861芯片上的开发时，可修改此目录下的全部文件，之后开发新内容。一般来说一个wifi-iot项目会涉及到这样几个文件，app目录下的BUILD.gn，此文件内容指定了需要运行的项目与路径；具体项目下的BUILD.gn，例如目前展开的demolink项目下的BUILD.gn，此文件是模块的构建脚本，在其中会指定需要运行的c文件与需要引用的库文件；以demolink为例，helloworld.c是它的主要业务代码。

看完了application目录，之后看一下base目录，base目录展开如下图所示。base这个目录是HarmonyOS的基本功能的集合，包括了global全球化模块；hiviewdfx是DFX模块，DFX具体包括了DFR可靠性与DFT可测试性；iot专有硬件子系统当中包含了各个总线驱动的内容，常见的gpio，pwm，i2c，uart都在其中，调用这些接口可以实现对总线驱动的调用。powermgr是轻量级电池组件；security负责安全相关内容；sensors负责传感器的管理与使用；startup是启动恢复子系统，其中包括了appspawn，bootstrap，init，syspara四大组成部分，关于这一部分的详细介绍可以查看开发者官网的“启动恢复子系统”，在此不做过多展开介绍。update下只有一个ota_lite目录，这是OTA升级相关的功能，目前HarmonyOS的OTA升级只能使用全量包升级。

build目录负责了OpenHarmony的编译构建，内容十分繁杂，不做过多介绍，在此引用源码的readme文件。

build/lite                      # 编译构建主目录
├── components                  # 组件描述文件。
├── hb                          # hb pip安装包源码。
├── make_rootfs                 # 文件系统制作脚本。
├── config                      # 编译相关的配置项
│   ├── component               # 组件相关的模板定义。包括：静态库、动态库、扩展组件、模拟器库等
│   ├── kernel                  # 内核的编译配置参数
│   └── subsystem               # 子系统模板
├── ndk                         # Native API相关编译脚本与配置参数
├── product                     # 产品全量配置表，包括：配置单元、子系统列表、编译器等。
└── toolchain                   # 编译工具链相关，包括：编译器路径、编译选项、链接选项等。

developtools目录下是开发者工具，目前此目录仅有一个子目录，为packing_tool打包工具组件，打包工具组件包括了打包，拆包，包解析相关的功能。打包模块有将资源文件打包成hap包，和将多个hap包打包成app包两种模式。拆包模块有从app包中拆出所有hap包，和从hap包中拆出json文件两种模式。包解析模块可以根据对应解析模式，解析出指定设备类型下的hap包列表、hap包信息、签名信息等。

device与硬件相关，目前的device目录下有两个子目录，分别是hisilicon海思相关的芯片设备，例如在其中可以看到编译构建，驱动，硬件设备，以及Hi3518，Hi3861，Hi3516芯片编译项目相关内容，此外还有一些模组与第三方库。qemu与海思硬件芯片不同，按照源码中对这部分的介绍，qemu可以模拟内核运行在不同的单板，解除了对物理开发板的依赖。具体内容如下。

/device/qemu
├── arm_virt                # arm virt单板
│   └── liteos_a            # 与liteos_a内核相关的配置
│       └── config          # 驱动相关配置
├── drivers                 # 与平台相关的驱动目录
│   └── libs                # 驱动库
│       └── virt            # virt平台
├── riscv32                 # riscv32架构相关
│   ├── driver              # 驱动目录
│   ├── include             # 对外接口存放目录
│   └── libc                # 基础libc库

docs目录就很容易理解了，这就是OpenHarmony的文档说明，内容与网站上的OpenHarmony的文档描述一致。有必要说一下的是这份文档内容更贴近代码，但是内容更新可能会相对滞后，例如很明显的在docker文件夹下，有docker镜像的使用方案，这里的docker版本是0.0.3，而官网的docker版本已经更新到了0.0.5（虽然我不知道这个版本更新有什么差别，因为确实新版本和旧版本都是可以用的）。

domain一般用于第三方SDK的集成，目前源码的目录下只有iot/link，readme文档中将这部分称为iot子系统的集成参考。

domains/iot/                              # 仓目录
└── link
    ├── BUILD.gn                       # 构建脚本
    ├── demolink                       # 三方厂商与平台接口的适配层构建目录
    │   ├── BUILD.gn
    │   ├── demosdk_adapter.c
    │   └── demosdk_adapter.h
    └── libbuild                       # 三方厂商SDK构建目录
        ├── BUILD.gn
        ├── demosdk.c
        └── demosdk.h

驱动这部分的代码非常的多，它主要分为四个子目录，分别是adapter适配器，这其中包括了HDF驱动框架相关内容，代码量较大，以后再展开详细说明；framework是驱动子系统的核心源码，包括驱动框架、配置管理、配置解析、驱动通用框架模型、硬件通用平台能力接口等。这一部分的具体功能如下。

/drivers/framework
├── ability        #提供驱动开发的能力支持，如消息模型库等
│   ├── config     #配置解析代码
│   └── sbuf       #数据序列化代码
├── core           #实现驱动框架的核心代码
│   ├── adapter    #实现对内核操作接口适配，提供抽象化的接口供开发者使用
│   ├── common     #驱动框架公共基础代码
│   ├── host       #驱动宿主环境模块
│   ├── manager    #驱动框架管理模块
│   └── shared     #host和manager共享模块代码
├── include        #驱动框架对外提供能力的头文件
│   ├── config     #提供配置解析能力的头文件
│   ├── core       #驱动框架对外提供的头文件
│   ├── net        #网络数据操作相关的头文件
│   ├── osal       #系统适配相关接口的头文件
│   ├── platform   #平台设备相关接口的头文件
│   ├── utils      #驱动框架公共能力的头文件
│   └── wifi       #WLAN对外提供能力的头文件
├── model          #提供驱动通用框架模型
│   ├── display    #显示框架模型
│   ├── input      #输入框架模型
│   ├── network    #WLAN框架模型
│   └── sensor     #Sensor驱动模型
├── support        #提系统的基础能力 
│   └── platform   #平台设备驱动框架及访问接口，范围包括GPIO、I2C、SPI等
├── tools          #hdf框架工具相关的源码
│   └── hc-gen     #配置管理工具源码
└── utils          #提供基础数据结构和算法等

drivers目录下的liteos是内核驱动相关内容，主要包括以下内容

/drivers/liteos
├── hievent         # 事件日志管理驱动
├── include         # 对外头文件存放目录
├── tzdriver        # 用于ree/tee切换、通讯，提供应用层访问的设备节点

drivers目录下的peripheral负责各种外设相关的驱动，内容较多，不做过多展开。

foundation目录下有着HarmonyOS分布式特性相关的功能，例如分布式任务调度与分布式通信就是再这个模块中实现的。其中aafwk是ability开发框架接口与ability管理服务，ace是js应用开发框架，ai是ai框架，appexecfwk是包管理服务相关内容，communication是分布式通信，distributedschedule是分布式任务调度，graphic负责图像相关功能，multimedia是多媒体模块。关于这一部分的源码，是HarmonyOS分布式特性的重中之重，日后再详细逐个展开阅读。

kernel不做过多展开，它是内核相关的源码，展开以后内容极多。目前的OpenHarmony全量代码中不包括linux内核，仅仅只包含了liteos-a内核与liteos-m内核，liteos-a适用于Hi3518，Hi3516，liteos-m适用于Hi3861。

out目录下存放了编译产物，首次下载源码之后没有out目录，执行过编译以后就会有了，使用hb set指令可以编译三种项目，分别对应着Hi3861芯片，Hi3518芯片，Hi3516芯片。Hi3861的wifiiot项目编译的产物在hispark_pegasus目录下，如果使用Hiburn工具进行烧录，则选择文件Hi3861_wifiiot_app_allinone.bin文件即可。

prebuilts预编译目录下有两个子目录，分别是lite目录与signcenter目录。lite目录下只有一个sysroot，sysroot是一个用作clang编译器查找标准库和头文件的根目录，其中libc库是由开源库musl编译得到，它的具体结构如下。signcenter包含了OpenHarmony编译构建过程中的应用签名相关内容。

/prebuilts/lite/sysroot
├── build                   # 工具链构建目录，包括构建脚本
├── thirdparty              # 临时生成的工具链构建所需的三方头文件
├── usr                     # 对外C库及头文件
│   ├── include             # 对外头文件存放目录
│   │  └── arm-liteos       # 工具链对应的芯片架构
│   └── lib                 # 对外C库存放目录
│       └── arm-liteos      # 工具链对应的芯片架构

test测试子系统下的内容相对也比较多，不做过多展开。初略的看test测试子系统下主要包括了这几个文件夹，developertest是开发者自测框架，开发者测试可以提高在编码阶段代码的鲁棒性，xdevice是OpenHarmony中为测试框架的核心组件，提供用例执行所依赖的相关服务，XTS子系统是OpenHarmony生态认证测试套件的集合，acts存放acts相关测试用例源码与配置文件，其目的是帮助终端设备厂商尽早发现软件与OpenHarmony的不兼容性，确保软件在整个开发过程中满足OpenHarmony的兼容性要求，tools存放acts相关测试用例开发框架。

third_party是第三方组件，直接解压出来的源码中已经集成了一些三方库，在此不做逐一介绍。

utils是HarmonyOS的公告基础库，在其他软件开发中，也常将utils作为工具类的存放使用，在HarmonyOS当中，公共基础库存放了OpenHarmony通用的基础组件。这些基础组件可被OpenHarmony各业务子系统及上层应用所使用。

vendor是厂商提供的源码，目前这里主要有两个厂商，分别是海思与华为，其中还包括了一些管脚的使用案例，例如华为提供的源码就有与gpio使用相关的案例。

最后还有两个小东西，分别是编译脚本与配置文件，两份内容都很精简，不做过多介绍。

以上就是关于OpenHarmony源码目录结构的简要介绍，在后续的系列帖子中，将对源码内容进行更详细的介绍。