能耗调试的新特性（WWDC 2018 session 228）

本文主要是介绍能耗调试的新特性（WWDC 2018 session 228），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

该篇博客记录了观看WWDC Session228《What’s new in energy debugging》的内容以及一些理解。

该Session主要从三方面来对能耗以及能耗调试进行讲解：

1. 回顾电池寿命概念(Review general battery life concepts)
2. 回顾调试能耗的工具(Review tools for energy debugging)
3. 调试能耗的新特性(New features for energy debugging)

回顾电池寿命概念(Review general battery life concepts)

能量(Energy)

从物理学上来说，能量就是力量和时间的产物。

由于App运行的平台不一致，所以它在不同平台上消耗能量的速度不一致。

下图是App运行时能量的消耗图：

从图中我们可以得知：

• 在程序运行时，功能的消耗有高峰也有低谷
• 不同运行模式下，功耗是不一样的
• 程序处于活跃状态时，功能消耗可能会达到最高点
• 程序在运行但空闲时，功能消耗会降低
• 程序在挂起时，会有基本的功能消耗

开销(Overhead)

当程序按照设计去做它该做的工作时，它会要求系统提供它工作所需要的硬件资源。虽然程序并没有直接控制硬件资源，但是它通过它所做的工作来影响硬件资源的使用，这些硬件资源的使用被称作开销(Overhead)

活动能源(Active energy)

当程序开始利用硬件资源(开销)来做工作时，此时一些子系统消耗的能源就叫做活动能源(Active energy)

所以，电池寿命问题就是由开销的优化和活动能源的优化来组成。

子系统

在程序开发中，程序可能会用到许多不同的硬件和子系统，对能耗影响最大的是下面四个子系统：

1. 处理(Processing)
2. 网络(Networking)
3. 定位(Location)
4. 图形(Graphics)

处理(Processing)

• 是工作的组成部分
• 处理消耗取决于工作量

总结：App操作越多 = 越多的功耗

网络(Networking)

• 通过蜂窝(Cellular)、Wi-Fi、蓝牙(Bluetooth)来与网络交互都会消耗能量
• 网络消耗取决于流量

总结：网络请求越多 = 越多的功耗

定位(Location)

• 通过GPS、Wi-Fi、蜂窝(Cellular)来定位会消耗能源
• 定位消耗依赖于定位的精度和频率

总结：定位时间越长 = 越多的功耗

图形(Graphics)

• 动画和UI布局会通过CPU或GPU来消耗资源
• 图形消耗依赖于动画或UI的复杂度

总结：需要渲染的越多 = 越多的功耗

我们通过对四个子系统的分析可以得出：App需要做的工作越多，那么功耗就越多。

但我们不必让App少做工作，App越少做工作，表明App功能越少。我们需要思考的是如何优化App的工作以及使这些工作尽可能的节能。

接下来通过现实中的例子来进行系统的分析：

前台(Foreground)

当App处于前台时，我们的关注点应该是专注于为用户提供价值

接下来从两方面来说：

只做必要的工作

下面是相关的现实中的例子：

我们构建了一个媒体应用，这个应用主要目的是以常规的节奏为用户提供新内容

如果我们使用Timer来按照常规的节奏来进行，这种方式将不是节能的，下图是随时间变化的功率图：

我们可以看到，在每次Timer启动的时候，我们都会有功能的消耗，但是这并不是主要的，更主要的是，每次Timer启动，都意味着我们可能去启动网络、图形以及处理等子系统来完成显示，这样随着程序的运行，我们会有一个持续的能量消耗。

我们可以换一种解决方案：根据用户交互(例如刷新)或者服务器通知来触发新内容的获取以及展示。这里的功率图如下，从图中可以看出，功耗已经被降低了很多：

降低UI的复杂度

下面是相关的现实中的例子：

我们构建了一个视频播放器，并且有一些UI控件来控制视频的播放(例如：音量、播放进度)，但是如果该控件一直存在的话，是十分消耗资源的，原因是：在许多设备上，当屏幕上没有用户界面时，会有一个显示的优化，这个优化可以让视频播放十分节能。所以我们可以改变一下解决方案：我们可以根据用户在一定时间内没有交互，那么我们就让控制控件进行隐藏，从而使用到显示优化来进行能源的较低消耗。

后台(Background)

我们在后台运行时，我们的应用程序可能与设备上的其他系统同时运行。当App处于后台时，我们的关注点应该是最大限度的降低工作量

接下来从两方面来说：

合并任务

下面是相关的现实中的例子：

我们经常会上传分析日志并使用这些分析来防止应用崩溃。所以我们一般的做法是在每次应用进入后台时都会发送分析日志，这种操作的功率消耗如下图：

我们可以看出，在每次进入后台时，都会启动网络请求来发送分析日志，随着时间的推移，这种功耗是非常大的。

我们正确的做法是分批发送分析日志。系统提供的很多API都支持合并原则，其中NSURLSession也支持合并原则：使用自主属性的NSURLSeesion和后台session会自动优化这种操作。下图是使用合并原则之后的功率消耗：

