From 853d2fc7ee689a41caf67174bb6fee2be4632160 Mon Sep 17 00:00:00 2001 From: wusongqing Date: Mon, 12 Jun 2023 08:42:37 +0000 Subject: [PATCH] correct format Signed-off-by: wusongqing --- .../task-management/background-task-overview.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/zh-cn/application-dev/task-management/background-task-overview.md b/zh-cn/application-dev/task-management/background-task-overview.md index a77cb0c2f1..4eefd27e3e 100644 --- a/zh-cn/application-dev/task-management/background-task-overview.md +++ b/zh-cn/application-dev/task-management/background-task-overview.md @@ -29,6 +29,7 @@ OpenHarmony将后台任务分为四种类型，并提供了一个资源申请的 退到后台的应用有不可中断且短时间能完成的任务时，可以使用短时任务机制。该机制允许应用在后台短时间内完成任务，保障应用业务运行不受后台生命周期管理的影响。 > **说明：** +> > 短时任务仅针对应用的临时任务提供资源使用生命周期保障，限制单次最大使用时长为3分钟，全天使用配额默认为10分钟（具体时长系统根据应用场景和系统状态智能调整）。 @@ -45,9 +46,11 @@ OpenHarmony将后台任务分为四种类型，并提供了一个资源申请的 - **配额机制**：为了防止应用滥用保活，或者申请后不取消，每个应用每天都会有一定配额（会根据用户的使用习惯动态调整），其中单日配额默认为10分钟，单次配额最大为3分钟。配额消耗完就不再允许申请短时任务，所以应用完成短时任务后应立刻取消延迟挂起，避免消耗配额。（注：该配额指的是申请的时长，系统默认应用在后台运行的时间不计算在内）。 ## 长时任务 + 长时任务给用户能够直观感受到的且需要一直在后台运行的业务提供后台运行生命周期的保障。比如：业务需要在后台播放声音、需要在后台持续导航定位等。此类用户可以直观感知到的后台业务行为，可以通过使用长时任务对应的后台模式保障业务在后台的运行，支撑应用完成在后台的业务。 ### 后台模式分类 + OpenHarmony提供了九种后台模式，供需要在后台做长时任务的业务使用，具体的后台模式类型如下： **表1** 长时任务种类 @@ -65,6 +68,7 @@ OpenHarmony提供了九种后台模式，供需要在后台做长时任务的业 | taskKeeping | 计算任务 | 正在运行计算任务 | 仅在特定设备生效 | ### 长时任务使用约束 + - 如果用户选择可感知业务（如播音、导航等），触发对应后台模式，在任务启动时，系统会强制弹出通知提醒用户。 - 如果任务结束，应用应主动退出后台模式。若在后台运行期间，系统检测到应用并未使用对应后台模式的资源，则会被挂起（Suspend）。 - 避免不合理地申请后台长时任务，长时任务类型要与应用的业务类型匹配。如果执行的任务和申请的类型不匹配，也会被系统检测到并被挂起（Suspend）。 @@ -72,6 +76,7 @@ OpenHarmony提供了九种后台模式，供需要在后台做长时任务的业 - 一个Ability同一时刻只能申请运行一个长时任务。如果同一时刻需要申请多个长时任务，需要创建多个Ability，每个Ability申请一个长时任务。 ## 延迟任务 + 延迟任务调度给应用提供一个机制，允许应用根据系统安排，在系统空闲时执行实时性要求不高的任务，比如设备空闲时候做一次数据学习等场景。当应用申请延迟任务的时候，任务会被放入待调度队列，系统会根据当前状态，如内存、功耗、温度等统一决策最优的调度时机。同时支持任务的持久化，应用退出或者设备重启，设置的任务同样能够被触发。 ### 延迟任务调度约束 @@ -102,16 +107,18 @@ OpenHarmony提供了九种后台模式，供需要在后台做长时任务的业 - 携带参数信息支持number、string、bool三种类型。 ## 申请能效资源 + 供系统应用使用的能效资源可以分为两类：软件资源(WORK_SCHEDULER, COMMON_EVENT, TIMER)，硬件资源(CPU, GPS, BLUETOOTH, AUDIO)。 应用申请不同的能效资源后可以执行相应的操作： * 申请CPU资源后可以不被挂起，直到任务完成。 * 申请WORK_SCHEDULER资源后不受延迟任务执行频率约束，且任务执行时间增加。 - * 申请COMMON_EVENT资源后，应用在后台处于挂起状态时，仍然能够接收到系统公共事件，申请TIMER资源后，应用能够使用定时器执行精确定时任务。 + * 申请COMMON_EVENT资源后，应用在后台处于挂起状态时，仍然能够接收到系统公共事件。 + * 申请TIMER资源后，应用能够使用定时器执行精确定时任务。 * 申请资源（GPS, BLUETOOTH, AUDIO）后，应用在后台被挂起后，依然能够被管理相关硬件的服务唤醒，执行相应的任务。 -**表1** 能效资源种类 +**表2** 能效资源种类 | 参数名 | 参数值 | 描述 | | -------------- | ---- | ------------------- | @@ -124,6 +131,7 @@ OpenHarmony提供了九种后台模式，供需要在后台做长时任务的业 | AUDIO | 64 | 音频资源，申请后挂起状态下不被代理掉 | ### 能效资源使用约束 + - 能效资源申请或者释放可以由进程或者应用发起，由应用发起的资源释放会释放属于它的同类型的所有资源，包括进程申请的资源。例如应用申请了CPU资源,进程申请了CPU和WORK_SCHEDULER资源，当应用释放CPU资源的时候，会将进程的CPU资源一同释放，同时不同类型的WORK_SCHEDULER资源不受影响。由进程发起的资源释放对应用申请的资源没有影响，例如当应用和进程同时申请了CPU，进程发起了CPU资源释放，应用的CPU资源不会被释放。 - 同时申请同一类持久资源和非持久资源，持久资源会覆盖非持久资源，在超时时不会释放资源。例如应用首先申请了10s的CPU资源，然后在第5s的时候申请了持久的CPU资源，那么资源会变成持久的，非持久的CPU资源记录会被持久化的CPU资源记录覆盖，到了第10s的时候资源不会被释放，如果在第8s的时候提前释放了资源，那么会将CPU资源释放，无法单独释放其中非持久的或者持久的CPU资源。 - WORK_SCHEDULER资源只能由应用申请和释放，不能由进程申请和释放。 -- GitLab