!6343 文档规范性修改

Merge pull request !6343 from Austin/master

zh-cn/device-dev/kernel/kernel-basic-mini-time.md

@@ -12,7 +12,7 @@
 OpenHarmony LiteOS-M内核时间管理模块提供时间转换、统计功能。
 
 
-## 时间单位：
+## 时间单位
 
 - Cycle
   系统最小的计时单位。Cycle的时长由系统主时钟频率决定，系统主时钟频率就是每秒钟的Cycle数。

zh-cn/device-dev/kernel/kernel-mini-basic-soft.md

@@ -64,7 +64,7 @@ OpenHarmony LiteOS-M内核的软件定时器模块提供下面几种功能，接
 
   **表1** 软件定时器接口
 
-| 功能分类 | p接口描述 | 
+| 功能分类 | 接口描述 | 
 | -------- | -------- |
 | 创建、删除定时器 | -&nbsp;LOS_SwtmrCreate：创建定时器<br/>-&nbsp;LOS_SwtmrDelete：删除定时器 | 
 | 启动、停止定时器 | -&nbsp;LOS_SwtmrStart：启动定时器<br/>-&nbsp;LOS_SwtmrStop：停止定时器 | 

zh-cn/device-dev/kernel/kernel-mini-basic-task.md

@@ -275,7 +275,7 @@ UINT32 Example_TskCaseEntry(VOID)
 ```
 
 
-### 结果验证
+ **结果验证** 
 
 编译运行得到的结果为：
 

zh-cn/device-dev/kernel/kernel-mini-extend-dynamic-loading.md

@@ -6,6 +6,7 @@
 在硬件资源有限的小设备中，需要通过算法的动态部署能力来解决无法同时部署多种算法的问题。以开发者易用为主要考虑因素，同时考虑到多平台的通用性，LiteOS-M选择业界标准的ELF加载方案，方便拓展算法生态。LiteOS-M提供类似于dlopen、dlsym等接口，APP通过动态加载模块提供的接口可以加载、卸载相应算法库。如图1所示，APP需要通过三方算法库所需接口获取对应信息输出，三方算法库又依赖内核提供的基本接口，如malloc等。APP加载所需接口，并对相关的未定义符号完成重定位后，APP即可调用该接口完成功能调用。目前动态加载组件只支持arm架构。此外，待加载的共享库需要验签或者限制来源，确保系统的安全性。
 
   **图1** LiteOS-M内核动态加载架构图
+
   ![zh-cn_image_0000001200292052](figures/zh-cn_image_0000001200292052.png)
 
 

zh-cn/device-dev/kernel/kernel-mini-extend-file-fat.md

@@ -79,24 +79,24 @@ FAT文件系统的使用需要底层MMC相关驱动的支持。在一个带MMC
 
 ### 示例代码
 
-前提条件：
+ **前提条件：** 
 
-- 系统已将MMC设备分区挂载到user目录
+ 系统已将MMC设备分区挂载到user目录
 
-  代码实现如下：
+ **代码实现如下：** 
   
-```
-#include <stdio.h>
-#include <string.h>
-#include "sys/stat.h"
-#include "fcntl.h"
-#include "unistd.h"
-
-#define LOS_OK 0
-#define LOS_NOK -1
-
-int FatfsTest(void) 
-{     
+  ```
+  #include <stdio.h>
+  #include <string.h>
+  #include "sys/stat.h"
+  #include "fcntl.h"
+  #include "unistd.h"
+
+  #define LOS_OK 0
+  #define LOS_NOK -1
+
+  int FatfsTest(void) 
+  {     
     int ret;
     int fd = -1;
     ssize_t len;
@@ -171,8 +171,8 @@ int FatfsTest(void)
     }
 
     return LOS_OK;
-}
-```
+    }
+  ```
 
 
 ### 结果验证

zh-cn/device-dev/kernel/kernel-mini-extend-file-lit.md

@@ -94,7 +94,7 @@ int main(void) {
 ```
 
 
-### 结果验证
+ **结果验证** 
 
 首次编译运行得到的结果为：
 

zh-cn/device-dev/kernel/kernel-mini-memory-perf.md

@@ -121,7 +121,7 @@ OpenHarmony LiteOS-A内核的Perf模块提供下面几种功能，接口详细
 5. 调用输出缓冲区数据的接口LOS_PerfDataRead读取采样数据，并使用IDE工具进行解析。
 
 
-## 内核态编程实例
+####  内核态编程实例
 
 本实例实现如下功能：
 
@@ -138,7 +138,7 @@ OpenHarmony LiteOS-A内核的Perf模块提供下面几种功能，接口详细
 6. 输出统计结果。
 
 
-## 内核态示例代码
+####  内核态示例代码
 
 前提条件：在menuconfig菜单中完成perf模块的配置。
 
@@ -226,7 +226,7 @@ LOS_MODULE_INIT(perfTestHwEvent, LOS_INIT_LEVEL_KMOD_EXTENDED);
 ```
 
 
-### 内核态结果验证
+#### 内核态结果验证
 
   输出结果如下：
   
@@ -336,7 +336,7 @@ save perf data success at /storage/data/perf.data
 > 在进行./perf stat/record命令后，用户可多次执行./perf start 和 ./perf stop进行采样， 采样的事件配置为最近一次执行./perfstat/record 中设置的参数。
 
 
-### 用户态编程实例
+#### 用户态编程实例
 
 本实例实现如下功能：
 
@@ -351,7 +351,7 @@ save perf data success at /storage/data/perf.data
 5. 读取perf采样数据。
 
 
-### 用户态示例代码
+#### 用户态示例代码
 
   实例代码如下：
   
@@ -422,7 +422,7 @@ int main(int argc, char **argv)
 ```
 
 
-### 用户态结果验证
+#### 用户态结果验证
 
   输出结果如下
   

zh-cn/device-dev/kernel/kernel-mini-overview.md

@@ -12,7 +12,7 @@ OpenHarmony LiteOS-M内核架构包含硬件相关层以及硬件无关层，如
   ![zh-cn_image_0000001199351155](figures/zh-cn_image_0000001199351155.png)
 
 
-### CPU体系架构支持
+## CPU体系架构支持
 
 CPU体系架构分为通用架构定义和特定架构定义两层，通用架构定义层为所有体系架构都需要支持和实现的接口，特定架构定义层为特定体系架构所特有的部分。在新增一个体系架构的时候，必须需要实现通用架构定义层，如果该体系架构还有特有的功能，可以在特定架构定义层来实现。
 
