应用程序中的电池消耗：比较和清单

电池消耗是应用中用户满意度的最决定性因素之一。即使应用程序提供了价值，但如果它过度消耗能量，质量感知也会迅速下降。用户不仅仅通过百分比来衡量消耗，而是通过感觉来衡量：如果手机变热，如果充电提前结束，如果系统建议限制应用程序，所有这些都成为问题的征兆。因此，考虑电池并不是一个技术细节，而是产品的核心部分。

本指南从头到尾涵盖了该主题。您将了解什么真正消耗了能量，如何测量它，如何比较场景，如何识别代码中的罪魁祸首，要进行哪些权衡，以及如何创建可应用于任何团队的优化清单。重点是实用性，具有清晰的语言、比较表以及适用于本机和混合应用程序的良好实践。

为什么鼓是一个产品主题，而不仅仅是一个技术主题

在移动设备中，电池意味着使用时间和自由度。自主权越多，用户探索功能的次数越多，他们对应用程序的信任度越高，卸载的可能性就越小。这直接影响留存率、店内评价和转化。耗尽电池电量的应用程序不仅会失去用户，还会产生支持和声誉成本。

在许多情况下，电池问题被误认为是随机错误。应用程序变得缓慢，系统终止进程，通知停止到达，用户将责任归咎于应用程序。这些失败并不总是逻辑错误，而是应用程序优化不佳的症状。因此，无论谁主导产品，都需要将消耗视为质量指标，还有崩溃率和加载时间。

应用程序中真正消耗电池的是什么

电池不会因单一原因耗尽。实际上，它是一组因素的总和：CPU、GPU、网络、传感器、磁盘、位置、屏幕和后台进程。这些元素的组合创建了一个轻或重的应用程序。应用程序的 CPU 使用率可能很低，但保持屏幕活动并每隔几秒发送请求，这仍然会产生高消耗。

以下是主要反派：

CPU 持续使用，特别是在循环、密集解析和过度加密中。
GPU 和 UI 渲染带有大量动画和不必要的效果。
网络在短时间内活跃，频繁轮询或不必要的下载。
始终保持高精度定位。
蓝牙、NFC 和传感器在后台无条件运行。
唤醒锁长时间保持，防止设备休眠。
无策略的持续磁盘写入、日志和缓存。
通知配置不当，会一直唤醒应用程序。

任何组件使用的能量取决于使用时间和强度。同样的任务如果每小时执行一次可能会产生很小的影响，但如果每 5 秒执行一次就会产生巨大的影响。重点应始终是减少频率、减少持续时间和减少所做的工作。

衡量消费的基本概念

为了延长电池寿命，您需要对其进行测量。正确的用药可以避免猜测并节省时间。有四个概念有助于解释结果：

基线：无交互情况下应用程序的基本状态。待机功耗需要较低。如果应用程序即使停止时也消耗大量资源，则存在严重的后台问题。
爆发：特定任务期间的消耗高峰，例如上传、拍照或地图。峰值是可以接受的，但不能太长。
典型用途：最常见的用户流程。这是对感知影响最大的指标。
极端使用：有压力的场景，例如在网络较弱的情况下使用该应用程序1小时，同时使用视频和GPS。

如果没有这些点，您就无法比较版本或功能。理想的情况是始终使用相同的脚本并在相同的设备或等效设备上进行测试。

如何比较不同版本之间的电池消耗

比较电池消耗需要一致性。如果您在不同的日子、不同的亮度、不同的网络和运行的不同应用程序下进行测试，结果是无效的。因此，建立一个简单的比较协议：

相同的设备和相同的系统版本。
固定亮度和标准音量。
经济模式关闭。
后台应用程序已关闭。
受控网络，最好是稳定的 Wi-Fi。
相同的使用行程和时间。

使用此协议，您可以测量固定时间内（例如 30 分钟）内消耗的电池百分比。如果版本 A 消耗 5%，版本 B 消耗 8%，则差异是相关的。重要的是重复测试至少三次以减少噪音。

产品团队实用的电池指标

