!16858 翻译已完成16232+16186+16236+16162+16325

Merge pull request !16858 from shawn_he/16232-d

en/application-dev/dfx/apprecovery-guidelines.md

@@ -37,18 +37,15 @@ No error will be thrown if the preceding APIs are used in the troubleshooting sc
 
 ### Application State Management
 Since API version 10, application recovery is not limited to automatic restart in the case of an exception. Therefore, you need to understand when the application will load the saved state.
-
 If the last exit of an application is not initiated by a user and a saved state is available for recovery, the startup reason is set to **APP_RECOVERY** when the application is started by the user next time, and the recovery state of the application is cleared.
 The application recovery status flag is set when **saveAppState** is actively or passively called. The flag is cleared when the application exits normally or the saved state is consumed. (A normal exit is usually triggered by pressing the back key or clearing recent tasks.)
 
 ![Application recovery status management](./figures/application_recovery_status_management.png)
 
 ### Application State Saving and Restore
-
 API version 10 or later supports saving of the application state when an application is suspended. If a JsError occurs, **onSaveState** is called in the main thread. If an AppFreeze occurs, however, the main thread may be suspended, and therefore **onSaveState** is called in a non-main thread. The following figure shows the main service flow.
 
 ![Application recovery from the freezing state](./figures/application_recovery_from_freezing.png)
-
 When the application is suspended, the callback is not executed in the JS thread. Therefore, you are advised not to use the imported dynamic Native library or access the **thread_local** object created by the main thread in the code of the **onSaveState** callback.
 
 ### Framework Fault Management
