最新OpenHarmony系统一二级目录整理

Posted 2023-03-13 坚果的博客

最新OpenHarmony系统一二级目录整理

坚果:润开鸿技术专家，华为HDE，InfoQ签约作者，OpenHarmony布道师，擅长HarmonyOS应用开发、跨平台Flutter开发、熟悉服务卡片开发、小程序开发、GO的相关开发。开源项目gin-vue-admin成员之一，先后在CSDN等平台分享了多篇技术文章，I在“战码先锋”活动中作为大队长，累计培养三个小队长，带领100+队员完成Pr的提交合入。

我们在学习OpenHarmony的时候，如果对系统的目录结构了解，那么无疑会提升自己对OpenHarmony更深层次的认识。

于是就有了今天的整理。

首先在此之前，我们要获取源码

获取源码的方式

OpenHarmony主干代码获取

方式一（推荐）：通过repo + ssh下载（需注册公钥，请参考码云帮助中心）。

repo init -u [e-mail]:openharmony/manifest.git -b master --no-repo-verify
repo sync -c
repo forall -c \'git lfs pull\'

方式二：通过repo + https下载。

repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
repo sync -c
repo forall -c \'git lfs pull\'

现在代码已经获取到了，我们就可以展开来对一二级目录进行更深的认识。

在此之气,我们来看一下tree的简单使用

控制深度（假设为2）

tree -L 2 

只显示目录

tree -d

对需要显示的文件进行过滤

# 只显示包含 "L2"字符串的文件，并将过滤后的空目录也同时过滤掉
[root@ Test]# tree -P \'*L2*\' --prune
# 只显示不包含 "L2"字符串的文件，并将过滤后的空目录也同时过滤掉
[root@ Test]# tree -I \'*L2*\' --prune

好的，学完这两个命令，我们就可以先运行tree -L 2 打印目录，总览一下。

打印如下