@@ -27,7 +27,7 @@ CPU体系架构分为通用架构定义和特定架构定义两层，通用架
 LiteOS-M已经支持ARM Cortex-M3、ARM Cortex-M4、ARM Cortex-M7、ARM Cortex-M33、RISC-V等主流架构，如果需要扩展CPU体系架构，请参考[芯片架构适配点](../porting/porting-chip-kernel-overview.md#芯片架构适配点)。
 
 
-### 运行机制
+## 运行机制
 
 在开发板配置文件target_config.h配置系统时钟、每秒Tick数，可以对任务、内存、IPC、异常处理模块进行裁剪配置。系统启动时，根据配置进行指定模块的初始化。内核启动流程包含外设初始化、系统时钟配置、内核初始化、操作系统启动等，详见下图。
 

zh-cn/device-dev/kernel/kernel-small-apx-dll.md

@@ -48,7 +48,7 @@
 > - 如果链表节点的内存是动态申请的，删除节点时，要注意释放内存。
 
 
-### 编程实例
+ **编程实例** 
 
 **实例描述**
 

zh-cn/device-dev/kernel/kernel-small-basic-memory-virtual.md

@@ -45,8 +45,8 @@
 
   **表3** 获取进程空间系列接口
 
-| 功能分类 | 接口**名称** | 描述 |
-| -------- | -------- | -------- |
+| 接口名称| 描述 | 
+| -------- | -------- | 
 |  LOS_CurrSpaceGet | 获取当前进程空间结构体指针 |
 | LOS_SpaceGet | 获取虚拟地址对应的进程空间结构体指针 |
 | LOS_GetKVmSpace | 获取内核进程空间结构体指针 |

zh-cn/device-dev/kernel/kernel-small-basic-trans-rwlock.md

@@ -51,33 +51,33 @@
 
 2. 申请读模式下的锁LOS_RwlockRdLock或写模式下的锁LOS_RwlockWrLock。
 
-申请读模式下的锁：
+   申请读模式下的锁：
 
-- 若无人持有锁，读任务可获得锁。
+   - 若无人持有锁，读任务可获得锁。
 
-- 若有人持有锁，读任务可获得锁，读取顺序按照任务优先级。
+   - 若有人持有锁，读任务可获得锁，读取顺序按照任务优先级。
 
-- 若有人（非自己）持有写模式下的锁，则当前任务无法获得锁，直到写模式下的锁释放。
+   - 若有人（非自己）持有写模式下的锁，则当前任务无法获得锁，直到写模式下的锁释放。
 
-申请写模式下的锁：
+   申请写模式下的锁：
 
-- 若该锁当前没有任务持有，或者持有该读模式下的锁的任务和申请该锁的任务为同一个任务，则申请成功，可立即获得写模式下的锁。
+   - 若该锁当前没有任务持有，或者持有该读模式下的锁的任务和申请该锁的任务为同一个任务，则申请成功，可立即获得写模式下的锁。
 
-- 若该锁当前已经存在读模式下的锁，且读取任务优先级较高，则当前任务挂起，直到读模式下的锁释放。
+   - 若该锁当前已经存在读模式下的锁，且读取任务优先级较高，则当前任务挂起，直到读模式下的锁释放。
 
 3.申请读模式下的锁和写模式下的锁均有三种：无阻塞模式、永久阻塞模式、定时阻塞模式，区别在于挂起任务的时间。
 
 4.释放读写锁LOS_RwlockUnLock。
 
-- 如果有任务阻塞于指定读写锁，则唤醒被阻塞任务中优先级高的，该任务进入就绪态，并进行任务调度；
+  - 如果有任务阻塞于指定读写锁，则唤醒被阻塞任务中优先级高的，该任务进入就绪态，并进行任务调度；
 
-- 如果没有任务阻塞于指定读写锁，则读写锁释放成功。
+  - 如果没有任务阻塞于指定读写锁，则读写锁释放成功。
 
 5. 删除读写锁LOS_RwlockDestroy。
 
-> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
-> - 读写锁不能在中断服务程序中使用。
-> 
-> - LiteOS-A内核作为实时操作系统需要保证任务调度的实时性，尽量避免任务的长时间阻塞，因此在获得读写锁之后，应该尽快释放该锁。
-> 
-> - 持有读写锁的过程中，不得再调用LOS_TaskPriSet等接口更改持有读写锁任务的优先级
+   > ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
+   > - 读写锁不能在中断服务程序中使用。
+   > 
+   > - LiteOS-A内核作为实时操作系统需要保证任务调度的实时性，尽量避免任务的长时间阻塞，因此在获得读写锁之后，应该尽快释放该锁。
+   > 
+   > - 持有读写锁的过程中，不得再调用LOS_TaskPriSet等接口更改持有读写锁任务的优先级

zh-cn/device-dev/kernel/kernel-small-bundles-fs-support-fat.md

@@ -18,7 +18,7 @@ OpenHarmony LiteOS-A内核通过Bcache提升FAT文件系统性能，Bcache是blo
 ## 开发指导
 
 
-### 开发流程
+ **开发流程** 
 
 基本使用流程为挂载→操作→卸载。
 

zh-cn/device-dev/kernel/kernel-small-bundles-fs-support-nfs.md

@@ -15,136 +15,135 @@ OpenHarmony LiteOS-A内核的NFS文件系统指的是NFS的客户端，NFS客户
 
 1. 搭建NFS服务器
 
-这里以Ubuntu操作系统为例，说明服务器端设置步骤。
+   这里以Ubuntu操作系统为例，说明服务器端设置步骤。
 
-- 安装NFS服务器软件。
+   - 安装NFS服务器软件。
 
-设置好Ubuntu系统的下载源，保证网络连接好的情况下执行：
+     设置好Ubuntu系统的下载源，保证网络连接好的情况下执行：
 
 
-```
-sudo apt-get install nfs-kernel-server
-```
+     ```
+     sudo apt-get install nfs-kernel-server
+     ```
 
-- 创建用于挂载的目录并设置完全权限
+   - 创建用于挂载的目录并设置完全权限
 
   
-```
-mkdir -p /home/sqbin/nfs
-sudo chmod 777 /home/sqbin/nfs
-```
+     ```
+     mkdir -p /home/sqbin/nfs
+     sudo chmod 777 /home/sqbin/nfs
+     ```
 
-- 设置和启动NFS server。
+   - 设置和启动NFS server。
 
-修改NFS配置文件/etc/exports，添加如下一行：
+     修改NFS配置文件/etc/exports，添加如下一行：
 
 
-```
-/home/sqbin/nfs *(rw,no_root_squash,async)
-```
+     ```
+     /home/sqbin/nfs *(rw,no_root_squash,async)
+     ```
 
-其中/home/sqbin/nfs是NFS共享的根目录。
+     其中/home/sqbin/nfs是NFS共享的根目录。
 
-执行以下命令启动NFS server：
+     执行以下命令启动NFS server：
 
 
-```
-sudo /etc/init.d/nfs-kernel-server start
-```
+     ```
+     sudo /etc/init.d/nfs-kernel-server start
+     ```
 
-执行以下命令重启NFS server：
+     执行以下命令重启NFS server：
 
 
-```
-sudo /etc/init.d/nfs-kernel-server restart
-```
+     ```
+     sudo /etc/init.d/nfs-kernel-server restart
+     ```
 
 2. 设置单板为NFS客户端
 
-本指导中的NFS客户端指运行OpenHarmony内核的设备。
+   本指导中的NFS客户端指运行OpenHarmony内核的设备。
 
-- 硬件连接设置。
+   - 硬件连接设置。
 
-OpenHarmony内核设备连接到NFS服务器的网络。设置两者IP，使其处于同一网段。比如，设置NFS服务器的IP为10.67.212.178/24，设置OpenHarmony内核设备IP为10.67.212.3/24，注意：此IP为内网私有IP地址，用户使用时有差异，以用户实际IP为准。
+     OpenHarmony内核设备连接到NFS服务器的网络。设置两者IP，使其处于同一网段。比如，设置NFS服务器的IP为10.67.212.178/24，设置OpenHarmony内核设备IP为 
+  10.67.212.3/24，注意：此IP为内网私有IP地址，用户使用时有差异，以用户实际IP为准。
 
-OpenHarmony内核设备上的IP信息可通过ifconfig命令查看。
+     OpenHarmony内核设备上的IP信息可通过ifconfig命令查看。
 
-- 启动网络，确保单板到NFS服务器之间的网络通畅。
+   - 启动网络，确保单板到NFS服务器之间的网络通畅。
 
-启动以太网或者其他类型网络，使用ping命令检查到服务器的网络是否通畅。
+     启动以太网或者其他类型网络，使用ping命令检查到服务器的网络是否通畅。
 
 
-```
-OHOS # ping 10.67.212.178
-[0]Reply from 10.67.212.178: time=1ms TTL=63
-[1]Reply from 10.67.212.178: time=0ms TTL=63
-[2]Reply from 10.67.212.178: time=1ms TTL=63
-[3]Reply from 10.67.212.178: time=1ms TTL=63
---- 10.67.212.178 ping statistics ---
-4 packets transmitted, 4 received, 0 loss
-```
+     ```
+     OHOS # ping 10.67.212.178
+     [0]Reply from 10.67.212.178: time=1ms TTL=63
+     [1]Reply from 10.67.212.178: time=0ms TTL=63
+     [2]Reply from 10.67.212.178: time=1ms TTL=63
+     [3]Reply from 10.67.212.178: time=1ms TTL=63
+     --- 10.67.212.178 ping statistics ---
+3. packets transmitted, 4 received, 0 loss
 
-客户端NFS初始化，运行命令：
+   客户端NFS初始化，运行命令：
 
 
-```
-OHOS # mkdir /nfs
-OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000
-```
+   ```
+   OHOS # mkdir /nfs
+   OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000
+   ```
 
-将从串口得到如下回应信息，表明初始化NFS客户端成功。
+   将从串口得到如下回应信息，表明初始化NFS客户端成功。
 
 
-```
-OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000
-Mount nfs on 10.67.212.178:/home/sqbin/nfs, uid:1011, gid:1000
-Mount nfs finished.
-```
+   ```
+   OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000
+   Mount nfs on 10.67.212.178:/home/sqbin/nfs, uid:1011, gid:1000
+   Mount nfs finished.
+   ```
 
-该命令将服务器10.67.212.178上的/home/sqbin/nfs目录挂载到OpenHarmony内核设备上的/nfs上。
+   该命令将服务器10.67.212.178上的/home/sqbin/nfs目录挂载到OpenHarmony内核设备上的/nfs上。
 
-> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
-> 本例默认nfs server已经配置可用，即示例中服务器10.67.212.178上的/home/sqbin/nfs已配置可访问。
-> 
-> mount命令的格式为：
-> 
-> 
-> ```
-> mount <SERVER_IP:SERVER_PATH> <CLIENT_PATH> nfs
-> ```
-> 
-> 其中“SERVER_IP”表示服务器的IP地址；“SERVER_PATH”表示服务器端NFS共享目录路径；“CLIENT_PATH”表示设备上的NFS路径，“nfs”表示客户端要挂载的路径，可以根据自己需要替换。
-> 
-> 如果不想有NFS访问权限限制，可以在Linux命令行将NFS根目录权限设置成777：
-> 
-> 
-> ```
-> chmod -R 777 /home/sqbin/nfs
-> ```
-> 
-> 至此，NFS客户端设置完毕。NFS文件系统已成功挂载。
+   > ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
+   > 本例默认nfs server已经配置可用，即示例中服务器10.67.212.178上的/home/sqbin/nfs已配置可访问。
+   > 
+   > mount命令的格式为：
+   > 
+   > 
+   > ```
+   > mount <SERVER_IP:SERVER_PATH> <CLIENT_PATH> nfs
+   > ```
+   > 
+   > 其中“SERVER_IP”表示服务器的IP地址；“SERVER_PATH”表示服务器端NFS共享目录路径；“CLIENT_PATH”表示设备上的NFS路径，“nfs”表示客户端要挂载的路径，可以根据自己需要替换。
+   > 
+   > 如果不想有NFS访问权限限制，可以在Linux命令行将NFS根目录权限设置成777：
+   > 
+   > 
+   > ```
+   > chmod -R 777 /home/sqbin/nfs
+   > ```
+   > 
+   > 至此，NFS客户端设置完毕。NFS文件系统已成功挂载。
 
-3. 利用NFS共享文件
+4. 利用NFS共享文件
 
-在NFS服务器下新建目录dir，并保存。在OpenHarmony内核下运行ls命令：
+   在NFS服务器下新建目录dir，并保存。在OpenHarmony内核下运行ls命令：
 
+   ```
+   OHOS # ls /nfs
+   ```
 
-```
-OHOS # ls /nfs
-```
+   则可从串口得到如下回应：
 
-则可从串口得到如下回应：
 
+   ```
+   OHOS # ls /nfs 
+   Directory /nfs:                 
+   drwxr-xr-x 0        u:0     g:0     dir
+   ```
 
-```
-OHOS # ls /nfs 
-Directory /nfs:                 
-drwxr-xr-x 0        u:0     g:0     dir
-```
+   可见，刚刚在NFS服务器上新建的dir目录已同步到客户端(OpenHarmony内核系统)的/nfs目录，两者保持同步。
 
-可见，刚刚在NFS服务器上新建的dir目录已同步到客户端(OpenHarmony内核系统)的/nfs目录，两者保持同步。
+   同样地，在客户端(OpenHarmony内核系统)上创建文件和目录，在NFS服务器上也可以访问，读者可自行体验。
 
-同样地，在客户端(OpenHarmony内核系统)上创建文件和目录，在NFS服务器上也可以访问，读者可自行体验。
-
-> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
-> 目前，NFS客户端仅支持NFS v3部分规范要求，因此对于规范支持不全的服务器，无法完全兼容。在开发测试过程中，建议使用Linux的NFS server，其对NFS支持很完善。
+   > ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
+   > 目前，NFS客户端仅支持NFS v3部分规范要求，因此对于规范支持不全的服务器，无法完全兼容。在开发测试过程中，建议使用Linux的NFS server，其对NFS支持很完善。

zh-cn/device-dev/kernel/kernel-small-bundles-fs-support-procfs.md

@@ -16,7 +16,7 @@ OpenHarmony内核中，procfs在开机时会自动挂载到/proc目录下，仅
 procfs文件的创建无法使用一般的文件系统接口，需要使用ProcMkdir接口创建目录，使用CreateProcEntry接口创建文件。文件节点功能的开发就是实现read和write函数的钩子挂到CreateProcEntry创建的文件中。当用户使用读写procfs的文件时，就会调用到钩子函数来实现自定义的功能。
 
 
-### 编程实例
+编程实例
 
 下面我们以创建/proc/hello/world文件为例，实现如下功能：
 

zh-cn/device-dev/kernel/kernel-small-bundles-fs-support-ramfs.md

@@ -4,66 +4,39 @@
 ## 基本概念
 
 RAMFS是一个可动态调整大小的基于RAM的文件系统。RAMFS没有后备存储源。向RAMFS中进行的文件写操作也会分配目录项和页缓存，但是数据并不写回到任何其他存储介质上，掉电后数据丢失。
-
-
 ## 运行机制
-
 RAMFS文件系统把所有的文件都放在 RAM 中，所以读/写操作发生在RAM中，可以用RAMFS来存储一些临时性或经常要修改的数据，例如/tmp和/var目录，这样既避免了对存储器的读写损耗，也提高了数据读写速度。
-
-
 ## 开发指导
-
-挂载：
-
-  
+挂载：  
 ```
 mount(NULL, "/dev/shm", "ramfs", 0, NULL)
 ```
-
-创建目录：
-
-  
+创建目录：  
 ```
 mkdir(pathname, mode)
 ```
-
-创建文件：
-
-  
+创建文件： 
 ```
 open(pathname, O_NONBLOCK | O_CREAT | O_RDWR, mode)
 ```
-
-读取目录：
-
-  
+读取目录：  
 ```
 dir = opendir(pathname) 
 ptr = readdir(dir)
 closedir(dir)
 ```
-
-删除文件：
-
-  
+删除文件：  
 ```
 unlink(pathname)
 ```
-
-删除目录：
-
-  
+删除目录： 
 ```
 rmdir(pathname)
 ```
-
-去挂载：
-
-  
+去挂载：  
 ```
 umount("/dev/shm")
 ```
-
 > ![icon-caution.gif](public_sys-resources/icon-caution.gif) **注意：**
 > - RAMFS只能挂载一次，一次挂载成功后，后面不能继续挂载到其他目录。
 > 

zh-cn/device-dev/kernel/kernel-small-debug-shell-guide.md

 # Shell命令开发指导
 
-
-## 开发指导
-
 新增Shell命令的典型开发流程如下：
 
 1. 包含如下头文件：

zh-cn/device-dev/kernel/kernel-small-debug-shell-magickey.md

@@ -12,23 +12,23 @@
 
 1. 配置宏LOSCFG_ENABLE_MAGICKEY。
 
-魔法键依赖于宏LOSCFG_ENABLE_MAGICKEY，使用时通过menuconfig在配置项中开启“Enable  MAGIC KEY”：
+   魔法键依赖于宏LOSCFG_ENABLE_MAGICKEY，使用时通过menuconfig在配置项中开启“Enable  MAGIC KEY”：
 
-  Debug ---> Enable MAGIC KEY；若关闭该选项，则魔法键失效。
-> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
-> 1. 可以在menuconfig中，将光标移动到LOSCFG_ENABLE_MAGICKEY上，输入“？”，查看帮助信息。
+   Debug ---> Enable MAGIC KEY；若关闭该选项，则魔法键失效。
+   > ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
+   > 可以在menuconfig中，将光标移动到LOSCFG_ENABLE_MAGICKEY上，输入“？”，查看帮助信息。
 
 2. 输入“ctrl + r”键，打开魔法键检测功能。
 
-在连接UART或者USB转虚拟串口的情况下，输入“ctrl + r” 键，打开魔法键检测功能，输出 “Magic key on”；再输入一次后，则关闭魔法键检测功能，输出“Magic key off”。魔法键功能如下：
+   在连接UART或者USB转虚拟串口的情况下，输入“ctrl + r” 键，打开魔法键检测功能，输出 “Magic key on”；再输入一次后，则关闭魔法键检测功能，输出“Magic key off”。魔法键功能如下：
 
-- ctrl + z：帮助键，输出相关魔法键简单介绍；
+   - ctrl + z：帮助键，输出相关魔法键简单介绍；
 
-- ctrl + t：输出任务相关信息；
+   - ctrl + t：输出任务相关信息；
 
-- ctrl + p：系统主动进入panic，输出panic相关信息后，系统会挂住；
+   - ctrl + p：系统主动进入panic，输出panic相关信息后，系统会挂住；
 
-- ctrl + e：系统进行简单完整性内存池检查，检查出错会输出相关错误信息，检查正常会输出“system memcheck  over, all passed!”。
+   - ctrl + e：系统进行简单完整性内存池检查，检查出错会输出相关错误信息，检查正常会输出“system memcheck  over, all passed!”。
 
-> ![icon-notice.gif](public_sys-resources/icon-notice.gif) **须知：**
-> 魔法键检测功能打开情况下，如果需要通过UART或者USB转虚拟串口输入特殊字符需避免与魔法键值重复，否则魔法键会被误触发，而原有设计功能可能出现错误。
+   > ![icon-notice.gif](public_sys-resources/icon-notice.gif) **须知：**
+   > 魔法键检测功能打开情况下，如果需要通过UART或者USB转虚拟串口输入特殊字符需避免与魔法键值重复，否则魔法键会被误触发，而原有设计功能可能出现错误。

zh-cn/device-dev/kernel/kernel-small-debug-shell-overview.md

@@ -13,7 +13,7 @@ OpenHarmony内核提供的Shell支持调试常用的基本功能，包含系统
   新增命令的详细流程可参见[Shell命令开发指导](../kernel/kernel-small-debug-shell-guide.md)和[Shell命令编程实例](../kernel/kernel-small-debug-shell-build.md)。
 
 
-## 注意事项
+ **注意事项** 
 
 在使用Shell功能的过程中，需要注意以下几点：
 

zh-cn/device-dev/kernel/kernel-small-debug-trace.md

@@ -186,7 +186,7 @@ LiteOS-A内核的Trace模块提供下面几种功能，接口详细信息可以
 - LOS_TraceRecordDump —— trace_dump
 
 
-## 内核态编程实例
+### 内核态编程实例
 
 本实例实现如下功能：
 
@@ -201,7 +201,7 @@ LiteOS-A内核的Trace模块提供下面几种功能，接口详细信息可以
 5. 格式化输出trace数据。
 
 
-## 内核态示例代码
+### 内核态示例代码
 
 实例代码如下：
 
@@ -253,7 +253,7 @@ LOS_MODULE_INIT(Example_Trace_test, LOS_INIT_LEVEL_KMOD_EXTENDED);
 ```
 
 
-## 结果验证
+### 结果验证
 
 输出结果如下：
 

zh-cn/device-dev/kernel/kernel-small-memory-lms.md

@@ -97,7 +97,7 @@ OpenHarmony LiteOS-A内核的LMS模块提供下面几种功能，接口详细信
 3. 重新编译，查看串口输出。如果检测到内存问题，会输出检测结果。
 
 
-## 内核态编程实例
+#### 内核态编程实例
 
 本实例实现如下功能：
 
@@ -108,7 +108,7 @@ OpenHarmony LiteOS-A内核的LMS模块提供下面几种功能，接口详细信
 3. 添加-fsanitize=kernel-address后编译执行，观察输出结果
 
 
-## 内核态示例代码
+#### 内核态示例代码
 
   实例代码如下：
   
@@ -169,7 +169,7 @@ LOS_MODULE_INIT(Example_Lms_test, LOS_INIT_LEVEL_KMOD_EXTENDED);
 ```
 
 
-### 内核态结果验证
+#### 内核态结果验证
 
   输出结果如下：
   
@@ -302,7 +302,7 @@ if ("$ohos_build_compiler_specified" == "gcc") {
 ```
 
 
-### 用户态编程实例
+#### 用户态编程实例
 
 本实例实现如下功能：
 
@@ -311,7 +311,7 @@ if ("$ohos_build_compiler_specified" == "gcc") {
 2. 添加对应编译选项后，重新编译执行
 
 
-### 用户态示例代码
+#### 用户态示例代码
 
   实例代码如下：
   
@@ -357,7 +357,7 @@ int main(int argc, char * const * argv)
 ```
 
 
-### 用户态结果验证
+#### 用户态结果验证
 
   输出结果如下：
   

zh-cn/device-dev/kernel/kernel-small-start-kernel.md

@@ -29,7 +29,7 @@
 ## 编程样例
 
 
-### 实例描述
+ **实例描述** 
 
 新增一个内核模块，需要在内核初始化时进行该模块的初始化，则通过内核启动框架将该模块的初始化函数注册进内核启动流程中。
 

zh-cn/device-dev/kernel/kernel-standard-build.md

 # Linux内核编译与构建指导
 
-- [Linux内核编译与构建指导](#linux内核编译与构建指导)
-  - [开发示例1](#开发示例1)
 
-## 开发示例1
+ **开发示例** 
 
 以hi3516dv300开源开发板+ubuntu x86主机开发环境为例。
 

zh-cn/device-dev/kernel/kernel-standard-sched-rtg.md

@@ -53,9 +53,9 @@ STATE           COMM       PID  PRIO    CPU  // 线程信息（状态/名称/pid
 
 关联线程组提供了设备节点和ioctl接口用于查询和配置分组信息，其中设备节点路径为`/dev/sched_rtg_ctrl`。
 
-| 设备节点                | request             | 描述                  |
-| ------------------- | ------------------- | ------------------- |
-| /dev/sched_rtg_ctrl | CMD_ID_SET_RTG      | 创建分组，添加/更新/删除分组中线程  |
-|                     | CMD_ID_SET_CONFIG   | 配置全局分组属性，例如最大实时分组个数 |
-|                     | CMD_ID_SET_RTG_ATTR | 配置指定分组属性，例如分组线程优先级  |
-|                     | CMD_ID_SET_MIN_UTIL | 设置分组最小utilization值  |
+ | request             | 描述                  |
+| ------------------- | ------------------- |
+| CMD_ID_SET_RTG      | 创建分组，添加/更新/删除分组中线程  |
+| CMD_ID_SET_CONFIG   | 配置全局分组属性，例如最大实时分组个数 |
+ | CMD_ID_SET_RTG_ATTR | 配置指定分组属性，例如分组线程优先级  |
+  | CMD_ID_SET_MIN_UTIL | 设置分组最小utilization值  |

zh-cn/device-dev/porting/porting-chip-board-driver.md

@@ -43,6 +43,6 @@
    OS接口适配后，板级驱动集成到OpenHarmony也存在2种选择：
 
    - SDK独立编译，通过二进制形式直接链入OpenHarmony；
-   - SDK基于OpenHarmony改造编译框架，从长期演进及后期联调便利性角度角度考虑，建议基于GN编译框架直接改造SDK编译框架，通过源码形式链入OpenHarmony工程。
+   - SDK基于OpenHarmony改造编译框架，从长期演进及后期联调便利性角度考虑，建议基于GN编译框架直接改造SDK编译框架，通过源码形式链入OpenHarmony工程。
 
 3. 验证SDK基本功能。

zh-cn/device-dev/porting/porting-chip-faqs.md

@@ -3,17 +3,16 @@
 
 ## 如何将用户的堆内存挂载进内核
 
-- 内核堆内存配置的相关宏如下，用户可根据实际情况，在target_config.h中配置：
+内核堆内存配置的相关宏如下，用户可根据实际情况，在target_config.h中配置：
 
   **表1** 内核堆内存配置相关宏
 
-| 宏名称 | 描述 | 
-| -------- | -------- |
-| LOSCFG_SYS_EXTERNAL_HEAP | 这个宏决定系统是使用内核的内部堆内存还是用户的堆内存，默认为0（即使用内部的堆内存），大小为0x10000；如果用户需要基于外部的堆内存，那么可以将该宏设置为1。 | 
-| LOSCFG_SYS_HEAP_ADDR | 内核堆内存的起始地址。 | 
-| LOSCFG_SYS_HEAP_SIZE | 内核堆内存的大小，即LOSCFG_SYS_HEAP_ADDR指定的内存块大小。 | 
+  | 宏名称 | 描述 | 
+  | -------- | -------- |
+  | LOSCFG_SYS_EXTERNAL_HEAP | 这个宏决定系统是使用内核的内部堆内存还是用户的堆内存，默认为0（即使用内部的堆内存），大小为0x10000；如果用户需要基于外部的堆内存，那么可以将该宏设置为1。 | 
+  | LOSCFG_SYS_HEAP_ADDR | 内核堆内存的起始地址。 | 
+  | LOSCFG_SYS_HEAP_SIZE | 内核堆内存的大小，即LOSCFG_SYS_HEAP_ADDR指定的内存块大小。 | 
 
-- 注意事项：
-
-指定的堆内存范围务必保证没有其他模块使用，避免踩内存，破坏堆内存功能。
 
+> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
+> 指定的堆内存范围务必保证没有其他模块使用，避免踩内存，破坏堆内存功能。

zh-cn/device-dev/porting/porting-linux-kernel.md

@@ -242,6 +242,7 @@ HDF（Hardware Driver Foundation)自测试用例，用于测试HDF框架和外
    等待编译完成。
 
 2. 将测试文件移动到目标移植设备上（以树莓派为例）。
+  
    方法一：使用[hdc_std工具](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-toolchain-hdc-guide.md)。
 
    1. 先在树莓派里新建data/test目录。

zh-cn/device-dev/porting/porting-smallchip-kernel-a.md

@@ -103,7 +103,7 @@ LiteOS-A提供系统运行所需的系统初始化流程和定制化配置选项
   > 可通过查看系统编译生成文件OHOS_Image.map中.rodata.init.kernel.\*段内的符号表来了解当前已注册进内核启动框架中的各个模块初始化入口，以及检查新注册的模块初始化入口是否生效。
 
 
-### 编程样例
+## 编程样例
 
   在单板SDK文件中
   

zh-cn/device-dev/porting/porting-thirdparty-cmake.md

@@ -123,52 +123,52 @@ CMake方式可通过指定工具链进行交叉编译，修改并编译该库，
    - 挂载成功后执行下列命令可列出用例所有条目：
 
      
-   ```
-   cd nfs
-   ./cctest --list
-   ```
-
-   上述命令执行结果部分展示：
+     ```
+     cd nfs
+     ./cctest --list
+     ```
 
+     上述命令执行结果部分展示：
+ 
      
-   ```
-   test-bignum/Assign<
-   test-bignum/ShiftLeft<
-   test-bignum/AddUInt64<
-   test-bignum/AddBignum<
-   test-bignum/SubtractBignum<
-   test-bignum/MultiplyUInt32<
-   test-bignum/MultiplyUInt64<
-   test-bignum/MultiplyPowerOfTen<
-   test-bignum/DivideModuloIntBignum<
-   test-bignum/Compare<
-   test-bignum/PlusCompare<
-   test-bignum/Square<
-   test-bignum/AssignPowerUInt16<
-   test-bignum-dtoa/BignumDtoaVariousDoubles<
-   test-bignum-dtoa/BignumDtoaShortestVariousFloats<
-   test-bignum-dtoa/BignumDtoaGayShortest<
-   test-bignum-dtoa/BignumDtoaGayShortestSingle<
-   test-bignum-dtoa/BignumDtoaGayFixed<
-   test-bignum-dtoa/BignumDtoaGayPrecision<
-   test-conversions/DoubleToShortest<
-   test-conversions/DoubleToShortestSingle<
-   ...
-   ```
+     ```
+     test-bignum/Assign<
+     test-bignum/ShiftLeft<
+     test-bignum/AddUInt64<
+     test-bignum/AddBignum<
+     test-bignum/SubtractBignum<
+     test-bignum/MultiplyUInt32<
+     test-bignum/MultiplyUInt64<
+     test-bignum/MultiplyPowerOfTen<
+     test-bignum/DivideModuloIntBignum<
+     test-bignum/Compare<
+     test-bignum/PlusCompare<
+     test-bignum/Square<
+     test-bignum/AssignPowerUInt16<
+     test-bignum-dtoa/BignumDtoaVariousDoubles<
+     test-bignum-dtoa/BignumDtoaShortestVariousFloats<
+     test-bignum-dtoa/BignumDtoaGayShortest<
+     test-bignum-dtoa/BignumDtoaGayShortestSingle<
+     test-bignum-dtoa/BignumDtoaGayFixed<
+     test-bignum-dtoa/BignumDtoaGayPrecision<
+     test-conversions/DoubleToShortest<
+     test-conversions/DoubleToShortestSingle<
+     ...
+     ```
 
    - 以test-bignum条目为例，执行下列命令开始测试：
 
      
-   ```
-   ./cctest test-bignum
-   ```
+     ```
+     ./cctest test-bignum
+     ```
 
-   测试结果如下则表示通过：
+     测试结果如下则表示通过：
 
      
-   ```
-   Ran 13 tests.
-   ```
+     ```
+     Ran 13 tests.
+     ```
 
 
 ## 将该库编译添加到OpenHarmony工程中
@@ -189,103 +189,103 @@ CMake方式可通过指定工具链进行交叉编译，修改并编译该库，
    - **新增的BUILD.gn文件实现如下，其他采用CMake方式可独立编译的三方库移植到OpenHarmony平台时只需修改路径即可**。
 
      
-   ```
-   import("config.gni")
-   group("double-conversion") {
-       if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
-           deps = [":make"]
-       }
-   }
-   if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
-       action("make") {
-           script = "//third_party/double-conversion/build_thirdparty.py"
-           outputs = ["$root_out_dir/log_dc.txt"]
-           exec_path = rebase_path(rebase_path("./build", ohos_third_party_dir))
-           command = "rm * .* -rf && $CMAKE_TOOLS_PATH/cmake .. $CMAKE_FLAG $CMAKE_TOOLCHAIN_FLAG && make -j"
-           args = [
-               "--path=$exec_path",
-               "--command=${command}"
-           ]
-       }
-   }
-   ```
+     ```
+     import("config.gni")
+     group("double-conversion") {
+         if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
+             deps = [":make"]
+         }
+     }
+     if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
+         action("make") {
+             script = "//third_party/double-conversion/build_thirdparty.py"
+             outputs = ["$root_out_dir/log_dc.txt"]
+             exec_path = rebase_path(rebase_path("./build", ohos_third_party_dir))
+             command = "rm * .* -rf && $CMAKE_TOOLS_PATH/cmake .. $CMAKE_FLAG $CMAKE_TOOLCHAIN_FLAG && make -j"
+             args = [
+                 "--path=$exec_path",
+                 "--command=${command}"
+             ]
+         }
+     }
+     ```
 
    - **新增的config.gni用于配置该库，实现如下，其他采用CMake方式可独立编译的三方库移植到OpenHarmony时只需修改CMAKE_FLAG的配置即可。**
 
      
-   ```
-   #CMAKE_FLAG: config compile feature
-   CMAKE_FLAG = "-DBUILD_TESTING=ON -DCMAKE_CXX_STANDARD=11"
+     ```
+     #CMAKE_FLAG: config compile feature
+     CMAKE_FLAG = "-DBUILD_TESTING=ON -DCMAKE_CXX_STANDARD=11"
    
-   #toolchain：follow up-layer，depend on $ohos_build_compiler
-   if (ohos_build_compiler == "clang") {
-       CMAKE_TOOLCHAIN_FLAG = "-DOHOS_SYSROOT_PATH=${ohos_root_path}prebuilts/lite/sysroot/"
-   } else {
-       CMAKE_TOOLCHAIN_FLAG = ""
-   }
+     #toolchain：follow up-layer，depend on $ohos_build_compiler
+     if (ohos_build_compiler == "clang") {
+         CMAKE_TOOLCHAIN_FLAG = "-DOHOS_SYSROOT_PATH=${ohos_root_path}prebuilts/lite/sysroot/"
+     } else {
+         CMAKE_TOOLCHAIN_FLAG = ""
+     }
    
-   #CMake tools path,no need setting if this path already joined to $PATH.
-   CMAKE_TOOLS_PATH = "setting CMake tools path..."
-   ```
+     #CMake tools path,no need setting if this path already joined to $PATH.
+     CMAKE_TOOLS_PATH = "setting CMake tools path..."
+     ```
 
    - **新增的build_thirdparty.py实现如下，其他采用CMake方式可独立编译的三方库移植到OpenHarmony时无需修改即可使用。**
 
      
-   ```
-   import os
-   import sys
-   from subprocess import Popen
-   import argparse
-   import shlex
+     ```
+     import os
+     import sys
+     from subprocess import Popen
+     import argparse
+     import shlex
    
-   def cmd_exec(command):
-       cmd = shlex.split(command)
-       proc = Popen(cmd)
-       proc.wait()
-       ret_code = proc.returncode
-       if ret_code != 0:
-           raise Exception("{} failed, return code is {}".format(cmd, ret_code))
+     def cmd_exec(command):
+         cmd = shlex.split(command)
+         proc = Popen(cmd)
+         proc.wait()
+         ret_code = proc.returncode
+         if ret_code != 0:
+             raise Exception("{} failed, return code is {}".format(cmd, ret_code))
    
-   def main():
-       parser = argparse.ArgumentParser()
-       parser.add_argument('--path', help='Build path.')
-       parser.add_argument('--command', help='Build command.')
-       parser.add_argument('--enable', help='enable python.', nargs='*')
-       args = parser.parse_args()
+     def main():
+         parser = argparse.ArgumentParser()
+         parser.add_argument('--path', help='Build path.')
+         parser.add_argument('--command', help='Build command.')
+         parser.add_argument('--enable', help='enable python.', nargs='*')
+         args = parser.parse_args()
    
-       if args.enable:
-           if args.enable[0] == 'false':
+         if args.enable:
+             if args.enable[0] == 'false':
                return
    
-       if args.path:
-           curr_dir = os.getcwd()
-           os.chdir(args.path)
-           if args.command:
-               if '&&' in args.command:
-                   command = args.command.split('&&')
-                   for data in command:
+         if args.path:
+             curr_dir = os.getcwd()
+             os.chdir(args.path)
+             if args.command:
+                 if '&&' in args.command:
+                     command = args.command.split('&&')
+                     for data in command:
                        cmd_exec(data)
                else:
                    cmd_exec(args.command)
            os.chdir(curr_dir)
    
-   if __name__ == '__main__':
-       sys.exit(main())
-   ```
+      if __name__ == '__main__':
+         sys.exit(main())
+     ```
 
    - 在配置文件中添加开关控制该库编译，默认设为关闭
 
-   在//build/lite/ohos_var.gni文件中添加下列配置：
+     在//build/lite/ohos_var.gni文件中添加下列配置：
 
      
-   ```
-   declare_args() {
-       ohos_build_thirdparty_migrated_from_fuchisa = true
-   }
-   ```
+     ```
+     declare_args() {
+         ohos_build_thirdparty_migrated_from_fuchisa = true
+      }
+     ```
 
 3. 编译构建
-   - 手动单独构建：
+   手动单独构建：
 
    执行下列命令
 

zh-cn/device-dev/porting/standard-system-porting-guide.md

@@ -87,7 +87,7 @@ product_company：不体现在配置中，而是目录名，vendor下一级目
 这一步需要移植Linux内核，让Linux内核可以成功运行起来。
 
 
-### 1.为SOC添加内核构建的子系统
+### 为SOC添加内核构建的子系统
 
 修改文件 //build/subsystem_config.json增加一个子系统. 配置如下：
 
@@ -104,7 +104,7 @@ product_company：不体现在配置中，而是目录名，vendor下一级目
 接着需要修改定义产品的配置文件//vendor/MyProductVendor/MyProduct/config.json，将刚刚定义的子系统加入到产品中。
 
 
-### 2. 编译内核
+### 编译内核
 
 源码中提供了Linux 4.19的内核，归档在//kernel/linux-4.19。本节以该内核版本为例，讲解如何编译内核。
 
@@ -133,7 +133,7 @@ BUILD.gn是subsystem构建的唯一入口。
 | $root_build_dir/packages/phone/images/uboot | bootloader镜像 | 
 
 
-### 3. 移植验证
+### 移植验证
 
 启动编译，验证预期的kernel镜像是否成功生成。
 
@@ -167,7 +167,7 @@ BUILD.gn是subsystem构建的唯一入口。
 ## HDF驱动移植
 
 
-### 1. LCD
+### LCD
 
 HDF为LCD设计了驱动模型。支持一块新的LCD，需要编写一个驱动，在驱动中生成模型的实例，并完成注册。
 
@@ -222,7 +222,7 @@ root {
 更详细的驱动开发指导，请参考 [LCD](../driver/driver-peripherals-lcd-des.md)。
 
 
-### 2. 触摸屏
+### 触摸屏
 
 本节描述如何移植触摸屏驱动。触摸屏的驱动被放置在//drivers/framework/model/input/driver/touchscreen目录中。移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。
 
@@ -283,7 +283,7 @@ HDF_INIT(g_touchXXXXChipEntry);
 更详细的驱动开发指导，请参考 [TOUCHSCREEN](../driver/driver-peripherals-touch-des.md)。
 
 
-### 3. WLAN
+### WLAN
 
 Wi-Fi驱动分为两部分，一部分负责管理WLAN设备，另一个部分负责处理WLAN流量。HDF WLAN分别为这两部分做了抽象。目前支持SDIO接口的WLAN芯片。
 
@@ -424,6 +424,6 @@ obj-$(CONFIG_DRIVERS_WLAN_XXX) += $(HDF_DEVICE_ROOT)/MySoCVendor/peripheral/buil
 当在内核中开启DRIVERS_WLAN_XXX开关时，会调用//device/MySoCVendor/peripheral/build/standard/中的makefile。更多详细的开发手册，请参考[WLAN开发](../guide/device-wlan-led-control.md)。
 
 
-### 4. 开发移植示例
+### 开发移植示例
 
 开发移植示例请参考[DAYU开发板](https://gitee.com/openharmony-sig/devboard_device_hihope_build/blob/master/DAYU%20%E5%B9%B3%E5%8F%B0OpenHarmony%20%E9%80%82%E9%85%8D%E6%8C%87%E5%AF%BC%20-202108.pdf)。

zh-cn/device-dev/subsystems/subsys-aiframework-demo-plugin.md

 # 唤醒词识别插件的开发示例
 
 
-1. 在代码路径//foundation/ai/engine/services/server/plugin中添加唤醒词识别插件的接口定义（IPlugin），并实现AI能力的调用。如下代码片段即实现唤醒词识别的算法插件的接口定义。更多插件开发的相关代码参考路径如下：//foundation/ai/engine/services/server/plugin/asr/keyword_spotting
+在代码路径//foundation/ai/engine/services/server/plugin中添加唤醒词识别插件的接口定义（IPlugin），并实现AI能力的调用。如下代码片段即实现唤醒词识别的算法插件的接口定义。更多插件开发的相关代码参考路径如下：//foundation/ai/engine/services/server/plugin/asr/keyword_spotting
      
    ```
    #include "plugin/i_plugin.h