您并不总是能够测量瓦时，但有一些简单的指标可以帮助团队监控进度：

每分钟活跃使用消耗：标准流程中每分钟消耗的百分比。
每小时待机消耗：应用程序未打开时消耗的百分比。
电量达到 20% 的时间：电池电量降至 20% 之前的预计连续使用时间。
系统使用报告：iOS和Android显示每个应用程序的消耗；此列表后面指示应用程序是否显示在顶部。

这些指标允许您设定目标并监控回归。如果新功能增加了消耗，这一点就会变得明显。

不同资源类型的能源影响比较表

下表总结了应用程序中常见功能的相对影响。这些值不是绝对的，但它们有助于确定优先级。

资源	能源影响	观察	重要提示
高精度GPS	高	快速消耗电池	尽可能使用低精度
全屏视频	高	GPU 和持续活动的屏幕	降低帧速率和自动亮度
音频流	中等	比视频小，但恒定	智能缓存和自适应比特率
频繁的网络轮询	中到高	保持无线电活跃	迁移到推送和批处理
复杂的动画	中等	GPU 和 CPU	简化过渡
后台同步	中等	取决于数据量	安排和使用退避
推送通知	低音	如果配置正确	避免不必要地唤醒应用程序
传感器读数	变量	取决于传感器	不使用时关闭

该表并不取代实际测试，而是提供讨论优先级的基础。

快速诊断清单

在修改代码之前，请进行快速诊断以发现明显的问题。使用此清单：

即使应用程序未打开，它也会消耗电池吗？
是否有不必要的后台服务在运行？
该应用是否在系统消费排名中名列前茅？
设备在简单流动过程中是否会发热？
是否存在非常频繁且无正当理由的网络请求？
应用程序是否不必要地使屏幕保持活动状态？
该位置是否一直处于活动状态？
是否有过多的日志和不断写入磁盘？

如果你对几个问题的回答都是肯定的，那么高消费的可能性就很大。从那里，您可以选择要调查的工具。

Android 上测量消耗的工具

在 Android 上，有本机工具和外部工具。主要有：

电池历史记录：允许您分析每个进程的消耗并识别唤醒锁。非常适合后台调试。
Android Studio Profiler：实时显示CPU、内存和网络。帮助关联消耗和峰值。
adb dumpsys Batterystats：生成详细报告。它需要知识，但它是强大的。
系统设置：每个应用程序的消费列表很简单，但对于验证对真实用户的影响很有用。

电池历史记录器和分析器的组合通常足以满足大多数情况。

iOS 上测量消耗的工具

在 iOS 上，数据访问受到更多限制，但仍然有不错的选择：

仪器（能源日志）：显示能源、CPU 和 GPU 以及详细的时间线。
Xcode Metrics：分析测试中的网络、CPU 和能源使用情况。
iOS 上的电池报告：用户可以看到每个应用程序的消耗情况，并且您可以将其与类似应用程序进行比较。

iOS 上的关键是优化后台任务并避免滥用位置。

始终有效的优化原则

减少消耗有一些普遍原则。它们作为一般指南：

频率较低：每秒运行的所有内容都可以每分钟或更长时间运行。
较短的持续时间：任何任务都应该持续尽可能短的时间。
更少的工作：减少数据量、图像大小和布局复杂性。
竞争减少：并行任务可能会消耗超出必要的资源。
更少的唤醒：应用程序唤醒系统的次数越少越好。

这些原则适用于网络、CPU 和传感器。始终质疑任务的真正需要。

网络优化：最大的隐性收获

电网是最大的能源消耗之一。每次应用程序激活无线电发送或接收数据时，系统都会退出保存模式。这意味着小型、频繁的请求比大型、分组良好的请求花费更多。

良好做法：

批处理：将多个请求分组为单个提交。
缓存：避免重复下载相同的内容。
增量同步：仅发送差异，而不发送完整的对象。
使用退避重试：避免在不良网络中循环尝试。
压缩：减少有效负载大小。

生成结果的一个简单策略是降低同步频率并增加应用程序在后台时的间隔。

