增加能效资源申请的api说明

Signed-off-by: NZhao-PengFei35 <zhaopengfei35@huawei.com>

zh-cn/application-dev/reference/apis/js-apis-backgroundTaskManager.md

@@ -304,7 +304,7 @@ backgroundTaskManager.stopBackgroundRunning(featureAbility.getContext()).then(()
 applyEfficiencyResources(request: [EfficiencyResourcesRequest](#efficiencyresourcesrequest9)): boolean
 
 向系统申请能效资源，使用boolean形式返回结果。
-进程和他所属的应用可以同时申请某一类资源，例如CPU资源，但是应用释放资源的时候会将进程的资源一起释放。
+进程和它所属的应用可以同时申请某一类资源，例如CPU资源，但是应用释放资源的时候会将进程的资源一起释放。
 
 **系统能力**: SystemCapability.ResourceSchedule.BackgroundTaskManager.EfficiencyResourcesApply
 **系统API**: 此接口为系统接口。
@@ -373,15 +373,15 @@ backgroundTaskManager.backgroundTaskManager.resetAllEfficiencyResources();
 
 | 参数名                     | 参数值  | 描述                    |
 | ----------------------- | ---- | --------------------- |
-| DATA_TRANSFER           | 1    | 数据传输                  |
-| AUDIO_PLAYBACK          | 2    | 音频播放                  |
-| AUDIO_RECORDING         | 3    | 录音                    |
-| LOCATION                | 4    | 定位导航                  |
-| BLUETOOTH_INTERACTION   | 5    | 蓝牙相关                  |
-| MULTI_DEVICE_CONNECTION | 6    | 多设备互联                 |
+| DATA_TRANSFER           | 1    | 数据传输。                  |
+| AUDIO_PLAYBACK          | 2    | 音频播放。                  |
+| AUDIO_RECORDING         | 3    | 录音。                    |
+| LOCATION                | 4    | 定位导航。                  |
+| BLUETOOTH_INTERACTION   | 5    | 蓝牙相关。                  |
+| MULTI_DEVICE_CONNECTION | 6    | 多设备互联。                 |
 | WIFI_INTERACTION        | 7    | WLAN相关<br />此接口为系统接口。 |
 | VOIP                    | 8    | 音视频通话<br />此接口为系统接口。  |
-| TASK_KEEPING            | 9    | 计算任务（仅在特定设备生效）        |
+| TASK_KEEPING            | 9    | 计算任务（仅在特定设备生效）。        |
 
 ## EfficiencyResourcesRequest<sup>9+</sup>
 
@@ -393,7 +393,7 @@ backgroundTaskManager.backgroundTaskManager.resetAllEfficiencyResources();
 | --------------- | ------ | ---- | ---------------------------------------- |
 | resourceTypes   | number  | 是    | 申请的资源类型。                               |
 | isApply         | boolean | 是    | 申请资源或者是释放资源。          |
-| timeOut         | number  | 是    | 资源的使用时间，以ms为单位。                |
+| timeOut         | number  | 是    | 资源的使用时间，以毫秒为单位。                |
 | isPersist       | boolean | 否    | 是否永久持有资源，如果是true，那么timeOut就无效。    |
 | isProcess       | boolean | 否    | 应用申请或者是进程申请。          |
 | reason          | string  | 是    | 申请资源的原因。                |
@@ -406,10 +406,10 @@ backgroundTaskManager.backgroundTaskManager.resetAllEfficiencyResources();
 
 | 参数名                     | 参数值  | 描述                    |
 | ----------------------- | ---- | --------------------- |
-| CPU                     | 1    | CPU资源，申请后不被挂起             |
-| COMMON_EVENT            | 2    | 公共事件，申请后挂起状态下不被代理掉  |
-| TIMER                   | 4    | 计时器，申请后挂起状态下不被代理掉    |
-| WORK_SCHEDULER          | 8    | 延迟任务，申请后有更长的执行时间      |
-| BLUETOOTH               | 16   | 蓝牙相关，申请后挂起状态下不被代理掉  |
-| GPS                     | 32   | GPS相关，申请后挂起状态下不被代理掉z  |
-| AUDIO                   | 64   | 音频资源，申请后挂起状态下不被代理掉 |
\ No newline at end of file
+| CPU                     | 1    | CPU资源，申请后不被挂起。             |
+| COMMON_EVENT            | 2    | 公共事件，申请后挂起状态下不被代理掉。  |
+| TIMER                   | 4    | 计时器，申请后挂起状态下不被代理掉。    |
+| WORK_SCHEDULER          | 8    | 延迟任务，申请后有更长的执行时间。      |
+| BLUETOOTH               | 16   | 蓝牙相关，申请后挂起状态下不被代理掉。  |
+| GPS                     | 32   | GPS相关，申请后挂起状态下不被代理掉。  |
+| AUDIO                   | 64   | 音频资源，申请后挂起状态下不被代理掉。 |
\ No newline at end of file

zh-cn/application-dev/task-management/background-task-dev-guide.md

@@ -4,7 +4,7 @@
 
 应用或业务模块处于后台（无可见界面）时，如果有需要继续执行或者后续执行的业务，可基于业务类型，申请短时任务延迟挂起（Suspend）或者长时任务避免进入挂起状态。如果应用需要更加灵活的配置，可以申请能效资源。常见的使用能效资源的场景有：1.应用保证自己在一个时间段内不被挂起，直到任务完成；2.应用处于挂起状态时仍然需要系统的资源，例如闹钟需要计时器资源；3.延时任务需要不受到执行频率的限制，并且拥有更长的执行时间。
 
-在挂起时需要单独的某种资源不被代理或者需要更长的延时任务执行时间，可以申请所需的能效资源。
+在挂起时如果需要单独的某种资源不被代理或者需要更长的延时任务执行时间，可以申请所需的能效资源。
 
 ## 短时任务
 
@@ -497,7 +497,7 @@ export default class BgTaskAbility extends Ability {
 | 接口名                                      | 描述                                       |
 | ---------------------------------------- | ---------------------------------------- |
 | applyEfficiencyResources(request: [EfficiencyResourcesRequest](../reference/apis/js-apis-backgroundTaskManager.md#efficiencyresourcesrequest9)): boolean | 申请能效资源。 |
-| resetAllEfficiencyResources():void | 释放申请的能效资源   |
+| resetAllEfficiencyResources():void | 释放申请的能效资源。   |
 
 
 ### 开发步骤

zh-cn/application-dev/task-management/background-task-overview.md

 # 后台任务概述
 
-后台应用频繁活动，会造成用户设备耗电快、卡顿等现象。因此，为了支撑性能、功耗诉求，系统仅允许应用在后台执行规范内的活动，规范外的活动默认会被挂起，当资源不足时会被回收。同时，应用可以申请能效资源，保证自己在一段时间内不会被挂起，或者在挂起状态能够正常使用一些资源，例如公共事件，计时器等。
+后台应用频繁活动，会造成用户设备耗电快、卡顿等现象。因此，为了支撑性能、功耗诉求，系统仅允许应用在后台执行规范内的活动，规范外的活动默认会被挂起，当资源不足时会被回收。同时，应用可以申请能效资源，保证自己在一段时间内不会被挂起，或者在挂起状态能够正常使用一些资源，例如公共事件、计时器等。
 
 
 ## 后台任务类型
@@ -13,7 +13,7 @@
 
  **3. 长时任务** ：如果是用户发起的可感知业务需要长时间后台运行，如后台播放音乐、导航、设备连接、VoIP等，则使用长时任务避免进入挂起（Suspend）状态。
 
- **4. 能效资源** ：能效资源包括CPU资源，WORK_SCHEDULER资源，软件资源(COMMON_EVENT, TIMER)，硬件资源(GPS, BLUETOOTH)。如果应用或者进程申请了能效资源，那么根据能效类型的资源会拥有相应的特权，例如申请了CPU资源的可以不被挂起，申请了WORK_SCHEDULER后延时任务可以拥有更长的执行时间。
+ **4. 能效资源** ：能效资源包括CPU资源、WORK_SCHEDULER资源、软件资源(COMMON_EVENT, TIMER)、硬件资源(GPS, BLUETOOTH)。如果应用或者进程申请了能效资源，那么根据能效资源的类型会拥有相应的特权，例如申请了CPU资源的可以不被挂起，申请了WORK_SCHEDULER后延时任务可以拥有更长的执行时间。
 
 
 ## 短时任务
@@ -81,6 +81,6 @@ OpenHarmony提供了九种后台模式，供需要在后台做长时任务的业
 | AUDIO                   | 64   | 音频资源，申请后挂起状态下不被代理掉 |
 
 ### 能效资源使用约束
-- 能效资源申请或者释放可以由进程或者应用发起，由应用发起的资源释放在释放的时候会释放属于他的同类型的所有资源，包括进程申请的资源。例如应用申请了CPU资源,进程申请了CPU和WORK_SCHEDULER资源，当应用释放CPU资源的时候，会将进程的CPU资源一同释放，同时不同类型的WORK_SCHEDULER资源不受影响。由进程发起的资源释放对应用申请的资源没有影响，例如当应用和进程同时申请了CPU，进程发起了CPU资源释放，应用的CPU资源不会被释放。
+- 能效资源申请或者释放可以由进程或者应用发起，由应用发起的资源释放会释放属于它的同类型的所有资源，包括进程申请的资源。例如应用申请了CPU资源,进程申请了CPU和WORK_SCHEDULER资源，当应用释放CPU资源的时候，会将进程的CPU资源一同释放，同时不同类型的WORK_SCHEDULER资源不受影响。由进程发起的资源释放对应用申请的资源没有影响，例如当应用和进程同时申请了CPU，进程发起了CPU资源释放，应用的CPU资源不会被释放。
 - 同时申请同一类持久资源和非持久资源，持久资源会覆盖非持久资源，在超时时不会释放资源。例如应用首先申请了10s的CPU资源，然后在第5s的时候申请了持久的CPU资源，那么资源会变成持久的，非持久的CPU资源记录会被持久化的CPU资源记录覆盖，到了第10s的时候资源不会被释放，如果在第8s的时候提前释放了资源，那么会将CPU资源释放，无法单独释放其中非持久的或者持久的CPU资源。
-- WORK_SCHEDULER资源只能由应用进行申请和释放，不能由进程申请和释放。
+- WORK_SCHEDULER资源只能由应用申请和释放，不能由进程申请和释放。

zh-cn/application-dev/task-management/work-scheduler-overview.md

@@ -11,7 +11,7 @@
 延迟调度任务的使用需要遵从如下约束和规则：
 
 - **超时**：系统会设置超时机制，延迟任务回调只允许运行一段时间，超时之后，系统会主动停止。默认的超时限制为2分钟，对于系统应用，可以通过[能效资源申请接口](background-task-overview.md#能效资源申请)获取更长的执行时间（充电状态20分钟，非充电状态10分钟）。
-- **执行频率**：系统会根据应用的活跃度对延迟任务做分级管控，限制延迟任务调度的执行频率。对于通过能效资源接口申请了WORK_SCHEDULER资源的应用，在资源的有效期内，他的延迟任务执行频率不受限制。
+- **执行频率**：系统会根据应用的活跃度对延迟任务做分级管控，限制延迟任务调度的执行频率。对于通过能效资源接口申请了WORK_SCHEDULER资源的应用，在资源的有效期内，它的延迟任务执行频率不受限制。
 
 应用分组             |     延迟任务执行频率约束                            
 --------------------|-------------------------