.
├── applications
│   ├── sample
│   └── standard
├── arkcompiler
│   ├── ets_frontend
│   ├── ets_runtime
│   ├── runtime_core
│   └── toolchain
├── base
│   ├── account
│   ├── customization
│   ├── global
│   ├── hiviewdfx
│   ├── inputmethod
│   ├── iothardware
│   ├── location
│   ├── msdp
│   ├── notification
│   ├── powermgr
│   ├── print
│   ├── request
│   ├── security
│   ├── sensors
│   ├── startup
│   ├── telephony
│   ├── theme
│   ├── time
│   ├── update
│   ├── usb
│   ├── useriam
│   └── web
├── build
│   ├── build_scripts
│   ├── common
│   ├── config
│   ├── core
│   ├── docs
│   ├── gn_helpers.py
│   ├── LICENSE
│   ├── lite
│   ├── loader
│   ├── misc
│   ├── OAT.xml
│   ├── ohos
│   ├── ohos.gni
│   ├── ohos_system.prop
│   ├── ohos_var.gni
│   ├── prebuilts_download_config.json
│   ├── prebuilts_download.py
│   ├── prebuilts_download.sh
│   ├── print_python_deps.py
│   ├── __pycache__
│   ├── README_zh.md
│   ├── rust
│   ├── scripts
│   ├── subsystem_config_example.json
│   ├── subsystem_config.json
│   ├── templates
│   ├── test.gni
│   ├── toolchain
│   ├── tools
│   ├── version.gni
│   └── zip.py
├── build.py -> build/lite/build.py
├── build.sh -> build/build_scripts/build.sh
├── commonlibrary
│   ├── c_utils
│   ├── ets_utils
│   ├── memory_utils
│   └── utils_lite
├── developtools
│   ├── ace_ets2bundle
│   ├── ace_js2bundle
│   ├── bytrace
│   ├── global_resource_tool
│   ├── hapsigner
│   ├── hdc
│   ├── hiperf
│   ├── integration_verification
│   ├── packing_tool
│   ├── profiler
│   └── syscap_codec
├── device
│   ├── board
│   ├── qemu
│   └── soc
├── docs
│   ├── CODEOWNERS
│   ├── DCO.txt
│   ├── docker
│   ├── en
│   ├── LICENSE
│   ├── OAT.xml
│   ├── README.md
│   ├── README_zh.md
│   └── zh-cn
├── drivers
│   ├── hdf_core
│   ├── interface
│   ├── liteos
│   └── peripheral
├── foundation
│   ├── ability
│   ├── ai
│   ├── arkui
│   ├── barrierfree
│   ├── bundlemanager
│   ├── communication
│   ├── deviceprofile
│   ├── distributeddatamgr
│   ├── distributedhardware
│   ├── filemanagement
│   ├── graphic
│   ├── multimedia
│   ├── multimodalinput
│   ├── resourceschedule
│   ├── systemabilitymgr
│   └── window
├── interface
│   └── sdk-js
├── kernel
│   ├── common_modules
│   ├── linux
│   ├── liteos_a
│   ├── liteos_m
│   └── uniproton
├── napi_generator
│   ├── docs
│   ├── examples
│   ├── FAQ.md
│   ├── figures
│   ├── hdc
│   ├── LICENSE
│   ├── napi_IntelliJ_plugin
│   ├── napi_vs_plugin
│   ├── OAT.xml
│   ├── package.json
│   ├── README_zh.md
│   ├── release-notes
│   ├── src
│   └── test
├── ohos_config.json
├── out
│   ├── hispark_pegasus
│   └── preloader
├── prebuilts
│   ├── ark_tools
│   ├── build-tools
│   ├── clang
│   ├── cmake
│   ├── develop_tools
│   ├── gcc
│   ├── mingw-w64
│   ├── previewer
│   ├── python
│   └── rustc
├── productdefine
│   └── common
├── qemu-run -> vendor/ohemu/common/qemu-run
├── test
│   ├── ostest
│   ├── testfwk
│   └── xts
├── third_party
│   ├── abseil-cpp
│   ├── alsa-lib
│   ├── alsa-utils
│   ├── benchmark
│   ├── bounds_checking_function
│   ├── bzip2
│   ├── cef
│   ├── chromium
│   ├── cJSON
│   ├── cmsis
│   ├── css-what
│   ├── curl
│   ├── e2fsprogs
│   ├── EGL
│   ├── ejdb
│   ├── elfio
│   ├── eudev
│   ├── exfatprogs
│   ├── expat
│   ├── f2fs-tools
│   ├── FatFs
│   ├── ffmpeg
│   ├── flatbuffers
│   ├── flutter
│   ├── FreeBSD
│   ├── freetype
│   ├── fsck_msdos
│   ├── gettext
│   ├── giflib
│   ├── glib
│   ├── glslang
│   ├── gn
│   ├── googletest
│   ├── gptfdisk
│   ├── grpc
│   ├── gstreamer
│   ├── harfbuzz
│   ├── icu
│   ├── iniparser
│   ├── iowow
│   ├── iptables
│   ├── jerryscript
│   ├── jinja2
│   ├── jsframework
│   ├── json
│   ├── jsoncpp
│   ├── libbpf
│   ├── libcoap
│   ├── libdrm
│   ├── libevdev
│   ├── libexif
│   ├── libffi
│   ├── libinput
│   ├── libjpeg-turbo
│   ├── libnl
│   ├── libphonenumber
│   ├── libpng
│   ├── libpsl
│   ├── libsnd
│   ├── libsoup
│   ├── libunwind
│   ├── libusb
│   ├── libuv
│   ├── libwebsockets
│   ├── libxml2
│   ├── littlefs
│   ├── ltp
│   ├── lwip
│   ├── lz4
│   ├── markupsafe
│   ├── mbedtls
│   ├── mesa3d
│   ├── mindspore
│   ├── mksh
│   ├── mtdev
│   ├── musl
│   ├── newfs_msdos
│   ├── nghttp2
│   ├── ninja
│   ├── node
│   ├── ntfs-3g
│   ├── NuttX
│   ├── opencl-headers
│   ├── openGLES
│   ├── openh264
│   ├── openmax
│   ├── openSLES
│   ├── openssl
│   ├── optimized-routines
│   ├── parse5
│   ├── pcre2
│   ├── pixman
│   ├── popt
│   ├── protobuf
│   ├── pulseaudio
│   ├── python
│   ├── PyYAML
│   ├── qrcodegen
│   ├── re2
│   ├── selinux
│   ├── skia
│   ├── spirv-headers
│   ├── spirv-tools
│   ├── sqlite
│   ├── toybox
│   ├── typescript
│   ├── typescript_eslint
│   ├── tzdata
│   ├── u-boot
│   ├── unity
│   ├── vk-gl-cts
│   ├── vulkan-headers
│   ├── wayland-ivi-extension
│   ├── wayland-protocols_standard
│   ├── wayland_standard
│   ├── weex-loader
│   ├── weston
│   ├── wpa_supplicant
│   └── zlib
└── vendor
    ├── alientek
    ├── asrmicro
    ├── bearpi
    ├── beken
    ├── bestechnic
    ├── chipsea
    ├── goodix
    ├── hihope
    ├── hisilicon
    ├── hpmicro
    ├── isoftstone
    ├── kaihong
    ├── lockzhiner
    ├── ohemu
    ├── openvalley
    ├── osware
    ├── talkweb
    ├── telink
    └── unionman