位置优化

位置是另一个恶棍。高精度GPS消耗很大。当物镜不需要精确坐标时，使用低精度。达到目标后立即关闭该位置也很重要。

方法示例：

对于交付应用程序，仅在交付过程中使用高精度。
对于新闻应用程序，仅在首次访问时使用位置。
对于健身应用程序，允许用户选择准确性级别。

另一种做法是使用地理围栏而不是不断更新。当应用程序使用适当的 API 时，系统会优化消耗。

CPU和渲染优化

CPU 持续使用并出现明显的消耗症状。不良循环、大 JSON、过度加密和大量动画是常见原因。

建议：

避免轮询循环。交换活动。
降低解析和中间对象的复杂性。
关闭背景动画。
避免在反应式框架中不必要的重新渲染。
对大型列表使用延迟加载。

当应用程序高效渲染时，用户会感觉设备更酷且响应更灵敏。

后台任务：危险领域

后台任务功能强大，但如果使用不慎，它们可能会损坏您的电池。理想的情况是使用系统的 API，它已经限制了频率和组执行。

在 Android 上，使用 WorkManager 和 JobScheduler。在 iOS 上，使用后台任务和静默推送。避免启动持续的服务，特别是当用户看不到立即的好处时。

经验法则：如果用户没有明确请求任务，则该任务不应在后台高频率运行。

常见情况：聊天和通知

当使用配置不当的持久连接时，聊天应用程序往往会消耗电池。解决方案几乎总是使用推送通知，并且仅在用户处于活动状态时打开连接。

减少消耗：

使用推送通知而不是轮询。
避免让套接字在后台保持活动状态。
调整连接心跳。
当应用程序在后台时暂停更新。

这些措施在不影响体验的情况下减少了消耗。

常见情况：无限源和社交网络

无限滚动的提要会产生消耗，因为它们会发出持续的请求、加载大图像并在滚动期间保持处理器处于活动状态。

良好做法：

上传合适尺寸的图像。
使用轻量级占位符。
仅预取部分内容。
限制滚动动画。

这可以防止应用程序在长时间会话期间消耗能量。

常见案例：视频应用

视频是最重的负载之一。即便如此，仍有可能的优化：

动态比特率调整。
当用户不交互时帧速率降低。
关闭额外的视觉效果。
允许离线下载，减少网络使用。

这些策略有助于平衡质量和电池寿命。

每层优化清单

使用此清单来检查您的分层应用程序。它可以帮助您快速识别高影响区域。

网络

请求是否分组？
是否有高效的缓存？
该应用程序是否可以防止频繁轮询？
有效负载是否被压缩？
是否有退避重试？
后台同步是否受到限制？

CPU和内存

是否存在频繁循环或不停顿的作业？
是否存在过多的 JSON 解析？
该应用程序是否避免了不必要的重新计算？
大型物体是否正确释放？
该应用程序是否可以防止泄漏，从而迫使系统更加努力地工作？

用户界面和 GPU

动画真的有必要吗？
是否存在过多的重新渲染？
图像是否经过优化？
转换简单吗？
应用程序是否避免不必要地保持屏幕处于活动状态？

传感器和硬件

GPS仅在必要时使用？
相机是否仅在使用时打开？
蓝牙和 NFC 在不活动时是否关闭？
是否不必要地使用了辅助传感器？

背景

系统是否安排后台任务？
该应用程序是否可以防止长时间唤醒锁定？
无声通知是否受到限制？
后台同步是否遵守适当的时间？

该清单可以合并到功能审查和质量检查中。

比较：轻型应用程序与重型应用程序

了解影响和比较的最佳方式。轻量级的应用并不意味着资源匮乏，而是意味着设备的使用更加智能。下面简单对比一下：

外观	轻量级应用	重型应用
同步	批量、较大间隔	持续轮询
地点	点播	永远在线
用户界面	简单的动画	复杂且持续的动画
图片	优化且响应迅速	未压缩的大图像
背景	计划任务	永远在线的服务
网络	缓存和增量	重复下载
经验	没有暖气	频繁加热

