廣州下午一點多，太陽正毒。梁澤祖把車停在路邊，點開叫車司機端，按下「出車」。
然後，什麼事也沒發生。
十分鐘過去，沒人叫車。半小時過去，螢幕還是安靜的。一個小時、兩個小時，他坐在駕駛座上，開始意識到一件有點尷尬的事：想研究叫車司機怎麼用手機，第一步不是打開測試工具，而是先讓平台相信你真是個司機。
梁澤祖不是來賺這十幾塊車費的。他是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