applications/

内置的示例应用程序

standard/

标准系统的示例应用程序，包括launcher，settings，systemui等

.
├── admin_provisioning
├── app_samples
├── call
├── camera
├── contacts
├── contacts_data
├── filepicker
├── hap
├── launcher
├── mms
├── notes
├── permission_manager
├── photos
├── screenlock
├── screenshot
├── security_privacy_center
├── settings
├── settings_data
├── systemui
└── theme

sample/camera

小型系统的示例应用程序，包括launcher，settings，camera等

sample/wifi-iot

轻量系统的示例应用程序,WIFI_IOT_APP组件，提供了iothardware、demolink、samgr等示例代码。

arkcompiler

ets_frontend

ets_frontend组件是方舟运行时子系统的前端工具，结合ace-ets2bundle组件，支持将ets文件转换为方舟字节码文件。

ets_runtime

方舟eTS运行时是OpenHarmony上默认的ArkTS语言运行时。支持Ecmascript规范定义的标准库和高效container容器库，提供完备的C++交互ArkTS NAPI和各种高性能的垃圾回收器，驱动着万物互联时代的OpenHarmony应用程序。

runtime_core

方舟编译器运行时公共组件（ArkCompiler Runtime Core）是OpenHarmony中语言运行时的公共组件。主要由与语言无关的基础运行库组成，包含承载字节码以及执行字节码所需要相关信息的ArkCompiler File文件组件、支持运行时调试的Debugger Tooling工具组件、提供不同系统平台公共接口的ArkCompiler Base基础库组件、以及与语言无关的公共指令集体系结构ISA等。

toolchain

方舟工具链（ArkCompiler Toolchain）为开发者提供了一套OpenHarmony应用程序调试调优工具，其功能包括单步调试、断点调试、Watch变量及表达式、CPU Profiler和Heap Profiler等，并支持多实例和Worker调试。

base

基础软件服务子系统集和硬件服务子系统集，可根据需要进行裁剪。

account/os_account

在标准系统上，帐号子系统主要提供系统帐号生命周期管理，分布式帐号登录状态管理和应用帐号添加删除等基础管理能力。

customization

customization/config_policy

配置策略组件为各业务模块提供获取各配置层级的配置目录或配置文件路径的接口。

customization/enterprise_device_management

企业设备管理组件EDM(Enterprise Device Management)给企业MDM（Mobile Device Management）应用开发者提供管理应用开发框架，设定管理模式以及提供企业设备管理功能能力集。为企业环境下的应用提供系统级别的管理功能API。

