广州下午一点多，太阳正毒。梁泽祖把车停在路边，点开网约车司机端，按下“出车”。
然后，什么也没发生。
十分钟过去，没人叫车。半小时过去，屏幕还是安静的。一个小时、两个小时，他坐在驾驶座上，开始意识到一件有点尴尬的事：想研究网约车司机怎么用手机，第一步不是打开测试工具，而是先让平台相信你真是个司机。
梁泽祖不是来赚这十几块钱车费的。他是 OPPO 硬件技术中心无线性能部的工程师，手上有个课题：解决手机长时间导航时的发热和功耗问题。
这听起来像一个普通手机用户也会遇到的小毛病。开车导航久了，手机发烫、屏幕卡顿、刷新率下降，严重时系统还会降频自保。对多数人来说，解决办法很简单：把手机放一边，等它凉下来。
但对网约车司机来说，手机不能凉，也不能停。订单来了，按钮卡住，可能就是一单没了；定位飘了，乘客等不及，取消也就一分钟的事。数据显示，普通用户每天 GPS 活跃时间大约半小时，而网约车司机一天可能要用十几个小时。换句话说，除了睡觉，他们几乎都在和导航绑在一起。
办公室里当然也能测导航，实验室里也能跑功耗曲线。但问题是，实验室里没有乘客催你，没有平台派单权重，没有暴晒的车窗，也没有一台会干扰 GPS 的车机。
所以梁泽祖把自己的新能源车开上了路，注册成一名真正的网约车司机。
他们原本想得很简单：找个没人的地方，让同事站在车边扮演乘客下一单，梁泽祖接上，手机挂着导航，一天的数据就有了。结果第一关就卡住了，派单系统不只看距离，还看司机评分、接单历史和优先级。一个刚注册的新手司机，就算乘客站在车窗外，单子也未必派给他。
取巧的路堵死了，只能老老实实接陌生人的真实订单。
从下午一点多挂到将近四点，第一单才来：一所高中放学，把学生送到地铁站，十几块钱。后面几单也并不顺利，不熟路、迟到、被取消、差点吃罚单。跑了一阵，他才摸出点门道：地铁站、医院门口、学校附近，才是手机真正进入“司机工作状态”的地方。
这只是第一天。接下来一周，梁泽祖尽量把早晚高峰、午后听单、夜间返程这些司机最常见的状态都跑了一遍，手机也跟着进入真正的长时间导航、充电、发热循环。听他分享跑车经历，俨然已经是一位有多年网约车从业经验的老炮儿。
一个工程师，为了几度温差，去跑一周网约车，值得吗？
OPPO 工程师甚至没考虑过值不值，这是他们工作的常态。这背后是一种典型的工程师思维：不靠直觉下判断，凡事先回到技术事实和用户的真实处境上，把一个含糊的抱怨拆成具体的问题，再一项项较真到底，这问题到底是什么、是不是用户真正的问题、值不值得做。
而他们认准的头一条就是：很多手机问题，根本不发生在手机里，而发生在用户的一天里。要搞清楚用户的那一天，光靠数据不够，得有人真的坐进那个驾驶座。
那么，司机手机一开导航就发烫，真的是 GPS 的锅吗？
一、GPS 不是元凶
用户说“导航一开手机就烫”，听起来 GPS 像最大嫌疑人。但工程师拆开功耗账之后，发现第一个该被排除的，恰恰是 GPS。它只是一个接收机，安静地收着卫星发来的信号，单看 GPS 模块，在该场景下的电流消耗约 20mA，并不是整机发热的大头。
“也可以优化，可优化来优化去就一两毫安，起不了什么决定性作用”，吴海飞说。
工程团队认为这是个系统问题。用户开着导航的时候，根本不止 GPS 在工作，屏幕得高亮着显示路线，地图渲染、路线计算、实时定位和网络请求，会持续唤醒 CPU、DDR 等模块，这些模块叠加起来的发热，远不是那二十毫安能比的。再加上网约车司机一天十几个小时连轴转，热量就这么一点点累起来。
麻烦的地方在于，那些变量大半不在实验室里，而在真实的车上、真实的一天里。司机插不插电、在不在导航、开什么车、什么天气……
这正是梁泽祖那一周要“撞”的东西。坐进真实的驾驶座、接真实的单，手机才会进入真实的工作状态，而那些藏在变量里的问题，才会一个个冒出来。
先是充电。很多司机导航时手机一直插着电，架在支架上，屏幕亮着，一插就是十几个小时，就为了不在半路趴窝。
原先 OPPO 工程师设想的那套想兼容所有人的通用降功耗方案，对司机并不适用，你在这头辛苦降下来的热量，会被那头持续充电产生的热量原样吃回去。而司机整天插着电，其实并不需要快充，只要稳稳地充、别太热就行。
还有听单状态。团队原本有个自然的假设：既然司机一天绝大多数时候都开着 GPS，那应该一直处在导航过程里。但跑过之后发现完全不是，司机有大量时间是车停在路边、人靠在座位上歇着，手机就那么挂在前台听单，GPS 照样被高频调用。
这是一个原先方案里根本没设的状态，人和车都不动，其实只需要保住信号、GPS 定位可以降低采集频率；真接到单跑起来，GPS 才需要重新拉满。倘若处理好这个场景，功耗自然就能降下来。
还有一些意外的发现。
梁泽祖接到一单，因为定位不准，错过了乘客，最终订单取消。他发现是自己的车机系统会干扰 GPS 频段，把定位带偏。手机上的检测工具显示信号一切正常，可实际跑起来，该在路口提醒的时候它没提醒，他绕了远路。
通过数据，能知道手机 GPS 被调用了多少次，却看不见这台手机此刻被放在哪、连着什么、人在不在开车、车本身会不会干扰手机，有些案例，甚至只能在特定的时间和地点才能复现。
通信开发部的贾俊凯负责电梯、地库、城中村这类弱网场景的网络优化，去年下半年，他在沈阳、长春、济南、临沂、西安、广州之间来回跑了两三个月，都是去看那些用户反馈了、却依靠后台难以判断的问题。
有一次，铁岭的用户反复报告某些时段打不出电话、上不了网，可后台数据一看，手机完全正常，测试同事专门去了好几趟、蹲了几次，一条异常日志都没抓到。最后贾俊凯自己拎着笔记本去用户家里守，守到那个反复出问题的时段才弄明白，毛病根本不在手机，是当地运营商为了省电费，在特定时段定时关掉了一批基站。
二、指标变好了，体验可能变差
找到真正的热源之后，事情是不是就简单了？把每个模块的功耗压下去，温度自然就降了。但工程优化最麻烦的地方在于：数字变好，不代表体验变好。
跑完了这一周网约车，拿到了更多数据，实验室里也花了功夫研究，吴海飞、梁泽祖和其他同事把导航场景下的每个模块都摊开，从最耗电的往下排，一项一项找能省的地方。
比如 CPU。大学生打游戏，需要它火力全开才流畅；可网约车的导航 APP 远没那么吃性能，把 CPU 从极限模式调到均衡模式，性能够用，省下来的电就变成了降下去的热量。
一个模块一个模块这样抠，最初预期顶多降五十毫安（换算成温度才一度），真拆下来，降到了两百到两百五十毫安，温度落了四到五度。
问题摸清楚，有了解决方案，剩下的就是埋头去做了。但是……稍等一下，效率最高的方案，未必是对用户最好的方案。
屏幕是用电大户，于是有个很简单的思路：司机用导航时，屏幕额外调暗一点，省电降热立竿见影，而司机似乎也不太需要一直盯着屏幕，暗一点关系不大。
一个漂亮的优化，没有任何理由不做，直到吴海飞他们拉来自己的同事当小白鼠。很多员工都有车，平时上下班也开着导航，于是工程师拉来一批人内测：把亮度给你降一档，怎么样？
最终负面评价远多于正面，而且有理有据：一来容易分神，开着车，屏幕亮度在眼角余光里忽明忽暗，人会下意识瞟一眼，犯嘀咕这手机是不是出毛病了；二来自动亮度本就是屏幕团队反复迭代出来的功能，根据当下的环境光，已经算出此刻最合适的亮度了，你为省这点电硬降一档，万一司机看不清路呢？
古德哈特定律说，当一个指标变成目标，它就不再是一个好指标。要破这个局，就得把指标放回真实场景里，看它会不会背离初衷。一个只盯着自己那块指标的工程师，会把亮度一路压到底，毫安数很好看，但数据对了就对了吗？
这个能降功耗、技术上挑不出毛病的优化项，被自己人否掉，没能进最终版本。
贾俊凯也经常“放弃”。他做电梯信号优化，一个难题是判断用户到底进没进电梯。最早他用 Wi-Fi 围栏，靠周围的 Wi-Fi 信号判断位置，准确率很高。
可功耗团队提了质疑：一直开着 Wi-Fi，明显拖续航，最终还是落到用户体验上。他只好改用一套混合识别，传感器加蜂窝信号的抖动，再叠上 Wi-Fi。因为单靠传感器，只能在电梯启动后才识别得出，信号优化来不及；而单靠蜂窝信号，在很多场景都不稳定，识别难免误触发，把不是电梯的地方认成电梯。
技术上复杂了不少，好处是不再拖功耗。
这本是退而求其次的妥协，贾俊凯却撞上了意外的收获。那些被错认成“电梯”的场合，恰恰是因为信号也在急剧变化，此时套上电梯那套快速切网的策略，竟把一些过去一直没解决的弱网问题给解决了。团队索性把这一类一并收进来，命名“类电梯场景”。
工程师做优化，要尊重功耗、温度这些可量化的指标，也要尊重用户的真实体验。多数时候两者一致，但也有指标优化了、体验反而下降的时候。该怎么选？
在这群人这儿，答案几乎不用想——指标是用来逼近好体验的，一旦它反过来开始伤害体验，那就是这个指标错了，而不是用户挑剔。对于贾俊凯来说，数字当然很重要，但更重要的是这些数字到底是为谁服务的。
三、为什么不先给旗舰机？
按手机行业惯例，新技术往往先上旗舰。但这一次，OPPO 的工程师没有这么选。GPS 的优化方案进度已经到了八成，接下来工程团队要找到合适的项目，把功能放进手机里。
那么，放进哪一款手机？
一般的理解里，新技术总是从旗舰机开始用，再慢慢下放到中低端。但吴海飞觉得，GPS 的功耗优化不能按这套逻辑来，而要从OPPO更入门的 A 系列和 K 系列开始。
逻辑也很简单：核心用户，也就是每天要用十几个小时 GPS 的那群人，在那里。
在吴海飞看来，司机的痛点更明确。一个用旗舰机的白领，GPS 漂移一下，可能是绕十分钟路、跑步时多跑几百米，属于可以原谅的错误（当然也需要优化解决）；可司机定错一个点，就可能没接到客人，乘客一分钟就取消订单，这一单的钱就没了，“影响到了人家的生活”。
去用户更集中的地方，也更利于技术迭代。
一项新技术不会一次就完美。贾俊凯优化电梯信号，两年前就有方案上线了，至今还在迭代，而迭代要靠用户去用、靠用户的反馈。倘若 GPS 功耗优化放在旗舰机型上，真正高频跑导航、会触发这个功能的目标用户本就没几个，反馈收不上来，技术也就喂不大、迭代不下去，会严重拖慢节奏。
先上 A、K，或者选择网约车司机作为原点用户，背后依然是基于工程师的直觉判断：因为他们在 GPS 这个场景上最“硬核”。
换句话说，先解决谁，看的不是谁的手机更贵、更该有卖点，而是谁的问题更真、更急。
贾俊凯的弱网优化，则不挑机型，也不挑人。电梯里的信号衰减，外卖员会撞上，保洁、上班族、路过的任何人都会撞上，于是他干脆把它做成一套通用能力，铺到所有进入这个场景的手机上。
“我不 care 人群，只 care 场景，我就负责让进了这个场景的人，业务能尽快变好。”贾俊凯说。
为了覆盖更多场景、让技术更好地泛化，OPPO 内部有一个技术池，别的团队要复用同一个技术去解决别的场景问题时，可以很快协作，不用重复造轮子。
于是，每一项技术的价值都不止停在单一场景、单一人群里。优化了 GPS 功耗，普通人导航时也不会再觉得手机烫手；为电梯做的信号优化，也能用到地库、城中村这些同样信号差的地方。
结语
今年下半年，搭载这套 GPS 功耗优化方案的某款 OPPO A 系列或 K 系列手机会上市。它大概率不会成为发布会上最热闹的卖点。毕竟，“导航时少烫几度”听起来不如影像、AI、芯片那么性感，也很难让人立刻掏出手机拍一条短视频。
但对一个每天跑十几个小时网约车的人来说，这种变化可能很具体。
下午三点，车停在医院门口，手机架在中控台上，屏幕常亮，电源线插着，司机一边听单，一边等下一位乘客。过去，这种时候手机已经开始发烫，地图偶尔卡一下，定位慢半拍。订单来了，手指点上去，如果屏幕迟疑一秒，乘客可能就取消了。
而现在，他可能只是觉得：今天这手机好像没那么烫。
没有惊喜，也没有仪式感。没有人会因为手机少卡了几次，专门去评论区夸一句“工程师辛苦了”。大多数体验优化的命运就是这样：做得不好，用户会骂；做得好了，用户只是少骂几句。
梁泽祖他们要的，可能也只是这几句少掉的骂声。
那个下午，他在广州街头挂了快三个小时，才等来第一单。一个研究手机导航发热的工程师，先被网约车派单系统上了一课：真实世界不按实验室的脚本走。你以为问题在 GPS，最后发现是屏幕、CPU、充电、车机、天气、平台规则和司机的一天一起把手机推热了。
这也是这件事最有意思的地方。
手机行业讲了太多年参数，多少瓦快充、多少尼特亮度、多少分跑分、多少亿像素。但用户真正记住一台手机，往往不是因为某个参数，而是因为某个狼狈瞬间：地库没信号，电梯里断网，高架下定位漂移，抢单时手机卡住，导航快到路口才反应过来。
一个 OPPO 工程师跑去开网约车，表面上是为了让手机少烫几度；往深一层看，是这群工程师把那套工程师思维贯彻到了底——用系统的方法解决问题是第一准则，问题不在实验室里，那就到现场去撞；指标和体验打架，那就让指标给体验让路；谁的问题最真、最急，就先去解决谁。
他们从不去想自己是不是在“为社会做点好事”，只是本着一个朴素的动机：用户遇到了问题，我要想办法解决问题。
至于那个未来用上这套方案的司机，他大概率不会知道梁泽祖是谁。他只会在某个晚上收车时，把手机从支架上取下来，发现它没有烫得像块刚下锅的铁板；今天定位没怎么飘，路口提醒也算准，订单没有因为卡顿丢掉。然后他锁车、回家、睡觉。第二天再把手机插回支架上，继续出车。
而在 OPPO 的工程师工作清单上，一个问题被划掉了，后面很快又添上新的：地下车库里的定位、高铁隧道里的会议、冬天低温下突然掉电的手机。更多真实世界的问题在等待工程师们给出答案。
富灯网提示：文章来自网络，不代表本站观点。
