泰晓科技 -- 聚焦嵌入式 Linux - 追本溯源,见微知著!
网站地址:http://tinylab.org
微信公众号关注我们新浪微博


扫一扫

关注 @泰晓科技
赞助泰晓原创 ○ 在线实验Linux ○ 下载开源书籍
请稍侯

智能手机系统优化的演进与实践

Wu Zhangjin 创作于 2015/11/27

By Falcon of TinyLab.org 2015-11-27

背景

笔者前不久受邀参加了 CSDN 主办的 2015 年移动开发者大会(MDCC 2015),在 IoT 峰会:嵌入式开发 分会场做了题为《智能手机底层系统优化的演进 —— 从 M9 到 PRO5》的报告。

为了跟更多的业界同行一起分享和交流相关的内容,下面对这个报告做一个简要回顾。

该报告首先介绍了产品演进的背景、优化的诉求来源、需求分析和关注对象以及一般的智能手机产品研发和迭代模型。接着,就产品优化的 4 大项(稳定性、温控、续航、性能) 5 个方面(问题、难点、目标、措施和技术)进行了展开。最后就关联的内容提出了几个开放问题,开放问题围绕团队架构、研发流程、标准建设和行业协作等方面。

产品演进脉络

该报告首先以魅族为例,介绍了历代产品的演进情况和不同阶段的产品重点优化进展:

meizu-products-development

2009 年,魅族完成了从 MP3 到 智能手机(M8) 的华丽转身,没有经历过功能机的研发历练,直接过渡到智能机时代,经历了阵痛,也拿到了第一桶金。随后,继而抓住开放 Android 平台的大势,放弃了封闭的 Windows CE 平台,于 2011 年推出了第一代 Android 手机:M9。这几年的磨练,造就了两代脍炙人口的机型:M8 和 M9。但是探寻的脚本没有停止,随后的 2012 年过渡到了持续至今的 MX 系列,产品的命名体现了追梦的本色,到 2014 年把产品受众扩大,推出了魅蓝系列,继而在 2015 年为了惠及高端用户,独立出 PRO 品牌。

伴随着受众的增加、产品形态的多样性、研发节奏的急剧加速,对产品品质和体验的加强越发的迫切,在图中可以看到技术演进的一个基本脉络:先是一个基本功能的研发,稍后是稳定性(也即服务可用性)的逐步增强,再之后是手机外壳触觉体验(温控)的提升,到后面是续航和性能等方面的较大突破。

优化的诉求来源与需求分析

系统研发必须为产品服务,产品必须为用户服务。所以系统研发和优化并不是漫无目的的,所有涉及的部门和单位都需要全力以赴并且需要有特定的机制串联起来统一服务于最终的用户。对于用户需求,很多公司都会有产品经理或者产品规划部,理想的情况下,它们会做好用户调研,需求分析,然后产生需求,递送研发部门实现。但是实际运作可能往往是,这些需求各自为阵,缺乏统一的架构、规划和部署,要么仅仅考虑功能本身,牺牲掉其他体验。其他体验是什么?用户除了关心功能外,最关心的是什么呢?

smartphone-user-requirement

从京东的几万个”买家印象“中找到了上述数据,用户除了关心功能外,对”系统流畅“的需求是第二位的,这个第二位就就是系统优化的基本诉求来源,这个”系统流畅“再扩展一些就是除了功能之外的各类系统用户体验。那具体到底有哪些体验,必须清晰化,否则所有的产品需求调研就是盲人摸象,难窥全貌和本质。

smartphone-user-experience

不难看出,用户体验是用户在使用系统提供的各种功能之后的各种感知的综合,通过分析用户的感知规律,细分以后除了很多所谓用户体验部门单纯关注的交互与视觉设计以外,其实还有温度触觉、稳定性、续航、性能、安全等等。

所以,如果要更好地做好系统优化,必须要理清到底要做什么,要明确用户真正需要什么,接下来才是梳理关注的对象,制定明确的定性和定量的目标,整合资源,有的放矢。

优化关注的对象

如果要让优化落地,必须找准落地的地方,也就是优化需要关注的对象。

smartphone-sys-opt-objects