global

全球化子系统，提供多语言支持，多文化的资源管理，以及国际化能力

.
├── i18n
├── i18n_lite
├── resource_management
├── resource_management_lite
├── system_resources
└── timezone

hiviewdfx

DFX框架子系统，提供日志和系统事件的打印，输出功能

.
├── blackbox
├── faultloggerd
├── hiappevent
├── hichecker
├── hicollie
├── hidumper
├── hidumper_lite
├── hievent_lite
├── hilog
├── hilog_lite
├── hisysevent
├── hitrace
├── hiview
└── hiview_lite

inputmethod

inputmethod/imf

输入法框架，主要作用是拉通应用和输入法，保证应用可以通过输入法进行文本输入

iothardware

iothardware/peripheral

IOT（The Internet of Things）硬件设备操作的接口。本模块提供设备操作接口有：FLASH,GPIO,I2C,PWM,UART,WATCHDOG等

location

位置服务组件

msdp

msdp/device_status

MSDP设备状态感知框架能够识别出目前设备的状态并传递给订阅者，整个框架是基于MSDP算法库和系统SensorHDI组件组成的

notification

notification/common_event_service

OpenHarmony通过CES（Common Event Service，公共事件服务）为应用程序提供订阅、发布、退订公共事件的能力。

notification/distributed_notification_service

OpenHarmony通过ANS（Advanced Notification Service，通知系统服务）对通知类型的消息进行管理，支持多种通知类型，包括文本，长文本，多文本，图片，社交，媒体等。所有系统服务以及应用都可以通过通知接口发送通知消息，用户可以通过SystemUI查看所有通知消息。

notification/eventhandler

EventHandler提供了OpenHarmony线程间通信的基本能力，可以通过EventRunner创建新线程，将耗时的操作抛到新线程上执行，从而实现在不阻塞原来的线程的基础上合理地处理耗时任务

power

电源管理服务子系统，提供系统各模块的电源状态管理等接口

print

print/print_fwk

打印框架服务（Distributed Print Service，DPS） 支持三方应用创建打印任务，拉起后台打印任务管理，管理打印扩展和打印任务。
提供打印扩展框架，实现三方打印扩展的接入，管理打印任务与打印机之间的关系，启动、暂停/恢复、取消打印任务，查询打印进度等。

打印框架服务覆盖范围包含：打印管理、打印管理服务和打印扩展管理

request

request/request

Request服务向三方应用提供文件下载/上传能力，以支撑应用开发者方便、高效地使用下载/上传业务的功能。

security

安全子系统，提供系统安全，数据安全，应用安全等能力

.
├── access_token
├── appverify
├── certificate_manager
├── crypto_framework
├── dataclassification
├── device_auth
├── device_security_level
├── huks
├── permission_lite
└── selinux

sensors

传感器服务子系统，提供轻量级传感器服务基础框架

.
├── medical_sensor
├── miscdevice
├── miscdevice_lite
├── sensor
├── sensor_lite
└── start

startup

启动恢复子系统，负责在内核启动之后，到应用启动之前的系统关键进程和服务的启动过程，并提供系统属性查询，修改及设备恢复出厂设置的功能。

telephony

电话服务子系统，提供了一系列的API用于获取无线蜂窝网络和SIM卡相关的一些信息。应用可以通过调用API来获取当前注册网络名称、网络服务状态、信号强度以及SIM卡的相关信息。

.
├── call_manager
├── cellular_call
├── cellular_data
├── core_service
├── ril_adapter
├── sms_mms
├── state_registry
└── telephony_data

theme

theme\\screenlock_mgr

锁屏管理服务是OpenHarmony中系统服务，为锁屏应用提供注册亮屏、灭屏、开启屏幕、结束休眠、退出动画、请求解锁结果监听，并提供回调结果给锁屏应用。锁屏管理服务向三方应用提供请求解锁、查询锁屏状态、查询是否设置锁屏密码的能力。

