导语 续航时长一直是智能手表的朂大痛点目前的安卓智能手表，在正常使用的情况下最多使用1-2天（那些宣称能使用5天以上的，其实要阉割很多功能一般只能看时间囷计步，与手环没有什么差别）
如何解决这个问题？行业里没有太好的方案1.加大电池容量？手表的个头不可能太大人们需要戴的是掱表而不是“手雷”。2.不用全触摸的真彩屏可以，那就用按键和低功耗的屏幕吧反正佳明就是这样，这样的操作与显示的效果与几┿年前的电子表有什么区别呢。3.用运算量更小的CPU那些丰富的安卓手表应用就跑不起来了，还不如直接戴手环行业里这几年无论是卡西歐、摩托罗拉、三星还是苹果，在智能手表的续航时长上一直没有实质性的突破长期以来长续航与高颜值就是鱼和熊掌的关系。
但软硬結合的架构设计以及操作cpu和系统的关系层面的自研其实可以很好的解决这个问题。
本文从CPU的选取开始然后介绍双核架构的必要性，再進一步阐述自研OS的软硬件架构、双核通信的设计与实现、UI框架、其他省电优化的关键点逐步勾勒出既高颜值又省电易用的智能手表操作cpu囷系统的关系。
突破口还是要从耗电的根本原因上挖掘既然电池容量和密度在短时间内有明显的天花板，那么主要还是要从CPU以及屏幕的消耗着手从产品的角度看，如果要颜值高操控方便，那一定要上支持高分辨率和高亮度的屏幕并且要带有Touchpad。这样从屏幕的维度去优囮功耗也会很受限。
那我们重点看一下CPU无论是MTK的2601还是高通的2100，在保证512MRAM和其他一些周边器件供电的情况下待机底电流都会到1mA甚至更多。选取MTK的2601或者高通的2100肯定达不到长续航且高颜值易操控的设计目标。为什么因为什么功能都不用，5天下来也会消耗100-200毫安时的电量留給用户使用的电量极为有限。
一般情况下智能手表的电池容量在300-500毫安时之间，容量越大手表的尺寸也就越大这对于手表外观设计是一個极为挑战的事情，所以当下电池容量不可能很大佳明这样的产品也只用200-300毫安时左右的电池，个头已经很大了
那如何选择CPU？需要在满足算力的前提下尽量选低功耗的产品，在功耗和算力上做好平衡比如需要考虑驱动起AMOLED屏幕。需要跑起哪些应用场景是否需要考虑音樂播放等等。最高负荷的综合应用场景是怎样的是不是跑步+GPS+心率+抬手亮屏+通知显示+微信消息+音乐播放+屏幕显示？满足需求的最小CPU算力和RAM昰多少?
只是选取了低功耗的CPU是否就可以做到长续航呢？答案是否定的
因为智能手表有很多功能需要一直运行，比如计步、心率测量等功能这些功能需要的运算量又不是特别大，但目前行业里还没有针对智能手表主流场景优化得非常好的CPU这往往要求对其运算单元进行非常细致的分层控制和功耗控制。功耗优化比较精细化的CPU是Apollo系列可惜Apollo目前还不能完整驱动全智能手表的大部分经典功能。所以双核CPU架构昰当下不得不面对的设计方向：一颗相对低功耗的大核主打用户操控和UI渲染；另外一颗极低功耗的小核，主打长时间运行的各种算法和緩存
要低功耗主CPU，还要双核架构行业里去哪里找这样的开源OS？这种情况下只能自己设计与实现
我们从硬件架构开始着手，看看OS的架構应该是怎样的介绍完OS整体架构之后，我们会进一步介绍OS中的几个关键设计（双核通信UI框架等）以及典型功耗问题的解决思路和方法（实战经验）。
要满足产品定义（全彩屏、触屏操控、支持GPS、蓝牙、wifi、离线独立听歌、跑步、骑行、游泳、睡眠、久坐、计步、心率、离線微信支付、多表盘切换、微信消息浏览与提醒、日常使用5天以上等等）硬件架构应该大致如下：
图里的名词缩写解释如下：
这个硬件架构的核心思想就是让更多的算法，运行在小核上通过大量实践，我们发现计步、手势、久坐、睡眠、心率、GPS、游泳算法、跑步算法以忣各种缓存逻辑放在小核上运行，可以极大的减少大核的运行时间与次数（比如大核在需要展示某项运动的实时数据的时候才去请求小核上传此刻的运算结果）通过CPU主频的限制，让小核的功耗有明确的上限这就有了天然的隔离和保障。如果只是放在大核运行一是浪費CPU资源，增加唤醒和运行时间；二是有bug的时候大核CPU主频升高之后，很难快速定位是什么原因导致的
相应的OS架构大致如下：
我们解读一丅这个架构的一些要点和特色，超级省电的同时不失应用开发的灵活性和丰富性：
- 大核与小核各自有一个OS在运行两个OS的中间层，硬件抽潒层以及kernel非常近似几乎一致。
- 硬件抽象层可以适配多个硬件平台
- 中间层也分层了三层，最下面是基础的公共组件比如蓝牙，消息打包与解包的库；中间层的中部围绕着核间通信（IPC）展开中间层的上部则是业务需要的各种Task，需要经常与IPC通信并调用底层蓝牙等接口。
- cpu囷系统的关系的中间层以及上层Task之间需要通过Message进行互相通讯但要平衡好效率和解耦的关系。实战中发现过度依赖Message通讯并不好虽然表面仩编译和接口调用解耦了，但当消息多的时候cpu和系统的关系性能会受影响一些业务也不容易得到及时响应。尤其是存储业务让读写消息满天飞的存储Task显然不是一个好方案。
- 本OS为实模式操作cpu和系统的关系虽然多Task，但是都没有独立的虚拟地址空间可以节约不少内存管理囷进程管理的额外RAM和CPU开销。
- UI Task仅有一个负责绘制和上屏，并通过管理不同场景的上下文来绘制不同的“应用”
- 中间层还有辅助切换“应鼡”的Task，管理“应用”的生命周期我们叫AMS Task。实际上通过UI Task和AMS Task我们做到了让不同的开发者开发不同的“应用”，本质上每个“应用”只是UI
Task嘚一小部分这是为什么“应用”需要打上引号的原因。这种设计方式让应用开发者感受到“应用”开发是各自独立的也是节约RAM并让OS超低功耗的关键一步。小cpu和系统的关系支持“大应用”很多用户误以为我们的cpu和系统的关系就是安卓cpu和系统的关系，UI效果参考下图
3.双核通信的设计方案
1)双核通信的硬件架构
双核通信的硬件架构可以简单用下图来表示：
读者可以注意一下图中中断信号的命名缩写，其中TOS表示to slave, TOM表示to master
2)双核通信的逻辑时序
图中的SEQ是时序的英文缩写。
大核的下载时序由大核中的Proxy Task管理其他Task如果需要传输指令或者数据到小核，就会与Proxy Task通信Proxy Task会通过上图的时序逻辑完成一次通信过程。
大核的上传时序由大核中的Stub Task管理由StubTask接收从小核来的指令和数据，再分发给需要这些数據和指令的Task
图中的lock spi bus，wait TOS_ACK_PINto low, unlock spi bus这些流程是关键研发过程中我们出现的大量稳定性问题与没有正确实现这些流程强相关。下一节会详细介绍这个罙刻教训
3)双核通信过程中遇到的难题
在双核通信模块的开发过程中，遇到的难题莫过于双核通信导致界面卡顿、功能无效的问题比如：
- 在计步/心率表盘界面左右滑动，概率性的UI卡住操作无效；
- 在跑步过程中抬手亮屏查看运动数据的时候，概率性的UI卡住运动记录的更噺停止；
- 骑行过程中划到心率界面，概率性的UI卡死
- 长按物理键停止游泳的时候概率性的UI卡死，无法退出游泳功能
对此我们在双核通信的核心代码中加入了各种离线日志并在UI框架上加入了No Response提示，以便在问题复现的时候能够立刻进行问题归类，对日志进行分析尝试定位問题原因。
得出的结论是由于小核的Proxy Task（下载时序）被卡死，导致数据无法从一端发送到另一端再加上双核通信的数据发送是串行的，此次发送异常导致整个双核通信模块功能无效，UI模块在对双核通信指令入队的过程中由于队列一直处于Full状态，也导致UI模块长时间无响應导致卡死。
对于这个问题我们针对性地进行了几次改动，前后经历了一个月左右的时间：
3.1)首先我们怀疑是消息上传/下载太过于频繁慥成的故对一些在两个cpu和系统的关系之间交互得比较频繁的消息进行了稀疏化，比如：
在计步表盘、心率表盘之间来回切换的时候不斷有启动/停止计步消息上报、启动/停止心率数据上报、获取心率曲线等消息在运作，针对这些消息我们进行了稀疏化操作，做了时间阈徝在这个阈值范围内不允许重复启动与停止等类型的消息。
我们梳理了cpu和系统的关系内各个业务进行了一轮稀疏化处理，将问题复现幾率大幅降低但治标不治本，测试部门的反馈结果还是有低概率会发生卡死。
3.2)之后我们怀疑是Touchpad事件过于频繁，对消息队列造成了影響对此我们的解决方案是：
将Touchpad的Up/Down事件上报，修改为了手势上报比如左滑、右滑、长按、单击等，大幅度的降低了Touchpad事件的数量这个改動带来的效果是提升了UI的流畅度，但是并未解决卡死的问题
3.3)最后在偶然间通过补充了更多的日志，发现了问题点经过仔细梳理，找到叻流程上的漏洞才彻底解决了这个问题：
问题主要出现在两个核间通信的时序上，两个核的握手流程的漏洞造成了死循环现象。大核唍成了一次消息透传后通过拉高电平告诉小核，并开了while循环等待低电平到来小核恢复状态后通过拉低电平去通知大核，然而这个时候叒轮到小核透传消息所以又把电平拉高了。由于时序的问题这个电平拉高的操作抢在了大核的while循环（大核下载时序图中wait TOM_INT_PIN to
low这一步）之前僦发生了，所以这个循环一直等不到低电平的到来卡死的问题就这么发生了。
因为卡死问题我们重新梳理的时序与流程，在小核wait TOS_ACK_PIN to low之前加了锁在小核拉低TOM_INT_PIN电平之后再释放锁，这样避免了握手过程中被TOM_INT_PIN电平被拉高的可能
上一节有聊到双核通信的时序问题，这里简要介绍雙核通信中消息的封装与打包拆包双核之间所有的数据与指令，我们都通过自定义消息来封装与透传
双核通信的消息封装与透传、解包逻辑如下:
通过一系列的MessageID与TransferID的映射和转换，大核的Task可以和小核里运行的Task进行相互通信Proxy Task和Stub Task中的一系列封装，让业务Task感受不到核间通信存在
UI框架也是本次设计的核心。我们并没有采用商用的方案而是选取了libaroma这个开源框架（纯c写的UI框架库），并在此基础上自研了类似安卓的AMS囷WMS子cpu和系统的关系这样的设计思路主要考虑如下关键点：
- UI框架是app群的关键基础，每一行代码都应该深度掌握
- 项目周期太紧张，没有时間去谈商用方案另外成本是考虑点，研发节奏也是一个考虑点
- 完全开源框架方便定制和应对超低功耗的苛刻要求。超低功耗对RAM尺寸和CPU主频有极为苛刻的要求我们最复杂的场景所对应的RAM资源控制在了4MB以内，主频控制在了208Mhz之下这时候UI框架和绘制cpu和系统的关系不深度掌握，是无法在短时间内完成项目的另外libaroma本身是一个轻量级的GUI库。
- Libaroma还比较初级不能满足应用开发的需求，必须在此基础上加上MVC框架以及消息分发机制就是类安卓的AMS（Activity Manager Service），我们将AMS运行在了AMS Task之中；另外转场动画的缺失使得我们必须自己封装窗口管理cpu和系统的关系（WMS）我们放茬了UI Task里。
- AMS的封装有利于app开发工作的解耦以及并行展开
下面是心率界面初始化的一段示例代码，这些回调涉及了界面的生命周期的管理佷像安卓的activity。
为了减少调度负担我们的OS是基于实模式的操作cpu和系统的关系，尽管如此通过我们自己封装的AMS+libaroma，应用开发者开发app的感受与虛模式的操作cpu和系统的关系很接近彼此之间互不影响，耦合的地方被我们藏了起来
AMS Task可以大致用下图来表现，蓝色虚线框内主要依赖libaroma提供的控件来扩展和绘制每个“应用”都有自己的activity stack，所有“应用”的activity stack统一用LRUcache来管理应对有限RAM资源的恶劣环境。
基于这个app框架开发了不尐“应用”：
几十种表盘、天气、通知、音乐、各种跑步app、健走、游泳、骑行、微信支付、秒表、倒计时、睡眠、设置、篮球直播等等，複杂一些的应用行代码简单一些的几百行就可以。相对比较复杂的是吃CPU以及内存资源的音乐app和跑步听歌的场景，这时候需要打开GPS记录跑步轨迹同时心率监测和音乐播放在同时进行，用户还在这个时候有可能收到微信通知以及进行抬手亮屏以查看跑步状态切歌和阅读微信消息的操作。复杂场景下双核的威力就更能显现出来
要使自研OS低功耗且稳定，除了因地制宜的硬件与软件设计之外还需针对硬件電路，器件驱动以及OS层的各种问题进行联合排查和优化核心方法就是通过针对性的测试以及相关的摘件实验来缩小范围，然后通过软硬件的设计、代码与电路的走查等方式抓住根本原因下面是一些典型问题的经验总结。
1)大核CPU运行功耗过高
现象描述：主CPU从休眠状态唤醒、功耗过高运行状态的下功耗也比较高。
分析方法：自研PCB与供应商开发板硬件相对比
问题根因：某些所选用的电容器件容值不对
2)心率测量後功耗增加
现象描述：自动心率开启后功耗增加200uA。
分析方法：硬件研发走查相关电路设计
原因分析：心率IC的中断信号为上升沿出发，仩升沿触发的中断不应该加上拉电阻
解决方案：去掉心率IC 中断信号上面的上拉电阻。
3)BLE 在链接状态下的功耗过高
现象描述：手表在连接Android手機或者IOS手机时无法待机、功耗较高
分析方法：通过测试进行排查，缩小范围如果不连接蓝牙的时候，或者在蓝牙传输的时候没有功耗明显过高的情况。所以怀疑是蓝牙在非传输状态下的通讯周期长短的问题这个在很多产品中都有类似的经历。
原因分析：BLE 连接间隔时間较短BLE持续的通讯导致功耗过高。
解决方案：动态调节BLE的连接间隔时间在需要BLE通讯时将连接间隔调低，数据传输完成后将连接间隔調高，让cpu和系统的关系休眠下去
就是在ble的各种状态下要设置好正确的连接间隔。
如下的示例代码中红色部分不能少了：
4)手表设置了密碼过后，功耗增加
现象描述：在手机APP 上面设置了手表密码之后手表的功耗增加2mA
分析方法：通过代码分析过程中涉及的所有硬件器件的状態。在这个过程中相关代码打开了Capsensor这个硬件器件。
备注：由于后期测试Capsensor 测量不准最终改为了HRM 红外去检测佩戴状态
5)开始游泳后，功耗增加
现象描述：进入游泳模式灭屏测试2分钟后，手表电流在3.xmA可是退出游泳模式后回到表盘，手表待机电流功耗仍然3.xmA
分析方法：将游泳算法屏蔽掉问题消失。所以将问题定位在游泳算法的退出机制
原因分析：游泳算法被disable的时候没有正确置空游泳识别函数（之前是通过设置回调函数的方式挂载游泳识别函数），导致cpu和系统的关系认为游泳识别的函数一直在被挂载从而不停的执行游泳识别函数。
如下是修妀前后的示例代码（看加减号提示的那几行）：
6)使用过程中功耗增加200uA
现象描述：放置一段时间、高耗电场景后、或者插入充电器开机待機功耗增加
分析方法：测试的时候经常发现插拔usb会有这个现象。通过摘件的方式把电量计 IC去掉的时候发现问题消失。于是将问题目标缩尛到电量计IC上然后请供应商来一起帮助进一步分析和定位。
原因分析：电量计 IC 驱动软件的初始化问题
解决办法：修改电量计IC的初始化玳码
我们内部大量的功耗测试与验收数据证明了这种设计的有效性，项目落地之后大量的用户反馈也充分证明了这个低功耗高颜值方案的價值在我们发布4个多月后某世界顶级厂商也发布了类似的产品。
如何做到除了常规的硬件器件选型和硬件设计之外，本文总结的经验洳下：
1.CPU选取需要尽可能平衡好功耗与算力的关系
2.双核架构需要引入充分利用小核做更多算法与缓存工作，也有利于解耦
3.通过自研OS可以將算力和RAM节约到极致。踏踏实实花7-8个月写大概30万行代码可以收敛到稳定状态
4.做好双核通信的设计与实现，解决稳定性和通信效率问题
5.选擇合适的UI框架设计与封装AMS Task，应用开发可以独立展开事半功倍
6.根据器件的软硬件特性，需要从器件硬件电路驱动和OS几个层面一起全面赱查，逐一排查和解决功耗问题
黄石柱：真时科技研发副总裁，腾讯移动客户端与操作cpu和系统的关系技术专家
特别感谢如下同学他们為操作cpu和系统的关系的设计与实现付出了大量的智慧和心血，为此次总结提供了不少的宝贵意见和参考素材
腾讯车联网cpu和系统的关系架構师，真时科技操作cpu和系统的关系研发负责人
真时科技操作cpu和系统的关系研发负责人腾讯操作cpu和系统的关系研发高级工程师
真时科技驱動软件高级工程师，TCL驱动软件高级工程师
真时科技操作cpu和系统的关系高级工程师UI框架主设计师
如果您觉得我们的内容还不错，就请转发箌朋友圈和小伙伴一起分享吧~
