※ 引述《limufish (ponpon)》之銘言：可是我一直很好奇續航有這麼難嗎？其他的廠商
做不到嗎？
照他們員工談研發的文章的說法，是蠻難的，他們自己也是絞盡腦汁攻克各種相關難題。
下面是其中一篇（看了以後稍微原諒SONY）：
“大家都知道，手機要工作就會有功耗，有功耗就會產生熱量，拍照的各種賣點功能需要
更新的硬體器件與更復雜的軟體演算法支持，往往意味著更高的功耗與發熱。而手機自然
散熱是存在極限的、因此發熱量要嚴格控制，否則手機就成“燙手山芋”了。
大概是我入職表現還不錯，團隊便把優化拍照發熱的任務安排給了我，我們在項目組成立
了攻關團隊，我新人一個，有股“初生牛犢不怕虎”的沖勁，面對發熱問題、義不容辭地
拉著材料、多媒體器件&性能演算法、晶元規劃、用戶體驗、功耗、軟工媒體域的多領域
專家，邊學邊乾，把問題一點點剝開、一點點改進。
剛開始每個人都有很多自己本領域的事情、在發熱問題的投入上需要很多溝通協調，但隨
著攻關的深入，為了產品最終上市的綜合體驗成功，大家都不再只盯著自己領域的“一畝
三分地”業務。
還記得在拍照發熱攻關的過程中，有一個阻礙近一周的異常問題——單次拍照功耗波峰持
續近10s（正常都是約2s），導致發熱量增加16%。我們針對拍照本身的特性、器件、演算
法嘗試了很多軟硬體的方法進行排查，把其中涉及的可能變量（器件功耗組成拆解、EMUI
與原生版本的差異、拍照演算法流程運行的時間等等）摸了個遍，但都沒有找到根因，百
思不得其解。
在一次和多媒體演算法專家的早會上，我們反復自問“卡在CPU上近10秒的‘瓶頸點’到
底是什麼？”一位專家突然想到可以求助性能專家進行系統進程的抓取分析。果然，當我
們採用systrace工具抓到拍照後必現的進程信息後，終於找到了問題的症結，原來每次拍
照動作後觸發性能雷達報錯與抓取，導致CPU上耽誤了時間。
這樣的案例有很多，手機系統與結構太過緊密而精密，問題多是跨領域的。一方面，需要
一支技術精深的戰友團隊，取長補短、相互激發，高效尋找問題的本質；另一方面，需要
個人有系統、開放的思維，不斷學習跨領域的知識與工具，耐心剖析系統中盤根錯雜的關
系，不能只盯著眼前的“一畝三分地”知識。
整個拍照發熱專項的攻關是個系統工程，從源頭降低發熱、從路徑優化散熱，最優化“性
能&功耗&熱”綜合體驗，支撐拍照賣點“清晰又涼快”。有時優化一點發熱量或散熱能力
，可能需要犧牲另一方的性能，或帶來新的問題，牽一髮而動全身。
需要我們綜合考慮拍照性能（速度與清晰度）、軟硬體（演算法與模組器件）與功耗熱的
耦合關系，剖析用戶的真實需求，綜合考量、設計優化，不再是單領域的“一畝三分地”
設計。（出自華為人“怎麼給博士軍團當好“博導””）