花半秒钟就看透事物本质的人，和花一辈子都看不透事物本质的人，注定是截然不同的命运。
做开发也一样，如果您能看透开发的整个过程，就不会出现“学会了某个 RTOS 的开发，同样的 RTOS 开发换一块开发板又不会了”，“跟着教程学会了某块开发板的某个 Demo 开发，自己开发另一个 Demo 又不会了”等等问题。
只要能看透就能做到触类旁通，游刃有余！一定要活学活用，不能学死了，多想想为什么，不要死记过程。
在基于 HarmonyOS 开发 Hi3861 之前，需要对整个开发环境及过程有一个全局上的了解。
目前我们对 Hi3861 的开发主要涉及上图中的内核抽象层、系统能力子系统、DXF 子系统、公共基础库子系统（提供 KV 存储、文件操作、定时器、IoT 外设控制等能力供 OpenHarmony 各业务子系统及上层应用使用）、系统服务框架子系统（用于提供面向服务编程和对外提供能力用于分布式任务调度）。
该构建系统由 Python 脚本配合 gn、ninja 组成，若是为了开发 Demo 或者应用，不必细究编译构建系统的具体实现细节，只需要做到会使用即可。
当我们输入 python build.py wifiiot 指令，Python 脚本开始读取 build 目录中与 wifiiot 设备相关的各项参数信息并构造编译指令如下：
gn工具所在目录/gn gen 源码所在目录/out/wifiiot --root=. --dotfile=build/lite/.gn --args='product = "wifiiot" ohos_build_type = "release"'
这条指令用于生成一些 xxx.ninja 文件，这些文件将在下一阶段指导 ninja 编译源码生成烧录文件。
ninja 工具所在目录 /ninja -w dupbuild=warn -C 源码所在目录 /out/wifiiot 这条指令用于根据前面生成的 xxx.ninja 文件调用工具链编译源码最终生成烧录文件。
gn 用于根据每个目录下的 BUID
.
gn 文件搜寻编译生成烧录文件所需的依赖文件，所以我们只要学会如何写 BUILD.gn 文件即可，关于具体实现本章就暂且略过，后期会给大家补上。
这里以 led_example.c 程序为例，给大家分析 BUILD.gn 文件，希望大家能举一反三：在 code-1.0\applications\sample\wifi-iot\app 目录中有一个 BUILD.gn 文件，大家可以将该文件理解为一个管理者。
它管理 app 目录中的每个子目录，通过这个 BUILD.gn 文件中的 features 字段可以决定哪一个子目录中的 BUILD.gn 中指定的源文件会被编译到烧录文件中。
假设我们要将 app/iothardware 目录中的 led_example.c 文件编译到烧录程序中，需要打开 app/iothardware/BUILD.gn 文件查看该文件中的源代码被为静态库的名称，可以看到名称为 led_example。
这时我们将 app/BUILD.gn 文件中的 startup 修改为 iothardware:led_example 就大功告成啦！
.gn 文件的 feature 字段格式为：模块源文件所在路径:模块名称。
请注意：
.gn 文件中的空白都是空格，不是 Tab 键（制表符），如果您输入了制表符，在生成 ninja 文件时就会产生如下图所示错误：
我出一个问题考考大家，如果我们在 app/iothardware 目录中添加一个 hello_world.c 文件，主要用于打印 hello_world。
假设源代码已经写好了，如下图所示，您应该如何将其添加进编译列表中与其他程序一起进行编译呢？
您应该修改 app/iothardware/BUILD.gn 文件，将 hello_world.c 文件添加到 sources 字段中，如下图所示：
若这时我们在 app/iothardware 目录下新建一个 head 的目录，并在其中新建一个名为 hello_world.h 的头文件，内容如下图所示：
并修改 hello_world.c 的内容如下图所示：
这时如果直接进行编译，则会产生找不到头文件错误，如下图所示：
我们应该继续对app/iothardware/BUILD.gn文件进行修改，在include_dirs中添加hello_world.h头文件所在路径，如下图所示：
上面的路径中以 // 开头的路径为绝对路径，// 表示 root 参数指定的路径，也就是 code-1,0，而 test 路径则为相对路径，以当前 BUILD.gn 文件所在目录作为参照。
这样一个简单的 Demo 就开发好了，不知道读者有没有这样的疑问：为什么我知道启动一个任务的宏是 SYSY_RUN()，IIC、SPI 等等外设操作的函数是什么？一系列类似的问题，那您继续往下看就能找到答案。
注意：Hi3861 模组只用到了部分组件。
希望大家能跟随我对目录的介绍，自己打开对应本地 SDK 的目录来看一看：
├── applications 存放例程
│ └── sample
├── base
│ ├── global 全球化子系统
│ ├── hiviewdfx DXF子系统
│ ├── iot_hardware iot设备的公共基础库子系统，提供外设操作，IIC、SPI等等
│ ├── security 安全子系统
│ └── startup 启动恢复相关
├── build 构建系统相关，存放各类芯片的编译构建参数等等
│ └── lite
├── build.py -> build/lite/build.py 与构建系统相配合的python脚本（用于启动构建）
├── docs 文档
├── domains 集成各个厂商的SDK
│ └── iot
├── drivers 驱动相关，HDF驱动框架
│ ├── hdf
│ └── liteos
├── foundation
│ ├── aafwk 提供一个Want名称的数据类型用于加速应用的启动
│ ├── ace JS应用开发框架
│ ├── appexecfwk 用于程序框架子系统
│ ├── communication 分布式通信子系统（软总线）
│ ├── distributedschedule 系统服务框架子系统（面向服务编程，提供服务、使用服务等）、分布式任务调度子系统
│ ├── graphic 图形子系统
│ └── multimedia 媒体子系统
├── kernel 内核以及kal层
│ ├── liteos_a 面向Hi3516 3518等资源较丰富设备的内核
│ └── liteos_m 面向资源受限设备的内核
├── out 编译输出文件
│ ├── ipcamera_hi3516dv300
│ └── wifiiot
├── prebuilts 提供一些库文件
│ └── lite
├── test 测试子系统
│ ├── developertest
│ ├── xdevice
│ └── xts
├── third_party 第三方库，例如cmsis、cJSON、Fatfs等等
├── utils 公共基础系统，提供文件操作统一接口、KV存储、文件操作、定时器
│ └── native
└── vendor 各个厂商提供的SDK
├── hisi
└── huawei
base 以及 foundation 中的各个组件中都有两个名字相同的文件夹 frameworks 和 interfaces。
