描述修改

Signed-off-by: wangqing <wangqing136@huawei.com>
This commit is contained in:
wangqing 2022-04-08 10:10:00 +08:00
parent 0d3e384043
commit 3ee268af47
2 changed files with 2 additions and 2 deletions

View File

@ -53,7 +53,7 @@ As mentioned above, applications and service modules with transient tasks have t
- **When to request**An application can request a transient task only when it is running in the foreground or before it is suspended in the background. Otherwise, the application may be suspended, resulting in request failure. By default, an application has 612 seconds of running time (subject to the application scenario) before it is suspended in the background.
- **Timeout**The system notifies the application of the suspension delay which is about to timeout by using a callback. The application must then cancel the delayed suspension if timeout . Otherwise, the application will be forcibly killed.
- **When to cancel**The requesting application shall cancel the request when the transient task is complete. Do not wait for the request is forcibly canceled by the system.Otherwise,the time frame allowed for the application to run in the background will be affected.
- **When to cancel**The requesting application shall cancel the suspension delay when the transient task is complete. Do not wait for the request is forcibly canceled by the system.Otherwise,the time frame allowed for the application to run in the background will be affected.
- **Quota mechanism**To prevent abuse of the keepalive, each application has a certain quota every day (dynamically adjusted based on user habits). After using up the quota, an application cannot request transient tasks. Therefore, applications should cancel their suspension delay immediately after the transient tasks are complete, to avoid quota consumption. (Note: The quota refers to the requested duration and does not include the time when the application runs in the background.)
## Continuous Tasks<a name="section18532577761"></a>

View File

@ -53,7 +53,7 @@
- **申请时机**允许应用在前台时或退后台在被挂起之前应用退到后台默认有6~12秒的运行时长具体时长由系统根据具体场景决定申请延迟挂起否则可能被挂起Suspend导致申请失败。
- **超时**延迟挂起即将超时Timeout系统通过回调知会应用应用需要取消对应的延迟挂起。如果超时不取消该应用会被强制杀掉。
- **取消时机**:任务完成后申请方应用应该主动取消延时申请,不要等到系统回调后再取消,否则会影响该应用的后台允许运行时长配额。
- **取消时机**:任务完成后申请方应用应该主动取消延迟挂起,不要等到系统回调后再取消,否则会影响该应用的后台允许运行时长配额。
- **配额机制**:为了防止应用滥用保活,或者申请后不取消,每个应用每天都会有一定配额(会根据用户的使用习惯动态调整),配额消耗完就不再允许申请短时任务,所以应用完成短时任务后立刻取消延迟挂起,避免消耗配额。(注,这个配额指的是申请的时长,系统默认应用在后台运行的时间不计算在内。)
## 长时任务<a name="section18532577761"></a>