Hi3861 业务代码编写框架
前言：
业务代码通过 ninja 进行构建，类似于 make，同时借助于 gn 生成 ninja 构建规则，类似于 cmake，所以我们编写业务代码除了关注代码本身的内容外，还要将代码添加到 gn 的构建规则中去。
这种风格是继承自 linux 编译框架的风格，可能用惯了 STM32 啥单片机的小伙伴会觉得这个编译流程是老太太的裹脚布-又臭又长，有这种想法很正常，我刚接触的时候也想，搞一个 MCU 级别的小芯片，编译流程做的这么麻烦，不是劝退使用者嘛，实际上这些是对 LiteOS 内核适配，LiteOS 做的很大，最小都要 128K 的 ROM，对于 STM32F103C8 来说，移植都没法移植，不像 RT-Thread、FreeRTOS，最小 10K ROM 就能实现功能了，所以主观就觉得 LiteOS 拉胯。
实际上 LiteOS 设计和应用的场景一般不是应用于 这种极小资源的芯片的，在很多场景下用在多核的 MCU、AIOT 芯片等等，内核编译框架需要有强大的多核开发支持，所以其编译框架有着很浓厚的 Linux 编译背景，学习的小伙伴也不要觉得麻烦，这可以作为向 linux 开发学习进军的一个小跳板呢！
代码目录规则：
下面继续研究 Hi3861，目前官方给出的目录规则框架如下：
.
└── applications
└── BearPi
└── BearPi-HM_Nano
└── sample
│── my_first_app
│ │── hello_world.c
│ └── BUILD.gn
└── BUILD.gn那我按照官方的规则来建立一个测试代码目录，我的如下：
.
└── applications
└── BearPi
└── BearPi-HM_Nano
└── sample
│── test_app
│ │── test.c
│ └── BUILD.gn
└── BUILD.gn业务代码：
.c 文件内容，就是一个简单的打印程序：
#include "ohos_init.h"
#include "ohos_types.h"
#include <stdio.h>
void test(void)
{
printf("[DEMO] Hello world Test.\n");
}
SYS_RUN(test);SYS_RUN 用于将函数注册到 LiteOS 系统的运行代码中执行。
最小代码单元：
最小特性的配置文件（和源代码同级目录的 gn 文件）用于每个代码模块的编译，代码如下：
static_library("testapp") {
sources = [
"test.c"
]
include_dirs = [
"//utils/native/liteos/include"
]
}该文件定义了 testapp 的编译规则，他的源文件和头文件目录，其中 // 是工程目录
组件单元：
上一级目录的 gn 文件代码如下，定义了组件的依赖关系，定义了 app 组件的特性包含 a_test_app 目录下的 testapp 静态库，编译时将它加入
import("//build/lite/config/component/lite_component.gni")
lite_component("app") {
features = [
"a_test_app:testapp",
]
}编译结果：
代码编译结果如下：
烧写测试，看看有没有将代码添加到启动过程，可以看到执行打印出我写的代码了：
