!20584 敏感词修改

Merge pull request !20584 from liyan/master

zh-cn/device-dev/device-test/smartperf-host.md

@@ -3,6 +3,7 @@
 Smartperf-Host是一款深入挖掘数据、细粒度地展示数据的性能功耗调优工具，旨在为开发者提供一套性能调优平台，支持对CPU调度、频点、进程线程时间片、堆内存、帧率等数据进行采集和展示，展示方式为泳道图，支持GUI（图形用户界面）操作进行详细数据分析。
 ## 架构图
 ![系统架构图](figures/smartperf_frame.png)
+
 该组件整体分为设备端和PC端两部分，设备端和PC端基于gRPC（Remote Procedure Call）通信框架进行数据交互。
 
 设备端内部分为应用程序内嵌组件、命令行工具、性能调优服务、性能调优插件集合、部分系统工具及部分系统内核等模块。设备端提供了插件扩展能力，对外提供了插件接口，基于该扩展能力可以按需定义自己的能力，并集成到框架中来，目前基于插件能力已经完成了native内存插件、trace插件等，详细介绍见[性能调优组件](https://gitee.com/openharmony/developtools_profiler)。

zh-cn/device-dev/device-test/xdevice.md

@@ -46,7 +46,7 @@ environment环境相关配置，详解介绍如下。
     <sn></sn>        <!-- sn: 设备串号列表，串号之间使用分号;分隔，sn为空时使用本地所有设备，非空时使用指定的sn设备 -->
 </device>
 
-<!-- L0设备配置 -->
+<!-- 轻量系统设备配置 -->
 <device type="com" label="wifiiot">    <!-- type: 设备连接方式，com表示连接方式是串口; label: 表示设备种类，如wifiiot -->
     <serial>                           <!-- serial:  表示一个串口定义 -->
         <com></com>                    <!-- com: 表示本地连接的串口，如COM20 -->
@@ -63,7 +63,7 @@ environment环境相关配置，详解介绍如下。
     </serial>
 </device>
 
-<!-- L1设备本地连接配置 -->
+<!-- 小型系统设备本地连接配置 -->
 <device type="com" label="ipcamera">
     <serial>
         <com></com>                       
@@ -75,7 +75,7 @@ environment环境相关配置，详解介绍如下。
     </serial>
 </device>
 
-<!-- L1设备远端连接配置,可配置多个 -->
+<!-- 小型系统设备远端连接配置,可配置多个 -->
 <device type="com" label="ipcamera">
     <ip></ip>
     <port></port>
@@ -383,7 +383,7 @@ run指令基本使用方法如下。
 
    若AT命令串口和日志输出串口共用，可以配置为相同，即user_config中的type为cmd的com口与type为deploy的com口可配置为一样的端口，如COM18。
 
-   ![L0-1](figures/L0-1.PNG)
+   ![轻量系统设备-1](figures/L0-1.PNG)
 
    user_config.xml的修改示例如下。
 
@@ -476,7 +476,7 @@ run指令基本使用方法如下。
 
    type为cmd的com口对应板子上的AT命令串口，用于对设备发送指令，示例中配置为ChA(COM20)串口号。
 
-   ![L0-1](figures/L0-1.PNG)
+   ![小型系统设备-1](figures/L0-1.PNG)
 
    ipcamera设备有两种连接方式，一种是本地串口连接，一种是通过局域网ip连接。
 

zh-cn/device-dev/driver/driver-peripherals-light-des.md

@@ -32,7 +32,7 @@ Light驱动模型为上层Light硬件服务层提供稳定的灯控制能力接
 
 ### 场景介绍
 
-灯设备的控制，在实际生活中比比皆是，例如短信通知时闪灯、手机电量不足时预警、充电时根据充电进度变换灯的颜色等等。这些动作的实现，都需要使用Light驱动模型提供的接口，动态配置点灯模式、配置灯闪烁效果、点灯、熄灯等。
+灯设备的控制，在实际生活中比比皆是，例如短信通知时闪灯、终端电量不足时预警、充电时根据充电进度变换灯的颜色等等。这些动作的实现，都需要使用Light驱动模型提供的接口，动态配置点灯模式、配置灯闪烁效果、点灯、熄灯等。
 
 ### 接口说明
 

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

@@ -23,13 +23,14 @@ OpenHarmony LiteOS-M提供异常接管调测手段，帮助开发者定位分析
 
 ## 接口说明
 
-OpenHarmony LiteOS-M内核的回溯栈模块提供下面几种功能，接口详细信息可以查看API参考。
+OpenHarmony LiteOS-M内核的回溯栈模块提供以下接口，接口详细信息可以查看API参考。
 
   **表1** 回溯栈模块接口
 
-| 功能分类 | 接口名 | 
+| 接口名 | 功能 | 
 | -------- | -------- |
-| 回溯栈接口 | LOS_BackTrace：打印调用处的函数调用栈关系。<br/>LOS_RecordLR：在无法打印的场景，用该接口获取调用处的函数调用栈关系。 | 
+| LOS_BackTrace | 打印调用处的函数调用栈关系。| 
+| LOS_RecordLR  | 在无法打印的场景，用该接口获取调用处的函数调用栈关系。|
 
 
 ## 使用指导
@@ -40,16 +41,19 @@ OpenHarmony LiteOS-M内核的回溯栈模块提供下面几种功能，接口详
 开启异常调测的典型流程如下：
 
 1. 配置异常接管相关宏。
+
    需要在target_config.h头文件中修改配置：
+   
    | 配置项 | 含义 | 设置值 | 
    | -------- | -------- | -------- |
    | LOSCFG_BACKTRACE_DEPTH | 函数调用栈深度，默认15层 | 15 | 
    | LOSCFG_BACKTRACE_TYPE | 回溯栈类型:<br/>0：表示关闭该功能；<br/>1：表示支持Cortex-m系列硬件的函数调用栈解析；<br/>2：表示用于Risc-v系列硬件的函数调用栈解析； | 根据工具链类型设置1或2 | 
 
-1. 使用示例中有问题的代码，编译、运行工程，在串口终端中查看异常信息输出。示例代码模拟异常代码，实际产品开发时使用异常调测机制定位异常问题。
+2. 使用示例中有问题的代码，编译、运行工程，在串口终端中查看异常信息输出。示例代码模拟异常代码，实际产品开发时使用异常调测机制定位异常问题。
+   
    本示例演示异常输出，包含1个任务，该任务入口函数模拟若干函数调用，最终调用一个模拟异常的函数。代码实现如下：
      
-   本演示代码在 ./kernel/liteos_m/testsuites/src/osTest.c 中编译验证，在TestTaskEntry中调用验证入口函数ExampleExcEntry。
+   本演示代码在`./kernel/liteos_m/testsuites/src/osTest.c`中编译验证，在TestTaskEntry中调用验证入口函数ExampleExcEntry。
    
    ```
    #include <stdio.h>
@@ -210,17 +214,17 @@ OpenHarmony LiteOS-M内核的回溯栈模块提供下面几种功能，接口详
 
 异常接管一般的定位步骤如下：
 
-0. 确认编译时关掉优化选项，否则下述的描述内容可能被优化掉。
+1. 确认编译时关掉优化选项，否则下述的描述内容可能被优化掉。
 
-1. 打开编译后生成的镜像反汇编（asm）文件。如果默认没有生成，可以使用objdump工具生成，命令为：
+2. 打开编译后生成的镜像反汇编（asm）文件。如果默认没有生成，可以使用objdump工具生成，命令为：
    
    ```
    arm-none-eabi-objdump -S -l XXX.elf
    ```
 
-1. 搜索PC指针（指向当前正在执行的指令）在asm中的位置，找到发生异常的函数。
-   PC地址指向发生异常时程序正在执行的指令。在当前执行的二进制文件对应的asm文件中，查找PC值0x2101c61a，找到当前CPU正在执行的指令行，反汇编如下所示：
+3. 搜索PC指针（指向当前正在执行的指令）在asm中的位置，找到发生异常的函数。
 
+   PC地址指向发生异常时程序正在执行的指令。在当前执行的二进制文件对应的asm文件中，查找PC值0x2101c61a，找到当前CPU正在执行的指令行，反汇编如下所示：
    
    ```
    2101c60c <GetResultException0>:
@@ -243,13 +247,13 @@ OpenHarmony LiteOS-M内核的回溯栈模块提供下面几种功能，接口详
    2101c630:	21025f90 	.word	0x21025f90
    ```
    
-1. 可以看到:
+4. 可以看到:
    1. 异常时CPU正在执行的指令是ldr r3, [r3, #0]，其中r3取值为0xffffffff，导致发生非法地址异常。
    2. 异常发生在函数GetResultException0中。
 
-2. 根据LR值查找异常函数的父函数。
-   包含LR值0x2101c64d的反汇编如下所示：
+5. 根据LR值查找异常函数的父函数。
    
+   包含LR值0x2101c64d的反汇编如下所示：
 
    ```
    2101c634 <GetResultException1>:
@@ -272,6 +276,6 @@ OpenHarmony LiteOS-M内核的回溯栈模块提供下面几种功能，接口详
    2101c658:	21025fb0 	.word	0x21025fb0
    ```
    
-1. LR值2101c648上一行是bl	2101c60c <GetResultException0&gt;，此处调用了异常函数，调用异常函数的父函数为GetResultException1。
+6. LR值2101c648上一行是bl 2101c60c \<GetResultException0\>，此处调用了异常函数，调用异常函数的父函数为GetResultException1。
 
-2. 重复步骤3，解析异常信息中backtrace start至backtrace end之间的LR值，得到调用产生异常的函数调用栈关系，找到异常原因。
+7. 重复步骤3，解析异常信息中backtrace start至backtrace end之间的LR值，得到调用产生异常的函数调用栈关系，找到异常原因。

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

@@ -27,7 +27,7 @@
 
 - 负责本机操作系统和另外一个设备上操作系统通信的“网络”。
 
-OpenHarmony采用了多内核结构，支持Linux和LiteOS，开发者可按不同产品规格进行选择使用。linux和LiteOS均具备上述组成单元，只是实现方式有所不同。多个内核通过KAL（Kernel Abstraction Layer）模块，向上提供统一的标准接口。
+OpenHarmony采用了多内核结构，支持Linux和LiteOS，开发者可按不同产品规格进行选择使用。Linux和LiteOS均具备上述组成单元，只是实现方式有所不同。多个内核通过KAL（Kernel Abstraction Layer）模块，向上提供统一的标准接口。
 
 内核子系统位于OpenHarmony下层。需要特别注意的是，由于OpenHarmony面向多种设备类型，这些设备有着不同的CPU能力，存储大小等。为了更好的适配这些不同的设备类型，内核子系统支持针对不同资源等级的设备选用适合的OS内核，内核抽象层（KAL，Kernel Abstract Layer）通过屏蔽内核间差异，对上层提供基础的内核能力。
 

zh-cn/device-dev/porting/porting-asr582x-combo-demo.md

@@ -693,9 +693,13 @@ dsoftbus组件的运行需至少预留80KB RAM。如资源不够，可对其它
 
 在communication_dsoftbus仓中，加入了-fPIC编译选项，这样会让编译器产生与位置无关代码，并使用相对地址，但是在LiteOS-M核中使用的是静态库，不推荐使用。
 建议开发者手动注释-fPIC编译选项，后续会推进OpenHarmony统一规划此编译选项的开关。修改方法是在如下的四个文件中，找到"-fPIC"选项，并全部注释：
+
 `//foundation/communication/dsoftbus/core/common/BUILD.gn`
+
 `//foundation/communication/dsoftbus/core/frame/BUILD.gn`
+
 `//foundation/communication/dsoftbus/sdk/BUILD.gn`
+
 `//foundation/communication/dsoftbus/components/nstackx_mini/nstackx_ctrl/BUILD.gn`
 
 软总线的组网需要通过设备认证，在研发阶段，可以把认证跳过，先行调试组网以及传输能力，需将文件`//foundation/communication/dsoftbus/core/authentication/src/auth_manager.c`中的HandleReceiveDeviceId函数替换为如下实现：

zh-cn/device-dev/porting/porting-stm32mp15xx-on-smallsystem.md

@@ -547,13 +547,13 @@ vendor
 `graphic`配置文件见 `//vendor/bearpi/bearpi_hm_micro/graphic_config/product_graphic_lite_config.h`。
 
 
-#### ACE开发框架子系统适配
+#### ArkUI开发框架子系统适配
 
-进行`ACE`开发框架子系统适配需要添加`ace_engine_lite`部件，直接在`config.json`配置即可。
+进行ArkUI开发框架子系统适配需要添加`ace_engine_lite`部件，直接在`config.json`配置即可。
 
 ```
     {
-        "subsystem": "ace",
+        "subsystem": "arkui",
         "components": [
         {
             "component": "ace_engine_lite",

zh-cn/device-dev/quick-start/quickstart-pkg-3516-burn.md

@@ -22,9 +22,7 @@
 1. 准备烧录相关文件。
    1. 在客户端新建用于保存烧录文件的文件夹，例如“D:\liteos”或“D:\linux”。
    2. 将烧录所需烧写配置文件和启动引导文件保存到新建的文件夹中。
-       - 其L1_LiteOS烧写配置文件为L1_3516_liteos.xml，其启动引导文件为“[u-boot-hi3516dv300.bin](https://gitee.com/openharmony/device_board_hisilicon/tree/master/hispark_taurus/uboot/out/boot)”。
-          其中L1_3516_liteos.xml文件需要开发者自行准备，模板如下：
-
+      - Hi3516DV300对应的LiteOS内核小型系统的启动引导文件为“[u-boot-hi3516dv300.bin](https://gitee.com/openharmony/device_board_hisilicon/tree/master/hispark_taurus/uboot/out/boot)”，烧写配置文件需要开发者自行准备（可自行命名，例如LS_3516_liteos.xml），模板如下：
           
           ```
           <?xml version="1.0" encoding="GB2312" ?>
@@ -35,9 +33,7 @@
           <Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="60M" Length="50M" SelectFile="D:\liteos\userfs_vfat.img"/>
           </Partition_Info>
           ```
-       - 其L1_Linux烧写配置文件为L1_3516_linux.xml，其启动引导文件为“[u-boot-hi3516dv300.bin](https://gitee.com/openharmony/device_board_hisilicon/tree/master/hispark_taurus/uboot/out/boot)”。
-          其中L1_3516_linux.xml文件需要开发者自行准备，模板如下：
-
+      - Hi3516DV300对应的Linux内核小型系统的启动引导文件为“[u-boot-hi3516dv300.bin](https://gitee.com/openharmony/device_board_hisilicon/tree/master/hispark_taurus/uboot/out/boot)”，烧写配置文件需要开发者自行准备（可自行命名，例如LS_3516_linux.xml），模板如下
           
           ```
           <?xml version="1.0" encoding="GB2312" ?>
@@ -51,17 +47,17 @@
           ```
    3. 将编译完成的源码包下载至客户端并解压，将烧录相关文件拷贝至步骤1中新建的文件夹。
       
-      针对Hi3516开发板（轻量级系统使用LiteOS内核或Linux内核根据业务实际需要选择）：
+      针对Hi3516DV300开发板（系统使用LiteOS内核或Linux内核根据业务实际需要选择）：
 
-       - 其L1_LiteOS烧写所需文件为：OHOS_Image.bin、rootfs_vfat.img、userfs_vfat.img
-       - 其L1_Linux烧写所需文件为：uImage_hi3516dv300_smp、rootfs_ext4.img、userfs_ext4.img、userdata_ext4.img
+       - LiteOS内核小型系统对应的烧写所需文件为：OHOS_Image.bin、rootfs_vfat.img、userfs_vfat.img
+       - Linux内核小型系统对应的烧写所需文件为：uImage_hi3516dv300_smp、rootfs_ext4.img、userfs_ext4.img、userdata_ext4.img
 
 2. 使用HiTool烧录。
    1. 打开HiTool。
    2. 设置HiTool参数。
       
       传输方式选择USB口，烧写方式选择烧写eMMC（单板的存储介质为eMMC）。
-   3. 单击浏览在步骤1创建的文件夹中选择烧写配置文件（例如L1_3516_linux.xml）。
+   3. 单击浏览在步骤1创建的文件夹中选择烧写配置文件（例如LS_3516_linux.xml）。
       
        ![zh-cn_image_0000001249937195](figures/zh-cn_image_0000001249937195.png)
    4. 单击烧写后，按住开发板上串口旁的按钮（Update键），并拔插USB线（上下电）。
@@ -77,7 +73,7 @@
       
       终端界面中出现“hisilicon \#”表示已连接开发板串口。
    3. 在串口终端拷贝如下启动参数后，按回车完成配置。
-       - 其L1_LiteOS对应的启动参数为：
+       - LiteOS内核小型系统对应的启动参数为：
          
           ```
           setenv bootcmd "mmc read 0x0 0x80000000 0x800 0x4800;go 0x80000000";
@@ -85,7 +81,7 @@
           saveenv
           sa;reset
           ```
-       - 其L1_Linux对应的启动参数为：
+       - Linux内核小型系统对应的启动参数为：
          
           ```
           setenv bootargs "mem=128M console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootfstype=ext4 rootwait blkdevparts=mmcblk0:1M(boot),9M(kernel),50M(rootfs),50M(userfs),1024M(userdata)"

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

@@ -111,10 +111,13 @@
    }
    ```
 
-3. 实现Service相关的生命周期方法。Service也是一种Ability，Ability为服务提供了以下生命周期方法，用户可以重写这些方法来添加自己的处理。用户在重写的方法里，需要调用父类对应的方法。
+3. 实现Service相关的生命周期方法。
+
+   Service也是一种Ability，Ability为服务提供了以下生命周期方法，用户可以重写这些方法来添加自己的处理。用户在重写的方法里，需要调用父类对应的方法。
+
    - OnStart()
-      该方法在创建Service的时候调用，用于做一些Service初始化且耗时较短的工作，在Service的整个生命周期只会调用一次。
      
+     该方法在创建Service的时候调用，用于做一些Service初始化且耗时较短的工作，在Service的整个生命周期只会调用一次。
    
       ```
       void MyServiceAbility::OnStart(const Want& want)