虽然每次发送分析日志的时间有所延长，但是能源的消耗会有很大的降低。

快速结束任务

系统提供了很多API允许程序在后台运行：UI后台任务、UIKit、VoIP和PushKit。同时这些API为开发人员提供了指示不再需要后台运行的方法。如果你在后台模式下使用了这些API，你应该调用完成回调告诉系统已经结束任务了。

下面是没有告诉系统任务结束，然后让任务超期无效了的效率图：

我们可以看到，在任务开始后的一段时间，任务执行完成，此时任务会进入空闲阶段，会继续进行能源的消耗，这就造成了能源的浪费。

正确的做法是，只要它们完成，就调用完成回调通知系统任务结束。这种做法的能耗图如下：

回顾调试能耗的工具(Review tools for energy debugging)

能量计(Energy Gauges)

能量计可以直接通过Xcode调试器直接访问。

Average Energy Impact

标准表表示了应用程序在瞬间的平均能量影响。

Average Component Utilization

平均组件利用率表是一个饼状图，它表示了不同组件相对于总消耗的百分比，该表有助于你确定某个子系统是否开销过多。

Energy Impact

这个时间序列可以实时的看到程序中每个时刻各个组件的平均使用率，同时这里还支持显示程序的前台、后台以及暂停状态。

Instruments

Instruments中包含三种与之前讨论子系统相关的工具。

我们用Time Profile为例来进行讲解

Time Profile

接下来对该UI进行讲解：

1.Top Bar

顶部条中有不同控件：左上角有播放和暂停按钮；右侧有加号按钮，允许快速的添加其他工具。

2.Profiling Pane Actually

这里允许查看当前运行的工具以及当前正在调试的App。

图中使用的是Time Profile，所以可以看到CPU的使用情况。

3.Weighted Call Graph

因为我们使用的是Time Profile，所以在加权调用图中，可以准确地看到程序中调用了什么，以及它对CPU的影响。

4.Summation of the Heaviest Stacked Race

Instruments的优势：

• 可以分析根本原因
• 可以进行深度分析
• 无约束的分析(可以在程序运行时没有束缚的进行分析)

调试能耗的新特性(New features for energy debugging)

对于调试已经存在于App Store或者TestFlight中的App，用户使用的场景与测试场景完全不一样，用户可能在Wi-Fi情况很差的情况下使用，而我们测试时是在Wi-Fi情况很好的情况下，所以对于这种情况，有两种方式解决：

Xcode Energy Logs

Xcode Energy Logs是报告设备能源问题的新方法。

• 在高CPU能耗事件进行报告
• 加权调用图可以指出代码中的能量热点
• 数据来自TestFlight和App Store，即来自于用户真实使用场景中

Xcode Energy Logs生成

当你的App给CPU带来很大的负载，那么就会生成Xcode Energy Logs：

触发生成的事件有两个：

1. 前台超过3分钟超过80%的CPU使用。
2. 后台超过1分钟超过80%的CPU使用，这种情况应用程序会被杀死。

这两个触发条件意味着会造成1%的电池电量的下降。1%的电池电量意味着在iPhone 6s上：

Xcode Energy Logs组成

• 触发报告的能源状况(例如：应用在3分钟内耗费8%的资源)
• 设备类型和应用程序构建版本号
• 能源热点中的加权调用图

接下来讲解如何使用加权调用图：

1. 假设代码中有一个main函数和许多函数构成(method1、method2、method3、method4)
   

2. 当程序运行到检测到高CPU能量时间时，会以每秒1次的周期进行采样：
   

3. 每个采样数据中都是当前时间点的活跃函数：
   

4. 将获得到的采样数据进行组合，就能得到一副加权调用图：
   
   在这幅图中，我们可以看出，main()方法100%的时间都在运行，而其他方法，我们也能看出他们运行时间占比。

该加权调用图有以下几个要点：

• 收集回溯样本
• 按照样本计数汇总
• 样本越多意味着代码的大量执行

Xcode Energy Logs生成流程

1. 设备创建日志。
2. beta测试人员或者用户将日志上传Apple。
3. App对成千上万的日志进行汇总分类整理，创建一个列表。
4. 开发者使用Xcode Energy Organizer来下载查看列表。

Xcode Energy Organizer

Xcode Energy Oranizer是一种查看能源报告的新工具。

在Xcode Energy Oranizer中，可以展示如下信息：

1. TestFlight和App Store中的App
   

2. 近期数据
   

3. 首要问题列表
   

4. 加权调用图
   

5. 逐页浏览日志
   

6. 项目中打开代码
   

使用Xcode Energy Logs有以下优点：

• 从文件中发现首要问题
• 使用加权调用图查看能源热点
• 通过使用(Open in Project)来调试代码

总结

• 考虑能源的使用，并在设计、开发和测试中将能源视为最重要的资源。
• 利用Energy Gauges和Instruments来调试App
• 多使用Xcode Energy Organizer新特性来发现能耗问题

这篇关于能耗调试的新特性（WWDC 2018 session 228）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---