zh-cn/device-dev/subsystems/subsys-aiframework-devguide-plugin.md

@@ -4,7 +4,7 @@
 AI引擎框架规定了一套算法插件接入规范，各插件需实现规定接口以实现获取插件版本信息、算法推理类型、同步执行算法、异步执行算法、加载算法插件、卸载算法插件、设置算法配置信息、获取指定算法配置信息等功能。（同步算法实现SyncProcess接口，异步算法实现AsyncProcess接口）。
 
 
-1）算法插件类IPlugin接口设计如下表所示。
+算法插件类IPlugin接口设计如下表所示。
 
 
   **表1** 算法插件类IPlugin接口设计
@@ -24,7 +24,7 @@ AI引擎框架规定了一套算法插件接入规范，各插件需实现规定
 算法插件类接口：Prepare、SyncProcess、AsyncProcess、Release、SetOption、GetOption分别于客户端接口AieClientPrepare、AieClientSyncProcess、AieClientAsyncProcess、AieClientRelease、AieClientSetOption、AieClientGetOption一一对应；GetInferMode接口用于返回算法执行类型——同步或异步。
 
 
-2）算法插件回调类IPluginCallback 接口设计如下表所示。
+算法插件回调类IPluginCallback 接口设计如下表所示。
 
 
   **表2** 算法插件回调类IPluginCallback 接口设计
