上個(gè)月幫一個(gè)團(tuán)隊(duì)排查攝像頭啟動(dòng)慢的問(wèn)題用戶反饋從點(diǎn)擊圖標(biāo)到預(yù)覽畫(huà)面出現(xiàn)要等將近兩秒而且打開(kāi)相機(jī)后手機(jī)溫度明顯上升。拆開(kāi)看trace才發(fā)現(xiàn)光Buffer分配和格式轉(zhuǎn)換就耗掉了700多毫秒真正留給ISP出圖的時(shí)間反而不多。這種問(wèn)題在Android Camera場(chǎng)景里太典型了——硬件參數(shù)看起來(lái)很強(qiáng)實(shí)際體驗(yàn)卻被軟件鏈路的低效拖垮。這篇文章我會(huì)結(jié)合Camera的多層架構(gòu)把性能優(yōu)化的關(guān)鍵路徑、Buffer管理、功耗控制、以及排查手段完整講一遍所有方案都是我在真機(jī)上調(diào)過(guò)的可以直接當(dāng)成一份排查手冊(cè)用。1. 先摸清Camera全鏈路架構(gòu)性能瓶頸幾乎沒(méi)在相機(jī)本身做性能優(yōu)化最大的忌諱是拿到問(wèn)題就猜猜錯(cuò)了方向后面全白干。Camera的性能問(wèn)題更是如此因?yàn)橐粠?huà)面從光線進(jìn)入傳感器到最終呈現(xiàn)在屏幕上中間要穿越應(yīng)用進(jìn)程、Framework服務(wù)、HAL層、內(nèi)核驅(qū)動(dòng)四條防線哪一層堵住都會(huì)表現(xiàn)為卡頓、掉幀、延遲大。1.1 一條預(yù)覽幀從傳感器到屏幕要經(jīng)過(guò)哪些環(huán)節(jié)先看一條最基礎(chǔ)的預(yù)覽幀鏈路。Sensor采集到RAW數(shù)據(jù)后ISP做去噪、壞點(diǎn)校正、色彩插值輸出YUV或RAW幀這份幀數(shù)據(jù)被放進(jìn)BufferQueue應(yīng)用層通過(guò)SurfaceTexture或ImageReader取出來(lái)做業(yè)務(wù)處理最后要么交給SurfaceFlinger去合成顯示要么交給編碼器去錄制。在這個(gè)鏈路上幀數(shù)據(jù)的流動(dòng)是典型的生產(chǎn)者-消費(fèi)者模型。HAL層是生產(chǎn)者應(yīng)用層是消費(fèi)者中間的BufferQueue是緩沖區(qū)。一個(gè)最基本的優(yōu)化原則就是生產(chǎn)者和消費(fèi)者的速度要匹配任何一方掉了鏈子幀率就會(huì)立刻波動(dòng)。1.2 各層性能損耗的關(guān)鍵環(huán)節(jié)我按層級(jí)把典型的性能損耗點(diǎn)整理了一下你會(huì)發(fā)現(xiàn)真正拖后腿的往往是那些不起眼的中間環(huán)節(jié)。層級(jí)典型瓶頸表現(xiàn)應(yīng)用層主線程做耗時(shí)操作、大圖Bitmap反復(fù)創(chuàng)建點(diǎn)擊快門卡頓、預(yù)覽掉幀F(xiàn)ramework層CameraService線程調(diào)度、BufferQueue阻塞ANR、Surface狀態(tài)異常HAL層ISP 3A算法耗時(shí)、降噪多幀合成耗時(shí)出圖慢、夜景模式處理時(shí)間長(zhǎng)內(nèi)核驅(qū)動(dòng)層Sensor上電、I2C配置耗時(shí)、CSI傳輸帶寬不足啟動(dòng)慢、高分辨率卡頓這里要特別提一下ISP的3A算法也就是自動(dòng)曝光、自動(dòng)對(duì)焦、自動(dòng)白平衡。3A需要連續(xù)采集多幀統(tǒng)計(jì)信息來(lái)做收斂在暗光環(huán)境下迭代次數(shù)會(huì)明顯增加單幀的統(tǒng)計(jì)耗時(shí)可能從1毫秒漲到5毫秒以上。如果你發(fā)現(xiàn)暗光下預(yù)覽幀率掉得厲害大概率是3A收斂花了太多時(shí)間而不是Sensor本身跑不動(dòng)。1.3 判斷瓶頸歸屬的優(yōu)先級(jí)順序很多開(kāi)發(fā)者一提到優(yōu)化相機(jī)就想直接把HAL層重寫一遍這是不對(duì)的。我的經(jīng)驗(yàn)是先查數(shù)據(jù)路徑再查業(yè)務(wù)邏輯最后才碰底層配置。數(shù)據(jù)路徑指的是幀能不能順暢地從HAL流到應(yīng)用層業(yè)務(wù)邏輯指的是你的應(yīng)用拿到幀之后做了什么底層配置才是HAL的tuning參數(shù)和驅(qū)動(dòng)行為。排查的時(shí)候優(yōu)先級(jí)反著來(lái)先用Perfetto看全局確認(rèn)瓶頸在APP進(jìn)程還是系統(tǒng)服務(wù)再逐層往下定位。這個(gè)思路貫穿全篇后面所有優(yōu)化手段都是圍繞這個(gè)排查順序展開(kāi)的。2. 幀率與時(shí)延優(yōu)化從Pipeline層面壓榨每一幀的耗時(shí)幀率上不去、時(shí)延壓不下來(lái)這是Camera優(yōu)化最高頻的兩個(gè)訴求。很多項(xiàng)目把目標(biāo)定成預(yù)覽要達(dá)到60fps、拍照零快門時(shí)延但實(shí)現(xiàn)路徑完全想反了——只顧著調(diào)大ISP頻率沒(méi)有先做管線層面的減法。2.1 幀率、時(shí)延、吞吐量的權(quán)衡邏輯先理清三個(gè)概念。幀率代表每秒鐘能出多少幀時(shí)延代表從觸發(fā)到結(jié)果的時(shí)間差吞吐量代表單位時(shí)間能處理的數(shù)據(jù)量。它們之間不是獨(dú)立的幀率提升后單幀的處理預(yù)算會(huì)縮短時(shí)延不一定同步下降甚至因?yàn)镃PU搶占導(dǎo)致時(shí)延升高。舉個(gè)具體數(shù)字60fps意味著每幀只有16.6毫秒的預(yù)算這16.6毫秒里要完成曝光、ISP處理、Buffer傳遞、應(yīng)用回調(diào)、顯示合成全套動(dòng)作。任何一環(huán)超過(guò)16.6毫秒掉幀立刻出現(xiàn)。而到了暗光環(huán)境曝光時(shí)間可能直接占掉10毫秒以上這時(shí)候如果HAL還堅(jiān)持用高幀率配置畫(huà)面就會(huì)快速劣化。所以幀率優(yōu)化的第一步不是硬拉頻率而是根據(jù)場(chǎng)景動(dòng)態(tài)調(diào)整目標(biāo)幀率。我通常在應(yīng)用層實(shí)現(xiàn)一個(gè)幀率分級(jí)策略光線充足時(shí)預(yù)覽60fps保證滑動(dòng)取景的流暢度中等光線降為30fps把CPU預(yù)算留給降噪算法暗光環(huán)境降到24fps以下同時(shí)開(kāi)多幀合成提升畫(huà)質(zhì)這個(gè)策略在底層只需要通過(guò)android.control.aeTargetFpsRange設(shè)置不同的range但帶來(lái)的體驗(yàn)提升非常明顯用戶不會(huì)感知到預(yù)覽變卡反而會(huì)覺(jué)得暗光下畫(huà)面更干凈。2.2 請(qǐng)求隊(duì)列與流配置對(duì)幀率的影響Camera2的Repeating Request機(jī)制是另一個(gè)經(jīng)常被誤解的點(diǎn)。很多初學(xué)者會(huì)誤以為并發(fā)請(qǐng)求越多越好實(shí)際恰恰相反。每一個(gè)CaptureRequest提交到HAL之后HAL需要按照優(yōu)先級(jí)調(diào)度。如果你同時(shí)提交了預(yù)覽流、拍照流、分析流三條流的請(qǐng)求HAL內(nèi)部的ISP帶寬會(huì)被平分單條流的幀率自然下降。我之前在一個(gè)項(xiàng)目里就遇到過(guò)后臺(tái)加了一個(gè)人臉檢測(cè)流之后預(yù)覽幀率直接從60fps掉到30fps而人臉檢測(cè)本身每秒只需要5幀。這背后其實(shí)是對(duì)Stream配置的理解問(wèn)題。在createCaptureSession時(shí)每個(gè)Surface的尺寸和格式?jīng)Q定了HAL分配的ISP通道。合理的做法是預(yù)覽流使用屏幕分辨率同比例的YUV流保持全幀率拍照流獨(dú)立高分辨率流不需要持續(xù)出幀分析流用低分辨率流比如640x480并通過(guò)setMaxImages限制緩沖數(shù)量另一個(gè)容易被忽略的點(diǎn)是aeTargetFpsRange和control.aeMode的聯(lián)動(dòng)。如果應(yīng)用把AE目標(biāo)幀率設(shè)成30fps即使物理Sensor支持60fps出幀HAL也會(huì)按照30fps的節(jié)奏做曝光控制。這個(gè)配置要在RepeatingRequest里持續(xù)攜帶不是設(shè)置一次就完事。2.3 減少阻塞的關(guān)鍵路徑優(yōu)化真正導(dǎo)致時(shí)延飆升的元兇是阻塞而阻塞最常出現(xiàn)在三個(gè)地方ScreenCapture的等待、BufferQueue的背壓、以及應(yīng)用線程的調(diào)度延遲。背壓?jiǎn)栴}尤其值得一提。BufferQueue有容量上限生產(chǎn)速度長(zhǎng)期大于消費(fèi)速度時(shí)生產(chǎn)者會(huì)被迫阻塞。Camera里最典型的一幕是App在onImageAvailable回調(diào)里做耗時(shí)操作占著消費(fèi)線程不放底層ISP已經(jīng)把Buffer填滿了后續(xù)幀只能排隊(duì)甚至丟棄。這個(gè)問(wèn)題的解藥是讓ImageReader的處理線程職責(zé)單一化只負(fù)責(zé)取幀和分發(fā)絕對(duì)不要在這個(gè)回調(diào)里做圖像處理。線程調(diào)度延遲是另一個(gè)隱性殺手。Android在移動(dòng)設(shè)備上默認(rèn)開(kāi)啟了CFS調(diào)度器CameraProvider線程和App主線程的優(yōu)先級(jí)如果不調(diào)整很容易被前臺(tái)渲染任務(wù)搶占。實(shí)踐中我會(huì)把CameraHandler的線程優(yōu)先級(jí)提到THREAD_PRIORITY_DISPLAY同時(shí)避免在這個(gè)線程上執(zhí)行Binder同步調(diào)用。Binder調(diào)用一旦發(fā)生IPC阻塞可能直接引發(fā)幾百毫秒的延遲這在快門時(shí)延優(yōu)化上是致命的。3. Buffer管理是幀率優(yōu)化的重災(zāi)區(qū)深挖丟幀和內(nèi)存抖動(dòng)如果說(shuō)幀率優(yōu)化是從管線層面做加法減法Buffer管理就是從內(nèi)存層面避免自爆。很多Camera項(xiàng)目的OOM和掉幀其實(shí)都是Buffer策略設(shè)計(jì)不合理造成的這塊太值得單獨(dú)拿出來(lái)講了。3.1 為什么Buffer分配會(huì)拖垮CameraAndroid Camera的Buffer管理和Java堆的GC不同它走的是GraphicBuffer這套機(jī)制內(nèi)存來(lái)自SurfaceFlinger或ION分配器。你每次創(chuàng)建一張Image底層就是一次完整的Buffer分配涉及ION內(nèi)存申請(qǐng)、映射、緩存同步代價(jià)比new一個(gè)Bitmap對(duì)象高出幾個(gè)數(shù)量級(jí)。設(shè)想一個(gè)最簡(jiǎn)單的預(yù)覽場(chǎng)景如果每幀出圖都新建Buffer、用完釋放60fps時(shí)一秒就產(chǎn)生60次分配和釋放。這種高頻率的內(nèi)存抖動(dòng)不僅拖慢單幀耗時(shí)還會(huì)觸發(fā)底層內(nèi)存池碎片化最終表現(xiàn)為系統(tǒng)內(nèi)存充足但大塊Buffer分配失敗。3.2 復(fù)用機(jī)制與BufferQueue的正確打開(kāi)方式避免Buffer抖動(dòng)的手段就是復(fù)用。Camera2的流程里ImageReader的Buffer池天然支持復(fù)用但你得正確地設(shè)置參數(shù)和持有方式。關(guān)鍵參數(shù)是setMaxImages。這個(gè)值代表ImageReader最多能同時(shí)持有多少個(gè)Buffer。設(shè)得太小比如設(shè)成1消費(fèi)線程來(lái)不及處理生產(chǎn)者就會(huì)阻塞設(shè)得太大會(huì)浪費(fèi)內(nèi)存尤其是高分辨率場(chǎng)景一個(gè)1080p的YUV Buffer就占3MB甚至更多。我常用的經(jīng)驗(yàn)值是這樣使用場(chǎng)景maxImages取值說(shuō)明預(yù)覽流2~3生產(chǎn)消費(fèi)速度基本匹配不需要太多緩沖拍照流3~5多幀合成需要同時(shí)持有多個(gè)原始幀分析流2盡量降低內(nèi)存占用分析幀不需要高吞吐拿到Image之后記得用image.getPlanes()拿到數(shù)據(jù)后立即image.close()這個(gè)close不是銷毀Buffer而是把Buffer釋放回ImageReader的池子供下一輪復(fù)用。3.3 預(yù)處理幀寬度對(duì)齊的玄學(xué)問(wèn)題這塊是我踩過(guò)很深的坑。曾經(jīng)有個(gè)項(xiàng)目做圖像識(shí)別發(fā)現(xiàn)識(shí)別速度突然掉了一半排查到最后發(fā)現(xiàn)是圖像寬度沒(méi)做對(duì)齊導(dǎo)致的。很多圖像算法庫(kù)要求輸入的圖像寬度是16或32的整數(shù)倍不滿足時(shí)就得做crop或padding。如果你在Java層用Bitmap做crop生成的臨時(shí)Bitmap會(huì)占用大量的Native堆內(nèi)存而且Crop通常需要在主線程做進(jìn)一步加劇卡頓。正確做法是先通過(guò)StreamConfigurationMap.getOutputSizes()拿到Camera支持的輸出尺寸從里面挑一個(gè)滿足算法對(duì)齊要求的分辨率直接讓Camera輸出對(duì)齊后的尺寸這樣底層ISP開(kāi)銷最小也完全避免Java層的二次裁剪。這個(gè)思路同樣適用于NV21轉(zhuǎn)RGB這種格式轉(zhuǎn)換操作能提前在底層解決就不要放到應(yīng)用層處理。4. 功耗與發(fā)熱性能優(yōu)化的另一把尺子性能優(yōu)化不能只看幀率和時(shí)延功耗是這個(gè)游戲里不能回避的另一半。一臺(tái)手機(jī)如果打開(kāi)相機(jī)5分鐘就發(fā)燙降頻幀率再高也是曇花一現(xiàn)用戶體驗(yàn)照樣崩潰。4.1 Camera功耗分布Camera場(chǎng)景的功耗大頭是這幾塊Sensor感光與模組供電、ISP與DSP運(yùn)算、內(nèi)存帶寬消耗、以及屏幕常亮顯示。其中ISP和內(nèi)存帶寬兩塊在App層面最能施加影響。以4K30視頻錄制為例編碼器需要持續(xù)的30fps輸入每幀數(shù)據(jù)量大概在12MB左右一秒的帶寬需求就是360MB。這么高的帶寬會(huì)拉動(dòng)DRAM頻率和總線頻率上調(diào)功耗顯著增加。如果你在錄4K的同時(shí)還開(kāi)了一個(gè)1080p的分析流帶寬幾乎翻倍這也是為什么很多手機(jī)同時(shí)開(kāi)錄像和掃碼會(huì)發(fā)熱嚴(yán)重的原因。4.2 降功耗的實(shí)用手段降功耗不是無(wú)腦降低分辨率而是根據(jù)業(yè)務(wù)場(chǎng)景精細(xì)化配置。我整理過(guò)幾個(gè)在真實(shí)項(xiàng)目中驗(yàn)證有效的策略第一限制分析流的幀率。人臉檢測(cè)、掃碼這些分析任務(wù)不需要30fps例如通過(guò)setRepeatingRequest時(shí)在CONTROL_AE_TARGET_FPS_RANGE之外再配合Surface自身的幀率限制只給分析Surface發(fā)5fps的幀。這個(gè)方法我在多個(gè)項(xiàng)目里用過(guò)預(yù)處理功耗能省一半以上。第二調(diào)整YUV格式。如果業(yè)務(wù)不需要高精度的色彩還原可以把YUV_420_888換成NV12或灰度格式減少數(shù)據(jù)量?；叶雀袷接绕溥m合純紋理分析的場(chǎng)景數(shù)據(jù)量直接降三分之二帶寬和內(nèi)存占用都會(huì)大幅下降。第三利用Thermal狀態(tài)動(dòng)態(tài)降級(jí)。注冊(cè)PowerManager.ThermalStatusListener當(dāng)系統(tǒng)溫度升高時(shí)主動(dòng)降低預(yù)覽幀率或畫(huà)質(zhì)檔位而不是等系統(tǒng)強(qiáng)殺。這個(gè)做法雖然看似保守但用戶感受到的是相機(jī)發(fā)熱了但還能用而不是相機(jī)卡死在黑屏界面。4.3 用FrameStats做功耗基準(zhǔn)測(cè)試功耗優(yōu)化的驗(yàn)證需要量化。我常用的方式是抓取一份長(zhǎng)時(shí)間運(yùn)行的FrameMetrics數(shù)據(jù)統(tǒng)計(jì)平均幀耗時(shí)和幀率分布結(jié)合功耗模型估算內(nèi)存帶寬占用然后用溫升曲線輔助判斷。具體操作方式是開(kāi)啟adb shell dumpsys gfxinfo packageName framestats持續(xù)收集幾分鐘的數(shù)據(jù)重點(diǎn)看FRAME_COMPLETED時(shí)間戳的間隔分布。如果間隔出現(xiàn)周期性跳變說(shuō)明BufferQueue存在周期性阻塞這時(shí)候配合Perfetto看Buffer狀態(tài)就能快速定位。5. 實(shí)戰(zhàn)排障用Systrace和Perfetto定位卡頓的完整思路紙上談兵講再多配置不如動(dòng)手排查一次實(shí)際問(wèn)題。這個(gè)部分我用一次真實(shí)的相機(jī)卡頓排查過(guò)程來(lái)演示完整思路。5.1 抓取一份有效的tracePerfetto是現(xiàn)在排查Android性能問(wèn)題的首選工具Camera場(chǎng)景也不例外。抓取的時(shí)候要注意幾點(diǎn)否則trace是不完整的抓取時(shí)間控制在10~15秒太長(zhǎng)文件巨大不便于分析太短又捕捉不到問(wèn)題窗口抓取前把問(wèn)題操作完整復(fù)現(xiàn)一遍如果問(wèn)題涉及SurfaceFlinger合成還要在adb shell setprop debug.sf.enable_gl_backpressure 1之后再抓。在Perfetto里我重點(diǎn)關(guān)注的Track包括App主線程、CameraProvider線程、SurfaceFlinger的Composition線程以及HAL側(cè)的CameraProvider2.4服務(wù)線程。5.2 關(guān)鍵線程與關(guān)鍵Callback怎么讀拿到trace之后先不要急著看CPU占用率先從Buffer流轉(zhuǎn)的角度走一遍。先看App主線程有沒(méi)有長(zhǎng)時(shí)間卡頓再看CameraProvider線程的空閑比例——如果CameraProvider線程長(zhǎng)期跑滿說(shuō)明HAL側(cè)的幀生產(chǎn)環(huán)節(jié)有問(wèn)題再看App消費(fèi)幀的Callback是否頻繁被阻塞比如onImageAvailable回調(diào)周期明顯拉長(zhǎng)往往是消費(fèi)側(cè)處理不過(guò)來(lái)。我印象很深刻的一個(gè)案例是某機(jī)型預(yù)覽卡頓trace顯示SurfaceFlinger的Composition線程每幀耗時(shí)都超過(guò)30毫秒而CameraProvider線程產(chǎn)出很正常。最后定位到是應(yīng)用在預(yù)覽Surface上疊加了一個(gè)全屏模糊效果導(dǎo)致每個(gè)Layer都需要GPU反復(fù)處理SurfaceFlinger直接成了瓶頸。把模糊效果去掉之后幀率恢復(fù)正常。5.3 一個(gè)典型的Buffer阻塞案例拆解再分享一個(gè)典型的BufferQueue阻塞案例。某App在每秒30fps的預(yù)覽中周期性出現(xiàn)丟幀Perfetto中看到BufferQueue的dequeueBuffer調(diào)用頻繁blocked。順著B(niǎo)ufferQueue的狀態(tài)一路查下去發(fā)現(xiàn)App側(cè)的消費(fèi)者線程在OnImageAvailable的同一個(gè)線程里執(zhí)行了RGB轉(zhuǎn)換和上傳紋理的操作單次耗時(shí)接近50毫秒導(dǎo)致Buffer消費(fèi)速度遠(yuǎn)低于生產(chǎn)速度BufferQueue很快就塞滿了。底層HAL的幀無(wú)處可放只能丟幀自保。這個(gè)案例的解決方案很直接把取幀和圖像處理徹底分離用兩個(gè)線程各司其職。取幀線程只負(fù)責(zé)拿Image、保存引用、快速close圖像處理線程負(fù)責(zé)后續(xù)的轉(zhuǎn)換和算法邏輯。這個(gè)改動(dòng)上線之后丟幀問(wèn)題完全消除。6. 從Framework到HAL層幾個(gè)容易被忽視的優(yōu)化點(diǎn)前面講完了排查思路最后補(bǔ)幾個(gè)我在底層調(diào)優(yōu)中認(rèn)為最容易被應(yīng)用層開(kāi)發(fā)者忽略卻影響巨大的點(diǎn)。6.1 Camera HAL與ISP的配合問(wèn)題HAL層涉及大量ISP相關(guān)的調(diào)優(yōu)很多參數(shù)是平臺(tái)相關(guān)的這里不展開(kāi)具體數(shù)值但有一個(gè)原則值得強(qiáng)調(diào)盡量不要在應(yīng)用層繞過(guò)HAL去做像素級(jí)別的后處理。很多App為了追求美顏效果自己實(shí)現(xiàn)了一套降噪或磨皮算法在onImageAvailable回調(diào)里對(duì)每一幀做全像素遍歷。這種做法不僅占CPU而且效率遠(yuǎn)低于ISP里現(xiàn)成的硬件降噪模塊。如果你確實(shí)需要做美化處理正確姿勢(shì)是把需求提給HAL層的tuning工程師通過(guò)調(diào)整ISP參數(shù)實(shí)現(xiàn)而不是用CPU硬扛。6.2 JVM堆與大圖Bitmap的內(nèi)存管理Camera應(yīng)用是Java堆內(nèi)存消耗大戶尤其是拍照后需要預(yù)覽大圖時(shí)一個(gè)2400萬(wàn)像素的Bitmap在ARGB8888格式下需要96MB內(nèi)存直接把應(yīng)用堆打爆。建議在圖片解碼階段就做好降采樣用BitmapFactory.Options的inSampleSize先縮到屏幕尺寸而不是加載原圖再做壓縮。備選方案是把大圖轉(zhuǎn)成Hardware Bitmap讓它直接借用GraphicBuffer的內(nèi)存池繞開(kāi)Java堆這個(gè)方案對(duì)減少GC壓力效果理想。6.3 分辨率選擇與算法對(duì)齊的隱性約束最后再說(shuō)一次對(duì)齊問(wèn)題因?yàn)檫@真的容易犯。Camera輸出的YUV幀寬度不一定是算法模型輸入的期望值盡量在Camera配置階段找到匹配的分辨率避免在Pipeline中途做Crop。這里的核心原則是所有轉(zhuǎn)換和裁剪盡量發(fā)生在最底層越早處理越省內(nèi)存和帶寬。如果算法要求輸入224x224而Camera輸出的是640x480直接在HAL層做裁剪輸出224x224比在應(yīng)用層取到整幀再縮放高效太多。val map characteristics.get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP) val targetSize map.getOutputSizes(ImageFormat.YUV_420_888) .minByOrNull { abs(it.width - 224) abs(it.height - 224) }這段代碼會(huì)遍歷所有支持的YUV輸出尺寸挑出和算法輸入最接近的一個(gè)。雖然只是幾行代碼但能省掉中間整幀的傳輸帶寬和縮放開(kāi)銷實(shí)際體感差距很大。6.4 多攝協(xié)作場(chǎng)景的帶寬分配策略現(xiàn)在的手機(jī)普遍是多攝方案主攝、廣角、長(zhǎng)焦各自獨(dú)立。多攝同時(shí)出流時(shí)帶寬分配尤其需要權(quán)衡。我之前處理過(guò)一個(gè)項(xiàng)目主攝錄像和長(zhǎng)焦取流同時(shí)進(jìn)行總線帶寬被打滿結(jié)果兩路流的幀率都不穩(wěn)定。解決思路是給高優(yōu)先級(jí)流分配更高的帶寬權(quán)重比如主攝走獨(dú)立的MIPI通道長(zhǎng)焦和廣角共享另一路同時(shí)降低輔助流的分辨率和幀率。這個(gè)需要在HAL層配置時(shí)明確區(qū)分Stream的使用場(chǎng)景我把這類參數(shù)的調(diào)整歸納為連接的流越少越好單流的負(fù)載越均勻越好。比如在HAL層的configureStreams里按業(yè)務(wù)場(chǎng)景分出主用流與備用流備用流始終啟用低功耗模式。比起全部流都全速跑這套策略在幀率和功耗之間找到了一個(gè)更好的平衡點(diǎn)。寫在最后的幾點(diǎn)心得做了這么多年Camera性能優(yōu)化我的體會(huì)是這個(gè)領(lǐng)域沒(méi)有銀彈每一臺(tái)設(shè)備的ISP行為、HAL實(shí)現(xiàn)、傳感器特性都不完全相同A機(jī)型上的優(yōu)化手段搬到B機(jī)型上可能完全失效。但通用的方法論是穩(wěn)定的。把幀率、時(shí)延、Buffer、功耗四件事拆開(kāi)看每一件事都有清晰的優(yōu)化路徑不要試圖用一個(gè)大而全的方案解決所有問(wèn)題。補(bǔ)一個(gè)長(zhǎng)期受益的習(xí)慣優(yōu)化前后都要保留數(shù)據(jù)記錄。幀率曲線、時(shí)延分布、溫升數(shù)據(jù)都存下來(lái)做成對(duì)比圖表。沒(méi)有量化就沒(méi)有說(shuō)服力多個(gè)項(xiàng)目迭代對(duì)比下來(lái)你會(huì)發(fā)現(xiàn)自己對(duì)Camera系統(tǒng)的感知比任何人都敏感。最后分享一個(gè)探測(cè)器小技巧優(yōu)化完記得用adb shell dumpsys media.camera看一下當(dāng)前Camera服務(wù)的狀態(tài)里面能看到各個(gè)Session的活躍情況對(duì)確認(rèn)問(wèn)題是否遺留很有幫助。