!1182 修改MD显示问题

Merge pull request !1182 from Austin/OpenHarmony-3.0-LTS

zh-cn/device-dev/guide/device-camera-control-example.md

@@ -7,7 +7,7 @@
 
     >![](../public_sys-resources/icon-note.gif) **说明：** 
     >开发板启动后默认会加载launcher应用，应用的图形界面默认显示在媒体图层上方，会影响camera\_sample的演示结果，因此需要在编译或是打包时去掉launcher应用。
-    >**修改方法：**将“build/lite/components/applications.json”中camera\_sample\_app组件的targets中"//applications/sample/camera/launcher:launcher\_hap"整行注释或删除。
+    >**修改方法**：将“build/lite/components/applications.json”中camera\_sample\_app组件的targets中"//applications/sample/camera/launcher:launcher\_hap"整行注释或删除。
 
 -   本示例编译结果路径为“out/hi3516dv300/ipcamera\_hi3516dv300\_liteos/dev\_tools/bin”，为让文件能在单板中执行，可将示例文件通过读卡器复制至TF卡中，或者修改camera\_sample的编译脚本将结果文件复制至rootfs.img中。
 

zh-cn/device-dev/kernel/kernel-mini-basic-ipc-event-basic.md

@@ -29,11 +29,11 @@ typedef struct tagEvent {
 
 ### 事件运作原理<a name="section187761153144617"></a>
 
-**事件初始化：**会创建一个事件控制块，该控制块维护一个已处理的事件集合，以及等待特定事件的任务链表。
+**事件初始化**：会创建一个事件控制块，该控制块维护一个已处理的事件集合，以及等待特定事件的任务链表。
 
-**写事件：**会向事件控制块写入指定的事件，事件控制块更新事件集合，并遍历任务链表，根据任务等待具体条件满足情况决定是否唤醒相关任务。
+**写事件**：会向事件控制块写入指定的事件，事件控制块更新事件集合，并遍历任务链表，根据任务等待具体条件满足情况决定是否唤醒相关任务。
 
-**读事件：**如果读取的事件已存在时，会直接同步返回。其他情况会根据超时时间以及事件触发情况，来决定返回时机：等待的事件条件在超时时间耗尽之前到达，阻塞任务会被直接唤醒，否则超时时间耗尽该任务才会被唤醒。
+**读事件**：如果读取的事件已存在时，会直接同步返回。其他情况会根据超时时间以及事件触发情况，来决定返回时机：等待的事件条件在超时时间耗尽之前到达，阻塞任务会被直接唤醒，否则超时时间耗尽该任务才会被唤醒。
 
 读事件条件满足与否取决于入参eventMask和mode，eventMask即需要关注的事件类型掩码。mode是具体处理方式，分以下三种情况：
 
@@ -41,9 +41,9 @@ typedef struct tagEvent {
 -   LOS\_WAITMODE\_OR：逻辑或，基于接口传入的事件类型掩码eventMask，只要这些事件中有任一种事件发生就可以读取成功，否则该任务将阻塞等待或者返回错误码。
 -   LOS\_WAITMODE\_CLR：这是一种附加读取模式，需要与所有事件模式或任一事件模式结合使用（LOS\_WAITMODE\_AND | LOS\_WAITMODE\_CLR或 LOS\_WAITMODE\_OR | LOS\_WAITMODE\_CLR）。在这种模式下，当设置的所有事件模式或任一事件模式读取成功后，会自动清除事件控制块中对应的事件类型位。
 
-**事件清零：**根据指定掩码，去对事件控制块的事件集合进行清零操作。当掩码为0时，表示将事件集合全部清零。当掩码为0xffff时，表示不清除任何事件，保持事件集合原状。
+**事件清零**：根据指定掩码，去对事件控制块的事件集合进行清零操作。当掩码为0时，表示将事件集合全部清零。当掩码为0xffff时，表示不清除任何事件，保持事件集合原状。
 
-**事件销毁：**销毁指定的事件控制块。
+**事件销毁**：销毁指定的事件控制块。
 
 **图 1**  事件运作原理图<a name="fig17799175324612"></a>  
 ![](figure/事件运作原理图.png "事件运作原理图")

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

@@ -48,11 +48,11 @@ typedef struct tagEvent {
 
 ### 事件运作原理<a name="section187761153144617"></a>
 
-**事件初始化：**会创建一个事件控制块，该控制块维护一个已处理的事件集合，以及等待特定事件的任务链表。
+**事件初始化**会创建一个事件控制块，该控制块维护一个已处理的事件集合，以及等待特定事件的任务链表。
 
-**写事件：**会向事件控制块写入指定的事件，事件控制块更新事件集合，并遍历任务链表，根据任务等待具体条件满足情况决定是否唤醒相关任务。
+**写事件**会向事件控制块写入指定的事件，事件控制块更新事件集合，并遍历任务链表，根据任务等待具体条件满足情况决定是否唤醒相关任务。
 
-**读事件：**如果读取的事件已存在时，会直接同步返回。其他情况会根据超时时间以及事件触发情况，来决定返回时机：等待的事件条件在超时时间耗尽之前到达，阻塞任务会被直接唤醒，否则超时时间耗尽该任务才会被唤醒。
+**读事件**如果读取的事件已存在时，会直接同步返回。其他情况会根据超时时间以及事件触发情况，来决定返回时机：等待的事件条件在超时时间耗尽之前到达，阻塞任务会被直接唤醒，否则超时时间耗尽该任务才会被唤醒。
 
 读事件条件满足与否取决于入参eventMask和mode，eventMask即需要关注的事件类型掩码。mode是具体处理方式，分以下三种情况：
 
@@ -60,9 +60,9 @@ typedef struct tagEvent {
 -   LOS\_WAITMODE\_OR：逻辑或，基于接口传入的事件类型掩码eventMask，只要这些事件中有任一种事件发生就可以读取成功，否则该任务将阻塞等待或者返回错误码。
 -   LOS\_WAITMODE\_CLR：这是一种附加读取模式，需要与所有事件模式或任一事件模式结合使用（LOS\_WAITMODE\_AND | LOS\_WAITMODE\_CLR或 LOS\_WAITMODE\_OR | LOS\_WAITMODE\_CLR）。在这种模式下，当设置的所有事件模式或任一事件模式读取成功后，会自动清除事件控制块中对应的事件类型位。
 
-**事件清零：**根据指定掩码，去对事件控制块的事件集合进行清零操作。当掩码为0时，表示将事件集合全部清零。当掩码为0xffff时，表示不清除任何事件，保持事件集合原状。
+**事件清零**根据指定掩码，去对事件控制块的事件集合进行清零操作。当掩码为0时，表示将事件集合全部清零。当掩码为0xffff时，表示不清除任何事件，保持事件集合原状。
 
-**事件销毁：**销毁指定的事件控制块。
+**事件销毁**销毁指定的事件控制块。
 
 **图 1**  事件运作原理图<a name="fig17799175324612"></a>  
 ![](figure/事件运作原理图-21.png "事件运作原理图-21")

zh-cn/device-dev/kernel/kernel-small-bundles-linking.md

@@ -47,7 +47,7 @@ LOS\_DoExecveFile
 
 INT32 LOS\_DoExecveFile\(const CHAR \*fileName, CHAR \* const \*argv, CHAR \* const \*envp\);
 
-**函数功能：**根据fileName执行一个新的用户程序。
+**函数功能**：根据fileName执行一个新的用户程序。
 
 **参数说明：**
 

zh-cn/device-dev/subsystems/subsys-aiframework-tech.md

@@ -2,9 +2,9 @@
 
 **用词约定：**
 
-**规则：**必须准守的约定
+**规则**：必须准守的约定
 
-**建议：**需要加以考虑的约定
+**建议**：需要加以考虑的约定
 
 -   **[代码管理规范](subsys-aiframework-tech-codemanage.md)**  
 

zh-cn/device-dev/subsystems/subsys-application-framework-overview.md

@@ -73,7 +73,7 @@ Ability子系统是管理OpenHarmony应用运行状态的开发框架。
 -   **AbilityKit**：Ability框架提供给开发者的开发包，开发者基于该开发包可以开发出基于Ability组件的应用。基于Ability组件开发的应用有两种类型：基于Javascript语言开发的Ability（JS Ability）和基于C/C++语言开发的Ability（Native Ability）。JS应用开发框架是开发者开发JS Ability所用到框架，是在AbilityKit基础封装的包含js UI组件的一套方便开发者能够迅速开发Ability应用的框架。
 -   **AbilityLoader**：负责注册和加载开发者Ability的模块。开发者开发的Ability先要调用AbilityLoader的注册接口注册到框架中，接着Ability启动时会被实例化。
 
--   **AbilityManager：**负责AbilityKit和Ability管理服务进行IPC的通信。
+-   **AbilityManager**：负责AbilityKit和Ability管理服务进行IPC的通信。
 
 -   **EventHandler**：AbilityKit提供给开发者的用于在Ability中实现线程间通信的一个模块。
 

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

@@ -660,7 +660,7 @@ hap包编译请参考[标准系统js应用开发指导](https://developer.harmon
 
     **测试用例输出目录**：out/release/suites/acts/testcases
 
-    **测试框架&用例整体输出目录：**out/release/suites/acts（编译用例时会同步编译测试套执行框架）
+    **测试框架&用例整体输出目录**：out/release/suites/acts（编译用例时会同步编译测试套执行框架）
 
 
 ## 全量用例执行指导（适用于小型系统、标准系统）<a name="section118149111426"></a>