@@ -52,7 +52,7 @@ Request类的属性如下表所示。
 | msg_ | 类型：DataInfo<br/>作用：存放调用算法接口的输入数据。 | .data&nbsp;=&nbsp;nullptr<br/>.length&nbsp;=&nbsp;0 | 
 
 
-Response类的属性如下下表所示。
+Response类的属性如下表所示。
 
 
   **表4** Response类的属性

zh-cn/device-dev/subsystems/subsys-aiframework-devguide-sdk.md

@@ -18,7 +18,7 @@ SDK头文件的功能实现是基于对SDK的调用映射到对客户端的调
 | int&nbsp;**AieClientGetOption**(const&nbsp;ClientInfo&nbsp;&amp;clientInfo,<br/>&nbsp;int&nbsp;optionType,&nbsp;const&nbsp;DataInfo&nbsp;&amp;inputInfo,<br/>&nbsp;DataInfo&nbsp;&amp;outputInfo) | **作用**：给定特定的optionType和inputInfo，获取其对应的配置项信息。<br/>**返回值**：0为成功，其他返回值失败。 | **clientInfo**(NOT&nbsp;NULL)：引擎客户端信息；<br/>**optionType**(NOT&nbsp;NULL)：所获取配置项信息的对应算法状态位；<br/>**inputInfo**(可为NULL)：所获取配置项信息的对应算法参数信息；<br/>**outputInfo**(可为NULL)：所要获取的配置项信息返回结果； |
 
 