@@ -124,8 +127,8 @@
       }
       ```
    - OnConnect​()
-      在组件和服务连接时调用，该方法返回SvcIdentity，组件可以通过它与服务交互。
       
+     在组件和服务连接时调用，该方法返回SvcIdentity，组件可以通过它与服务交互。
         
       ```
       const SvcIdentity *MyServiceAbility::OnConnect(const Want &want)
@@ -135,13 +138,16 @@
       }
       ```
    - OnDisconnect​()
+      
      在组件与绑定的Service断开连接时调用。
+
    - OnStop()
+     
      在Service销毁时调用。Service应通过实现此方法来清理任何资源，如关闭线程、注册的侦听器等。
 
 4. 重写消息处理方法。
-   MsgHandle是Service用来处理客户端消息的方法。其中funcId是客户端传过来的消息类型，request是客户端传过来的序列化请求参数。如果用户在处理完成之后想要把结果传回去，需要把结果序列化后写入reply中。
 
+   MsgHandle是Service用来处理客户端消息的方法。其中funcId是客户端传过来的消息类型，request是客户端传过来的序列化请求参数。如果用户在处理完成之后想要把结果传回去，需要把结果序列化后写入reply中。
  
    ```
    void ServiceAbility::MsgHandle(uint32_t funcId, IpcIo *request, IpcIo *reply)