图中只展示了最核心的部分,也就是系统内部的各个模块(以及负责各个模块的背后团队)。这部分涉及整个手机系统的方方面面,下到结构和硬件设计,上到应用开发,中间最核心的是 BSP 和 Android Framework,而不可忽视的还有交互和动画设计,甚至涉及器件选型、采购、生产等诸多环节,没有一个部门可以独立于产品的品质之外,而且这些部门必须有精密的流程联系起来进行紧密地配合。

除此之外,还需要关注系统外部以及周边,比如说各软、硬件供应商,各电信运营商,各应用开发商以及各个应用商店。具体地,涉及到上游硬件厂商的设计与工艺的技术发展,Android 开放系统的逐步完善以及各运营商对产品的入库标准,还有一个比较重要的是,各个应用经历了大浪淘沙和技术积累,也在不断优化。所以,优化的演进过程实际上也是整个 Android 智能手机生态或者是整个通信产业的演进过程,产业界同仁如果要更好地服务于广大用户,必须齐心协力,密切配合,统一规范,制定标准,与此同时,做出自己的差异化。

这些外围部分对产品体验的影响,主要表现在:

  • 供应商本身的软、硬件技术
  • OEM/ODM 本身的品控标准和产线良率控制
  • 电信运营商的入库标准和把关情况
  • 各个应用开发商的资质和技术积累
  • 以及各个应用商店的准入门槛和监督机制

一般研发与迭代模型

系统研发与优化不可能一蹴而就,而是要经历长到 1 年,短到几个月的历程,这个历程里头有可能经历几个阶段。

  • 大多都会经历完整的功能研发过程,也就是为用户提供基本可用的功能。部分企业可能因为没有足够的资源,做完这一步就开卖了。这个阶段简单命名为”可用“。
  • 而少部分企业则会投入额外的资源确保各个功能能够持续稳定的提供服务,即要确保各项功能以及多个功能混合使用后,这些功能还能够持续稳定的可用。简单命名为”能用“。
  • 剩下的极少数企业有更进一步的追求,会继续探索非功能性的体验,比如说温度舒适、性能流畅、续航持久、安全可靠等。这个可以简单描述为”好用“。

当然,无论产品本身还是多代产品之间,实际上是一直在经历一个不断迭代和进化的过程,只有”更好用“,没有”完美“,甚至中途还发生严重的衰退,所以必须要做好风险管控。

smartphone-3-core-dev-stages

系统优化:4 大项 5 方面

本报告在介绍完背景之后,依次搬出了系统优化的 4 个大项,针对每项又系统地展示了 5 个方面:问题、难点、目标、措施和技术。

很多企业可能还停留在 Bug Fix 阶段,来则解之。但是随着产品受众的加大,产线良率和售后返修的压力以及为应对上市进度而导致的研发周期压缩等会迫使有追求的企业逐步考虑如何系统地面对某类问题,梳理出疑难点,理清定性和定量的目标,并调研出应对措施,并做相应的技术、工具和文档积累,进而形成完整而清晰的架构,为后续研发做长久的指导。

考虑到时间和篇幅关系,这里重点介绍各大项的目标设定部分,下面所有的量化数据是纯粹举例,实际会因不同需求和追求而异。其他内容请参看演讲幻灯

稳定性

稳定性的定性目标主要是让系统的功能能够持续一致地提供服务。最典型的问题是死机和异常重启,重启实际上是死机的一种退化补偿,尽量减少功能不可用的时间。还有一种退化的补偿是,提供一个按钮,当用户长按几秒后可以复位整机(重启),这个对于目前的不可拆卸电池的设计来说,几乎是一个标配。而定量可度量的目标是,在多少时间内,持续在多少台机器上做哪些常规操作(以便模拟用户的日常使用场景),这些机器出现死机或者异常重启的数量为多少。这个实际也是电信运营商入库的一个量化措施。

如果要尽量地模拟用户的使用情况,核算出一个相对准确的出错概率,那么这些数值(运行时间、机器数、运行的测试用例、死机或者异常重启的次数)就需要较准确的计算。而从人体感知的角度来看,死机和异常重启是非常难以接受的糟糕体验,所以,这类优化通常是第一位的。

smartphone-stability-opt-targets

由于稳定性尤其关键,这里也贴出为应对稳定性,我们设计的 RAS 架构:

smartphone-stability-ras-architecture

