Android固件研发中的角色和职责


请尊重原创版权,转载注明出处。

第一次写跟技术有关,却又跟代码无关的文章,算是对这些年工作的一个总结。 毕竟在Android这个领域已经工作到了第9个年头,需要停下来想一想:积累了哪些领域知识?以后技术成长的支撑在哪里?甚至乎,以后工作的方向在哪里?

回来起来,这些年工作的关键字就是Android ROM,而一款优秀的ROM背后,是产品、运营、开发和测试这四个角色各司其职又相互协作。那么,各个角色具体有什么不同的职责?角色之间又如何相互配合?谨以此文,把自己的观察、实践和思考记录下来。

首先,解释一下本文要讨论的ROM究竟是什么?本来ROM仅仅是只读存储器(Read Only Memory),这个名词用在手机上,表示存储厂商预置数据的固定区域,属于硬件(Firmware)的范畴,包括:Boot分区、System分区、Recovery分区等。我们平常说的刷机,就是重写手机上的ROM,刷入ROM的数据就是Android系统了,而Android系统属于软件(Software)的范畴。但这些概念逐渐变得边界模糊后,ROM就等同于Android系统,而Android系统通常以一个压缩包的形式存在,打包了各分区的镜像文件(boot.img, system.img等),所以,这个压缩包又被称为ROM包或固件(Firmware)包。

然后,解释一下“stock ROM”和“custom ROM”的这两个名词,这是大家逛论坛会经常遇到的名词,两者是同一个意思,都表示对出厂系统定制过的系统。比如,将MIUI移植到三星的机器上,那MIUI就是stock ROM。因为Android是开源的,所以很多开发者都会基于AOSP(Android Open Source Project)进行定制:简单的会改一些界面样式、精简一些应用;复杂的会深入系统底层优化,增强系统功能。有几个较为著名的AOSP定制版,他们是在Android原生系统上做定制,所以也是stock ROM

  • LineageOS: 其前身就是大名鼎鼎的CyanogenMod,功能丰富、界面简洁、支持机型众多
  • AOKP: AOSP的一个轻量定制,支持机型较少
  • Paranoid Android: 功能较为实用,支持机型较少

最后,需要说明,ROM的范围并没有一个明确的界定,当我们说到“固件研发”或者“ROM研发”的时候,可以指代整个Android系统相关的界面定制、框架调试、性能优化,也可以指代系统移植、分支管理、版本控制,这完全由实际的情况去分割职责。对于一个手机厂商而言,其出厂Android系统本身就是stock ROM,譬如:MIUI, Flyme, ColorOS等,对Android定制深度不同,所需要的团队规模就不同。

了解ROM的相关概念后,就可以介绍固件研发中的不同角色和职责了,这些角色合力的目标,就是产出可以交付给用户的固件

Role and Responsibility

运营

固件运营这个角色是直面用户的,“拉新-留存-促活-裂变”是核心职责,目的就是让更多人使用,并将用户流量有效地转化成商业价值,这些职责和目的其实运营任何一款产品都需要具备的,成熟的方法论一大把,总的原则是:基于量化数据评价产品力,针对目标群体进行活动策划,保持和用户的良好沟通。

具体到Android固件这个领域,涉及到固件中集成的应用、系统级功能、整机的体验、版本的迭代等,因此不管是跟踪的数据也好,还是制定的运营策略也好,都需要立足于手机的生命周期。不同于运营一个纯软件范畴的APP,固件运营是伴随一个特定的手机硬件的,而一个硬件产品,从被生产出来、到销售期、再到维护期、最后到淘汰期,是有不同的时间窗口的。而且,在一个时间点,不同的手机设备通常是处于不同的窗口期的。举个例子:为了双11冲量,计划在9月初发布一款旗舰产品,采用主流的配置,搭载最新的Android版本;而上半年发布的中低端产品,Android版本略旧,在9月份依旧处于维护期,这是手机厂商都会遇到的场景:

  • 引发媒体曝光的是搭载最新Android版本的旗舰机,而真正冲量的是搭载旧Android版本的中低端机
  • 用户呼声较高的是升级旧机型的版本,而厂商的主要资源都投放在新旗舰机的研发
  • 部分用户担心升级引发的问题会抗拒新版本,而厂商又希望将最新版送达用户以便落地新的业务