这种比较对于教育利益相关者和证明优化优先级的合理性很有用。

如何创建电池消耗目标

目标有助于团队保持专注。一个简单的方法和定义：

典型使用 30 分钟的最大消耗量。
后台每小时最大消耗量。
每小时唤醒锁限制。

这些目标因类别而异。地图应用程序自然比阅读应用程序花费更多。但即使在地图上，也存在可接受的限制。

将电池集成到开发周期中

为了确保持续改进，电池需要进入开发周期：

在构思期间：评估该功能的能源影响。
在设计中：避免不必要地保持屏幕打开的流程。
在实现中：使用高效的 API 并避免轮询。
在 QA 中：运行消耗脚本并与基线进行比较。
无发布：监控用户有关电池的反馈。

这可以减少回归并防止每个版本的消耗变得更糟。

如何处理电池权衡

降低电池电量并不总是有损失。一些常见的权衡：

降低图像质量以节省能源。
增加同步间隔并失去即时更新。
使用低精度定位并丢失细节。
减少动画并失去高级感。

产品的作用是决定哪种权衡有意义。在许多情况下，用户比视觉细节更喜欢更大的自主权。

最终发布清单

在发布之前，请使用此最终清单：

该应用程序不会出现在系统消耗的顶部。
使用后 30 分钟内消耗是典型的且可接受的。
背景消耗低。
没有长时间或过多的唤醒锁。
如果不使用，该位置将不会处于活动状态。
网络请求被分组。
该应用程序在正常流媒体期间不会升温。
内部反馈并不表明电池电量耗尽。

如果遵循此清单，出现实际问题的可能性就会大大降低。

如何在实验室和现场测量消耗量

仅在实验室中测量电池是有用的，但还不够。实际用户行为包括网络不稳定、亮度过高、多任务处理以及后台有数十个应用程序。理想的做法是将受控测试与生产中的信号收集相结合。在实验室中，您创造可重复性；在现场，您可以验证增益是否确实出现在现实生活中。两者共同带来了决定发布并避免回归的信心。

在实验室中，使用标准设备，配有校准电池和相同的初始状态。测试脚本需要详细、有明确的步骤和可测量的时间。在生产中，重点应该关注间接信号：使用时间、退货率、投诉以及系统的消耗排名。尽管您没有生产中的确切瓦时数，但总体行为很重要。如果发布后卸载率增加，并且一些用户抱怨电池，这将成为一个警告信号。

一种行之有效的做法是使用标准设备创建一个小型内部组。每个版本都会经过这个小组和一个简单的路线图。同时，团队观察商店中的支持数据和评论。这种交叉可以降低风险并加速学习。

带有脚本和结果表的测试方法

一个好的测试脚本需要反映真实的用户流程。如果应用程序用于送货，则行程需要包括搜索、地图、产品选择、支付和跟踪。如果应用程序是内容，则包括滚动、视频和共享。以下是标准 30 分钟行程的示例：

打开应用程序，登录并加载主页（5 分钟）。\n2.浏览 3 个主屏幕（5 分钟）。\n3.执行产品的核心操作（10 分钟）。\n4.执行辅助操作，例如共享或保存（5 分钟）。\n5.将应用程序留在后台（5 分钟）。

目标不仅仅是测量总消耗量，而是了解峰值在哪里。使用结果表来比较版本：

|版本 | 30分钟总消耗量| CPU秒杀|背景天气 |观察|\n| ---| ---| ---| ---| --- |\n| 1.4.0 | 7% | 65% 持续 2 分钟 | 5 分钟 |打开地图时出现峰值 |\n| 1.5.0 | 9% | 82% 持续 4 分钟 | 5 分钟 |新动画 |\n| 1.5.1 | 6% | 55% 持续 2 分钟 | 5 分钟 |优化缓存 |\n+ 有了这个表，就可以清楚某个功能是否恶化了消耗以及哪个部分需要调整。团队能够根据数据而不是意见做出决策。