-其中，ConfigInfo，ClientInfo，AlgorithmInfo，DataInfo的数据结构如下下表所示。
+其中，ConfigInfo，ClientInfo，AlgorithmInfo，DataInfo的数据结构如下表所示。
 
 
   **表2** ConfigInfo，ClientInfo，AlgorithmInfo，DataInfo的数据结构

zh-cn/device-dev/subsystems/subsys-boot-overview.md

@@ -161,20 +161,20 @@
 
       - 准备工作
 
-      1. init从cmdline中读取required fstab，若获取失败，则尝试读fstab.required文件，从中获取必须挂载的块设备的PARTNAME，例如system和vendor.
-      2. 创建接收内核上报uevent事件广播消息的socket，从/proc/cmdline里读取default_boot_device。
-      3. 带着fstab信息和socket句柄遍历/sys/devices目录，准备开始触发内核上报uevent事件。
+        1. init从cmdline中读取required fstab，若获取失败，则尝试读fstab.required文件，从中获取必须挂载的块设备的PARTNAME，例如system和vendor.
+        2. 创建接收内核上报uevent事件广播消息的socket，从/proc/cmdline里读取default_boot_device。
+        3. 带着fstab信息和socket句柄遍历/sys/devices目录，准备开始触发内核上报uevent事件。
 
       - 触发事件
 
