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

By Falcon of TinyLab.org 2015-11-27

背景

笔者前不久受邀参加了 CSDN 主办的 2015 年移动开发者大会(MDCC 2015)，在 IoT 峰会：嵌入式开发 分会场做了题为 智能手机系统优化的演进 的报告。

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

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

产品演进脉络

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

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

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

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

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

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

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

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

优化关注的对象

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

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

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

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

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

一般研发与迭代模型

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

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

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

系统优化：4 大项 5 方面

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

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

如果希望详细了解稳定性、性能、续航、温控这 4 大项 5 个方面具体是如何开展的，欢迎通过微信号 tinylab 联系我们。

开放问题讨论

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

团队架构

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

流程优化

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

标准建设

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

技术突破

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

加强交流

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