如何解释 Battery Historian 和 Energy Log

诊断工具可能看起来很复杂，但其实并非如此。主要目标是确定应用程序何时阻止设备休眠，或者何时某个功能处于活动状态太长时间。在 Battery Historian 中，最重要的两条线是 wakelocks 和 jobs。如果存在许多长唤醒锁，则应用程序会强制 CPU 保持活动状态。如果顺序有很多作业，可能会出现过度同步的情况。

在 iOS 能源日志中，观察能源图和 CPU 峰值。如果即使应用程序处于后台，电源线仍保持高电平，则表示出现问题。另一个信号是网络使用时间。如果网络在后台处于活动状态，则值得检查同步策略。

不要试图立即解释所有内容。从两个问题开始：应用程序是否不必要地唤醒设备？当应用程序应该处于睡眠状态时，它却在后台处于活动状态？解决这个问题已经产生了很大的改进。

影响消耗和混淆测试的变量

有些变量可以在不改变应用程序的情况下改变结果。如果你不控制，你可能会得出错误的结论：

屏幕亮度：也是最大的消费者之一。调整并修复。\n- 网络：4G 和 3G 的使用量比 Wi-Fi 多。\n- 电池性能下降：旧设备消耗速度更快。\n- 环境温度：热量会降低电池效率。\n- 后台应用程序：干扰总消耗。\n 在得出回归的结论之前，请确保测试具有可比性。

混合和跨平台应用程序的优化

在 React Native、Flutter 和 WebView 等混合应用程序中，存在额外的层，可能会增加消耗。 JS 和 Native 之间的桥接使用效率低下可能会导致 CPU 过高。另一个风险是缺乏对重新渲染的关注，这在反应式框架中更为常见。

混合动力的良好做法：\n

避免高频率使用 setState。\n- 滚动和输入事件中的反跳。\n- 减少始终处于活动状态的侦听器。\n- 优化图像并减少阴影和模糊。\n- 当流程需要性能时使用本机组件。\n 即使在混合应用程序中，最大的收益通常来自减少网络和后台，而不是来自 UI 微优化。

第三方 SDK 和广告的影响

第三方 SDK 是消费的常见原因。分析、广告、推送和反欺诈 SDK 可以为团队添加后台任务、持久连接和隐形网络调用。如果应用程序无缘无故变得沉重，请检查 SDK。检查哪些运行定期作业以及哪些使服务保持活动状态。

推荐的做法是隔离 SDK，并在使用和不使用 SDK 的情况下测量消耗情况。如果 SDK 消耗过多，请评估替代方案或调整设置。在广告中，减少横幅刷新并选择不需要持续联网的格式。在分析中，批量聚合事件以减少请求。

生产监控策略

在生产中，您无法完全访问功率指标，但可以监视间接信号。一些示例：\n

发布后的卸载率。\n- 提及电池或加热的评论。\n- 放弃之前的平均会话时间。\n- 应用打开的频率。\n- 启用经济模式的用户百分比。\n 将这些信号与内部日志进行匹配。如果会话时间下降并且支持人员收到电池投诉，则表明存在明显的退化迹象。这些信号使您能够快速调整，而无需等待数周。

产品清单以及与用户的沟通

并非所有优化都是看不见的。在某些情况下，用户需要了解为什么某个功能需要位置权限或为什么任务在后台运行。当应用程序解释得很好时，用户就能更好地容忍消费。因此，产品团队必须审查：\n

采用清晰语言的权限文本。\n- 当繁重的任务处于活动状态时发出警告。\n- 限制消耗的选项，例如经济模式。\n- 说明应用为何使用位置。\n 这种沟通减少了投诉并提高了用户的控制感。

减少电池消耗的 30 天行动计划

如果应用程序消耗量很大，行动计划有助于组织工作。 30 天计划的示例:\n

第 1 周：测量基线，确定前 3 个原因，创建测试脚本。\n- 第 2 周：优化网络和后台，减少轮询，实施缓存。\n- 第 3 周：检查位置和传感器的使用情况，调整准确性。\n- 第 4 周：优化 UI 和图像，重新评估 SDK，比较结果。\n 最后，重复脚本并将其与基线进行比较。这创造了一个持续改进的循环。

