郑重声明：原文参见标题，如有侵权，请联系作者，将会撤销发布！ 以下是对本文关键部分的摘抄翻译，详情请参见原文。
Abstract
移动应用程序已经成为我们日常生活中不可或缺的一部分，但许多应用程序的设计都不具备能源意识，因此它们可能会以浪费的方式消耗移动设备上有限的资源。盲目地限制大量的资源使用，在帮助减少能源消耗的同时，限制了应用程序利用资源来做有用的工作。我们认为，要解决这个问题，移动操作系统需要不断地评估一个资源是否仍然是真正需要的，即使它被授予了一个应用程序。
本文提出，在资源受限的移动设备中，租赁机制是一种非常适合的抽象机制，可以用来缓解app的能量错误行为。我们设计了一个基于租赁的、实用的资源管理机制LeaseOS，它在每个租赁期分析分配给应用程序的资源的效用，然后根据效用做出租赁决策。我们在最新的Android操作系统上实现LeaseOS，并用20个存在能源漏洞的真实应用程序对其进行评估。LeaseOS平均减少了92%的功耗浪费，并且显著优于最先进的Android Doze和DefDroid。它也不会对评估的应用程序造成可用性中断。LeaseOS本身会产生少量的能源开销。
1 Introduction
如今的移动设备为第三方开发者编写应用程序提供了巨大的可编程性。例如，Android 7 SDK提供了30662个API。但丰富的界面并不意味着移动编程很容易。实际上，应用程序开发人员在使用受限资源时必须仔细优化，并考虑设备的可变性。由于用户交互、环境条件和运行时更改[38]可能会发生许多事件，因此对代码进行推理并测试应用程序也很困难[47，58]。对于缺乏系统编程训练的应用程序开发人员来说，这些问题尤其具有挑战性。
开发人员经常在他们的应用程序中引入的一种严重缺陷是能量错误[34、35、50、55、58]，它们会异常快速地耗尽电池。例如，wakelock是Android中的一种机制，用于指示操作系统保持CPU、屏幕、WiFi、收音机等处于活动状态。预期用途是在关键操作之前获取唤醒锁，并在操作完成后立即释放它。实际上，应用程序可能会发出一个获取请求，而忘记在某些代码路径中调用释放或很晚才调用它。类似地，iOS通过音频会话管理应用程序的音频资源。Facebook iOS应用发布了一个错误版本[19]，在某些情况下会泄露音频会话，使得该应用除了在后台保持清醒外什么也不做，耗尽了电池电量。这个版本在网络处理代码中也有一个bug，它会导致长时间的CPU运转而没有任何进展。
虽然有一些解决方案可以帮助在发布之前通过更好的应用程序测试（32、51、60）、错误检测（44、46、56、66）和库（30）来消除能源缺陷，但复杂的能源缺陷仍然可以逃离这些工具。因此，在运行时设计技术来减少能源缺陷是很重要的。毕竟，能源缺陷在一定程度上会对用户造成损害，因为现有的移动系统在保护资源方面还不够。
最先进的运行时技术[17，41，45，52]监视应用程序资源的使用情况，如果使用超过阈值，则终止或限制应用程序。但大量使用资源并不一定意味着不当行为。有合法的情况下，使用是正当的，例如，导航或游戏。盲目限制可能会破坏应用程序功能。我们认为缺失的部分是一种移动资源管理机制，用于在资源被授予后持续评估资源是否对应用程序仍然真正有用。
本文提出的租赁（lease）[40]是一种用于分布式系统中管理缓存一致性的机制，是一种非常适合于缩小这一差距的抽象方法。在分布式缓存中，租约是服务器和客户端之间的一种合同，授予持有者在租约期限内访问数据的权利。在租用期限内，客户端的读取访问不需要服务器的批准。期满后，如果租约未续签，例如由于客户端崩溃或网络分区，服务器可以安全地继续运行，而无需无限期等待。
尽管移动应用程序的能源不当行为是一个不同的问题领域，但租赁的基本抽象可以扩展到移动设备，作为操作系统和应用程序之间关于资源（例如，wakelock、GPS、sensor）的合同，并有时间条件。这种抽象带来了两个好处。首先，租约可以容忍应用程序中常见的草率资源使用错误（例如，仅在onDestroy中释放wakelock）。默认情况下，租约支持的资源在期限结束时过期，除非应用程序或操作系统显式续订该资源。如果租赁期大于所需的持续时间，即使应用程序忘记释放资源，也会减少能量的浪费。相比之下，由现有机制默认管理的资源在被授予后仍然存在，除非它被显式释放；这鼓励了多余的持有。其次，与盲目的一次性限制方法相比，一次租赁允许一系列的小条款，并且在每个条款结束时，根据过去的行为做出租赁决策。此反馈循环允许租约决策适应不断变化的应用程序行为，例如从低资源利用率到高利用率。这样，应用程序开发人员也就免去了仔细跟踪资源以避免浪费能源的负担。
我们提出了一种基于租赁的移动资源管理机制LeaseOS，以减轻应用程序的能源不当行为。在LeaseOS中，授予应用程序的资源可以由一个或多个条款的租约支持。如果应用程序在期限结束时仍保留资源，则租约将被延长或推迟（暂时过期）。稍后尝试将资源与过期的租约一起使用需要获得租约管理器的批准。
租赁的一个核心挑战是作出适当的租赁决定，包括是否续租和租期长短。理想情况下，这些决定应该有效地缓解能源不当行为，但不应该剥夺应用程序对资源的合法使用。一个简单的租赁策略是使用资源持有时间[45，52]。但是通过研究现实世界中的应用程序（§2），我们发现这个指标是一个误导性的能量错误行为的分类器。相反，LeaseOS在其租赁管理决策中采用了功利主义的方法。我们引入了一个新的方法，效用，来增强租约，它描述了一个应用程序从被授予的资源中获得的“有用性”的数量。从效用的角度思考，可以让我们进一步将能源的不当行为分为四类，并准确地捕捉其中的三类。
为了将租约透明地集成到现有的移动系统中，LeaseOS设计了一个应用程序难以察觉的租约管理，它可以处理所有的租约操作，包括创建和续租都是在幕后进行的。在每个租赁期，LeaseOS收集一组通用效用得分来衡量资源效用信息。这样，就不需要更改应用程序源代码。LeaseOS还提供了一个简单的API，允许应用程序有选择地定义自定义实用程序函数，从而利用开发人员的语义信息。为防止开发人员滥用此API，当通用效用得分不是特别低时，此函数的返回值将作为提示。
我们在Android 7.1.2版上实现了LeaseOS。为了评估LeaseOS，我们复现了20个具有不同能量缺陷的真实应用程序。当在LeaseOS上运行这些有缺陷的应用程序时，浪费的功耗平均可以减少92%。相比之下，Android Doze[28]和DefDroid[45]这两个运行时状态解决方案仅分别平均降低69%和62%的功耗。LeaseOS也没有对被评估的应用程序造成可用性中断，因为临时撤销的资源确实没有对这些应用程序的实用性做出贡献。LeaseOS产生<1%的电源开销。
本文的贡献如下：
- 分析能源不当行为运行时的特征，并将不当行为分为四类。
- 对109个真实世界的能源缺陷案例进行研究，以了解不同不良行为类型的普遍性。
- 将租约抽象调整到移动系统中，以减轻常见的能源错误行为。
- 设计和实施以租赁为基础的实用资源管理机制LeaseOS。
- 一项评估，展示了LeaseOS方法的实际效益。
2 Understanding Energy Misbehavior
为了改进应用程序能量错误行为的系统级运行时解决方案，首先了解有缺陷的应用程序在运行时的行为是非常有用的。为此，我们在多个智能手机和环境中复现并分析了五个现实世界中的有缺陷的应用程序。在本节中，我们重点介绍了三个案例和我们的主要见解，然后对109个现实世界中的能源不当行为案例进行了定量研究。
2.1 Real-world Cases and Experiment Setup
Case I. K-9 mail[26]是一款应用广泛的Android电子邮件应用程序。应用程序有一个缺陷，即当网络断开连接或邮件服务器出现故障时，应用程序将遇到异常并通过无限期重试来处理它。每次重试，应用程序都会获取一个wakelock，这将使设备保持在导致严重电池耗尽的状态。开发人员通过添加指数后退和提示性的wakelock释放来解决了这个问题。
Case II. Kontalk[27]是一款受欢迎的信息应用程序。当用户登录时，Kontalk会向服务器进行身份验证并建立连接。在一个版本中，应用程序在创建服务时获取wakelock，只有在服务被破坏时才会释放它。这迫使CPU长时间保持活动状态。开发人员通过在应用程序通过身份验证后立即释放wakelock修复了该缺陷。
Case III. BetterWeather[23]是一个基于用户当前位置显示天气状况的小部件。当设备无法获得GPS锁定时（例如，在建筑物内），其中一个版本会导致高电量消耗。根本原因是应用程序的requestLocation方法在GPS信号差的环境中不停地搜索GPS。
为了捕获有缺陷的应用程序的运行时特性，我们构建了一个分析工具，它每隔60秒对每个应用程序的度量向量进行采样，例如wakelock时间、CPU使用率（sysTime+userTime）。实验在五种不同的Android手机上进行：Google Pixel XL、Nexus 6、Nexus 4、Samsung Galaxy S4和Motorola G。它们代表了硬件容量和电池容量不断下降的高端到低端智能手机。他们的软件生态系统也有所不同，Pixel、Samsung和Moto手机被大量使用，Nexus手机则被少量使用。
2.2 Analytical Model: Ask-Use-Release
通过现实世界中的应用程序，我们可以找到几个问题的答案：什么是能源不当行为？什么是常见的能源不当行为模式？为什么现有的移动资源管理机制不足?
通过研究能量缺陷案例的编码模式，我们发现现有移动操作系统中使用的抽象模型ask-use-release捕捉到了能量错误行为的内在特征。在这种模式下，应用程序1）请求（试图获取）资源；2）基本检查后，授予资源；3）应用程序使用资源执行某些工作；4）应用程序最终释放资源。这个模型虽然直观易懂，但对于缺乏有效管理资源经验的应用程序开发人员来说，并不友好，因为它有三个假设：（a）请求者可以在短时间内获得请求的资源；（b）持有资源的持续时间是有限的；（c）必要的工作一完成，资源就释放出来。正如我们在实验中分析的那样，这三个假设都可能是容易出错的，从而导致能量的错误行为。
2.3 Experimental Results and Observations
在Ask阶段的错误行为：我们在位于GPS信号较弱的建筑物中的Nexus手机上运行有缺陷的BetterWeather应用程序（case III）超过1小时。图1显示了GPS请求持续时间。每个点都是在60秒的时间内测量的。我们可以看到，在每个测量间隔内，应用程序花费大约60%的时间来请求GPS锁。但是这个应用程序永远不会得到GPS信息；图中所有的数据点都会消耗大量的能量，而不需要进入使用GPS位置的阶段就可以进行请求。如果没有GPS信息，应用程序就无法获取天气、更新用户界面等信息。因此，在请求阶段花费的过多功耗对应用程序几乎没有任何价值，从而让用户感到沮丧。
Use阶段的不当行为：授予资源后，应用程序可能会将其保留很长时间。我们在有问题邮件服务器的网络连接环境中，在Motorola和Nexus手机上运行有缺陷的K-9 mail（case I）。图2显示，在大多数一分钟的测量间隔中，wakelock锁保持时间很长。但比较Motorola和Nexus的测量结果（由于空间限制未显示），由于生态系统和硬件的差异，异常间隔的绝对保持时间和频率相差2倍。此外，测试手机中的几个普通应用程序（如Pandora、Transdroid、Flym）也会导致长时间的wakelock保持时间。
因此，资源的长绝对保持时间可能仅仅是不同移动系统中的变化或合法的大量资源使用的产物。使用它作为分类器可能将正常的应用程序标记为行为不正常。当一个应用程序长时间持有一个资源，但没有积极利用该资源时，就会发生真正的能量错误行为。对于wakelock资源（它指示CPU保持活动状态），这意味着CPU使用率将低于wakelock保持期间。图2显示，在有错误的K-9 mail情况下，CPU使用率比长的wakelock保持时间要小得多（大多为0）。在我们的实验中，这种超低利用率（<1%）的模式在不同的手机和生态系统中是一致的。图3描绘了Nexus和Samsung手机上有缺陷的Kontalk应用程序（Case II）的测量结果，显示了类似的模式。超低的利用率在测试过的大量使用的普通应用程序中也没有体现出来。
利用好资源不仅仅意味着资源利用率。如果使用的大部分资源都用于对用户毫无用处的工作，那么高利用率并不排除应用程序的不当行为。有缺陷的K-9 mail（case I）在处理由于网络断开而导致的异常时会出现第二个触发条件。图4显示了在这种情况下在Pixel XL上运行K-9的结果。我们可以看到，与有问题邮件服务器的连接环境中的结果相比（图2），wakelock时间平均要高出4倍。CPU使用率超过唤醒锁定时间的比率也更高，甚至超过100%。从利用率的角度分析，结果表明，CPU唤醒时间K-9 mail请求具有较高的利用率。但从K-9 mail的运行日志来看，该应用程序陷入异常状态的循环中，无法进行wakelock获取、网络请求和错误处理，也没有任何进展。因此，资源的利用应该广泛地代表被授予资源的效用，即被消耗的资源给用户带来的价值。
Release阶段的不当行为：当一个资源被高度利用并产生高效用时，如果该资源在很长一段时间后没有被释放，或者经常被重新获取，它可能会产生巨大的能源消耗。但是，用户可能不会认为这是一个异常的电池消耗。例如，用户可以玩愤怒的小鸟或广泛使用Facebook。电池寿命的缩短是一个预期的结果，因此为了节能而牺牲功能可能是不可取的。
基于实验分析，表1总结了ask-use-release模型中的四种能量错误行为。前三种是由于明显的应用程序缺陷造成的：频繁询问行为（FAB），即应用程序经常试图获取资源，但很少获取资源（如图1）；长期持有行为（LHE），即应用程序被授予资源，并持有该资源很长时间，但很少使用资源（如图2）和低效用行为（LUB），即应用程序使用授予的资源很长时间来做大量工作，但大部分工作都是无用的（如图4）。第四种类型是过度使用行为（EUB），即应用程序做了很多有用的工作，但会产生很高的开销。
表1显示了行为类型如何应用于不同的移动资源。并不是所有的资源都能产生FAB。例如，对wakelock或传感器的请求几乎可以立即成功。对于LHB，由于机制不同，GPS和传感器资源的语义与CPU略有不同。对于CPU来说，在应用程序获得wakelock之后，它可以做任何事情，包括不使用它。但对于GPS或传感器，应用程序会向操作系统注册一个侦听器以接收位置更新。获取资源时，将调用侦听器。因此，收集位置信息的时间与GPS保持时间的比率几乎总是100%。我们将GPS/传感器的LHB定义为GPS定位数据的利用，而不是物理资源的利用。
快速下降的观察还意味着，要及早发现能源不当行为，我们不需要将租赁期细分为非常小的时期，并检查每个时期。在租赁期结束时检查资源效用指标就足够了。
2.5 Prevalence of Misbehavior Types
为了了解如何将我们对在前一节分析的少数案例的观察结果普适化，我们对81个流行应用程序中109个真实世界的能源不当行为案例进行了研究。所有应用程序和问题都是从开源托管服务[24，25]或流行的用户论坛[22，31]收集的。我们根据评论和源代码研究每个案例的根本原因。为了了解每种情况的严重性，我们将根本原因分为错误、配置/策略和增强。错误意味着能源浪费是由软件缺陷造成的；配置意味着开发人员有意选择用能源效率换取其他属性（例如准确性）；增强意味着开发人员可以添加一些优化。错误通常具有很高的严重性和优先级，需要开发人员修复。表2显示了不同的能量错误行为类型的分布。
基于这两个发现，我们认为EUB是介于正常行为和错误行为之间的灰色区域，前三个类应该是运行时缓解机制的主要目标，以供用户接受。
3 Lease Abstraction for Mobile System
3.1 Abstraction
在现有的移动操作系统中，当应用程序请求资源时，操作系统将执行初始健全性检查；如果检查通过，应用程序无限期保留资源的权利将持续，除非应用程序显式放弃该资源。这个ask-use-release模型假设应用程序能够在整个资源生命周期内有效地管理资源，这是有问题的。
LeaseOS通过引入租约来显式地管理资源权限。租约实质上授予应用程序请求和使用特定资源实例（以内核对象的形式）的权限。这项权利在一段时间内即租赁期内得到尊重。在当前的移动操作系统方案中，应用程序通过应用程序地址空间中的绑定包装器访问内核对象。使用LeaseOS，当应用程序第一次访问内核对象时创建租约，当相应的内核对象死亡时销毁租约。一个租约可以持续多个期限，t1，…，tn。一个应用程序可以同时持有多个租约，每个租约都可以用租约描述符唯一标识。
在租赁期内，ti，租赁持有者拥有访问资源实例的权利，不需要OS的批准。在ti结束时，OS决定是否续订（延长）租约。换句话说，LeaseOS中的租约表示一种定时能力。租期可以从零到无限。零长度项意味着OS需要检查每个访问。无限期租约意味着在资源被授予应用程序之后，OS不会进行任何检查，这实际上会退化为现有的ask-use-release模型。
3.2 Lease States
在分布式系统中，租约有两种简单的状态：创建或续订租约时的active状态和期限结束时的expired状态。我们调整租约以实现高效的移动资源管理。所得到的租约状态和转换稍微复杂一些（图5）。当租赁期结束时，如果应用程序仍保留资源，则会检查上一个期限的资源效用度量（第2.4节）。对于正常行为，租约将立即使用新期限延长，并再次切换到active状态。LeaseOS引入了一种新的deferred状态。如果行为是三种不当行为之一（FAB、LHB、LUB），则租约进入deferred状态，在此状态下租约将有一个延迟间隔为τ的延长。τ期间，临时取消与本租约相关的能力和资源，以减少浪费的能源消耗。τ之后，能力和资源得到恢复，租约再次过渡到active状态。deferred状态本质上是一个控制器，用于减缓低效用应用程序的执行（第4.6节）。
如果在租约到期时，资源不再被持有，即应用程序在租约的某个时间点调用资源释放，则租约将转换为inactive状态。当租约处于inactive状态时，如果应用程序尝试重新获取或使用租约过期的资源，则访问需要与将做出续订决定的OS进行检查。当租约支持的资源完全解除分配时，租约将进入dead状态。无效的租约将不再续签，并将被清除。
通过定期检查每个期限，并暂时取消τ的未充分利用资源，在不显著损害应用程序实用程序的情况下减少了能源浪费。此外，当一个应用程序只在有限的时间内未充分利用资源，并且以后可以有效地使用资源时，该应用程序有机会获得租约续签并恢复正常行为。这种连续检测更新模型不同于其他简单的一次节流方案。
3.3 Lease and Utility Metrics
为了根据分配的资源对应用程序的有用程度做出租赁决策，我们使用租赁状态来增强抽象的租赁，每个租赁期限记录一个状态，其中包含三个广泛的效用度量（第2.4节），用于对该期间的资源使用行为进行分类，我们以wakelock、GPS和传感器的效用度量为例进行了描述。
当一个应用程序经常试图获取资源，但很少得到资源时，经常会出现频繁访问问题。这可能发生在低信号环境中的GPS，但不适用于wakelock或传感器。度量包括总请求时间和失败的GPS锁定的请求持续时间。如果请求是频繁的或长期的，但成功率低于一个阈值，则出现FAB。当app是以资源为基础的，并且持有它的时间很长，但很少使用它，这会出现长期持有问题。对于wakelock，CPU与wakelock保持时间的比率表示效用。对于GPS和传感器，由于应用程序提供的侦听器总是被唤起，在这种情况下，应用程序活动绑定到侦听器的生存期与侦听器的生存期之比是更合适的效用指标。低效用行为涉及了一个大型资源，它的利用率是高的，但大部分工作没有价值。为了量化使用情况，我们使用了0到100的效用分数。如果得分低于门槛，那就有点滑稽了。当效用分数经常被应用到特定的应用中时，可以使用一些保守的启示来确定一个通用的效用。具体地说，我们将应用程序中出现严重异常的频率作为wakelock的低效用，将GPS的移动距离作为GPS的效用，将UI更新和用户与应用程序的交互用作为高效用。
除了通用效用程序外，LeaseOS还提供了一个可选的简单回调接口IUtilityCounter，供应用程序提供自定义实用程序。图6显示了屏幕控制应用程序TapAndTurn如何实现该接口。该应用程序为用户提供了一个控制屏幕旋转的图标。如果方向传感器检测到方向变化，屏幕上将出现一个图标，供用户单击。开发人员可以记录图标出现的次数和单击该图标的次数。然后，他可以实现IUtilityCounter，方法是返回单击图标出现次数的比率乘以100。对于健身跟踪应用程序，自定义实用程序函数可以是一段时间内写入数据库的跟踪数据量，标准化为0-100。为了防止滥用此函数，只有当通用效用程序不是特别低时，才会将自定义效用程序作为提示。
4 Design of LeaseOS
LeaseOS是一个运行时解决方案，用于减轻移动应用程序中的能源缺陷。具体来说，LeaseOS的目标是解决ask-use-release模型中频繁请求、长期持有和低效用的错误行为（第2.4节）。解决过度使用并非是一个目标。我们之所以做出这个设计决定，是因为FAB、LUB或LHB是由于编程错误造成的明显的能量错误行为。另一方面，EUB是由大量使用资源引起的，这通常是一种有意的权衡，判断为不当行为是有争议的。
4.1 Overview
图7显示了LeaseOS的体系结构。系统组件Lease Manager管理系统中的所有租约。租约管理器处理与租约相关的操作，例如创建和转换租约状态。为了做出租赁决策，租赁管理器还跟踪衡量租赁相关资源效用的关键租赁状态。由于移动应用程序对延迟敏感，租赁管理操作应避免产生过多的开销。为此，LeaseOS设计了一些轻型租赁代理。每个租用代理管理一种类型的受限移动资源，例如wakelock、GPS。代理放置在管理该类型资源的OS子系统中，并代表应用程序与租约管理器交互。
4.2 Achieving Transparent Lease Integration
在当前的移动操作系统下，应用程序和OS子系统生活在不同的地址空间中。当应用程序成功地从管理该资源的子系统获取资源（例如wakelock）时，它将获得资源描述符上的包装器，该包装器可以在应用程序的地址空间中本地使用。在Android中，资源描述符通常是唯一的客户端IPC令牌，IBinder对象。包装由系统包提供，例如android.os.PowerManager。真正的资源是该子系统中的一个内核对象，例如与应用程序令牌关联的IBinder IPC令牌。由于应用程序资源描述符和内核对象有一对一的映射，调用描述符上的资源操作将转换为向OS子系统生成一个IPC，操作相应的内核对象。
使用LeaseOS，应用程序仍然像往常一样通过IPC和资源描述符向子系统发出资源请求。租约代理透明地代表应用程序向租约管理器发出租约请求。它维护对应于应用程序资源的内核对象与租约管理器返回的租约描述符之间的映射。由于租约代理与子系统位于相同的地址空间中，因此它可以直接操作内核对象，以便按照租约管理器的指示对资源应用操作，而不必遍历或操作应用程序地址空间中的资源描述符。这样，租约就可以无缝地集成到系统中，而无需重写应用程序。因此，LeaseOS与现有应用程序兼容。
4.3 Lease Manager
租约管理器创建、过期、续订和删除资源的租约。当应用程序第一次被授予访问资源实例的权限时，将创建租约。租约分配有唯一的租约描述符和初始期限。应用程序被记录为租约持有人。租约管理器维护一个表，其中包含在整个系统中为授予所有应用程序的不同资源创建的所有租约。
对于分配的每个租赁期限，租赁管理器会在期限到期后安排一次检查。LeaseOS根据应用程序资源使用行为做出租赁决策。在每个租约期限结束时，租约管理器计算资源成功率、效用和效用统计。使用资源状态信息，租约管理器可以判断过去租约期内的资源使用行为类型（第2.4节）。对于每个租约，都会在租约管理器中保留过去期限的状态和行为类型的有界历史记录。给定当前期限和最后几个期限的行为类型，租约管理器将决定是否续订或暂时终止租约。
租约管理器为租约代理提供一组API。表3显示了接口。代理调用registerProxy向租约管理器注册，以启用某一类型资源的租约管理。租约代理调用noteEvent来通知租约管理器有关内核对象的重要事件，例如，应用程序调用内核对象的release或应用程序尝试重新获取该对象。这些事件将在期限末进行分析，以计算与资源保持时间类似的状态。在租赁协议中，租赁到期和续租决定由租赁管理器做出。租约代理提供onExpire和onRenew回调函数，供租约管理器调用。当租约代理检测到应用程序试图使用具有过期租约的资源时，该代理将调用renew API以请求租约扩展。当租赁者（应用程序）死亡时，持有者请求资源的系统服务将清理内核对象。在这种情况下，租约代理还需要通知租约管理器通过调用remove来清理所有相关的租约。
4.4 Lease Proxy
租约代理是租约管理器的轻量级代理。它们直接插入并检查由租约支持的资源（内核对象）。对于管理器创建的每个租约，租约代理存储内核对象和租约描述符之间的映射，以便管理器在决定租约时，代理知道要应用哪个内核对象操作。代理不存储或管理租约内容或状态。他们缓存状态以便进行有效的检查。租约代理使用租约描述符与租约管理器通信。租约代理和租约管理器之间的通信是双向的。当租约代理启动时，它将向管理器注册，创建并保留IPC通道以进行通信。
如果应用程序对代理的主机子系统进行某些资源请求操作，代理可以通过IPC通道调用租约管理器的API，例如create。此外，租约代理将向租约管理器提供若干必需的回调，如onExpire和onRenew。当租约到期或续订时，租约管理器将调用这些已注册的回调。在这些回调中，租约代理将更新其本地租约描述符表、缓存的租约状态及其主机子系统的状态，以反映更改。例如，当应用程序在wakelock实例上调用acquire时，power manager子系统实际上是将内核对象IBinder添加到一个内部数组中，该数组将被检查以确定CPU是否应进入深度睡眠模式。在这种情况下，power manager中的租约代理需要从onExpire中的数组中删除IBinder。
4.5 Lease Mechanism from Apps’ Perspective
使用租约代理，启用基于租约的资源管理不需要更改任何应用程序代码，除非应用程序选择实现可选的自定义实用程序功能。图8以一个真实的应用程序（K-9 mail）为例，从应用程序的角度展示了租赁机制。
(0)创建唯一的资源描述符wkLock，power manager OS子系统创建相应的唯一内核对象（未显示）。当(1)首次执行时，代理将在场景后面创建新租约。在到达(4)之前，可能已经通过了多项租赁条款。在正常情况下，在每个租约期限内，应用程序都会对资源执行一些有用的操作，因此租约到期后会立即续订。当包含(4)的租约期限结束时，租约管理器发现wakelock资源不再持有，因此租约将转换为inactive状态。一段时间后，再次执行函数start。在(1)上，租赁能力立即恢复active。当推送服务最终停止时，租约代理死亡接收者立即请求管理器删除租约。在此过程中，即使(1)和(4)之间的绝对保持时间很长，应用程序的行为也将与不使用租用机制的情况相同。
在某些租赁期内，应用程序可能会出现能源不当行为。例如，当网络断开连接时，在长时间保持wakelock时，它将由于(3)而陷入异常循环。在这种情况下，租赁机制会通过以时长为τ的惩罚期将下一个租赁期的续期推迟来对应用程序执行惩罚。在τ期间，内核资源被暂时撤销以减少能量浪费，但在τ之后恢复。如果网络重新连接，能量错误行为将消失。租赁条款也再次续签了。与一次节流相比，租赁机制能够适应暂时性的能量错动。
4.6 Implication of Deferring Lease Term Renewal
租赁延迟状态的语义是暂时撤销能力和资源，时间为τ。通过用内核对象改变OS子系统的状态来撤销。但是应用程序地址空间中的资源描述符仍然可以被应用程序用来在τ期间生成IPCs。应用程序逻辑也不受影响。对于acquire IPC，OS子系统基本上是假装成功的。对于release IPC，事件将由代理记录。如果τ期间没有释放，则在τ之后将恢复暂时吊销的资源。
应用程序所遭受的主要惩罚是，低效用程序执行速度可能会减慢。以图8为例。假设当代码执行达到(2)时，wkLock的租约进入延迟状态。租约代理将从电源管理器服务的内部数组中删除IBinder对象，而不修改wkLock描述符。如果这恰好是阵列中最后一个IBinder对象，则手机进入深度睡眠模式。因此暂停执行，稍后将无缝恢复。如果暂停的执行涉及网络操作（例如(3)），则当执行恢复时，可能会发生由于超时而导致的I/O异常。但是应用程序已经被要求在编译时处理这种异常。
因此，租约延期不会导致应用程序出现未知异常。对于基于侦听器的资源（如GPS和传感器），延迟状态意味着不会调用app监听器回调（或调用频率较低）。减缓低效用程序执行通常不会对用户造成不良影响，因为它无论如何都不会产生什么价值（例如，不停地重试失败的(3)）。
5 Lease Policy
5.1 Choosing the Lease Term and Deferral Interval
对于以租赁为基础的机制，租赁期限的选择很重要。在原来的分布式缓存场景中，租约期限会影响租约续订开销和由于错误共享而导致的额外延迟之间的权衡。在我们的例子中，不存在虚假共享的权衡，因为大多数消耗能量的移动资源是以不需要协调的订阅方式共享的。但是，租赁期t以及我们引入的延迟间隔τ会影响缓解能源不当行为的有效性以及对合法资源使用的影响。短期租赁期可以让租赁管理器快速发现能源不当行为，但它可能会产生高额的租赁管理费用。一个短的延迟间隔可以减少误判的成本（降低合法的高效用执行），但对减少能源浪费的作用有限。
我们分析租赁期如何影响减轻不当行为的有效性。假设一个应用程序在第i个租赁期开始时开始表现出Long-Holding错误行为，在第j个租赁期结束时，LeaseOS检测到Long-Holding模式。
这意味着，如果一个应用持有的未利用资源的时间长于租赁期，那么对于Long-Holding错误行为，λ越大，越有效的租赁机制有助于减少浪费的能源消耗。此外，绝对租赁期限不是决定因素。它与平均延期间隔的比率是关键。
为了验证上述分析，我们编写了一个测试应用程序，该程序基于真实世界中有错误的应用程序（Torch）模拟Long-Holding错误行为。测试应用程序获取一个wakelock并保持wakelock30分钟而不做任何事情，并且从不释放它。出于实验目的，租赁期限设为30秒、1分钟、3分钟和∞（不租赁）。延迟间隔设置为30s，这意味着λ分别为1、0.5、1/6。每个实验进行30分钟。在实验期间，租赁状态在active状态和deferred状态之间交替（即n=1）。图9（a）显示了结果。我们可以看到，如果租赁期限是30s，应用程序只持有wakelock约15分钟，这意味着大约一半的持有时间没有租赁机制。当租赁期增加到1min时，持有时间增加到20分钟，当租赁期限为3min时，持有时间约为26分钟，我们用同样的三项重复实验，但保持了λ为1。图9（b）显示了结果。我们可以看到，在不同租赁条件下的wakelock持有时间几乎是相同的。这证实了我们的分析结论。上述结论也适用于频繁询问和低效用错误行为，因为它们的租赁状态转换是相同的。基于我们的分析和实证实验，LeaseOS将违约租赁期设为5秒，违约延期间隔设为25秒。
5.2 Optimizing for The Common Case
在移动系统中引入租赁机制的目的是为了减少由于一些行为不端的应用程序而造成的能源浪费。对于许多用户来说，他们设备中的大多数应用程序以相对合理的方式使用资源。即使对于行为不端的应用程序来说，能量不端也是通常是间歇性的（例如，当网络连接或GPS信号较弱时）。这就为LeaseOS创造了一个机会，可以使用自适应的租赁期限来优化常见情况下的正常资源使用行为。特别是，如果应用程序一直在有效地使用资源，LeaseOS可以增加下一个租赁期限。增加租赁期限将减少性能开销，以及对暂时性错误行为的不必要延迟。因此，如果过去的12个期限（1分钟）正常，则租赁管理器会将租赁期限增加到1分钟；如果120个期限正常，则进一步将租赁期限增加到5分钟。如果look-back窗口中的任何期限有不当行为，它将恢复为5秒的租赁期限。
6 Implementation
我们在Android 7.1.2之上实现了LeaseOS，对Android核心框架进行了9100行代码修改。不同租约代理的许多逻辑是相同的，例如与租约管理器通信、维护内核对象和租约描述符的映射。这个公共逻辑是通过一个通用的租约代理类提供的。因此，为一种新型资源启用租赁管理并不需要作出重大努力。这是通过从该代理继承、实现一些代理回调和在系统服务中插入一些hooks来完成的。我们对每个增强系统服务的修改只有大约200行代码。
一个实现挑战是跟踪来自通用租赁效用程序的应用程序的异常。这些异常由Android libcore处理。libcore本身不能直接使用系统API将异常信息传递给Android框架。为了解决这个问题，我们在libcore ExceptionNoteHandler中定义了一个带有get和set接口的新类。在系统服务中应用程序进程的运行时初始化期间，我们设置了一个全局处理程序，该处理程序将在调用时通知租约管理器服务。当应用程序抛出异常时，libcore将检查是否设置了处理程序，如果设置了，则将调用处理程序。
7 Evaluation
本节评估LeaseOS。我们通过在LeaseOS中运行有错误的应用程序并将其功耗与在普通Android中运行它们进行比较，来衡量LeaseOS在缓解频繁询问、长期持有和低效用能源错误行为方面的效率（第2.4节）。我们还测量了LeaseOS的可用性影响和性能开销。
7.1 Experiment Setup
主要的实验是在运行LeaseOS的Google Pixel XL手机上进行的。该设备有一个2.15GHz四核CPU、32 GB存储空间、4 GB RAM和3450 mAh电池。为了衡量缓解能源不良行为的有效性，我们需要获得应用程序级别的功耗。这是通过高通Trepn高精度分析器[29]和安卓内置功率分析器实现的。为了测量整个系统的功耗，我们使用了Monsoon硬件功率监测器。由于Pixel手机的电池很难与Monsoon电源显示器集成，我们使用Nexus 5X手机作为替代品来设置测量（图10）。为了确保基准Android系统拥有相同的应用生态系统，我们在LeaseOS中提供了一个标志来完全关闭租赁服务。初始租约期限设置为5秒，默认延迟间隔为25秒。
7.2 Micro Benchmark
我们首先对主要租赁业务的表现进行微观基准测试。我们编写了一个测试应用程序，20次获取和释放不同的资源。然后我们收集每个租约操作的延迟。表4显示了结果。我们可以看到操作速度很快，接近Android IPC的延迟。作为比较，我们测量了一个应用程序在不使用租约的情况下进行资源获取IPC的延迟大约为2ms，租约更新操作比创建和检查稍高，因为它需要计算效用度量。但租约更新不会强制暂停应用程序执行流，对应用程序的总体延迟影响很小，特别是因为大多数情况下，租赁操作不在应用程序关键路径中。
我们还测量了正常使用场景下的租赁活动。在实验期间，我们积极使用流行的应用程序，包括玩游戏、浏览社交网络、阅读新闻和听音乐30分钟，然后再保持30分钟不动。图11描绘了一段时间内active租约的数量。它显示active租约是中等的，并且与用户活动匹配。总共创建了160个租约。大多数租约都是短期的，active时间的中位数为5秒，但最长时间是18分钟，平均租期个数为4，最多为52。
7.3 Mitigate Energy Misbehavior
我们在流行的现实应用程序中复现了20个代表不同错误行为类型的能源缺陷案例。在早期的研究中使用了5个案例（第2节），我们比较了在普通Android（w/o lease）上运行这些有问题的应用程序和在LeaseOS（w/lease）下运行它们的功耗。App能源不良行为的兴起激发了最近的一些工作。从6.0开始，Android引入了Doze模式（28），当设备长期闲置时，它将延迟应用程序后台CPU和网络活动。Amplify[11]和DefDroid[45]限制过多的请求。我们比较了LeaseOS与Doze和简单节流方法（与DefDroid[45]中的节流设置）的有效性。每个实验运行30分钟，在此期间每100ms采样一次功耗。
表5显示了不同解决方案下的平均功耗，我们可以看到，LeaseOS可以显著降低所有情况下的浪费功耗，平均降低率为92%。默认的Doze是非常保守的（例如，在手机闲置了很长一段时间，没有在4分钟内的角度变化），因为它是一个适用于所有应用程序的非同步模式。只有8例被触发。为了评估是否放松其触发条件可以有所改善，我们迫使它在每个实验的开始通过adb命令行生效。表5显示，尽管主动触发有改善，但它仍然比LeaseOS低得多，因为任何非琐碎的活动都可能中断延迟。类似地，LeaseOS明显优于盲节流解决方案。这是因为该机制本质上无法区分合法行为与不当行为，因此其设置必须是保守的。LeaseOS在每个租赁期结束时都会持续分析应用程序的资源使用和效用，并可以采取主动行动，防止浪费资源的索取或持有。
7.4 Usability Impact
LeaseOS在缓解应用程序能量错误行为方面的高效性并不以降低应用程序可用性为代价。对于我们评估的所有案例，LeaseOS没有引入任何负面的可用性影响。这是因为设计的租赁优化了应用程序的实用性。我们针对的三种错误行为：频繁询问（但很少得到）、长期持有（但很少处理）、低效用（但大部分都是无用的工作）对应用程序的可用性贡献甚微。作为一个轶事的用户体验，主要作者一直积极使用Google Pixel手机运行LeaseOS超过10天，并没有由于租赁而经历任何可见的副作用或缓慢的应用程序交互。
为了进一步证明LeaseOS的效用性方法的重要性，我们比较了普通后台应用在LeaseOS下如何运行基于时间的节流系统（基本上只租用一个期限）。我们选择三个代表性的正常后台应用：1）Run-Keeper跟踪健身活动的位置和传感器记录在后台；2）Spotify在后台对音乐进行流处理；3）Haven使用传感器和相机持续监测入侵者。对于所有三个应用程序，因为资源被充分利用，LeaseOS将不断更新租约而不引入任何中断。相比之下，在纯节流方案下，所有三个应用程序都经历了一些中断，例如，健身跟踪、音乐流处理或监控停止。有趣的是，我们还发现我们使用的分析工具Trepn profiler也停止收集数据，而它在LeaseOS下运行良好。
7.5 Sensitivity to Lease Policy
LeaseOS的效率取决于租赁期限和延期间隔的选择。对于单次错误行为，第5.1节分析了关键参数λ的理论影响。现实世界中的应用程序错误行为可能会间歇性地发生（如图2）。对于这种间歇性的错误行为，用公式很难捕捉到λ的影响。我们编写了一个测试应用程序来模拟影响。测试应用程序生成1000个错误行为片段和1000个正常片段，每个片段的随机长度为0到10分钟。这些片段的组合是一个测试用例。我们生成了1000个测试用例，并计算了它们在1到5的不同λ下的缩减率。图12表明，λ越大，压缩比越高。但是，较大的λ也会增加误判正常行为的可能性，因为效用低且预期惩罚（合法应用程序执行速度减慢）。
7.6 Overhead
利用Monsoon功率监测仪测量LeaseOS的系统功耗开销。我们评估五种设置：1）只使用股票应用程序，并且屏幕关闭；2）没有用户交互，但屏幕打开并安装了一些流行的应用程序；3）使用YouTube；4）依次使用10个应用程序；5）依次使用30个应用程序。每个实验运行8次。对于涉及使用应用程序的实验，我们试图尽最大努力重复用户交互。图13显示了LeaseOS和普通Android的平均结果和错误条图。我们可以看到LeaseOS引入可忽略的开销（＜1%），方差稍大。低开销是轻量级租约代理和自适应租期优化的结果。
作为一个端到端的测试，我们在系统中使用一个有错误的GPS应用程序来测量能量消耗。在实验中，我们播放音乐2小时，观看YouTube 1小时，浏览30分钟，保持手机待机。结果显示，Android w/o lease在大约12小时后耗尽电池，而LeaseOS则持续15小时。
我们还测量了租约对端到端应用程序延迟的影响。我们选择三个具有交互流（例如，按钮点击进行UI更新）的具有代表性的应用程序，这些应用程序涉及租约支持的资源。图14描绘了延迟结果，这表明租约引入了非常小的延迟开销。
8 Discussion
虽然我们的评估显示租赁是解决现实世界能源不良行为的有效机制，但仍然有几个局限性是我们计划解决的，也是我们未来的工作。
我们的效用指标目前是根据能源消耗与资源使用持续时间成比例的假设来定义和测量的。为了考虑诸如动态电压和频率缩放（DVFS）等复杂的硬件行为，我们需要根据设备状态因子调整度量。
作为系统级解决方案，LeaseOS不理解应用程序的语义，而是使用一组通用的效用工具度量。缺乏语义信息可能会导致某些应用程序的潜在错误分类。在这些情况下编写自定义效用程序函数是必要的。但我们认为，与节能计划所需的努力相比，这一努力仍然是可以接受的。
LeaseOS也不能在正常使用和过度使用之间划清界限，因为它们对租赁管理器来说都具有很高的效用。我们计划调查推断应用程序和用户意图，作为效用衡量的一部分，以解决过度使用行为。
基于离线分析（第3.3章和第5.1章）静态地设置了租赁策略和参数，可能存在新的不良行为模式，不能由当前的不当行为判断策略解决。我们计划在未来根据应用程序使用历史动态调整策略。
9 Related Work
OS支持能效：资源受限的移动设备需要特殊的OS支持。为有效的移动资源管理，设计了大量的系统[33, 42, 48, 49, 61, 62, 64, 68]。举几个例子，Anand等人[33]提出OS接口，从应用程序向设备公开“ghost hints”；ECOSystem[68]提出统一的currentcy模型以提供公平的能量分配；Joule Guard[42]使用控制理论为近似应用提供能量保证。这些系统旨在在正常情况下优化能源，而我们的系统的目标是减少由于应用程序中的缺陷造成的能源浪费。
Cinder[61]提出了新的抽象概念——reserves and taps——以明确控制能源消耗。Cinder中的储量和我们提议的租约概念都描述了资源的使用权。但Cinder将reserve视为分配；因此，只要不超过分配，即使能源被浪费，授予reserve的申请也可以运行。我们的租约描述了对时间维度中细粒度内核资源的权限。授予租约的应用程序可以继续使用资源，只要它能有效地使用它。
能量敏感的适应：将反馈环路构建到移动系统中是研究能量效率的一个很好的方法（例如，Odyssey[39, 54]、Grace OS[67]、Proportion allocator[65]、SPECTR[59]、CALOREE[53]。这些解决方案通常通过监测资源、能源和环境变化来适应和调整应用行为。他们假设移动系统和应用是协作的。我们针对应用程序可能出错的场景，使用功利主义租赁来奖励能有效地利用资源的应用程序。
运行时缓解：有几种减少后台应用程序能耗的运行时解决方案[11，45，52，63]。其中，Doze[28]和DefDroid[45]与LeaseOS关系最为密切。当设备长时间不使用时，Doze通过推迟后台CPU和网络活动来延长电池寿命。当某些资源持有的时间太长时，DefDroid对引起混乱的应用程序采用细粒度限制。这种基于持有时间的一次性延迟或限制方法不能将错误行为与合法的大量资源使用区分开来。因此，他们很容易对正常的应用程序反应过度。通过将租约与效用度量结合使用，LeaseOS本质上不会对可用性产生负面影响。持续的检查-更新也使LeaseOS能够很好地适应间歇性的能量错误行为（例如，由于环境条件）。
能量缺陷检测与诊断：应用程序能源不当行为是一个常见的问题，挫败了许多用户。Pathak等人[58]首先研究无休眠能量缺陷的代码模式，并提出静态分析解决这些缺陷的方法。随后的一些项目改进了应用程序错误检测技术[34、43、44、46]、细粒度功率分析[36、37、56、57]、应用程序测试[51]和异常电池耗尽诊断[50]。LeaseOS专注于运行时用能量漏洞来缓解应用程序，这是这些工作的补充。
10 Conclusion
随着在能源受限的移动设备上提供丰富的应用程序，设计资源管理机制变得越来越重要。我们在移动资源管理的设计空间中探索了一种实用的方法，并提出了移动租赁抽象。我们设计的LeaseOS可以持续测量应用程序资源的效用，从而做出租赁决策。实验表明，LeaseOS可以减少20个真实世界中有错误的应用程序平均92%的浪费功耗，比两个最先进的运行时解决方案明显更有效。实验还表明，由于其固有的功利性，在合法用途下大量使用资源的应用程序可以在租赁环境下正常运行。LeaseOS产生的功耗开销小于1%。
LeaseOS的开源代码获取方式为：https://orderlab.io/LeaseOS