对于APP而言,新用户的增加,老用户的留存,是以软件服务为载体运营的;对于固件而言,是有一个切实的硬件载体的,新用户的增加表现在用户购买一个新的手机,老用户的留存表现在换手机时依旧选择相同的厂商。软件服务的边际成本是可以迅速递减的,即服务1000个用户投入的成本不会比服务100个用户投入的成本大很多,而硬件本身就是真实的投入,卖1000台手机与卖100台手机成本比基本还是趋于线性关系的。因此,固件运营有边界,软件服务于硬件

作为运营角色,该如何圈定不同的用户群,制定和推动运营方案呢?

产品

测试

开发

写在最后的话

我依然清晰的记得自己写的第一个Android应用:地铁的路线查询应用,作为一个Android 2.3上的练手项目,实现了A*算法来寻找两个站点之间的最短路径。

后来的工作中,又接触了短彩信(MMS),联系人(Contacts)这些系统应用,获益匪浅,这些应用的架构方式对我影响至今,设计任何应用,我都还是会遵循那些系统应用的接口和缓存的设计方式。

逐渐的,做到了通信框架,那时候Android还没有双卡接口,两家大的芯片方案商(MTK和QCom)各有一套自己的双卡方案,于是费了很大的力气把两套方案兼容起来。

两三年时间这么过去了,在通信的应用层到框架层摸爬打滚了一番,当自我感觉摸到藤了的时候,接下来面临的挑战一下让良好的感觉破灭了:ROM移植,把一份已有的Android代码移植到任何一款机型上去。突然一下,与Android的接触面大了许多,从kernel到framework调试,从编译系统到固件集成,从BeyondCompare到分支管理,查尽资料万千,依然躺坑无数。

我们当时并不生产手机硬件,只是做软件层的ROM,基于CM(CyanogenMod)来进行机型适配看上去是一个“优良”的方案,因为CM本身已经适配了数百款机型,但后面的实践检验,这套方案投入大,但产出的ROM质量不高,仅仅能满足一些玩机党的需要,这迫使我们转向了另外一种方案:逆向移植。当时业界成熟的逆向移植方案有MIUI的PathRom,不同于Android源码的移植,逆向移植从最终固件的角度逆推,需要哪一块的改动就将局部进行反编译再修改,不仅投入小,而且质量高。

做了两年时间的ROM移植后,开始转向框架层,同AMS/PMS/WMS等几大系统服务周旋了很久,也在系统稳定和功耗上投入了很多时间,随着对Android了解的逐渐加深,越发感觉Android这片浩瀚海洋的广阔无边。

除了Android,这几年还做了一些前端和后端的开发,每一项技术都发展的很快:以前的后端J2EE大行其道,SSH(Struts+Spring+Hibernate)三件套足够秒天秒地,现在的后端丰富无比,NodeJS、PHP、Python、Go的开发框架都已经非常成熟;以前的前端就是HTML+CSS+JavaScript,了不得用一些JavaScript库(譬如JQuery,ProtoJS等),现在的前端已经有无数优秀的框架,Angular、Vue、React等都能够极大的降低开发成本,借助于一些多端转换工具(譬如Appache Cordova,Electron),用JavaScript开发的前端应用也能很快移植到移动端(Android/iOS)和PC端(Window/Linux)。

技术在更迭,新名词新概念层出不穷,我也时刻提醒自己持续学习,保持对技术的敬畏和热情,无奈生有崖而知无崖,越成长就越渺小。 在技术周边也有很多美好的事物:创业者喜于讨论的商业模式、投资者乐于所见的指数增长、管理者精于修炼的职业素养,行行有门道,每个领域都有一个自转体系,都值得我去探索和实践。