移动电池耗尽测试与诊断工具的开发经验

804经验：为移动行业开发可用的电池耗尽测试Abhilash JindalIIT德里和移动能源摘要本文报告了我们6年来开发移动电池耗尽测试和诊断工具--电子测试仪（简称电子测试仪）的经验我们展示了如何从一个“学术”原型的电子测试我们首先介绍了我们的初步研究原型的设计，并讨论了从Android生态系统中一些最受欢迎的软件供应商那里收集的可用电池消耗测试和诊断工具的8个关键要求。这些要求提出了有趣的科学和工程挑战，例如如何准确估计电池消耗而无需先验功率建模，在未修改的设备上工作这些要求促使对电子测试仪的设计进行了彻底的改革，并导致了一种新型蝙蝠的诞生电池漏电流测试方法。我们展示了重新设计的电子测试仪被用来在一些最受欢迎的Android应用程序中发现电池漏洞，这些应用程序拥有数亿用户，例如NetAndroid和CNN。我们正在开源电子测试仪，以鼓励进一步研究电池诊断，并授权开发人员编写电池效率的移动软件。CCS概念• 硬件→功率估计和优化;·软件及其工程→软件维护工具;·以人为中心的计算→无处不在和移动计算系统和工具。关键词移动终端;电池耗尽;测试和诊断;准确性;可重复性;自动化测试;可行见解1介绍在过去的十年里，学术界和工业界都有许多人致力于开发移动软件允许制作本作品全部或部分的数字或硬拷贝供个人或教室使用，是免费的，前提是复制品不为利润或商业利益而制作或分发，并且复制品的第一页上载有本通知和完整的引用。本作品的版权归ACM以外的其他人所有，必须予以尊重。允许使用学分进行摘要。复制，或重新发布，张贴在服务器上或重新分发到列表，需要事先的特定许可和/或费用。请求权限请发邮件至permissions@acm.org。2022年1月31日至2月4日，美国路易斯安那州新奥尔良市，©2022计算机协会。ACM ISBN 978-1-4503-8342-4/22/01。. . 15.00美元https://doi.org/10.1145/3447993.3483269Y.胡志明普渡大学和移动能源能源效率学术研究包括表征和检测能量缺陷[15，16，23，26]，构建功率模型，移动硬件的元素[4，11，25，27]，构建细粒度的能源配置器[3，24，36]，构建能源感知操作系统抽象，应用程序[29，37，38]，能源感知应用程序适配[9，19]，以及向应用程序开发人员[14]和移动用户[22]提供可操作的诊断。行业竞争主要来自谷歌和苹果等操作系统开发商以及英特尔和高通等硬件制造商。这些工作包括运行自动静态分析检查以捕获常见的能量错误[45]，提供电池消耗诊断工具[40，42，52，61，65]，向开发人员报告在野外捕获的电池消耗问题[51，58]，为移动应用程序开发人员创建能量感知API [41，44]，并通过YouTube视频[48]和会议谈话[59]提高通过这些努力，在提高智能手机电池寿命方面取得了巨大进展但我们在与移动软件行业数百家主要参与者的互动中发现，包括像Net Webix和Facebook这样的流行应用程序，以及像谷歌和三星这样的原始设备制造商，他们的电池消耗测试和诊断过程仍然是临时的，无组织的或根本不存在。这是因为这些开发人员使用的电池消耗测试和诊断工具（BTDT）不存在。在本文中，我们报告了我们的经验，在转换成一个完全自动化的BTDT工具，电子游戏测试仪，或电子测试仪，可用于移动行业的学术原型E prof。本文共分为五个部分。第2提供了基本原理和工程设计 我们的学术原型E教授E PROF是一个“教科书式”的电池消耗分析器，它通过在软件模块中分解应用程序的总电池消耗来识别电池消耗“热点”，从而将gprof [10]等性能分析器扩展到能量维度。第3节描述了我们从与移动生态系统中数百家主要参与者的互动中获得的关键经验。我们调查了移动软件行业中流行的各种电池消耗测试和诊断实践，并通过现场演示和部署收集了有关E prof的反馈。我们报告了电池消耗测试和诊断实践，并在现有的BDTs，包括E教授传达给我们的这些开发人员。他们将电池消耗回归测试和诊断确定为重要的缺失部分，并描述了可用BTT的8项关键要求。首先，这些开发人员需要一个预发布的BTDT工具，可以准确估计电池消耗无需先验功耗建模，可在未修改的设备上工作，并可自动监控代码2022年1月31日至2月4日，美国路易斯安那州新奥尔良市，Abhilash Jindal和Y.胡志明805进化以生成具有可操作见解的高可靠性电池尖峰警报。第4 - 6节描述了从我们的学术原型EPROF中重新设计的电子测试仪，以满足这些关键要求，使电子测试仪可用于移动行业。第9节讨论了正在进行的工作，即扩展电子测试仪以支持5G和基于AI/ML的应用程序，并评估电池电量。而不需要先验功率建模。第7笔记本IDE插件测试装置修改的内核评价了测试人员在完成两个定量测试中的有效性行业要求：准确性和可重复性。第8节重点介绍了ETESTER在一些最受欢迎的Android应用程序中发现的几个能源bug，这些应用程序的数量高达数亿1. 选择AUT。启动分析3.停止分析并查看结果2. 与AUT例如Net Examix和CNN。第10节将E测试器与移动软件行业开发的其他BTTT工具进行了对比。第11节回顾了6年开发电子测试仪的经验教训。这些经验可以应用于开发工具，更一般地说，可以应用于研究中孵化出来的系统。本文的贡献如下：• 它提出了在6年的行业互动过程中收集的行业要求。这些要求提出了有趣的科学和工程挑战。我们设法解决了所有需求，除了一个：使细粒度的BTDT无缝工作，而不需要先验的功耗建模。• 它展示了我们对E教授所做的重大设计更改并证明他们在满足要求方面的能力-的部分。• 它描述了一种新颖的测试方法，用于获得高度可重复的电池消耗测量，即使是短时间的测试运行和一个基于遗传算法的算法，设置高可靠性电池消耗回归警报。• 它提供了相关的经验教训，有助于系统研究者谁关心他们的研究原型在现实世界中的采用• 我们有开源的电子测试器，使开发人员能够编写电池效率软 件 ， 并 促 进 进 一 步 的 研 究 。 测 试 器 源 代 码 可 在https://bitbucket.org/mobileenerlytics/etester/下载。2原型我们最初的BTDT设计基本上是一个2.1能源配置基础知识能量分布已得到充分研究[3，8，24，30，36，39，55]。在操作上，分析应用程序的电池消耗， 应用程序运行包括三个任务：（1）在应用程序运行期间，跟踪应用程序活动，例如，以不同粒度（例如方法、线程和进程）调用软件模块，类似于在常规性能分析器（例如GPROF [10]）中，通过源代码插装（instrumentation）或通过执行堆栈的运行时采样，以及通过记录每个线程/每个进程执行的上下文切换。(2)跟踪电源事件，如电话组件使用情况，通过记录所有图1：Eprof架构和开发人员工作流程。每个手机组件的电源事件，通常通过操作系统导出的日志记录工具，如Android中的atrace。(3)在计算机处理中，通过映射进行能量核算。电池消耗由于电源事件到应用程序活动，使用电源模型。功率模型是数学函数，用于捕获触发电话组件使用的功率事件与所产生的组件功率消耗之间的相关性。对于每个移动终端模型，模型需要被导出为流水线，通常使用微基准使用功率模型，通过以下方式将应用运行的总电池消耗归因于各个软件模块：（i）将每个电话组件的功率事件馈送到其功率模型以估计组件功率消耗，以及（ii）遵循在步骤⑴和（2）中导出的功率事件-应用活动映射将功率消耗以及因此电池消耗映射回软件模块2.2Eprof实施图1显示了E prof的体系结构和开发人员工作流程。EPROF是作为IDE插件开发的，带有按钮来选择待测应用程序（AUT），以及启动和停止profiling。开发人员通过USB将她的笔记本电脑与一部已使用自定义Android内核进行root和扩展的手机连接，然后单击开始配置按钮。自定义的Android内核是用允许跟踪系统调用的标记编译的。在开始分析时，EPROF在笔记本电脑上分叉了三个记录器，通过USB连接从手机上捕获跟踪：（1）atrace记录器，用于记录CPU频率变化，线程级上下文切换，GPU频率和状态变化;（2）使用systemtap的网络系统调用记录器[63];以及（3）使用Android的traceview的AUT方法记录器当用户在电话上与AUT当开发人员完成测试时，她点击停止配置按钮。E PROF处理捕获的轨迹，以按照第2.1节中针对CPU、GPU、WiFi和LTE描述的步骤（3）执行能量核算。开发适用于移动行业的电池耗尽测试和诊断工具2022年1月31日至2月4日，美国路易斯安那州新奥尔良市，8063移动行业要求通过与移动软件行业的主要参与者合作，我们开始了将我们的学术专业人士转变为可用工具的旅程。 我们的目标是了解电池消耗测试和诊断的重要性，了解现有的行业实践，并收集行业要求，以改善我们的BTDT原型。 其中一些互动是匿名的，因为它们是根据保密协议完成的。3.1手机行业中的电池耗尽测试和从我们与移动软件供应商的互动中，我们了解到电池消耗测试实践存在重大差异。(1) 无测试。我们开始与小型应用程序开发人员进行互动，他们的团队只有一两个工程师。我们很快了解到，这些开发人员专注于通过添加病毒式应用功能来使他们的应用程序流行。电池效率不是他们的主要目标;他们没有任何设置来测试他们的应用程序的电池消耗接下来，我们将业务重点放在热门应用程序开发商和OEM供应商上。我们了解到一些流行应用程序的开发人员也没有电池消耗测试设置，因为用户每天在应用程序上花费的平均时间不到5分钟;他们的大多数用户使用的是桌面版本的产品。热门游戏应用程序开发人员告诉我们，他们的用户希望应用程序流失 很多电池，而玩游戏，因此他们几乎没有收到任何投诉电池流失。他们只是优化了他们的应用程序的CPU和GPU资源消耗，以确保游戏保持响应，但没有任何设置来测试电池消耗。除了这些例外，行业的其他部分都有电池优化设置。(2) 黑盒测试，无诊断。许多供应商已经建立了内部的，通常是基本的，电池消耗测试和偶尔的诊断设置，以防止尴尬的电池消耗问题。例如，两个流行的音乐流媒体应用程序让测试设备整夜播放音乐，并在第二天早上人工检查电池电量下降。Brave Browser [54]构建了BatteryLab [33]，将测试设备与Monsoon电源监视器[1]连接，并允许在运行自动测试时测量手机电池总电量。两个主要的手机OEM有一个类似的设置，在他们的设备上运行的Android框架上运行电池消耗回归测试。这种“黑盒”测试不能提供对电池消耗差异的根本原因的任何洞察。事实上，如果测试显示新软件版本比以前的版本消耗更多的电池，整个开发团队将进入“战斗”模式，以特定的表1：可用电池耗尽测试和诊断工具的行业要求。要求供应商类型感知严重程度测试设置S1：自动化测试音乐流媒体应用程序，社交网络-work应用程序关键S2：运行对未改进的装置音乐流媒体应用程序，移动云检测公司重要S3： 没有 第一，ori功率建模热门OEM重要可用性U1： 短测试运行音乐流媒体app重要U2： 长的测试运行位置智能-gence app关键U3：可操作见解移动云测试-ING公司期望保真度F1：准确浏览器app关键F2：高-fidelity警报社交网络app关键自上次测试以来，代码出现了变化。这有时会延迟应用程序的发布。(3)诊断，没有测试。Face-book上的电池耗尽诊断是使用电池数据库完成的[55]。要使用Battery Toolkit，开发人员需要手动使用库调用对其应用进行插装，然后发布应用。当此应用在野外设备上运行时，库将根据插装收集资源使用信息。这种设置能够在新版本推出给初始用户后捕获几次电池退化-这是应用程序供应商的常见做法。然而，这些回归在影响初始用户集后被捕获3.2行业对BTDT的我们向移动软件开发人员展示了我们的学术原型EPROF，并收集了他们的需求。表1总结了需求，分为三类该表进一步显示了每项需求的供应商，这些供应商对需求和感知的严重性级别最为关注。在这三个严重性级别中，如果大多数用户不支持，则“关键”要求是一个显示停止器，如果不支持，则“重要”要求会对某些用户的使用决策产生负面影响，并且强烈首选“期望”要求，但用户仍然会使用没有它的BTDT。3.2.1设置要求。第一组需求都与工具的设置有关，如果不支持，其中一些被开发人员视为2022年1月31日至2月4日，美国路易斯安那州新奥尔良市，Abhilash Jindal和Y.胡志明807S1：自动化测试。大多数开发团队没有专门的电池团队，因此运行手动能量配置，例如在EPROF中，会破坏开发人员的工作流程。出于这个原因，缺乏对测试自动化的支持被大多数对测试其软件的电池消耗感兴趣的供应商认为是一个特别是，BTDT工具需要支持通过自动化用户交互脚本测量电池消耗。这些自动化脚本可以是黑盒测试，因为应用程序开发人员无法访问竞争对手应用程序S2：在未修改的设备上安装 E PROF需要root访问权限和自定义内核来记录系统调用和其他电源事件触发器。这些权限可以通过root手机和安装自定义内核来授予然而，受欢迎的OEM由于安全原因拒绝与我们分享他们的设备内核。他们还禁止我们对他们的测试设备进行root操作，因为一些内核进程不能在root设备上运行，因此对root设备的电池消耗测量可能不可靠。 一些应用程序开发人员担心生根他们的设备，因为生根无效的设备保修，如果没有正确完成可以“砖”的设备，即，对设备造成不可修复的损坏，使得设备甚至无法启动。 其他应用程序开发人员，特别是开发Facebook等企业应用程序的开发人员，对他们的测试设备很满意。这提出了一个重要的要求，即BTDT工具需要在未修改的设备上运行。S3：无先验功耗建模。EPROF可以支持各种设备，但需要访问设备，绕过电池连接Monsoon电源监视器，并运行广泛的微基准测试来创建每个组件的电源模型。然而，原始设备制造商通常需要测试尚未发布到市场的新设备，因此无法首先将它们提供给我们，这是创建EPROF使用的功率模型所需的。E试验酯U2：长时间测试。还应该可以运行长时间测试来测试后台电池消耗行为，并测试在支持长时间用户交互（如观看电影）时的电池消耗。这在E prof中是不可能的，因为它会生成太多的日志，例如， 以6Mbps的速率观看Youtube视频。由于测试后台活动是许多应用程序和OEM感兴趣的，因此此要求被视为至关重要。U3：可操作的见解。EPROF将应用程序进程的总能量消耗计入其Java方法调用。在与开发人员交谈时，我们发现这种“教科书”式的能源核算方法通常不足以提供可操作的见解，原因如下：（1）无法有效地对手机组件（如屏幕和硬件解码器）进行方法上的能源分解;(2)主要的电池消耗方法通常是Android框架或第三方库方法，使得应用程序开发人员无法操作方法方面的故障;（3）不是用Java编写的软件，例如React Native应用程序和内核工作程序，无法从EPROF系统问题和应用程序开发人员调试应用程序与系统服务的交互[2]无法从一个应用程序的方法智能能量分解中获得太多见解因此，输出可以简化或自动化调试新应用版本的电池消耗尖峰的过程的可操作见解的能力被认为是BTDT工具的高度期望的特征。3.2.3测试输出的保真度要求。第三组要求与工具的可靠性有关F1：准确。为了生成高精度测试和诊断输出，BTDT工具需要输出相对于真实测量值的高度准确的电池消耗估计值。这被所有类型的供应商视为BTDT工具因此，需要进行电池消耗估计，并考虑我们无法访问的设备，以创建其功率模型。这一要求对OEM供应商至关重要，但对应用供应商来说并不重要，因为应用供应商通常会在一些代表性手机上测试应用电池消耗，例如， 从最近几代手机。3.2.2可用性要求。 第二组要求与BTDT 工 具 的可用性有关。U1：短期测试运行。应该可以在应用程序中测试单个用户的流量，例如，在IM应用程序中搜索朋友并向朋友发送语音消息，这甚至可能不会产生1%的电池电量下降。短测试运行允许快速连续测试，并有助于将电池耗尽问题直接提交给负责该用户流程的团队领导。许多复杂应用程序的供应商和OEM（通常涉及大型开发团队）都认为这一要求很重要大型开发团队中的较小团队通常负责单独模块的开发和测试。F2：高保真警报。由于大多数开发团队没有专门的电池团队，因此每当最新的代码更改导致电池消耗激增时，BTDT工具必须生成警报。这些警报必须具有高可靠性，以使开发人员对其保持信心。如果警报有许多误报，开发人员将开始忽略它们，使测试设置无效[18]。如果警报有许多假阴性，那么电池耗尽问题将蔓延到发布中，再次使测试设置无效。出于这个原因，所有供应商类型都将生成高可靠性警报的能力视为一项关键要求。我们注意到F1之间微妙但重要的差异和F2。F1是关于特定测试运行的准确性，即BTDT工具应报告准确的电池消耗profiling结果然而，即使BTDT对于每次测试运行都是准确的，电池消耗也可能在不同的测试运行中有所不同，因为它受到许多因素的影响（参见§6.2）。因此，F2是（1）关于可重复性，即，如何减少测试运行中电池消耗结果的变化，以及（2）关于处理不可重复的行为，即，自信地开发适用于移动行业的电池耗尽测试和诊断工具2022年1月31日至2月4日，美国路易斯安那州新奥尔良市，8081.编写电池测试电池测试测试@测试库public void testCase（.. ）的情况下，bdTool.startMeasure（.. ）的情况下;} bdTool.stopMeasure（.. ）的情况下;2.开始电池测试表2：使用标准Android界面的eTester全系统记录器开发商图2：eTester架构和开发人员工作-流程图。即使是相同的测试运行导致电池耗尽时，电池尖峰的标记也可能彼此不同为了满足上述要求，我们对EPROF进行了一些重大更改，并将其转换为新的BTDT解决方案ETestESTER。我们将在以下章节中详细讨论这些设计变更。4设置改进下面我们将介绍解决这些设置要求的挑战和方法。S1：自动化测试。为了支持测试自动化，我们完全修改了E prof的IDE插件架构，使ETEST与持续集成（CI）平台无缝集成，如图2所示。这个新的体系结构通过以下步骤工作。(1) 编写电池测试。开发人员首先使用标准Android测试库编写自动电池消耗测试：使用Espresso [43]进行白盒测试，使用UI Automator或Robotium [62]进行黑盒测试。需要测量电池消耗的任务包含由ETestESTER测试库提供的两种简单方法：startMeasure和stopMeasure。为了测试背侧的电池消耗，地面任务，自动化测试可以只是休眠一段时间，等待后台任务发生，或者模拟触发后台活动的外部事件，例如，发送电子邮件到被测设备(2) 开始电池测试。提交电池耗尽测试后，CI设置（如Jenkins）根据定义的节奏在连接的测试设备上运行这些测试通过CI设置，例如(3) 收集日志。当测试执行到达startMeasure方法调用时，ETestESTER测试库将向安装在测试设备上的ETestESTER应用程序发送IPC消息。电子测试仪应用程序开始捕获日志并将其写入设备当测试执行到达stopMeasure方法调用时，测试库将另一条IPC消息发送到E测试仪应用程序以停止记录。(4) 上 传 日 志 进 行 处 理 。 当 所 有 测 试 完 成 后 ，ETestESTERCI插件会使用REST API将设备上的所有日志上传到ETestESTER服务器(5) 处理日志。电子测试服务器以类似于能量分析器（§2.1）的方式处理加载的日志，以计算每个组件的瞬时功耗。我们的新型高可靠性警报生成算法（§6.2.3）进一步比较了测试运行的电池消耗与用户设置的参考测试运行的电池消耗，例如，先前的应用程序版本或竞争对手的应用程序，并且如果电池消耗率高于阈值，则(6) 可视化和诊断电池消耗增加。开发人员可以登录到电子测试仪仪表板，以可视化和诊断电池消耗测量结果。S2：在未修改的设备上安装。E教授要求在测试设备上安装一个自定义内核，因为它使用非标准接口（如systemtap）来提取日志。 为了让ETESTER在没有自定义内核的设备上运行，我们决定只使用标准的Android接口，这些接口不需要安装自定义内核，如表2所示。 我们必须对E PROF进行重大修改，以实现这一过渡，例如，使用基于分组的网络功率估计而不是基于系统调用的估计。这消除了自定义内核的要求，但仍然要求我们根设备这是因为应用程序，包括电子测试应用程序，不允许记录数据从这些标准接口中的一些没有根手机。然而，我们观察到这些日志可以通过Android Debug Bridge（adb）读取，后者作为特殊的Linux用户调试运行。此调试用户的权限高于通过Google Play商店安装的应用，但低于root用户。因此，为了进一步消除root需求，我们发布了一个独立的Java应用程序来执行日志记录，作为ETestESTER应用程序的替代方案，它可以直接推送到测试设备并作为调试用户运行。在目前的Android系统中，这一...dalone Java应用程序只能支持有限数量的硬件组件，如CPU，屏幕，GPS，WiFi和LTE。 这是因为对于一些电话组件，例如，CI Master测试装置6. 可视化和诊断电池消耗增加3.收集日志测试仪应CI插件服务器、仪表板5. 流程日志詹金斯4.上传日志进行处理服务器接口测井目的阿特拉切CPU、GPU和硬件解码器功耗估计;线程级CPU能耗核算从上下文切换PS中标识进程和线程名的它们的id屏幕记录屏幕功率估计;相关功率带有屏幕更新的tcpdump网络功率估计;套接字级网络功能核算logcat将电源时间轴与系统日志相dumpsysGPS功率估计;将功率时间线与系统事件（如警报、定位）相关联，请求和唤醒锁strace将电源时间轴与系统调用相2022年1月31日至2月4日，美国路易斯安那州新奥尔良市，Abhilash Jindal和Y.胡志明809GPU和硬件解码器，甚至调试用户不允许读取他们的日志。这些日志不受Android的控制，并且由OEM以具有分散权限模型的分散方式进行记录。S2：因此，未修改设备上的插件只能在有限的范围内完成;要从测试程序中提取完整的功能，开发人员仍然需要root他们的设备。要在未经修改的手机上实现完整的电子测试器功能，需要Android生态系统进一步的日志标准化和强制执行，这也是AndroidPerfetto的目标[47]。最后，S3：无先验功耗建模仍然是E测试中未解决的挑战。5可用性改进U1：短期测试运行。通过§4中描述的测试自动化和eTest中的细粒度能量会计，自然可以满足这一要求。接下来我们讨论测试人员解决剩下的两个可用性需求的方法。U2：长时间测试。 为了减少生成的日志的大小，我们对E prof记录器进行了两个主要更改：（1）记录低分辨率的屏幕视频，以及（2）优化读取atrace。atrace是一个环形缓冲器，用于保存系统事件的跟踪，例如上下文切换和CPU/GPU频率变化。我们观察到，来自atrace中线程级上下文切换的日志是E prof生成的大日志的主要贡献者。为了减少日志大小，我们在将日志写入SDCard之前对日志执行修剪和压缩我们将记录器更改为使用现代智能手机上可用的多个CPU内核 测试人员启动一个读取器线程，从atrace读取日志，并启动（核心数-1）写入器线程，在将日志写入SD卡之前压缩和修剪日志。读线程和写线程之间的协调使用这些机制，ETESTER生成的日志比E prof少6倍，这允许更长时间的运行测试。测试器还允许有选择地禁用组件的日志记录，例如网络和屏幕，以进一步减少生成的日志的大小。U3：可操作的见解。正如第3.2.2节中所讨论的，E教授我们在E测试中增强了可操作的洞察力，这是因为我们发现，现代应用程序严重依赖于移动操作系统提供的系统服务，而框架的电池消耗无法通过方法级能量会计因此，我们将eTester的可操作洞察设计重点放在将系统范围的事件与每个组件的功耗相关联上，如图3所示。(1)测试仪输出显示与记录的屏幕视频同步的每个电话组件的功耗时间轴、来自logcat的系统日志、来自strace的系统呼叫日志以及来自Batterystats的系统事件，其中包括电话呼叫和音频回放等事件。这使得去噪器能够轻松地识别图3：eTester的可操作见解：（1）与每个组件功耗时间表相关的各种系统事件;（2）每个线程和每个插槽功耗时间表。时间轴。(2) 测试仪还显示所有组件的每个进程功耗、每个线程CPU功耗和每个插槽网络功耗，以进一步了解系统功耗。总之，e Tester中的这些系统范围的电源诊断功能已经证明可以成功地发现流行应用程序中的错误，我们将在第8节中看到。我们承认，额外的诊断功能，例如， 那些专门用于其他主要手机组件，如无线网卡或OLED显示屏，可以开发，我们继续发展电子测试，以产生更多的可操作的输出。6提高忠诚6.1准确的电池消耗估计E PROFdesign的优势之一是使用测试设备的精确组件功率模型（§2）获得的高电池消耗估计精度。 E测试仪通过保留相同的能量核算设计继承了这种高电池消耗估计精度，以满足F1：Accurate。然而，E PROF只支持文献中常见的有限 数量的组件 ，包括CPU ，GPU ， GPS和WiFi/4GNIC。 ETESTER通过包括OLED和硬件解码器两个额外的组件，将耗电组件的覆盖范围扩展到整个手机，这两个组件对建模具有挑战性。1我们开发了一种精确的OLED功率模型，其显著提高了现有技术的基于线性回归的OLED功率模型的准确性[6，17，20]。我们的新模型将RGB颜色空间划分为更小的子空间，并分别为它们开发基于线性回归的功率模型。由此产生的新模型可以估计OLED显示器的功耗仅为地面真实值的3.3%，由季风功率监视器测量，在Nexus 6和Pixel 2上显示一组100张不同的图像1E测试仪还模拟了LCD显示屏的能量消耗，这在现代手机中已经变得不那么常见了开发适用于移动行业的电池耗尽测试和诊断工具2022年1月31日至2月4日，美国路易斯安那州新奥尔良市，810我们亦为ETester增加了广泛用于视频流应用程序的硬件解码器的精确、细粒度功耗建模和电池消耗核算。我们仔细分析了atrace日志中与硬件解码器相关的所有事件的时序以及功率监视器读数中功率变化的时序，发现MDSS（移动显示子系统）事件与功率读数中的峰值之间存在很强的相关性。 然后，我们使用MDSS事件作为功率事件，用于硬件解码器的功率模型推导和使用。据我们所知，这是智能手机硬件解码器的第一个已知经验功率模型该模型实现了较低的平均估计误差为5.0%时相比，季风功率监视器读数作为地面实况重播下载 的 YouTube 视 频 的 不 同 分 辨 率 ， 包 括 1080p ， 720p ，480p，360p，240p和144p的像素2。6.2高保真警报生成F2：高保真警报的行业要求通常与支持U1：短测试运行不一致。这是因为短测试具有较小的噪声衰减范围，并且由于总电池消耗较小而倾向于具有较大的相对变化。为了使测量具有高度的可重复性，我们首先列举了电池耗尽测试设置出现变化的原因，然后在我们的新型测试方法中解决了这些问题。然后我们开发了一种基于神经网络的算法，该算法使用通过测试方法收集的电池消耗估计值进行比较测试运行与用户确认的参考测试运行，例如，他们的软件或竞争对手的软件的最新版本6.2.1可重复电池耗尽测试的挑战。移动软件的可重复电池消耗测试是令人担忧的，因为电池消耗受许多因素的影响，这些因素在不同的测试运行之间可能会有所不同。我们将这些因素分为三大类：手机内部变化。现代电话是建立在先进的硬件和运行全边缘分时操作系统。因此，移动软件的行为及其电池消耗可能会受到与其他进程、操作系统和硬件的复杂交互的影响。（1）后台应用程序和系统进程可能会导致手机的总功耗;（2）CPU调度程序可以将相同的线程分配给不同大小（大/小）的核心，这些核心在不同的运行中以不同的频率运行;（3）高温可能会导致CPU功率增加高达15%，同时在相同的频率下运行，并可能导致热节流[64]。电话外部变化。流行的移动应用程序通过丰富的UI与用户交互，并通过网络与远程服务器交互。因此，它们的电池消耗可能会受到几种外部条件的影响。（1）用户交互变化导致不同的应用执行行为;（2）无线信号强度影响网络的延迟和带宽数据传输，并因此导致无线NIC汲取不同幅度的功率并持续不同的持续时间;以及（3）服务器/网络等待时间和带宽变化可以改变应用行为，例如，触发视频流应用中的自适应比特率（ABR）以切换到较低的视频比特率。应用程序状态。移动软件很复杂，通常包含导致不可重复执行的功能和内部优化这种执行变化可能导致电池消耗变化。（1）不同的启动状态触发不同的应用行为，例如，如果网页不在高速缓存中，则浏览器必须从网络下载实际网页，但是如果存在，则可以简单地从高速缓存使用它;（2）A/B测试可能导致相同的应用程序二进制文件表现出不同的行为;以及（3）广告本质上可以是动态的;显示和下载动态内容可能导致电池消耗在测试运行中变化。6.2.2解决电池测量变化的来源。ETESTER自动处理来自手机内部条件以及一些手机外部条件和应用程序状态的变化。• ETESTER中的细粒度能量会计，E教授，准确地计算了电话蝙蝠的部分电池消耗，这是由于每个进程和线程在测试中，因此可以消除电池消耗，由于后台应用程序，包括电子测试应用程序本身和系统进程。• 电子测试仪应用程序监控手机温度，并确保它在每次测试运行之前处于正常温度，以避免由于热效应而导致的变化• 为了确保在不同的测试运行中保持一致的用户交互，eTester支持自动化测试。• E测试人员在每次测试运行前自动清理应用缓存，以确保相同的启动状态。为了控制剩余的变化来源，我们建议QA工程师遵循其他测试指南：• 稳定外部条件。 对于使用网络的测试，将测试手机放置在具有稳定无线信号强度（WiFi或蜂窝）的位置，如果可能，使用私人WiFi AP 我们进一步建议使用内部服务器或模拟服务器（例如，使用代理）来控制服务器响应时间。• 控制应用程序状态。负责电池排水试验应确保相同的A/B试验在多个测试运行中使用应用程序的版本。我们还建议使用无广告的应用程序版本，例如，使用高级帐户，以消除由于广告而导致的电池消耗变化。• 重复测试运行。 建议CI设置为确保每个测试至少进行5次。这样做是为了解决无法控制的变化，例如来自CPU调度程序的变化。6.2.3生成高保真电池耗尽尖峰警报。在解决了变化的来源之后，我们收到了5个或更多2022年1月31日至2月4日，美国路易斯安那州新奥尔良市，Abhilash Jindal和Y.胡志明811BR每次测试运行的电池消耗测量 为了生成测试运行的警报，我们需要找出该测试运行的平均电池消耗与用户设置的参考测试运行的平均电池消耗的比率，例如，他们的软件或竞争对手的软件的最新版本。简单地取各个测量值的平均值，然后取这两个平均值的比率是不合理的，因为它没有考虑测量值中的方差和样本数量。为高度确信地计算此比率，我们采用以统计为基础的方法。我们将测试运行的电池消耗表示为B，将参考测试运行的电池消耗表示为R。我们进一步假设B和R都是正态分布随机变量，即，B<$N（μB，σ2）和R<$N（μR，σ2），电池消耗测量值是这些分布的样本。我们需要找到μB/μR比值，如果该比值大于用户定义的阈值τ，则生成警报。由于我们不知道实际的B和R分布，因此确定μB/μR的比值具有挑战性;我们只能访问样本。此外，B和R可能具有不相等的样本数量，因为测试运行可能会崩溃，或者用户可能会重新配置每个测试用例运行的次数。 B和R也可能具有不等的平均值和不等的方差，因为它们是独立测量的，并且是相同软件或两个完全不同软件的不同代码版本的据我们所知，没有直接的数学表达式来估计两个正态分布样本的平均值之比。为了判断是否生成警报并估计精确的比率μB/μR，我们开发了一种新的迭代算法。该算法使用Welcht检验表示为P（X > Y）≥ 0。95个验证具有95%的置信度，即X的平均值大于Y的平均值。测试可以对来自两个正态分布的样本进行操作;实际分布是未知的。我们的算法采用阈值τ和置信水平α作为输入。首先使用Welch t检验确定P（B > τ R）≥α。为了建立这个t检验，我们简单地将来自R的样本相乘：R1，R2，. 因为R是正态分布的，所以τR也是正态分布的。如果t检验失败，则不生成警报;否则生成警报，包含精确的比率μB/μR，以通知用户电池消耗尖峰。该精确比率计算如下。首先，算法从τ开始重复地将hi加倍，直到（P >hi·R）≥α失败。这给出了t检验成功的比率hi/2和t检验失败的比率hi。接下来，在hi/2和hi之间进行二分搜索，以找到满足给定置信水平α的t检验的最高比率γ，即， P（B> γR）≥ α。 这个γ给出了μB/μR的精确比值。总而言之，E测试员首先进行电池消耗测量-在短期测试运行中，仔细地减轻变化的来源，然后使用基于遗传算法的算法生成高可靠性警报7验证在测试器设计中，我们已经解决了§3中概述的所有行业要求，除了S3：没有先验功耗建模。 在本节中，我们评估了测试仪的定量保证：电池消耗测量的准确性和可重复性。我们省略了开销评估，因为ETESTER执行精确的细粒度能源核算，并且可以准确地隔离和删除由于其本身2而产生的能源开销。 我们使用6种常见测试场景对4种流行的预安装Google应用程序进行评估，如表3所示。所有测试场景都消耗OLED屏幕上的电量，来自YouTube应用程序的2个视频播放测试场景也驱动硬件解码器。 所有测试均使用使用UIAutomator编写的自动化脚本执行，每次运行5次，共运行30次。在每次测试运行之前，测试人员都会清除本地设备缓存。在Youtube的情况下，我们的自动测试也会在每次测试运行之前清除保存的用户帐户历史记录，我们使用高级帐户来禁用广告。测试是在Nexus 6手机上进行的，该手机连接到稳定的WiFi连接，屏幕亮度水平固定为38%;亮度水平是根据我们室内环境的Android自适应屏幕亮度选择的7.1精度为了测量给定测试持续时间内的电池消耗误差，我们将总估计电池消耗与持续时间内的真实电池消耗进行比较。总估计电池消耗量是通过在持续时间内对来自测试仪的瞬时功率估计进行积分来获得的，而地面真实电池消耗量是通过对来自内置电流传感器的功率读数进行积分来获得的（使用Android功率传感器API，其在Nexus6上具有170 ms的采样分辨率）。我们首先评估30次测试运行的端到端能量误差。我们发现，所有30次运行的端到端能量误差均小于6.5%。表3显示了6个测试场景的平均端到端错误。我们进一步评估了e测试器的细粒度能量估计误差。由于E测试人员使用准确的功率模型来估计所有主要电话组件的功耗，并且由于E测试人员日志记录这些组件的所有功率事件（见表2），E测试人员可以估计电话组件的瞬时功耗。以量取之，粒度能量估计误差，我们选择2秒作为时间粒度，因为我们从与开发者的交互中了解到，他们很少关心调试持续小于2秒的功率尖峰。我们发现，对于测试仪感兴趣的时间粒度（2秒），内置电流传感器报告的能量与季风功率监视器报告的能量非常相似因此，我们使用内置电流传感器进行细粒度精度测试。我们还添加了当前传感器读数沿侧E测试仪2因此，与我们互动的移动软件供应商通常认为电子测试的开销不是一个问题。开发适用于移动行业的电池耗尽测试和诊断工具2022年1月31日至2月4日，美国路易斯安那州新奥尔良市，812Σ表3：测试的应用程序、使用场景、准确性和可重复性指标列表，包括平均端到端错误、变异系数以及平均成对组件和线程曼哈顿距离（MD）。App测试场景测试时间-口粮平均期末数到端误差科厄齐埃变异组件MD线程MD谷歌 日历（6.0）导航，创建和