theme\\wallpaper_mgr

该仓主要为系统提供壁纸管理服务能力，支持系统显示、设置、切换壁纸等功能。

time

time\\time_service

在整个OpenHarmony架构中提供管理系统时间时区和定时的能力，支持设置获取时间、日期、时区和系统定时器功能。

update

OpenHarmony升级子系统用来支持OpenHarmony设备的OTA(Over The Air)升级。

.
├── packaging_tools
├── sys_installer
├── sys_installer_lite
├── update_app
├── updater
└── updateservice

usb

usb/usb_manager

Usb设备作为host设备连接device设备进行数据传输。

useriam

/useriam/face_auth

人脸认证 （faceauth）支持用户人脸的录入，删除和认证功能。

useriam/pin_auth

口令认证（pinauth）模块支持用户口令的设置，删除和认证功能。与用户IAM子系统基础框架配合，也可以支持用户口令修改的功能。

useriam/user_auth_framework

统一用户认证框架

web

web/webview

nweb是OpenHarmony webview组件的Native引擎，基于Chromium和CEF构建。

build

编译构建子系统提供了一个基于Gn和ninja的编译构建框架。

foundation

系统基础能力子系统集，这部分可以根据需要进行裁剪。

ability

├── ability_base
├── ability_lite
├── ability_runtime
├── dmsfwk
├── dmsfwk_lite
├── form_fwk
└── idl_tool

ability_base：部件作为元能力的基础定义部件，提供组件启动参数（Want），系统环境参数（Configuration），URI参数（Uniform Resource Identifier）的定义，用于启动应用，获取环境参数等功能。

ability_lite：元能力组件，是OpenHarmony为开发者提供的一套开发鸿蒙应用的开发框架

ability_runtime：元能力子系统实现对Ability的运行及生命周期进行统一的调度和管理，应用进程能够支撑多个Ability，Ability具有跨应用进程间和同一进程内调用的能力。Ability管理服务统一调度和管理应用中各Ability，并对Ability的生命周期变更进行管理。

dmsfwk：分布式组件管理部件模块负责跨设备组件管理，提供访问和控制远程组件的能力，支持分布式场景下的应用协同

dmsfwk_lite：轻量级分布式组件管理模块负责跨设备启动FA的能力，支持分布式场景下的应用协同

form_fwk：卡片是一种界面展示形式，可以将应用的重要信息或操作前置到卡片，以达到服务直达的目的。

idl_tool：在OpenHarmony中，当应用/系统服务的客户端和服务端进行IPC（Inter-Process Communication）跨线程通信时，需要定义双方都认可的接口，以保障双方可以成功通信，OpenHarmony IDL（Interface Definition Language）则是一种定义此类接口的工具。OpenHarmony IDL先把需要传递的对象分解成操作系统能够理解的基本类型，并根据开发者的需要封装跨边界的对象。

commonlibrary

.
├── c_utils
├── ets_utils
├── memory_utils
└── utils_lite

c_utils：C++公共基础类库为标准系统提供了一些常用的C++开发工具类

ets_utils：ets_utils组件共提供四个子模块，分别是：js_api_module、js_util_module、js_sys_module和js_worker_module

memory_utils：内存基础库部件位于公共基础库子系统中，为上层业务提供对应的操作内存的系统库，保证上层业务的稳定性。

utils_lite：轻量级公共基础库存放OpenHarmony通用的基础组件。这些基础组件可被OpenHarmony各业务子系统及上层应用所使用

developtools

常用开发工具集合

developtools\\ace_ets2bundle提供声明式范式的语法编译转换，语法验证，丰富友好的语法报错提示能力。

device

docs

此仓库存放OpenHarmony网站提供的设备开发、应用开发对应的开发者文档。

drivers

OpenHarmony驱动子系统采用C面向对象编程模型构建，通过平台解耦、内核解耦，兼容不同内核，提供了归一化的驱动平台底座，旨在为开发者提供更精准、更高效的开发环境，力求做到一次开发，多系统部署。