-      1. 通过ueventd触发内核上报uevent事件
-      2. 匹配uevent事件中的partitionName与required fstab中的device信息。
-      3. 匹配成功后将会进一步处理，格式化设备节点路径，准备开始创建设备节点。
+        1. 通过ueventd触发内核上报uevent事件
+        2. 匹配uevent事件中的partitionName与required fstab中的device信息。
+        3. 匹配成功后将会进一步处理，格式化设备节点路径，准备开始创建设备节点。
 
       - 创建节点
 
-      1. 为了便于用户态下对设备节点的访问以及提高设备节点的可读性，会对即将创建的required块设备节点同时创建软链接，这就需要先格式化软链接的路径。
-      2. 以上工作都完成后，将执行最后的创建设备节点的步骤，根据传入的uevent中的主次设备号、前置步骤中构建的设备节点路径和软链接路径等创建设备节点，并创建相应软链接。
+        1. 为了便于用户态下对设备节点的访问以及提高设备节点的可读性，会对即将创建的required块设备节点同时创建软链接，这就需要先格式化软链接的路径。
+        2. 以上工作都完成后，将执行最后的创建设备节点的步骤，根据传入的uevent中的主次设备号、前置步骤中构建的设备节点路径和软链接路径等创建设备节点，并创建相应软链接。
 
       至此，块设备节点创建完毕。
 

