穿戴产品功耗开发——系统篇

上两篇分别从总结了主控和外设在穿戴产品功耗的影响，本篇来点干货，将从系统角度来说明常见的功耗优化措施以及debug措施。

在说明功耗措施前，我们首先来看下系统是如何管控并进入休眠的。

IDLE任务中的功耗管控

系统通常会将功耗管控的流程放在idle执行，主要原因是idle任务优先级低（在接触过的OS中，idle任务优先级都是置于最低的），只要有高优先级的任务处于就绪态，idle就不会被执行。因此，把功耗管控放在idle任务执行就能将管控判断对其他应用的影响降到最低。说白了，只要有应用要跑，那么功耗管控就得让道，要记住：功耗管控是服务于应用，而并非应用服务于功耗管控。

那功耗管控怎么判断要不要进休眠，应该进入浅睡还是深睡呢？

通常BSP会提供性能调节接口（如主频申请等接口），然后在功耗管控的位置对各应用申请不同性能的情况，进行裁决，来判断系统是否要进入休眠（另外对于多核芯片，每个核的休眠动作都是单独管控的）。

举个例子，系统有3个应用（id 0~2），分别申请了24M、32K、96M主频，功耗管控会从中选择最高的主频来执行，那此时就是跑96M，所以系统当前还得处于no sleep状态，很快调度器又会把执行权限交到其他应用中进行运行；当id 0~2申请的主频都等于系统最低主频32K时，此时功耗管控模块经裁决发现，所有的应用申请主频情况是最低主频，允许系统进入休眠，当产生异常（中断）时，系统才会被唤醒去执行相关应用。实际场景会稍微复杂些，还要考虑如何进入不同的睡眠等级等。简单的说就是“一个应用忙，系统就要忙；全部应用闲，系统才能闲”。

功耗优化措施

了解完系统休眠的管控流程，我们就得实打实从系统层面执行功耗优化了，以下罗列了几种常见的方法（欢迎各位大佬在评论区给出更多更优的措施，供小弟学习学习）

1. 主频选择：各应用在满足性能的要求下，选择最低的主频；
2. 时间同步：比如多个应用都是1Hz执行频率，那么可以考虑将其对齐，由1个应用统一触发其他应用的执行，这样做有2个好处：a) 资源优化（将原本多个定时器的资源压缩到1个），b)  功耗优化（减少系统的唤醒次数）；
3. 中断同步：原理和2相似，比如2个sensor都是1Hz唤醒频率，且采用了中断方式，如果其中1个sensor支持polling方式，那么就可以借助另一个sensor的中断，来完成工作；
4. 降低系统唤醒频率：比如亮屏时，需要及时同步健康数据到APP，而当熄屏后，健康数据的同步频率就可以降到半小时、1小时甚至更久同步一次。很多应用需求都可以根据是否亮屏来调整。
5. 等等。

功耗debug措施

在测试阶段一定会遇到功耗问题，比如外设关闭异常、系统未进入休眠等都会让产品以预期之外的速度在耗电，所以如何追踪功耗异常，也显得至关重要。以下是几点debug措施：

1. 功耗日志追踪：a) 各个外设工作工作状态（LCD、PPG、GPS、NFC、ACC等），b) 芯片的系统信息（休眠时长、休眠等级、系统主频等），c) 用户使用情况统计。我们能够通过分析当前用户的使用情况，来排查外设、芯片端是否存在异常。比如用户使用过程处于熄屏状态，但主控却没有进入休眠，那么我们就能够根据系统主频信息来推断是哪个应用主频没有正常释放，导致的功耗异常。
2. 分析用户的实际耗电：如果方式1没有定位到问题，那么我们就要计算下用户反馈的功耗异常的实际耗电情况，结合前期对芯片端、外设端的功耗拆分获取的功耗数据，来定位异常模块。比如通过压降计算出用户系统熄屏场景出现了10mA左右的耗电，那么我们可以考虑先排除掉一些功耗较低的外设异常，再将接近实际耗电的外设模块进行打桩压测（不同模式的切换，并记录对应的功耗）排查是否存在开关异常的情况。还有就是硬件损坏的情况，通常硬件复位是无法修复的，那么就可以挂测功耗仪，直接进行排查了。

实际情况同样比上述的操作会更复杂，因为我们很难一上来做到把芯片、外设端所有状态都监测到，很大概率是出现异常，最后排查出异常，再把功耗日志的监测信息给完善的，这样才能方便后面遇到类似问题时快速定位，收敛问题。

最后

功耗优化和debug就是持久战：从战略防守，到准备反攻，再到战略反攻，最后收获胜利。si磕就完事了，加油！！！

本专栏内容就先告一段落了，欢迎对功耗开发感兴趣的兄弟在评论区互动或者私聊。明天又周一，继续搬砖，睡觉了，溜！