廣州下午一點多，太陽正毒。梁澤祖把車停在路邊，點開網約車司機端，按下“出車”。

然后，什么也沒發生。

十分鐘過去，沒人叫車。半小時過去，屏幕還是安靜的。一個小時、兩個小時，他坐在駕駛座上，開始意識到一件有點尷尬的事：想研究網約車司機怎么用手機，第一步不是打開測試工具，而是先讓平臺相信你真是個司機。

梁澤祖不是來賺這十幾塊錢車費的。他是 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 的工程師工作清單上，一個問題被劃掉了，后面很快又添上新的：地下車庫里的定位、高鐵隧道里的會議、冬天低溫下突然掉電的手機。更多真實世界的問題在等待工程師們給出答案。

本內容由作者授權發布，觀點僅代表作者本人，不代表虎嗅立場。如對本稿件有異議或投訴，請聯系 tougao@huxiu.com。

本文來自虎嗅，原文鏈接：https://www.huxiu.com/article/4865433.html?f=wyxwapp