伴隨貼紙、短視頻越來越火爆，這兩項功能也基本成為各大拍照App的標配，但每個App的技術(shù)路線又都有所不同。Camera360 iOS技術(shù)負責(zé)人唐雷在LiveVideoStack Meet上與我們分享了Camera360在iOS端新玩法的探索嘗試、技術(shù)實現(xiàn)以及遇到的坑和優(yōu)化方案。

演講 / 唐雷

整理 / LiveVideoStack

大家下午好，我是來自Camera360的唐雷，今天與大家一同分享Camera360 iOS端的音頻優(yōu)化。對于一款拍照軟件，貼紙、美妝、特效現(xiàn)在已經(jīng)成為一種標配，而我們最大的區(qū)別在于左下角的相冊——它支持連拍，不需要拍照預(yù)覽再去保存。從產(chǎn)品角度，我們最開始只是簡單的拍照軟件，拍風(fēng)景再加上一些濾鏡處理，到后面開始添加美妝、貼紙等功能，包括短視頻也有嘗試。

作為技術(shù)團隊，整個Camera360產(chǎn)品演變之路就是如何保證產(chǎn)品的質(zhì)量以及穩(wěn)定性。而決定拍照軟件的流暢度有幾個因素：分辨率、SDK處理速度、人臉識別速度以及幀率。接下來的內(nèi)容也會主要分享在這四個方面如何進行優(yōu)化的。

正確的選擇分辨率

對于用戶而言，第一感受也是最直觀的感受就是照片是否會糊，這一點對女性用1戶更為重要，而影響照片糊的最大影響因素就是分辨率。不同手機的分辨率也是不一樣的，正確選擇分辨率就顯得至關(guān)重要，因此我們也是長期在做手機分辨率的測試。Camera360全球有８億用戶，而其中一半以上都在東南亞——泰國、越南，對于這些國家iPhone4,4s以及5是主要機型，而網(wǎng)絡(luò)條件也會相對差很多。

這張表格是我們對拍照導(dǎo)出分辨率的方案，iPhone 6以前的機型使用導(dǎo)出分辨率就是依照200萬的拍照分辨率，6代和7代基本是以手機前置攝像頭的分辨率規(guī)定，而iPhone8因為自身機器性能較好，我們則是選擇導(dǎo)出原圖。雖然7和7Plus攝像頭分辨率和8代相同，但內(nèi)存消耗相對比較高，因此無法按照原圖導(dǎo)出。

良好的內(nèi)存控制

在對分辨率調(diào)優(yōu)后，我們就需要考慮內(nèi)存控制問題。對于一張200萬的照片，它的內(nèi)存使用率就是200萬（像素）乘以4（RGBA的4個通道）再除以1024、除以1024，也就是7.6兆，而前面提到Camera360的一個特色就是連拍功能，它就會產(chǎn)生幾個照片的拷貝，特別在底層SDK做渲染的時候也會做雙緩沖，這樣一張照片就等于有幾個實例，大概要消耗掉30幾兆的內(nèi)存。同時對于拍完的照片，我們首先會存一張80萬的圖片在沙盒，再去根據(jù)不同機型自動導(dǎo)出不同分辨率的照片。

這張表格是我們對iPhone6和6Plus內(nèi)存消耗的測試，它們的基準分辨率都是200萬。假如做一張200萬的圖進到相機取景頁面，并把所有資源加載完之后的內(nèi)存是155兆，當(dāng)我拍一張照片時峰值可以到218兆，這其中的內(nèi)存差值就有63兆，當(dāng)然普通的平均值大致在30兆左右；假如對400萬和800萬的圖做測試，雖然兩者渲染時內(nèi)存的波動不大，但內(nèi)存峰值（也就是實際內(nèi)存）的波動是很大的，在iPhone6上400萬的圖最大消耗96兆內(nèi)存，800萬則需要163兆，而iPhone實測的崩潰值大致在360-440兆，最大崩潰內(nèi)存是645兆，也就是拍兩張照片內(nèi)存就已經(jīng)很滿了。而對于6Plus而言，200萬的圖就已經(jīng)需要消耗很大內(nèi)存了。

這是我們做的不同機型的連拍崩潰測試。比如iPhone6在快速點擊拍照大致20次左右就會崩潰，因為此時隊列已經(jīng)被塞滿了，即使處理再快或者有異步線程隊列依然無法解決。因此我們做了冷卻處理的優(yōu)化，其實對于真實用戶如此頻繁點擊拍照是不可能的，而且系統(tǒng)相機也不允許這么快的拍照，它自身調(diào)用系統(tǒng)API的時間也會有延遲。同時我們內(nèi)部也建立了性能監(jiān)控系統(tǒng)，包括“鷹眼系統(tǒng)”來記錄日志，我們可以實時看到當(dāng)前特效、美妝、貼紙的渲染速度，幀率、人臉識別速度，App內(nèi)存使用情況、剩余內(nèi)存情況、渲染總時間等等這些關(guān)鍵數(shù)值，并且通過“鷹眼系統(tǒng)” 記錄下來，綠色代表在可控范圍內(nèi)、黃顏色代表警告、紅色則表示出現(xiàn)問題。

人臉識別

提到美妝和貼紙，不可或缺的技術(shù)就是人臉識別，人臉一共有106個點位，基于一些點位就可以去做貼紙的貼合算法。人臉識別基本有兩種算法：精準模式和快速識別模式。當(dāng)拍一張照片時，Camera360內(nèi)部會判斷拍照者人臉區(qū)域變動幅度，當(dāng)變動較小時會切換到精準模式，這時人臉識別度是非常高的，貼合度也很高，即使由于鏡片反光出現(xiàn)的眼睛也是可以區(qū)分出來的；而快速識別模式則是針對人臉區(qū)域出現(xiàn)變動較大，這時我們會取第一個點和最后一個點，而中間過程則是通過算法計算出移動軌跡，這種方法在短視頻的貼紙動態(tài)貼合上比較明顯。

時間間隔也是人臉識別中重要的一環(huán)，現(xiàn)在的手機吐原始幀Buffer時滿幀是30幀，我們內(nèi)部滿幀是24幀，而當(dāng)已經(jīng)識別到人臉后，是沒有必要每一幀都再去做檢測的，因為人臉信息大致一樣，我已經(jīng)可以保證快速切換模式，因此可以調(diào)整檢測的時間間隔，比如設(shè)置為40幀檢測一次，當(dāng)取景頁面中沒有人像時則調(diào)整為10幀檢測一次，保證當(dāng)重新出現(xiàn)人像時可以快速上臉。

很多自拍用戶都喜歡仰望星空的45度角拍照，但這樣就有可能會導(dǎo)致只識別出一個眼睛或者嘴的點位不齊全等情況，進而導(dǎo)致貼合度出現(xiàn)問題，但這個問題至今也還沒有解決。最后一個問題就是人臉識別比較消耗CPU和GPU，與我們的SDK搶占資源導(dǎo)致手機發(fā)熱、發(fā)燙，因此我采用延遲處理的方式，包括前面提到動態(tài)調(diào)整算法的時間間隔，當(dāng)已識別人臉后適當(dāng)增大間隔時間，以及切換模式的方法來減小SDK功率消耗。

短視頻探索

在做短視頻的探索中我們也發(fā)現(xiàn)了一些坑，首先是我們采取的方案是邊錄邊寫，也就是原始buffer會通過SDK處理后進入隊列，我們會同步對處理好的Buffer開始寫視頻，最后再和音頻合并。需要注意的一點這里的視頻是無聲的，因此我們需要錄制現(xiàn)場聲音，這時就會面臨麥克風(fēng)的選擇問題，iPhone4和4S有2個麥克風(fēng)，到了iPhone5則有3個，6S之后更是有4個麥克風(fēng)，其中一個是專門做降噪處理的。而iPhone一共有2個功放——聽筒和底部，如果采集人聲的麥克風(fēng)和功放在同一個位置，那么素材聲音就會把人聲給蓋住。因此在使用前置攝像頭時會從前置攝像頭旁邊的麥克風(fēng)收聲，使用后置攝像頭時會切換到閃光燈旁邊的麥克風(fēng)。

用戶對于拍攝的視頻會要求盡量小，同時還要保證清晰度足夠高，因此視頻參數(shù)設(shè)置也是一個關(guān)鍵。我們也參考了行業(yè)中一些App，發(fā)現(xiàn)碼率基本選擇在1500-2000之間，因為我們自身濾鏡特效對色彩飽和度的一些要求，我們選擇了1800的碼率，尺寸則是屏幕的1.5倍，這樣保證制作出來的10秒視頻，大小基本能控制在2兆以內(nèi)。

動態(tài)貼紙——U3D

貼紙的研發(fā)此前我們是使用C++、OpenGL自己內(nèi)部處理，但貼合度、素材以及調(diào)試卻存在很多問題，最終我們選擇了U3D。它的優(yōu)勢最直觀的就是貼紙素材高了一個檔次，在特效和素材貼合度上都有很大提升；而且使用U3D還可以加入一些游戲場景，比如利用碰撞檢測達到用嘴吃掉天上掉下來的甜甜圈，增添了更多的樂趣性；第三U3D的開發(fā)效率高，相比用OpenGL和C++底層SDK，由于它們是JSON文件沒有平臺，開發(fā)效率、調(diào)試會很糟糕，而U3D引擎本身的平臺就可以支持；最后它的可擴展性很高，可以預(yù)見AR是未來發(fā)展的一個方向，因此我們也希望可以借此做一些嘗試。

我們在使用U3D時特別做了一個雙緩沖策略——特效處理在異步線程、U3D渲染在主線程，一開始原始Buffer傳入SDK Queue從兩個紋理字段找一個空閑的做渲染，然后把紋理傳給Rendering Queue，Unity Queue不停的從Rendering Queue詢問是否有新的紋理，有就取過來做Unity渲染，然后把渲染結(jié)果呈現(xiàn)在屏幕上，再把空的紋理傳回Rendering Queue，然后SDK Queue不停的詢問Rendering Queue是否有新的空閑紋理，有就拿回來準備做新的渲染。

當(dāng)然U3D也存在一些負面影響：首先是在安卓上我們的SDK跟U3D引擎有一些沖突從而導(dǎo)致啟動慢；第二是發(fā)熱，這主要是人臉識別SDK和底層SDK性能搶占的問題；而發(fā)熱也帶來了另一個問題——CPU降頻，幀率會降到非常低，只有一兩幀。還有就是素材包資源比較大，即使我們做了WebP的優(yōu)化，但依然沒有非常明顯的改善。

U3D帶來最大的問題是armv7編譯，armv7在打包時_TEXT_字段不能超過32兆，但我們發(fā)現(xiàn)僅僅U3D一個SDK就占了18兆，我們自己SDK占了6兆，這樣其他SDK也只有8兆的空間可用，雖然現(xiàn)在我們能把包打出來，但也只剩下幾百K的空間可用。而當(dāng)我們后期接入Swift后發(fā)現(xiàn)加劇了這個問題，在Xcode8中Build setting里Enable Code Coverage這個設(shè)置應(yīng)該默認Release是No，但是接入Swift會導(dǎo)致設(shè)置失效，結(jié)果_TEXT_字段直接飆到70多兆，而且無法降下來，最后也是通過升級到Xcode9解決了這個問題。

以上是全部分享，謝謝大家。

LiveVideoStack招募全職技術(shù)編輯和社區(qū)編輯

LiveVideoStack是專注在音視頻、多媒體開發(fā)的技術(shù)社區(qū)，通過傳播最新技術(shù)探索與應(yīng)用實踐，幫助技術(shù)人員成長，解決企業(yè)應(yīng)用場景中的技術(shù)難題。如果你有意為音視頻、多媒體開發(fā)領(lǐng)域發(fā)展做出貢獻，歡迎成為LiveVideoStack社區(qū)編輯的一員。你可以翻譯、投稿、采訪、提供內(nèi)容線索等。

通過contribute@livevideostack.com聯(lián)系，或在LiveVideoStack公眾號回復(fù)『技術(shù)編輯』或『社區(qū)編輯』了解詳情。

總結(jié)

以上是生活随笔為你收集整理的U3D激发拍照新活力，Camera360优化之旅的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。