审查 PR 和新功能的问题

为了避免回归，请在每次评论中包含简单的问题：\n

此功能是否会产生额外的请求？以什么频率？\n- 它取决于位置或传感器吗？精确度如何？\n- 它在后台运行吗？每隔什么时间间隔？\n- 此功能是否添加大量动画？\n- 是否添加新的 SDK？他们从事什么工作？\n 此预防性检查清单可以在问题到达用户之前防止问题发生。

操作系统如何节能

了解系统策略有助于您创建更高效的应用程序。在 Android 上，存在 Doze 和 App Standby 等模式，这些模式会在设备停止或长时间不使用应用程序时限制后台活动。在 iOS 上，后台任务受到限制并且在较短的窗口中运行。如果应用程序试图逃避这些规则，系统可能会限制或终止进程，这会造成不稳定。

在 Android 上，应用程序被放置在使用“存储桶”中（活动、工作集、频繁、罕见）。用户使用的次数越多，应用程序的自由度就越大。如果应用程序在活动较少的存储桶中尝试运行频繁的作业，系统可能会延迟或阻止，这会浪费电池寿命，而没有真正的好处。因此，根据用户优先级规划作业至关重要。

在 iOS 上，如果应用程序尝试在后台保持任务不变，系统可能会降低应用程序的优先级或暂停该应用程序。正确的策略不是试图避免这种情况，而是使应用程序与系统的预期行为保持一致。

按功能划分的能源预算

与利益相关者讨论电池并按功能创建能源预算的实用方法。将其视为财务预算：每个功能都有可接受的能量限制。这有助于确定优化的优先级，并防止新功能损害整个应用程序。

引用示例：\n

馈送和阅读：低消耗。\n- 地图和路线：中到高消耗。\n- 视频和流媒体：高消耗，但集中。\n- 后台同步：低消耗，但连续。\n 在定义此预算时，团队明确表示并非所有功能都可以消耗相同水平的能源。这会形成纪律并防止消费随着时间的推移而升级。

消耗电池电量的常见反模式

几乎所有应用程序都会重复出现一些错误。识别这些反模式可以加速改进：\n

每隔几秒轮询一次以更新数据。\n- 即使没有交互也循环动画。\n- 即使用户几天没有打开应用程序也会运行后台作业。\n- 同时同步多个模块。\n- 包含大量内容的 WebView，在不受控制的情况下运行脚本。\n- 生产中的永久调试日志。\n- 上传照片而不压缩。\n- 仅当部分更改时重新加载完整数据。\n 避免这些错误可以立即带来收益，而无需进行重大重构。

建议的同步间隔表

当没有明确的业务规则时，使用保守的范围。下表显示了常见建议：\n |数据类型 |推荐范围 |注意 |\n| ---| ---| --- |\n|新闻和社论内容 | 30 至 60 分钟 |更新不影响电池 |\n|非关键财务数据| 15 至 30 分钟 |根据紧急程度进行调整 |\n|关键信息|后备推送 |避免轮询 |\n|地点更新 |点播|仅在特定任务中高精度 |\n|库存同步 | 1 至 4 小时 |可以在后台 |\n 这些范围只是一个起点。理想的情况是使用仍为用户保留价值的最低频率。

电池、温度和感知性能

当消耗增加时，设备的温度会升高。这会激活保护机制，从而降低性能。用户注意到速度缓慢并将其与应用程序联系起来，即使问题源于能源消耗。这种连锁效应是将电池视为用户体验一部分的最大原因之一。冷酷的应用程序往往会被认为速度很快，而升温的应用程序会产生负面印象，即使它的屏幕很漂亮。

因此，在评估性能时，不要只看FPS和加载时间。还要观察温度和稳定性。如果应用程序在简单任务期间变热，则表明 CPU 过高或网络使用率过高。

降低能耗的缓存策略