@@ -157,6 +163,7 @@
    ```
 
 5. 注册Service。
+  
    Service也需要在应用清单文件config.json中进行注册，注册类型type需要设置为service。
 
      
@@ -173,7 +180,9 @@
    ```
 
 6. 启动Service。
+
    - Ability为用户提供了StartAbility()方法来启动另外一个Ability，因为Service也是Ability的一种，开发者同样可以通过将Want传递给该方法来启动Service。
+        
      开发者可以通过Want的SetWantElement ()来设置目标服务信息。ElementName结构体的两个主要参数：第一个参数为包名称；第二个参数为目标Ability。
         
       ```
@@ -191,10 +200,14 @@
 
       StartAbility() 方法会立即执行，如果Service尚未运行，则系统首先会调用OnStart()。
    - 停止Service。
+     
      Service一旦创建就会一直保持在后台运行，开发者可以通过调用StopAbility()来停止Service。
 
 7. 连接Service。
-   - 如果Service需要与Page Ability或其他应用组件中的Service进行交互，则应创建用于连接的Service。Service支持其他Ability通过ConnectAbility()与其进行连接，ConnectAbility()需要传入目标Service的Want，以及IAbilityConnection的实例来处理回调。IAbilityConnection提供了两个方法供用户实现，OnAbilityConnectDone()用来处理连接的回调，OnAbilityDisconnectDone()用来处理断开连接的回调。
+
+   - 如果Service需要与Page Ability或其他应用组件中的Service进行交互，则应创建用于连接的Service。
+
+     Service支持其他Ability通过ConnectAbility()与其进行连接，ConnectAbility()需要传入目标Service的Want，以及IAbilityConnection的实例来处理回调。IAbilityConnection提供了两个方法供用户实现，OnAbilityConnectDone()用来处理连接的回调，OnAbilityDisconnectDone()用来处理断开连接的回调。
         
       ```
       {
@@ -264,12 +277,18 @@
 
 
   安装接口只能给内置的系统应用使用。根据应用的安装路径，可以在安装应用时进行选择：
+
 - 将应用安装到系统默认的文件目录/storage/app/。
 
 - 将应用安装到系统外挂的存储介质中，例如micro sdcard。
 
 
-这两种选择可以在创建InstallParam实例的时候指定，当InstallParam的成员变量installLocation为 INSTALL_LOCATION_INTERNAL_ONLY时，意味着应用将会被安装到/storage/app/目录下；当InstallParam的成员变量installLocation为INSTALL_LOCATION_PREFER_EXTERNAL时，意味着应用将被安装到存储介质，其安装目录是/sdcard/app/。由于安装应用的过程是异步的，所以需要使用类似信号量的机制来确保安装的回调可以被执行。
+这两种选择可以在创建InstallParam实例的时候指定，
+
+- 当InstallParam的成员变量installLocation为 INSTALL_LOCATION_INTERNAL_ONLY时，意味着应用将会被安装到/storage/app/目录下。
+- 当InstallParam的成员变量installLocation为INSTALL_LOCATION_PREFER_EXTERNAL时，意味着应用将被安装到存储介质，其安装目录是/sdcard/app/。
+
+由于安装应用的过程是异步的，所以需要使用类似信号量的机制来确保安装的回调可以被执行。
 
 
   安装应用的步骤如下（示例代码以安装到系统目录为例）：
@@ -384,7 +403,9 @@
 
 
   打包工具一般集成到开发工具或者IDE中，开发者一般不涉及直接使用该工具，下面的介绍开发者可以作为了解。打包工具的jar包在开源代码中的位置：developtools/packing_tool/jar。
+
 - 打包命令行参数
+    
    **表2** 打包所需要的资源文件描述
   
   | 命令参数 | 对应的资源文件 | 说明 | 是否可缺省 | 

zh-cn/device-dev/subsystems/subsys-boot-init-deviceInfo.md

@@ -35,7 +35,7 @@
 
 - 适配说明：
 
-  OHOS 固定值参数由OHOS系统填充，厂商不能也不需适配，目前这部分参数主要定义在/base/startup/init/services/etc/param/ohos_const/ohos.para文件中。
+  OHOS 固定值参数由OHOS系统填充，厂商不能也不需适配，目前这部分参数主要定义在`/base/startup/init/services/etc/param/ohos_const/ohos.para`文件中。
 
 ### 厂商固定值参数的适配:
 
@@ -63,7 +63,7 @@
 
   由各产品根据自身情况在vendor目录下适配。
 
-   （1）L2以RK3568为例，在/vendor/hihope/rk3568/etc/para/hardware_rk3568.para中适配，并安装到指定目录。
+  - 标准系统以RK3568为例，在`/vendor/hihope/rk3568/etc/para/hardware_rk3568.para`中适配，并安装到指定目录。
 
     ```
     ohos_prebuilt_etc("para_for_chip_prod") {
@@ -74,7 +74,7 @@
     }
     ```
 
-   （2）L0与L1 在产品对应的 hals/utils/sys_param/vendor.para文件中配置。例如:
+  - 轻量系统与小型系统在产品对应的`hals/utils/sys_param/vendor.para`文件中配置。例如：
 
     ```
     const.product.manufacturer=Talkweb
@@ -97,15 +97,17 @@
 
 ### 厂商动态参数的适配
 
-- 厂商动态值参数，目前有三种获取形式：cmdline 读取，编译宏定义，在BUILD.gn中定义。
+厂商动态值参数，目前有三种获取形式：cmdline读取，编译宏定义，在BUILD.gn中定义。
 
-  1、cmdline 中读取的值有：ohos.boot.hardware, ohos.boot.bootslots, ohos.boot.sn等，其中ohos.boot.sn的获取略有不同，具体如下：
+1. cmdline中读取的值有：ohos.boot.hardware、ohos.boot.bootslots、ohos.boot.sn等，其中ohos.boot.sn的获取略有不同，具体如下：
 
-  （1）L2 Serial从参数ohos.boot.sn读取，ohos.boot.sn 参数值的获取方式：首先从cmdline （由uboot生成）获取，如果获取到的是sn值则直接读取，若获取的是文件路径，则从文件中读取；当获取不到时从默认的Sn文件读取，默认文件为：/sys/block/mmcblk0/device/cid；/proc/bootdevice/cid。
+   - 标准系统的Serial从参数ohos.boot.sn读取。
      
-  （2）L0 和 L1的 Serial各产品在实现过程中可能有自己特殊的算法，因此我们支持在hals/utils/sys_param目录下hal_sys_param.c文件中通过HalGetSerial()接口自定算法来获取Serial。
+     ohos.boot.sn参数值的获取方式：首先从cmdline（由uboot生成）获取，如果获取到的是sn值则直接读取，若获取的是文件路径，则从文件中读取；当获取不到时从默认的Sn文件读取，默认文件为：`/sys/block/mmcblk0/device/cid；/proc/bootdevice/cid`。
 
-  2、编译宏定义的形式获取参数，目前主要在L0 和 L1中用到，例如：
+   - 轻量系统与小型系统的Serial各产品在实现过程中可能有自己特殊的算法，因此OpenHarmony支持在`hals/utils/sys_param`目录下hal_sys_param.c文件中通过HalGetSerial()接口自定算法来获取Serial。
+
+2. 编译宏定义的形式获取参数，目前主要在轻量系统与小型系统中用到，例如：
 
      ```
      defines = [
@@ -117,8 +119,7 @@
          "BUILD_ROOTHASH=\"${ohos_build_roothash}\"",
      ]
      ```
-
-  3、在BUILD.gn中定义,可参考文件/base/startup/init/services/etc/BUILD.gn,例如：
+3. 在BUILD.gn中定义，可参考文件`/base/startup/init/services/etc/BUILD.gn`，例如：
 
      ```
      if (target_cpu == "arm64") {
@@ -142,11 +143,11 @@
          ]
      }
      module_install_dir = "etc/param"
