pt1和pt2滤波_利用后台执行力pt 1

pt1和pt2滤波

How to effectively distribute and defer work from the foreground to the background.

如何有效地分配工作并将工作从前台推迟到后台。

Last year Apple's Software Battery Life Team introduced in the WWDC the brand new BackgroundTasks Framework. It's a very lightweight — yet powerful — library, it holds only 7 new classes (being 2 abstract). It mainly exposes APIs we can use to schedule tasks to run in the background.

去年，苹果公司的软件电池寿命团队在WWDC中引入了全新的BackgroundTasks框架 。 这是一个非常轻量级但功能强大的库，它仅包含7个新类(即2个抽象类)。 它主要公开了可用于安排任务在后台运行的API。

Background Tasks isn't a new thing, though. It's been around since iOS 7, with a different — and now deprecated — API. When first introduced, it was aimed to help your app to keep the content up-to-date for the user, a routine named "App Refresh".

但是，后台任务并不是新事物。 自iOS 7以来，就已经有了不同的API(现已不推荐使用)。 首次引入时，它旨在帮助您的应用程序为用户保持内容最新，这是一个名为“ App Refresh”的例程。

The way it works is pretty straightforward — We register handlers for tasks when the app launches and schedule them as required. The system will launch the app in the background and execute these tasks.

它的工作方式非常简单-我们在应用启动时为任务注册处理程序，并根据需要安排它们的时间。 系统将在后台启动该应用程序并执行这些任务。

One of the coolest things about this framework is that it also allows us to leverage the processing power with the CPU monitor off. This can be very useful to you to train CoreML models or any other energy consuming task.

一个关于这个框架中最酷的一点是，它也使我们能够利用与 CPU关闭显示器的处理能力。 这对于训练CoreML模型或任何其他耗能的任务非常有用。

By the way — from iOS 13 on, we are able to satisfy several other background execution use cases, such as Discretionary Downloads, Background Pushes and more!

顺便说一下-从iOS 13开始，我们能够满足其他一些后台执行用例，例如自由下载 ， 后台推送等等！

This all sounds promising… but how can we adopt it in our App?

这听起来很有希望……但是我们如何在我们的应用程序中采用它呢？

In this article we'll have an overview of this API as well as some of the limitations and challenges we can find along the way, while dealing with background tasks.

在本文中，我们将对此API进行概述，并在处理后台任务的过程中发现一些限制和挑战。

什么是后台执行？ (What is Background Execution?)

I realise we have the "Background" term spread all over APIs. Often this name refers to something that is not being performed in the first plan.

我意识到我们的“背景”一词遍布所有API。 此名称通常是指第一个计划中未执行的操作。

We have background queues, background threads… But when we talk about background execution, we mean the app executing code when it is not in the foreground. In other words, the app is running but not necessary visible to the user.

我们有后台队列，后台线程……但是当我们谈论后台执行时，我们指的是应用程序不在前台时执行代码 。 换句话说，该应用程序正在运行，但对用户而言不是必需的。

背景执行Struts (Pillars of Background Execution)

Firstly, a little bit of history.

首先，有一点历史。

Back in 2013, Apple introduced Background App Refresh Task. It was a big step forward in multitasking, but it came with a drawback: any app with this capability was allowed to continue running code in the background even when the device was locked (🤯):

早在2013年，Apple便推出了Background App Refresh Task。 这是多任务处理中的一大进步，但它有一个缺点： 即使设备被锁定(🤯)，任何具有此功能的应用程序都可以在后台继续运行代码：

here 此处观看

It was fixed in iOS 7, by distributing the work when the device was unlocked or received an event (such as checking for new e-mail). The scheduled background task then would have some time to run again.

通过在设备解锁或收到事件(例如检查新电子邮件)时分发工作，此问题已在iOS 7中修复。 然后，计划的后台任务将有一些时间再次运行。

here 此处观看

This taught us an important lesson — whenever you are performing work, you are consuming power. And this affect directly the device battery life.

这给了我们一个重要的教训- 每当您执行工作时，便会消耗能量。 这直接影响设备的电池寿命。

So before getting started, I must bring your attention to the User Experience.

因此，在开始之前，我必须引起您对User Experience的关注。

In order to design background execution functionality, we should consider three pillars: Power, Performance and Privacy.

为了设计后台执行功能，我们应该考虑三个Struts： 力量 ， 性能和隐私 。

功率 (Power)

As we have seen above, an app consumes power whenever it is running code (either in the foreground or background). So choose wisely how you'll use this time.

正如我们在上面看到的，应用程序每当运行代码(在前台或后台)时都会消耗能量。 因此，明智地选择这次的使用方式。

When scheduling background tasks, we have a way to exit the execution earlier. We can tell the system to complete the task in advance by calling the setTaskCompleted method.

在安排后台任务时，我们有一种方法可以更早退出执行。 我们可以通过调用setTaskCompleted方法来告诉系统提前完成任务。

性能 (Performance)

We might end up assuming that whenever our app runs in the background, there will be nothing else happening. However, the User has several apps acting under the same circumstances.

我们可能最终会假设，只要我们的应用程序在后台运行，就不会发生任何其他事情。 但是，用户有多个在相同情况下运行的应用程序。

So the interface was designed to set smart CPU and memory limits to minimise this impact. We should be aware of what these limits are so that we don’t affect what the user is actively doing (and so that the system doesn’t terminate our app).