缓存不仅仅是性能。它减少了网络使用量，从而减少了能源消耗。三种类型的缓存可以提供帮助:\n

内存缓存：适合临时数据，但会消耗 RAM。\n- 磁盘缓存：非常适合图像和文档，但会过期。\n- 智能缓存：存储最常用的数据并根据版本失效。\n 秘诀在于制定明确的政策。例如，图像可以有 7 天的有效期，配置文件数据可以有很短的有效期，并且列表数据只能在用户拉动刷新时更新。这些政策可以防止不必要的请求。

如何使用 WebView 处理应用程序中的电池

具有 WebView 的应用程序可以隐藏高消耗，因为脚本和动画在内置浏览器内运行。为了减少消耗：\n

禁用视频自动播放。\n- 限制 CSS 中的动画和效果。\n- 避免短时间运行的脚本。\n- 仅加载第一个屏幕上所需的内容。\n- 谨慎使用 Service Worker，因为它可以将工作保留在后台。\n 通过控制网页内容，您可以防止应用程序成为重型浏览器。

权限政策及对消费的影响

后台位置、通知和蓝牙访问等权限增加了消费潜力。理想情况下，仅当用户理解该值时才请求许可。如果应用程序在首次访问时请求许可，用户可能会拒绝，您就失去了解释的机会。当在正确的时间请求许可时，您可以提高批准率并减少投诉。

这种护理也减少了消耗。在没有实际使用的情况下激活的权限只会创建后台任务并消耗电池电量。

如何建立内部基准

内部基准将您的应用程序与竞争对手进行比较。使用相同的设备和相同的脚本。如果竞争对手消耗较少，这有助于证明优化投资的合理性。该基准还有助于校准目标。如果您的应用程序在 30 分钟内消耗了 10%，而您的竞争对手消耗了 6%，那么显然还有改进的空间。

创建包含数据的电子表格并每季度更新一次。这成为一种产品和战略工具，而不仅仅是一种技术工具。

以电池为中心的 QA 检查表

如果您有一个简单的脚本，QA 可以对控制消耗有很大帮助：\n

运行典型使用脚本并记录消耗情况。\n- 在后台运行应用程序 1 小时并测量消耗情况。\n- 检查位置是否在未使用的情况下处于活动状态。\n- 检查应用程序在正常浏览期间是否升温。\n- 验证通知不会不必要地唤醒应用程序。\n- 与以前的版本进行比较。\n 此清单可防止新版本在团队不知情的情况下增加消耗。

关于应用程序中电池的快速常见问题解答

为什么我的应用程序即使在关闭时也会消耗电池？ 通常是由于后台任务、服务或非常频繁的同步。检查唤醒锁和计划的作业。

您如何知道该类别的消费是否很高？ 与同一设备上的类似应用程序进行比较。如果你的出现上面的情况，那就有问题了。

推送通知会消耗大量电量吗？ 一般来说不会，只要配置好就可以。最大的开销来自于反复唤醒应用程序的通知。

GPS总是消耗很多？ 是的，尤其是在高精度的情况下。仅在必要时使用。

缓存对电池有帮助吗？ 是的，因为它减少了网络使用量，而网络使用量是主要的能源消耗者。

电池优化会损害性能吗？ 不一定。在许多情况下，它可以提高性能，因为它减少了不必要的工作。

结论

电池消耗不仅仅是一个技术细节。也是质量的核心属性。节能的应用程序可以提供更多价值、增强用户信心并提高保留率。好消息是，大多数改进都来自简单的良好实践：降低任务频率、使用缓存、避免固定位置和控制后台。

通过本指南中的清单和原则，您的团队可以以结构化的方式诊断、比较和改善电池消耗。结果是一个更轻、更可靠、更有竞争力的应用程序。

另请阅读

【应用中的电池消耗：与真实案例的比较2
【应用中的电池消耗：比较和快速指南3
【应用性能：实例4
【应用性能：实践中的真实例子5
【应用中的电池消耗：如何优化移动性能6
[混合应用程序什么是7?