-  }
+  
      ```
 #### 特别说明：
 
-  (1) L1的产品需要在hals/utils/sys_param/BUILD.gn中添加vendor.para的编译，具体如下：
+1. 小型系统的产品需要在`hals/utils/sys_param/BUILD.gn`中添加vendor.para的编译，具体如下：
 
       ```
       copy("vendor.para") {
@@ -155,4 +156,4 @@
       }
       ```
 
-  (2) L0的由于没有文件系统，在编译时会把hal_sys_param.c和vendor.para文件转化为头文件，编译时直接编译到系统中。
\ No newline at end of file
+2. 轻量系统的产品由于没有文件系统，在编译时会把hal_sys_param.c和vendor.para文件转化为头文件，编译时直接编译到系统中。
\ No newline at end of file

zh-cn/device-dev/subsystems/subsys-boot-init-log.md

@@ -5,15 +5,14 @@
 - 基于日志可以定位故障问题，可以查看各子系统启动时长，命令执行时长等。
 - 可以查看不同模块的日志tag，如param、uevent、module等。
 - 输出关键阶段日志，如第一阶段启动日志、required partition设备节点、uevent创建日志、服务启动日志等。
-- 日志等级可控，根据需要输出不同级别日志，目前日志级别分为INIT_DEBUG,
-INIT_INFO,INIT_WARN,INIT_ERROR,INIT_FATAL。
+- 日志等级可控，根据需要输出不同级别日志，目前日志级别分为INIT_DEBUG、INIT_INFO、INIT_WARN、INIT_ERROR、INIT_FATAL。
 
 ### 基本概念
 
 init日志根据OpenHarmony版本不同实现方式不同。
-- 对于OpenHarmony标准版本，init日志采用内核的dmesg log实现。
-- 对于OpenHarmony liteos L1版本init日志采用hilog接口实现。
-- 对于OpenHarmony liteos L0版本init日志采用printf接口实现。
+- 对于OpenHarmony标准系统版本，init日志采用内核的dmesg log实现。
+- 对于OpenHarmony LiteOS小型系统版本init日志采用hilog接口实现。
+- 对于OpenHarmony LiteOS轻量系统版本init日志采用printf接口实现。
 
 ### 约束与限制
 无

zh-cn/device-dev/subsystems/subsys-build-gn-hap-compilation-guide.md

@@ -27,8 +27,8 @@
 | hap_profile | HAP的config.json，Stage模型对应module.json。 |
 | raw_assets | 原始assets，这些assets会直接拷贝到HAP的assets目录下。 |
 | resources | 资源文件，编译后放置在assets/entry/resources目录下 |
-| js_assets | js资源，ace编译后放置在assets/js/default目录下。|
-| ets_assets | ets资源，ace编译后放置在assets/js/default目录下 |
+| js_assets | js资源，编译后放置在assets/js/default目录下。|
+| ets_assets | ets资源，编译后放置在assets/js/default目录下 |
 | deps | 当前目标的依赖 |
 | shared_libraries | 当前目标依赖的native库 |
 | hap_name | HAP的名字，可选，默认为目标名 |
@@ -55,7 +55,7 @@
 | sources | HAP的AppScope中的资源resources，只在Stage模型下使用。|
 
 #### ohos_js_assets
-js或ets代码，ace编译后放置在assets/js/default目录下，stage模型根据代码分别放置到js或ets目录。
+js或ets代码，编译后放置在assets/js/default目录下，stage模型根据代码分别放置到js或ets目录。
 
 | 支持的变量 | 说明 |
 | --------- | ---- |

zh-cn/device-dev/subsystems/subsys-remote-start.md

@@ -76,7 +76,7 @@
    // 启动远程设备FA
    Want want = new Want(); // 封装启动远端FA的Want
    // 使用步骤2中获取的设备ID，并指定FA信息
-   ElementName name = new ElementName(remote_device_id, "com.huawei.remote_package_name", "remote_class_name"); 
+   ElementName name = new ElementName(remote_device_id, "com.example.remote_package_name", "remote_class_name"); 
    want.setElement(name); // 将待启动的FA信息添加到Want中
    want.setFlags(Want.FLAG_ABILITYSLICE_MULTI_DEVICE); // 设置分布式标记，若不设置将无法使用分布式能力
    startAbility(want); // 按照Want启动指定FA,Want参数命名以实际开发平台API为准