zh-cn/device-dev/subsystems/subsys-build-gn-kconfig-visual-config-guide.md

@@ -103,12 +103,12 @@
 
 解决办法：
 
-- 更新[Kconfig文件](https://gitee.com/openharmony/build/blob/master/tools/component_tools/kconfig)
+更新[Kconfig文件](https://gitee.com/openharmony/build/blob/master/tools/component_tools/kconfig)
 
-  ```shell
-  cd build/tools/component_tools
-  python3 generate_kconfig.py
-  ```
+```shell
+cd build/tools/component_tools
+python3 generate_kconfig.py
+```
 
-  更多选项通过`python3 generate_kconfig.py -h`查看。
+更多选项通过`python3 generate_kconfig.py -h`查看。
 

zh-cn/device-dev/subsystems/subsys-build-mini-lite.md

@@ -198,35 +198,35 @@ component
   
 - 芯片解决方案目录树规则如下：
 
-```
-device                                      
-└── board                         # 芯片解决方案厂商
-    └── company                       # 开发板名称
-        ├── BUILD.gn                # 编译脚本
-        ├── hals                    # OS南向接口适配
-        ├── linux                   # 可选，linux内核版本
-        │   └── config.gni          # linux版本编译配置
-        └── liteos_a                # 可选，liteos内核版本
-            └── config.gni          # liteos_a版本编译配置
-```
+  ```
+  device                                      
+  └── board                         # 芯片解决方案厂商
+      └── company                       # 开发板名称
+          ├── BUILD.gn                # 编译脚本
+          ├── hals                    # OS南向接口适配
+          ├── linux                   # 可选，linux内核版本
+          │   └── config.gni          # linux版本编译配置
+          └── liteos_a                # 可选，liteos内核版本
+               └── config.gni          # liteos_a版本编译配置
+  ```
 
-> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
-> config.gni为开发板编译相关的配置，编译时会采用该配置文件中的参数编译所有OS部件，编译阶段系统全局可见。
+  > ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
+  > config.gni为开发板编译相关的配置，编译时会采用该配置文件中的参数编译所有OS部件，编译阶段系统全局可见。
 
 - config.gni的关键字段介绍如下：
 
-```
-kernel_type:            开发板使用的内核类型，例如：“liteos_a”, “liteos_m”, “linux”。
-kernel_version:         开发使用的内核版本，例如：“4.19”。
-board_cpu:              开发板CPU类型，例如：“cortex-a7”, “riscv32”。
-board_arch:             开发芯片arch, 例如： “armv7-a”, “rv32imac”。
-board_toolchain:        开发板自定义的编译工具链名称，例如：“gcc-arm-none-eabi”。若为空，则使用默认为ohos-clang。
-board_toolchain_prefix：编译工具链前缀，例如：“gcc-arm-none-eabi”。
-board_toolchain_type：  编译工具链类型，目前支持gcc和clang。例如：“gcc” ，“clang”。
-board_cflags：          开发板配置的c文件编译选项。
-board_cxx_flags：       开发板配置的cpp文件编译选项。
-board_ld_flags：        开发板配置的链接选项。
-```
+  ```
+  kernel_type:            开发板使用的内核类型，例如：“liteos_a”, “liteos_m”, “linux”。
+  kernel_version:         开发使用的内核版本，例如：“4.19”。
+  board_cpu:              开发板CPU类型，例如：“cortex-a7”, “riscv32”。
+  board_arch:             开发芯片arch, 例如： “armv7-a”, “rv32imac”。
+  board_toolchain:        开发板自定义的编译工具链名称，例如：“gcc-arm-none-eabi”。若为空，则使用默认为ohos-clang。
+  board_toolchain_prefix：编译工具链前缀，例如：“gcc-arm-none-eabi”。
+  board_toolchain_type：  编译工具链类型，目前支持gcc和clang。例如：“gcc” ，“clang”。
+  board_cflags：          开发板配置的c文件编译选项。
+  board_cxx_flags：       开发板配置的cpp文件编译选项。
+  board_ld_flags：        开发板配置的链接选项。
+  ```
 
 ### 产品解决方案
 

zh-cn/device-dev/subsystems/subsys-build-standard-large.md

@@ -80,15 +80,15 @@ OpenHarmony侧的编译构建流程主要包括编译命令行解析，调用gn
 
 /build                           # 编译构建主目录
 
-├── __pycache__                   # ----------------------
+├── __pycache__                   
 ├── build_scripts/                # 编译相关的python脚本
-├── common/                       # ----------------------
+├── common/                      
 ├── config/                       # 编译相关的配置项
 ├── core
 │   ├── gn/                       # 编译入口BUILD.gn配置
-    └── build_scripts/            # ----------------------
-├── docs                          # ----------------------
-gn_helpers.py*                    # ----------------------
+    └── build_scripts/           
+├── docs                          
+gn_helpers.py*                    
 lite/                             # hb和preloader入口                      
 misc/
 ├── ohos                          # OpenHarmony编译打包流程配置
@@ -100,19 +100,19 @@ misc/
 │   ├── sdk                       # sdk模板和处理流程，包括sdk中包含的模块配置
 │   └── testfwk                   # 测试相关的处理
 ├── ohos.gni*                     # 汇总了常用的gni文件，方便各个模块一次性import
-├── ohos_system.prop              # ----------------------
-├── ohos_var.gni*                 # ----------------------
-├── prebuilts_download.sh*        # ----------------------
-├── print_python_deps.py*         # ----------------------
-├── scripts/                      # ----------------------
-├── subsystem_config.json         # ----------------------
-├── subsystem_config_example.json # ----------------------
+├── ohos_system.prop             
+├── ohos_var.gni*                 
+├── prebuilts_download.sh*        
+├── print_python_deps.py*         
+├── scripts/                      
+├── subsystem_config.json         
+├── subsystem_config_example.json 
 ├── templates/                    # c/c++编译模板定义
-├── test.gni*                     # ----------------------
+├── test.gni*                     
 ├── toolchain                     # 编译工具链配置
 ├── tools                         # 常用工具
-├── version.gni                   # ----------------------
-├── zip.py*                       # ----------------------
+├── version.gni                   
+├── zip.py*                       
 
 
 ```

zh-cn/device-dev/subsystems/subsys-sensor-overview.md

@@ -6,6 +6,7 @@
 Sensor服务子系统提供了轻量级传感器服务基础框架，您可以使用该框架接口实现传感器列表查询、传感器控制、传感器订阅去订阅等功能。轻量级传感器服务框架如下图所示：
 
   **图1** Sensor服务框架图
+
   ![zh-cn_image_0000001200229829](figures/zh-cn_image_0000001200229829.png)
 
 - Sensor API：提供传感器的基础API，主要包含查询传感器的列表、订阅/取消传感器数据、执行控制命令等，简化应用开发。

zh-cn/device-dev/subsystems/subsys-usbservice-guide.md

@@ -3,50 +3,50 @@
 
 下面使用步骤以bulktransfer为例。
 
-## 使用步骤<a name="section18816105182315"></a>
+使用步骤<a name="section18816105182315"></a>
 
-1.  获取usb service实例
+1. 获取usb service实例
 
-```cpp
-static OHOS::USB::UsbSrvClient &g_usbClient = OHOS::USB::UsbSrvClient::GetInstance();
-```
+   ```cpp
+   static OHOS::USB::UsbSrvClient &g_usbClient = OHOS::USB::UsbSrvClient::GetInstance();
+   ```
 
-2.  获取usb设备列表
+2. 获取usb设备列表
 
-```cpp
-std::vector<OHOS::USB::UsbDevice> deviceList;
-int32_t ret = g_usbClient.GetDevices(deviceList);
-```
+   ```cpp
+   std::vector<OHOS::USB::UsbDevice> deviceList;
+   int32_t ret = g_usbClient.GetDevices(deviceList);
+   ```
 
-3.  申请设备权限
+3. 申请设备权限
 
-```cpp
-int32_t ret = g_usbClient.RequestRight(device.GetName());
-```
+   ```cpp
+   int32_t ret = g_usbClient.RequestRight(device.GetName());
+   ```
 
-4.  打开设备
+4. 打开设备
 
-```cpp
-USBDevicePipe pip;
-int32_t et = g_usbClient.OpenDevice(device, pip);
-```
+   ```cpp
+   USBDevicePipe pip;
+   int32_t et = g_usbClient.OpenDevice(device, pip);
+   ```
 
-5.  配置设备接口
+5. 配置设备接口
 
-```cpp
-ret = g_usbClient.ClaimInterface(pip, interface, true);
-interface为deviceList中device的interface。
-```
+   ```cpp
+   ret = g_usbClient.ClaimInterface(pip, interface, true);
+   interface为deviceList中device的interface。
+   ```
 
-6.  数据传输
+6. 数据传输
 
-```cpp
-srvClient.BulkTransfer(pipe, endpoint, vdata, timeout);
-```
-pipe为打开设备后的数据传输通道，endpoint为device中数据传输的端点，vdata是需要传输或读取的二进制数据块，timeout为传输超时时长。
+   ```cpp
+   srvClient.BulkTransfer(pipe, endpoint, vdata, timeout);
+   ```
+   pipe为打开设备后的数据传输通道，endpoint为device中数据传输的端点，vdata是需要传输或读取的二进制数据块，timeout为传输超时时长。
 
-7.  关闭设备
-
-```cpp
-ret = g_usbClient.Close(pip);
-```
+7. 关闭设备
+  
+   ```cpp
+   ret = g_usbClient.Close(pip);
+   ```

zh-cn/device-dev/subsystems/subsys-utils-faqs.md

 # 公共基础库常见问题
 
 
-## 1.LiteOS-A内核(Hi3516、Hi3518平台)KV存储路径设置错误，导致KV存储运行失败
+## LiteOS-A内核(Hi3516、Hi3518平台)KV存储路径设置错误，导致KV存储运行失败
 
 **现象描述**
 

zh-cn/device-dev/subsystems/subsys-xts-guide.md

@@ -114,50 +114,50 @@ XTS子系统当前包括acts与tools软件包：
    ```
 
 2. src目录下用例编写样例。
-   1.引用测试框架
-
+   
+    1.引用测试框架
      
-   ```
-   #include "hctest.h"
-   ```
+     ```
+     #include "hctest.h"
+     ```
 
    2. 使用宏定义LITE_TEST_SUIT定义子系统、模块、测试套件名称
 
      
-   ```
-   /**  
-   * @brief  register a test suite named "IntTestSuite"  
-   * @param  test subsystem name  
-   * @param  example module name  
-   * @param  IntTestSuite test suite name  
-   */
-   LITE_TEST_SUIT(test, example, IntTestSuite);
-   ```
+      ```
+      /**  
+      * @brief  register a test suite named "IntTestSuite"  
+      * @param  test subsystem name  
+      * @param  example module name  
+      * @param  IntTestSuite test suite name  
+      */
+       LITE_TEST_SUIT(test, example, IntTestSuite);
+      ```
 
    3. 定义Setup与TearDown
 
-   命名方式：测试套件名称+Setup，测试套件名称+TearDown。
+      命名方式：测试套件名称+Setup，测试套件名称+TearDown。
 
-   Setup与TearDown必须存在，可以为空函数。
+      Setup与TearDown必须存在，可以为空函数。
 
    4. 使用宏定义LITE_TEST_CASE写测试用例
 
-   包括三个参数：测试套件名称，测试用例名称，用例属性（测试类型、用例粒度、用例级别）。
+      包括三个参数：测试套件名称，测试用例名称，用例属性（测试类型、用例粒度、用例级别）。
 
      
-   ```
-   LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1) 
-   {  
-     //do something 
-   };
-   ```
+      ```
+      LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1) 
+      {  
+        //do something 
+         };
+      ```
 
    5. 使用宏定义 RUN_TEST_SUITE注册测试套件
 
      
-   ```
-   RUN_TEST_SUITE(IntTestSuite);
-   ```
+      ```
+      RUN_TEST_SUITE(IntTestSuite);
+      ```
 
 3. 测试模块的配置文件（BUILD.gn）样例：
    在每个测试模块目录下新建BUILD.gn编译文件，用于指定编译后静态库的名称、依赖的头文件、依赖的库等；具体写法如下：
@@ -237,52 +237,52 @@ XTS子系统当前包括acts与tools软件包：
 2. 测试模块src下用例编写样例：
    1. 引用测试框架：
 
-   需要引用gtest.h  如：\#include "gtest/gtest.h"
+      需要引用gtest.h  如：\#include "gtest/gtest.h"
 
      
-   ```
-   #include "gtest/gtest.h"
-   ```
+      ```
+      #include "gtest/gtest.h"
+      ```
 
    2. 定义Setup与TearDown
 
      
-   ```
-   using namespace std;
-   using namespace testing::ext;
-   class TestSuite: public testing::Test {
-   protected:
-   // Preset action of the test suite, which is executed before the first test case
-   static void SetUpTestCase(void){
-   }
-   // Test suite cleanup action, which is executed after the last test case
-   static void TearDownTestCase(void){
-   }
-   // Preset action of the test case
-   virtual void SetUp()
-   {
-   }
-   // Cleanup action of the test case
-   virtual void TearDown()
-   {
-   }
-   };
-   ```
+      ```
+      using namespace std;
+      using namespace testing::ext;
+      class TestSuite: public testing::Test {
+      protected:
+      // Preset action of the test suite, which is executed before the first test case
+      static void SetUpTestCase(void){
+      }
+      // Test suite cleanup action, which is executed after the last test case
+      static void TearDownTestCase(void){
+      }
+     // Preset action of the test case
+     virtual void SetUp()
+     {
+     }
+     // Cleanup action of the test case
+     virtual void TearDown()
+     {
+      }
+      };
+     ```
 
    3. 使用宏定义HWTEST或HWTEST_F写测试用例
 
-   普通测试用例的定义：HWTEST（测试套名称， 测试用例名称， 用例标注）。
-
-   包含SetUp和TearDown的测试用例的定义 ：HWTEST_F（测试套名称， 测试用例名称，用例标注）。
+      普通测试用例的定义：HWTEST（测试套名称， 测试用例名称， 用例标注）。
 
-   宏定义包括三个参数：测试套件名称，测试用例名称，用例属性（测试类型、用例粒度、用例级别）。
+      包含SetUp和TearDown的测试用例的定义 ：HWTEST_F（测试套名称， 测试用例名称，用例标注）。
+  
+      宏定义包括三个参数：测试套件名称，测试用例名称，用例属性（测试类型、用例粒度、用例级别）。
 
      
-   ```
-   HWTEST_F(TestSuite, TestCase_0001, Function | MediumTest | Level1) {
-   // do something
-   }
-   ```
+      ```
+      HWTEST_F(TestSuite, TestCase_0001, Function | MediumTest | Level1) {
+      // do something
+      }
+      ```
 
 3. 测试模块下用例配置文件（BUILD.gn）样例：
    每个测试模块目录下新建BUILD.gn编译文件，用于指定编译后可执行文件的名称、依赖的头文件、依赖的库等；具体写法如下。每个测试模块将独立编译成.bin可执行文件， 该文件可直接push到单板上进行测试。
@@ -482,7 +482,7 @@ Windows工作台下安装python3.7及以上版本，确保工作台和测试设
 
 1. 在Windows工作台上，找到从Linux服务器上拷贝下来的测试套件用例目录(对应编译生成的out/release/suites/acts目录)，在Windows命令窗口进入对应目录，直接执行acts\run.bat。
 
-1. 界面启动后，输入用例执行指令。
+2. 界面启动后，输入用例执行指令。
    - 全量执行
         
       ```
@@ -505,5 +505,5 @@ Windows工作台下安装python3.7及以上版本，确保工作台和测试设
 
    等待执行完成。
 
-1. 查看测试报告。
+3. 查看测试报告。
    进入acts\reports\，获取当前的执行记录，打开“summary_report.html”可以获取到测试报告。