这个架构反应出:

  • 稳定性优化是一个伴随整个产品生命周期的不断迭代和演进的过程
  • 在 R、A、S 各个阶段都需要有专门的应对措施、技术和工具,避免缺陷引起最终的故障发生
  • 如果要压缩研发周期,必须尽可能早地暴露缺陷并拦截掉,进而减少迭代的次数和时长

温控

温控的定性目标是确保各项器件能够安全工作,确保用户能够舒适的使用,当然更不能被灼伤。各个器件在设计之初因为所使用材料以及工艺等原因,有一个工作温度,这个必须要满足,不同的器件会有差异。而除了器件之外,人体由于本身有一个正常的温度范围,对外部感知基本在这个温度上下才会感觉舒适,更准确地,人体对不同材料的温度感知也是有差异的,所以,更定量的标准需要有一个较为客观的量化。而电信运营商目前也在初步制定了一些量化标准,比如说一些运营商已经把外壳 45 度作为上限。

smartphone-temperature-opt-targets

限定温度的普遍做法是降低各类器件的能耗。这个的定量标准随着处理器工艺水平的提升,已经逐步容易达到,当然,能耗管控的结果在一定程度上会影响性能,需要有特定的处理。

续航

续航的定性目标就是确保整机能够在各种场景下的使用时间更长,即在完成同样功能地情况下,消耗更少的电量。这个的定量标准目前主要落实在各个使用场景上,几家电信运营商都有比较详细的规范。但是难点实际上在即使这些续航的定量标准在入库时达到了,但是目前的闲时功耗和后台功耗通常是失控的,这类问题的基本原因是应用行为不可控以及系统厂商本身(包括 Android)的不作为。不过 Android M 已经在做一些优化的尝试,比如说 Doze 和 App Standby;部分企业也逐步在自启动管理、后台进程管控、Power Tail 方面做了不少工作。

smartphone-power-opt-targets

性能

性能的定性目标其实是各种时间属性要符合人体的感知期望,而定量的目标也可以转换为各类场景的目标响应时间,比如说应用启动时间、游戏 Frame Rate 等。性能这一块的难点是它跟续航和温控的诉求有一定的矛盾。在硬件工艺不变的情况下,往往是此消彼长,还有一个难点是,性能的衰退有些有累计效应,比如说在使用一段时间以后,内存泄露的累计效应出现,才逐步导致卡顿。

smartphone-perf-opt-targets

开放问题讨论

在这个报告的最后,提到了几个开放问题,这些问题或多或少会影响整个系统优化的效果,这里稍微整理下自己的看法。

团队架构

团队建设以项目为中心还是以技术为中心呢?前者在项目进度管控、团队对项目的荣誉度等方面有特别的优势;而后者在技术积累等方面可能有所侧重。具体的情况要看企业发展的阶段和资源的可用情况。如果有能力投入资源,系统优化部分应该组建专门的团队去应对。

流程优化

跨部门问题分析与协作过程?无论是 Top Down 还是 Down Top,各类常见的问题都最好有一个明确的分发流程,避免团队间扯皮导致事情进展缓慢甚至影响产品的研发进度。针对上述优化中的一些重点和难点问题,跨部门之间必须梳理好明细地流程,避免某些问题无人跟进或者确保有正确的人去跟进。

标准建设

各项需求、用例、目标、步骤必须标准化,清晰化。避免模棱两可、可有可无的任务出现,这些标准化的内容都可以转化为可落地的任务。所有系统优化的岗位,都必须有明确可执行的任务,否则优化的工作就很难落地。有些标准建设也可能需要协同其他企业通过合作一起制定。

技术突破

如果要有特别的技术突破,在疑难问题上有重大进展,除了加强预研外,必须扩大合作,拓展与同行、社区、供应商的合作深度和广度。优化作为改进体验的最后一步,往往是较难突破的部分,所以必须摆脱孤军奋战的作法,加强跟不同岗位的交流,加强跟外界的合作。

加强交流

要获取末端的真实需求,必须加强与用户的交流;要产生更多的创意,必须要加强各类不同背景的人才的交流与碰撞。系统优化方面或许可以从不同的用户反馈那里获得很有价值的明细需求,也可以从产品经理和品控人员那里获取不同的看法和思路,务必不要闭门造车。

Read More: