上個(gè)月幫一個(gè)團(tuán)隊(duì)排查攝像頭啟動(dòng)慢的問題用戶反饋從點(diǎn)擊圖標(biāo)到預(yù)覽畫面出現(xiàn)要等將近兩秒而且打開相機(jī)后手機(jī)溫度明顯上升。拆開看trace才發(fā)現(xiàn)光Buffer分配和格式轉(zhuǎn)換就耗掉了700多毫秒真正留給ISP出圖的時(shí)間反而不多。這種問題在Android Camera場(chǎng)景里太典型了——硬件參數(shù)看起來很強(qiáng)實(shí)際體驗(yàn)卻被軟件鏈路的低效拖垮。這篇文章我會(huì)結(jié)合Camera的多層架構(gòu)把性能優(yōu)化的關(guān)鍵路徑、Buffer管理、功耗控制、以及排查手段完整講一遍所有方案都是我在真機(jī)上調(diào)過的可以直接當(dāng)成一份排查手冊(cè)用。1. 先摸清Camera全鏈路架構(gòu)性能瓶頸幾乎沒在相機(jī)本身做性能優(yōu)化最大的忌諱是拿到問題就猜猜錯(cuò)了方向后面全白干。Camera的性能問題更是如此因?yàn)橐粠嬅鎻墓饩€進(jìn)入傳感器到最終呈現(xiàn)在屏幕上中間要穿越應(yīng)用進(jìn)程、Framework服務(wù)、HAL層、內(nèi)核驅(qū)動(dòng)四條防線哪一層堵住都會(huì)表現(xiàn)為卡頓、掉幀、延遲大。1.1 一條預(yù)覽幀從傳感器到屏幕要經(jīng)過哪些環(huán)節(jié)先看一條最基礎(chǔ)的預(yù)覽幀鏈路。Sensor采集到RAW數(shù)據(jù)后ISP做去噪、壞點(diǎn)校正、色彩插值輸出YUV或RAW幀這份幀數(shù)據(jù)被放進(jìn)BufferQueue應(yīng)用層通過SurfaceTexture或ImageReader取出來做業(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ì)信息來做收斂在暗光環(huán)境下迭代次數(shù)會(huì)明顯增加單幀的統(tǒng)計(jì)耗時(shí)可能從1毫秒漲到5毫秒以上。如果你發(fā)現(xiàn)暗光下預(yù)覽幀率掉得厲害大概率是3A收斂花了太多時(shí)間而不是Sensor本身跑不動(dòng)。1.3 判斷瓶頸歸屬的優(yōu)先級(jí)順序很多開發(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í)反著來先用Perfetto看全局確認(rèn)瓶頸在APP進(jìn)程還是系統(tǒng)服務(wù)再逐層往下定位。這個(gè)思路貫穿全篇后面所有優(yōu)化手段都是圍繞這個(gè)排查順序展開的。2. 幀率與時(shí)延優(yōu)化從Pipeline層面壓榨每一幀的耗時(shí)幀率上不去、時(shí)延壓不下來這是Camera優(yōu)化最高頻的兩個(gè)訴求。很多項(xiàng)目把目標(biāo)定成預(yù)覽要達(dá)到60fps、拍照零快門時(shí)延但實(shí)現(xiàn)路徑完全想反了——只顧著調(diào)大ISP頻率沒有先做管線層面的減法。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)超過16.6毫秒掉幀立刻出現(xiàn)。而到了暗光環(huán)境曝光時(shí)間可能直接占掉10毫秒以上這時(shí)候如果HAL還堅(jiān)持用高幀率配置畫面就會(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í)開多幀合成提升畫質(zhì)這個(gè)策略在底層只需要通過android.control.aeTargetFpsRange設(shè)置不同的range但帶來的體驗(yàn)提升非常明顯用戶不會(huì)感知到預(yù)覽變卡反而會(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)目里就遇到過后臺(tái)加了一個(gè)人臉檢測(cè)流之后預(yù)覽幀率直接從60fps掉到30fps而人臉檢測(cè)本身每秒只需要5幀。這背后其實(shí)是對(duì)Stream配置的理解問題。在createCaptureSession時(shí)每個(gè)Surface的尺寸和格式?jīng)Q定了HAL分配的ISP通道。合理的做法是預(yù)覽流使用屏幕分辨率同比例的YUV流保持全幀率拍照流獨(dú)立高分辨率流不需要持續(xù)出幀分析流用低分辨率流比如640x480并通過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è)問題的解藥是讓ImageReader的處理線程職責(zé)單一化只負(fù)責(zé)取幀和分發(fā)絕對(duì)不要在這個(gè)回調(diào)里做圖像處理。線程調(diào)度延遲是另一個(gè)隱性殺手。Android在移動(dòng)設(shè)備上默認(rèn)開啟了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)如果說幀率優(yōu)化是從管線層面做加法減法Buffer管理就是從內(nèi)存層面避免自爆。很多Camera項(xiàng)目的OOM和掉幀其實(shí)都是Buffer策略設(shè)計(jì)不合理造成的這塊太值得單獨(dú)拿出來講了。3.1 為什么Buffer分配會(huì)拖垮CameraAndroid Camera的Buffer管理和Java堆的GC不同它走的是GraphicBuffer這套機(jī)制內(nè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的正確打開方式避免Buffer抖動(dòng)的手段就是復(fù)用。Camera2的流程里ImageReader的Buffer池天然支持復(fù)用但你得正確地設(shè)置參數(shù)和持有方式。關(guān)鍵參數(shù)是setMaxImages。這個(gè)值代表ImageReader最多能同時(shí)持有多少個(gè)Buffer。設(shè)得太小比如設(shè)成1消費(fèi)線程來不及處理生產(chǎn)者就會(huì)阻塞設(shè)得太大會(huì)浪費(fèi)內(nèi)存尤其是高分辨率場(chǎng)景一個(gè)1080p的YUV Buffer就占3MB甚至更多。我常用的經(jīng)驗(yàn)值是這樣使用場(chǎng)景maxImages取值說明預(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é)問題這塊是我踩過很深的坑。曾經(jīng)有個(gè)項(xiàng)目做圖像識(shí)別發(fā)現(xiàn)識(shí)別速度突然掉了一半排查到最后發(fā)現(xiàn)是圖像寬度沒做對(duì)齊導(dǎo)致的。很多圖像算法庫(kù)要求輸入的圖像寬度是16或32的整數(shù)倍不滿足時(shí)就得做crop或padding。如果你在Java層用Bitmap做crop生成的臨時(shí)Bitmap會(huì)占用大量的Native堆內(nèi)存而且Crop通常需要在主線程做進(jìn)一步加劇卡頓。正確做法是先通過StreamConfigurationMap.getOutputSizes()拿到Camera支持的輸出尺寸從里面挑一個(gè)滿足算法對(duì)齊要求的分辨率直接讓Camera輸出對(duì)齊后的尺寸這樣底層ISP開銷最小也完全避免Java層的二次裁剪。這個(gè)思路同樣適用于NV21轉(zhuǎn)RGB這種格式轉(zhuǎn)換操作能提前在底層解決就不要放到應(yīng)用層處理。4. 功耗與發(fā)熱性能優(yōu)化的另一把尺子性能優(yōu)化不能只看幀率和時(shí)延功耗是這個(gè)游戲里不能回避的另一半。一臺(tái)手機(jī)如果打開相機(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í)還開了一個(gè)1080p的分析流帶寬幾乎翻倍這也是為什么很多手機(jī)同時(shí)開錄像和掃碼會(huì)發(fā)熱嚴(yán)重的原因。4.2 降功耗的實(shí)用手段降功耗不是無(wú)腦降低分辨率而是根據(jù)業(yè)務(wù)場(chǎng)景精細(xì)化配置。我整理過幾個(gè)在真實(shí)項(xiàng)目中驗(yàn)證有效的策略第一限制分析流的幀率。人臉檢測(cè)、掃碼這些分析任務(wù)不需要30fps例如通過setRepeatingRequest時(shí)在CONTROL_AE_TARGET_FPS_RANGE之外再配合Surface自身的幀率限制只給分析Surface發(fā)5fps的幀。這個(gè)方法我在多個(gè)項(xiàng)目里用過預(yù)處理功耗能省一半以上。第二調(diào)整YUV格式。如果業(yè)務(wù)不需要高精度的色彩還原可以把YUV_420_888換成NV12或灰度格式減少數(shù)據(jù)量。灰度格式尤其適合純紋理分析的場(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ù)覽幀率或畫質(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)存帶寬占用然后用溫升曲線輔助判斷。具體操作方式是開啟adb shell dumpsys gfxinfo packageName framestats持續(xù)收集幾分鐘的數(shù)據(jù)重點(diǎn)看FRAME_COMPLETED時(shí)間戳的間隔分布。如果間隔出現(xiàn)周期性跳變說明BufferQueue存在周期性阻塞這時(shí)候配合Perfetto看Buffer狀態(tài)就能快速定位。5. 實(shí)戰(zhàn)排障用Systrace和Perfetto定位卡頓的完整思路紙上談兵講再多配置不如動(dòng)手排查一次實(shí)際問題。這個(gè)部分我用一次真實(shí)的相機(jī)卡頓排查過程來演示完整思路。5.1 抓取一份有效的tracePerfetto是現(xiàn)在排查Android性能問題的首選工具Camera場(chǎng)景也不例外。抓取的時(shí)候要注意幾點(diǎn)否則trace是不完整的抓取時(shí)間控制在10~15秒太長(zhǎng)文件巨大不便于分析太短又捕捉不到問題窗口抓取前把問題操作完整復(fù)現(xià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主線程有沒有長(zhǎng)時(shí)間卡頓再看CameraProvider線程的空閑比例——如果CameraProvider線程長(zhǎng)期跑滿說明HAL側(cè)的幀生產(chǎn)環(huán)節(jié)有問題再看App消費(fèi)幀的Callback是否頻繁被阻塞比如onImageAvailable回調(diào)周期明顯拉長(zhǎng)往往是消費(fèi)側(cè)處理不過來。我印象很深刻的一個(gè)案例是某機(jī)型預(yù)覽卡頓trace顯示SurfaceFlinger的Composition線程每幀耗時(shí)都超過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。順著BufferQueue的狀態(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)上線之后丟幀問題完全消除。6. 從Framework到HAL層幾個(gè)容易被忽視的優(yōu)化點(diǎn)前面講完了排查思路最后補(bǔ)幾個(gè)我在底層調(diào)優(yōu)中認(rèn)為最容易被應(yīng)用層開發(fā)者忽略卻影響巨大的點(diǎn)。6.1 Camera HAL與ISP的配合問題HAL層涉及大量ISP相關(guān)的調(diào)優(yōu)很多參數(shù)是平臺(tái)相關(guān)的這里不展開具體數(shù)值但有一個(gè)原則值得強(qiáng)調(diào)盡量不要在應(yīng)用層繞過HAL去做像素級(jí)別的后處理。很多App為了追求美顏效果自己實(shí)現(xiàn)了一套降噪或磨皮算法在onImageAvailable回調(diào)里對(duì)每一幀做全像素遍歷。這種做法不僅占CPU而且效率遠(yuǎn)低于ISP里現(xiàn)成的硬件降噪模塊。如果你確實(shí)需要做美化處理正確姿勢(shì)是把需求提給HAL層的tuning工程師通過調(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)存池繞開Java堆這個(gè)方案對(duì)減少GC壓力效果理想。6.3 分辨率選擇與算法對(duì)齊的隱性約束最后再說一次對(duì)齊問題因?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è)。雖然只是幾行代碼但能省掉中間整幀的傳輸帶寬和縮放開銷實(shí)際體感差距很大。6.4 多攝協(xié)作場(chǎng)景的帶寬分配策略現(xiàn)在的手機(jī)普遍是多攝方案主攝、廣角、長(zhǎng)焦各自獨(dú)立。多攝同時(shí)出流時(shí)帶寬分配尤其需要權(quán)衡。我之前處理過一個(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)域沒有銀彈每一臺(tái)設(shè)備的ISP行為、HAL實(shí)現(xiàn)、傳感器特性都不完全相同A機(jī)型上的優(yōu)化手段搬到B機(jī)型上可能完全失效。但通用的方法論是穩(wěn)定的。把幀率、時(shí)延、Buffer、功耗四件事拆開看每一件事都有清晰的優(yōu)化路徑不要試圖用一個(gè)大而全的方案解決所有問題。補(bǔ)一個(gè)長(zhǎng)期受益的習(xí)慣優(yōu)化前后都要保留數(shù)據(jù)記錄。幀率曲線、時(shí)延分布、溫升數(shù)據(jù)都存下來做成對(duì)比圖表。沒有量化就沒有說服力多個(gè)項(xiàng)目迭代對(duì)比下來你會(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)問題是否遺留很有幫助。