.
├── hdf_core
├── interface
├── liteos
└── peripheral

hdf_core该仓主要存放OpenHarmony驱动子系统核心源码信息（包括驱动框架、配置管理、配置解析、驱动通用框架模型、硬件通用平台能力接口等），旨在为开发者提供更精准、更高效的开发环境，力求做到一次开发，多系统部署。

interface该仓库用于管理各模块HDI(Hardware Device Interface)接口定义，接口定义使用IDL语言描述并以·idl文件形式保存。

liteos内核驱动是软件与硬件交互的桥梁，通过文件系统接口访问OpenHarmony内核的硬件资源，是用户与内核之间、进程与进程之间通信的一种方式。每类驱动代表一种能力，用户可以根据需求选择对应驱动，完成数据的传输

peripheral此仓主要包含各外设器件驱动相关的HDI（Hardware Driver Interface）接口、HAL实现、驱动模型及测试用例等，根据模块划分不同目录。

interface

interface/sdk-js

JS/TS API 公共仓，用来提交 API d.ts 声明文件以及API相关工具。

kernel

OpenHarmony针对不同量级的系统，分别使用了不同形态的内核，分别为LiteOS和Linux。在轻量系统、小型系统可以选用LiteOS；在小型系统和标准系统上可以选用Linux。

.
├── common_modules
├── linux
├── liteos_a
├── liteos_m
└── uniproton

common_modules

New IP在现有IP能力的基础上，以灵活轻量级报头和可变长多语义地址为基础，通过二三层协议融合，对协议去冗和压缩，减少冗余字节，实现高能效比，高净吞吐，提升通信效率。打造终端之间高效的横向通信，支撑超级终端的体验，实现异构网络的端到端互联。

linux

不同版本的Linux内核，以及不同芯片平台适配Linux内核的相关配置，编译脚本等等

liteos_a

OpenHarmony LiteOS-A内核是基于Huawei LiteOS内核演进发展的新一代内核，Huawei LiteOS是面向IoT领域构建的轻量级物联网操作系统。在IoT产业高速发展的潮流中，OpenHarmony LiteOS-A内核能够带给用户小体积、低功耗、高性能的体验以及统一开放的生态系统能力，新增了丰富的内核机制、更加全面的POSIX标准接口以及统一驱动框架HDF（OpenHarmony Driver Foundation）等，为设备厂商提供了更统一的接入方式，为OpenHarmony的应用开发者提供了更友好的开发体验

liteos_m

OpenHarmony LiteOS-M内核是面向IoT领域构建的轻量级物联网操作系统内核，具有小体积、低功耗、高性能的特点，其代码结构简单，主要包括内核最小功能集、内核抽象层、可选组件以及工程目录等，分为硬件相关层以及硬件无关层，硬件相关层提供统一的HAL（Hardware Abstraction Layer）接口，提升硬件易适配性，不同编译工具链和芯片架构的组合分类，满足AIoT类型丰富的硬件和编译工具链的拓展

uniproton

UniProton主要目的在于为上层业务软件提供一个统一的操作系统平台，屏蔽底层硬件差异，并提供强大的调试功能。使得业务软件可在不同的硬件平台之间快速移植，方便产品芯片选型，降低硬件采购成本和软件维护成本。

napi_generator

本文主要介绍NAPI框架代码生成工具，它可以根据用户指定路径下的ts(typescript)接口文件一键生成NAPI框架代码、业务代码框架、GN文件等。在开发JS应用与NAPI间接口时，底层框架开发者无需关注Nodejs语法、C++与JS之间的数据类型转换等上层应用转换逻辑，只关注底层业务逻辑即可，专业的人做专业的事，从而可以大大提高开发效率。目前工具支持可执行文件、VS Code插件、IntelliJ插件三种入口。

prebuilts