因此，该界面旨在设置智能CPU和内存限制，以最大程度地减少这种影响。 我们应该意识到这些限制是什么，以便我们不影响用户正在做的事情(并且系统不会终止我们的应用程序)。

隐私 (Privacy)

Users are really sensitive and care about their personal data. While they may be aware of all the times that the app is running in the foreground and expected to have access to certain pieces of information, they may not be as aware of all the times the app is running in the background.

用户确实很敏感，并且关心他们的个人数据。 尽管他们可能知道应用程序在前台运行的所有时间，并有望访问某些信息，但他们可能并不知道应用程序在后台运行的所有时间。

This means that we have different APIs for different use cases, each with their own specific set of data needed to support that. When we consume these APIs, we should think about how to be transparent to the user and let them know which pieces of data you’re using.

这意味着我们针对不同的用例有不同的API，每个API都有支持它们所需的特定数据集。 当我们使用这些API时，我们应该考虑如何对用户透明，并让他们知道您正在使用哪些数据。

These three pillars are very important to take into account during development. Background execution isn't foreground execution. Instead, it is a very restricted scope.

在开发过程中，这三个Struts非常重要。 后台执行 不是 前台执行。 相反，这是一个非常有限的范围。

后台任务风味 (Background Task Flavours)

There are mainly two paths to take under the background execution road:

后台执行路径主要采取两种途径：

BGAppRefreshTask (BGAppRefreshTask)

App Refresh Tasks have been around us since iOS 7. You may be familiar with this API already. They represent a short task typically used to refresh content.

自iOS 7以来， App Refresh Tasks就一直存在。您可能已经熟悉此API。 它们代表通常用于刷新内容的简短任务。

According to the WWDC Session 707 "the system will learn how the user uses your app and wake it up shortly before it is launched again to give you the chance to update its state".

根据WWDC会话707， “ 系统将了解用户如何使用您的应用，并在再次启动之前不久将其唤醒，以使您有机会更新其状态” 。

Tip 💡: To design a great App Refresh experience, consider implementing the State Preservation and Restoration in your app as well. This will make the app launch transitions look seamless!

提示To：要设计出色的“应用刷新”体验，请考虑同时在应用中实施“ 状态保存和恢复” 。 这将使应用程序启动过渡看起来无缝！

BGProcessingTask (BGProcessingTask)

As we discussed previously, we have now a way to leverage the device's processing power. The BGTaskScheduler turns off the system consumptions limits for a moment so you can have full processing power to perform heavy tasks. This can be useful to you to train CoreML models or any other energy consuming task.

如前所述，我们现在有了一种利用设备处理能力的方法。 BGTaskScheduler会BGTaskScheduler关闭系统消耗限制，以便您具有执行繁重任务的完整处理能力。 这对于您训练CoreML模型或任何其他耗能的任务很有用。

When creating Processing Tasks we also has the ability to tell the system to run the task only if the device is recharging or has network connectivity.

在创建处理任务时，我们还能够告诉系统仅在设备正在充电或具有网络连接时才运行任务。

Processing tasks run only when the device is idle. The system terminates any background processing tasks running when the user starts using the device. Background App Refresh tasks, though, are not affected.

处理任务仅在设备空闲时运行。 当用户开始使用设备时，系统将终止正在运行的所有后台处理任务。 但是，后台应用刷新任务不会受到影响。

So… what's the background task you should use?

那么……您应该使用什么后台任务？

如何进行 (How to proceed)

• Analyse what kind of work you want to run in the background. Check if it respects the Background Execution Pillars and if your app will be able to finish it in time;
  分析您想要在后台执行的工作。 检查它是否遵守后台执行Struts，以及您的应用程序是否能够及时完成它；

• Decide then what kind of Background Task suits your case — BGAppRefreshTask or BGProcessingTask? You can use both if you want to, and as many tasks as you want as well.

  然后确定哪种背景任务适合您的情况BGAppRefreshTask或BGProcessingTask ？ 您可以根据需要使用两个任务，也可以同时使用多个任务。

局限性 (Limitations)

Although we can register and schedule as many tasks as we want, we will have the same processing time limit for them, altogether. So we must make sure the tasks have enough time to be completed. If we believe the time won't be enough, we should balance this overload ourselves (e.g. avoiding to schedule them to be executed at the same time).

尽管我们可以注册和调度所需的任意多个任务，但是对于它们，我们将具有完全相同的处理时间限制。 因此，我们必须确保任务有足够的时间来完成。 如果我们认为时间不够用，我们应该自己平衡这种过载(例如，避免安排它们在同一时间执行)。

下一步 (Next Steps)

I have set up an app to demonstrate how the background tasks works in practice. It follows Apple’s Project Sample, but it is a bit simpler.

我已经建立了一个应用程序来演示后台任务如何在实践中工作。 它遵循Apple的Project Sample，但要简单一些。

This article is part of a series. If you want to know more about it, I've set a new article to talk about this implementation, which you can check out here.

本文是系列文章的一部分。 如果您想了解更多信息，我将撰写一篇新文章来讨论此实现，您可以在此处查看 。

Thanks for reading! If you enjoyed this article and want to say the word, please contact me in twitter. Happy coding! 👨🏻‍💻

谢谢阅读！ 如果您喜欢这篇文章并想说这个词，请通过Twitter与我联系。 编码愉快！ ‍💻

翻译自: https://medium.com/@felipericieri/leveraging-the-power-of-background-execution-pt-1-3604ac2fc0bb

pt1和pt2滤波