@@ -62,13 +59,9 @@ Fault management is an important way for applications to deliver a better user e
 - Fault query is the process of calling APIs of [faultLogger](../reference/apis/js-apis-faultLogger.md) to obtain the fault information.
 
 The figure below does not illustrate the time when [faultLogger](../reference/apis/js-apis-faultLogger.md) is called. You can refer to the [LastExitReason](../reference/apis/js-apis-app-ability-abilityConstant.md#abilityconstantlastexitreason) passed during application initialization to determine whether to call [faultLogger](../reference/apis/js-apis-faultLogger.md) to query information about the previous fault.
-
 ![Fault rectification process](./figures/fault_rectification.png)
-
 It is recommended that you call [errorManager](../reference/apis/js-apis-app-ability-errorManager.md) to handle the exception. After the processing is complete, you can call the **saveAppState** API and restart the application.
-
 If you do not register [ErrorObserver](../reference/apis/js-apis-inner-application-errorObserver.md) or enable application recovery, the application process will exit according to the default processing logic of the system. Users can restart the application from the home screen.
-
 If you have enabled application recovery, the recovery framework first checks whether application state saving is supported and whether the application state saving is enabled. If so, the recovery framework invokes [onSaveState](../reference/apis/js-apis-app-ability-uiAbility.md#uiabilityonsavestate) of the [Ability](../reference/apis/js-apis-app-ability-uiAbility.md). Finally, the application is restarted.
 
 ### Supported Application Recovery Scenarios

en/device-dev/subsystems/subsys-dfx-hisysevent-logging-config.md

@@ -28,8 +28,7 @@ Constraints on the event domain, event name, and parameter
 
 - Zero or more event names can be defined for one event domain. The event names in the same event domain must be unique.
 
-- Multiple parameters can be defined for one event name. The parameters in the same event name must be unique. There must be only one parameter named **__BASE** in each event name. See Table 1 for the fields of this parameter and Table 2 for the fields of other custom parameters.
-
+- Multiple parameters can be defined for one event name. The parameters in the same event name must be unique. There must be only one parameter named **\__BASE** in each event name. See Table 1 for the fields of this parameter and Table 2 for the fields of other custom parameters.
     **Table 1** Fields in the \__BASE parameter
   
   | Field| Description|
@@ -47,8 +46,10 @@ Constraints on the event domain, event name, and parameter
   | arrsize | Length of the parameter of the array type. This field is optional.<br>Value:<br>1-100|
   | desc | Parameter description. This field is mandatory.<br>Rule:<br>The description contains 3 to 128 characters, including a to z, A to Z, 0 to 9, and underscores (_).|
 
+
 ## How to Develop
 
+
 ### Writing a YAML File
 
 

en/device-dev/subsystems/subsys-dfx-hisysevent-overview.md

-# HiSysEvent Overview
+# HiSysEvent
 
 
 ## Introduction

en/device-dev/subsystems/subsys-dfx-hitracemeter.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-HiTraceMeter is the OpenHarmony subsystem that provides APIs to implement call chain trace throughout a service process. With HiTraceMeter, you can quickly obtain the run log specific to the call chain of a service process and locate faults in inter-device, inter-process, or inter-thread communications. HiTraceMeter supports event logging in user mode and can collect trace data in user mode and kernel mode for performance tracing and analysis.
+HiTraceMeter is the OpenHarmony subsystem that provides APIs to implement call chain trace throughout a service process. With HiTraceMeter, you can quickly obtain the run log specific to the call chain of a service process and locate faults in inter-device, inter-process, or inter-thread communications. HiTraceMeter supports event logging in user mode and can collect trace data in user mode and kernel mode for performance trace and analysis.
 
 ## Basic Concepts
 
@@ -12,7 +12,7 @@ The HiTraceMeter subsystem consists of three parts:
 - hitrace CLI tool for data collection
 - smartperf tool for graphical data analysis 
 
-Wherein, HiTraceMeter APIs and the hitrace CLI tool run on the device side, and the smartperf tool runs on the PC side. HiTraceMeter APIs are provided in C++ and JS for event logging, which aims to generate the trace data necessary for performance tracing and analysis during the development process.
+Wherein, HiTraceMeter APIs and the hitrace CLI tool run on the device side, and the smartperf tool runs on the PC side. HiTraceMeter APIs are provided in C++ and JS for event logging, which aims to generate the trace data necessary for performance trace and analysis during the development process.
 
 The hitrace CLI tool is used to collect trace data. It captures trace data flows and saves the data as a text file.
 
@@ -348,4 +348,4 @@ You can set **-t** to **60** and **-b** to **204800** to increase the trace time
 
 # Reference
 
-For details about HiTraceMeter, see [hiviewdfx_hitrace: Lightweight Distributed Tracing](https://gitee.com/openharmony/hiviewdfx_hitrace).
+For details about HiTraceMeter, see [hiviewdfx_hitrace: Lightweight Distributed Trace](https://gitee.com/openharmony/hiviewdfx_hitrace).

en/device-dev/subsystems/subsys-dfx-overview.md

-# DFX Overview<a name="EN-US_TOPIC_0000001185974398"></a>
+# DFX Overview
 
-[Design for X](https://en.wikipedia.org/wiki/Design_for_X)  \(DFX\) refers to the software design that aims to improve the quality attributes in OpenHarmony. It mainly consists of two parts: design for reliability \(DFR\) and design for testability \(DFT\).
+
+## Introduction
+
+[Design for X](https://en.wikipedia.org/wiki/Design_for_X)  \(DFX\) refers to the software design that aims to improve the quality attributes in OpenHarmony. It mainly consists of two parts: design for reliability \(DFR\) and design for testability \(DFT\). 
 
 The DFX subsystem provides the following functions:
 
-- HiLog: implements the logging function. It is applicable to mini-system devices \(reference memory ≥ 128 KiB\), small-system devices \(reference memory ≥ 1 MiB\), and standard-system devices \(reference memory ≥ 128 MB\).
-- HiTraceChain: implements distributed call chain tracing. It is applicable to standard-system devices \(reference memory ≥ 128 MiB\).
+- HiLog: implements the logging function. It is applicable to mini-system devices \(reference memory ≥ 128 KiB\), small-system devices \(reference memory ≥ 1 MiB\), and standard-system devices \(reference memory ≥ 128 MiB\).
+
+- HiTraceChain: implements distributed call chain trace. It is applicable to standard-system devices \(reference memory ≥ 128 MiB\).
+
 - HiTraceMeter: implements performance trace. It is applicable to standard-system devices \(reference memory ≥ 128 MiB\).
+
 - HiCollie: implements thread suspension detection. It is applicable to standard-system devices \(reference memory ≥ 128 MiB\).
+
 - HiSysEvent: implements system event logging. It is applicable to standard-system devices \(reference memory ≥ 128 MiB\).
+
 - HiDumper: exports system information. It is applicable to standard-system devices \(reference memory ≥ 128 MiB\).
-- FaultLogger: implements crash detection. It is applicable to standard-system devices \(reference memory ≥ 128 MiB\).
+
+- Faultlogger: implements crash detection. It is applicable to standard-system devices \(reference memory ≥ 128 MiB\).
+
 - Hiview: implements device maintenance across different platforms. It is applicable to standard-system devices \(reference memory ≥ 128 MiB\).
-- HiAppEvent and HiChecker are only hap developer oriented。
+
+- HiAppEvent and HiChecker are applicable only for HAP developers.
 
 ![dfx features overview](figure/dfx-overview.png)
 
-## Basic Concepts<a name="section5635178134811"></a>
+## Basic Concepts
 
 **Logging**
 
 Logging means to record the log information generated during system running so you can understand the running process and status of the system or applications.
 
-**Distributed call chain tracing**
+**Distributed call chain trace**
 
-In a distributed system, the initiation of a service may involve multiple software modules, with control commands and data transmitted over intra-process, inter-process, and inter-device communication interfaces. To help you understand such complex communication processes and locate service faults efficiently, the DFX subsystem provides a distributed call chain tracing framework.
+In a distributed system, the initiation of a service may involve multiple software modules, with control commands and data transmitted over intra-process, inter-process, and inter-device communication interfaces. To help you understand such complex communication processes and locate service faults efficiently, the DFX subsystem provides a distributed call chain trace framework.
 
 **Thread suspension detection**
 
-If a thread is trapped in an infinite loop or the kernel state \(for example, Uninterruptable Sleep, Traced, Zombie, or synchronous wait\) when it is running, the thread cannot respond to normal service requests and cannot detect and recover from faults by itself. To detect and locate this type of faults, the DFX subsystem provides a simple watchdog mechanism by inserting detection probes to the process nodes that are prone to suspension. This ensures that suspension faults can be detected and logs can be collected.
+If a thread is trapped in an infinite loop or the kernel state (for example, Uninterruptable Sleep, Traced, Zombie, or synchronous wait) when it is running, the thread cannot respond to normal service requests and cannot detect and recover from faults by itself. To detect and locate this type of faults, the DFX subsystem provides a simple watchdog mechanism by inserting detection probes to the process nodes that are prone to suspension. This ensures that suspension faults can be detected and logs can be collected.
 
-**Event logging**
+**Logging**
 
 Event logging means to collect and log events reported during system running. The log information will help you better analyze the product usage.