.
├── ark_tools
├── build-tools
├── clang
├── cmake
├── develop_tools
├── gcc
├── mingw-w64
├── previewer
├── python
└── rustc

productdefine

/productdefine/common

一个完整的产品包括芯片组件部分和系统组件部分。芯片组件部分在vendor/company/product/目录下定义。本仓主要定义与芯片无关的通用系统组件形态配置。

test

\\ostest\\wukong

OpenHarmony稳定性测试自动化工具，通过模拟用户行为，对OpenHarmony系统及应用进行稳定性压力测试。

testfwk

/arkXtest

OpenHarmony自动化测试框架代码部件仓arkXtest，包含单元测试框架(JsUnit)和Ui测试框架(UiTest)。

/developer_test

OpenHarmony为开发者提供了一套全面的开发自测试框架OHA-developertest，开发者可根据测试需求开发相关测试用例，开发阶段提前发现缺陷，大幅提高代码质量。

/developer_test

/xdevice

xdevice是OpenHarmony中为测试框架的核心组件，提供用例执行所依赖的相关服务

xts

生态认证测试套件集合

third_party

三方库

.
├── abseil-cpp
├── alsa-lib
├── alsa-utils
├── benchmark
├── bounds_checking_function
├── bzip2
├── cef
├── chromium
├── cJSON
├── cmsis
├── css-what
├── curl
├── e2fsprogs
├── EGL
├── ejdb
├── elfio
├── eudev
├── exfatprogs
├── expat
├── f2fs-tools
├── FatFs
├── ffmpeg
├── flatbuffers
├── flutter
├── FreeBSD
├── freetype
├── fsck_msdos
├── gettext
├── giflib
├── glib
├── glslang
├── gn
├── googletest
├── gptfdisk
├── grpc
├── gstreamer
├── harfbuzz
├── icu
├── iniparser
├── iowow
├── iptables
├── jerryscript
├── jinja2
├── jsframework
├── json
├── jsoncpp
├── libbpf
├── libcoap
├── libdrm
├── libevdev
├── libexif
├── libffi
├── libinput
├── libjpeg-turbo
├── libnl
├── libphonenumber
├── libpng
├── libpsl
├── libsnd
├── libsoup
├── libunwind
├── libusb
├── libuv
├── libwebsockets
├── libxml2
├── littlefs
├── ltp
├── lwip
├── lz4
├── markupsafe
├── mbedtls
├── mesa3d
├── mindspore
├── mksh
├── mtdev
├── musl
├── newfs_msdos
├── nghttp2
├── ninja
├── node
├── ntfs-3g
├── NuttX
├── opencl-headers
├── openGLES
├── openh264
├── openmax
├── openSLES
├── openssl
├── optimized-routines
├── parse5
├── pcre2
├── pixman
├── popt
├── protobuf
├── pulseaudio
├── python
├── PyYAML
├── qrcodegen
├── re2
├── selinux
├── skia
├── spirv-headers
├── spirv-tools
├── sqlite
├── toybox
├── typescript
├── typescript_eslint
├── tzdata
├── u-boot
├── unity
├── vk-gl-cts
├── vulkan-headers
├── wayland-ivi-extension
├── wayland-protocols_standard
├── wayland_standard
├── weex-loader
├── weston
├── wpa_supplicant
└── zlib

vendor

.
├── alientek
├── asrmicro
├── bearpi
├── beken
├── bestechnic
├── chipsea
├── goodix
├── hihope
├── hisilicon
├── hpmicro
├── isoftstone
├── kaihong
├── lockzhiner
├── ohemu
├── openvalley
├── osware
├── talkweb
├── telink
└── unionman

build.py

轻量系统编译脚本的软链接

build.sh

标准系统编译脚本的软链接

总结：

由于Master分支代码更新迭代速度很快，部分目录结构可能在后面会发生变化。特别是高层次的部分代码。所以后面需要大家自己去修改，最后还是要感谢梁老师的《沉浸式刨析OpenHarmony源代码》一书，给我的启示。