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

演講 / 唐雷

整理 / LiveVideoStack

大家下午好，我是來自Camera360的唐雷，今天與大家一同分享Camera360 iOS端的音頻優化。對于一款拍照軟件，貼紙、美妝、特效現在已經成為一種标配，而我們最大的區别在于左下角的相冊——它支持連拍，不需要拍照預覽再去保存。從産品角度，我們最開始隻是簡單的拍照軟件，拍風景再加上一些濾鏡處理，到後面開始添加美妝、貼紙等功能，包括短視頻也有嘗試。

作為技術團隊，整個Camera360産品演變之路就是如何保證産品的質量以及穩定性。而決定拍照軟件的流暢度有幾個因素：分辨率、SDK處理速度、人臉識别速度以及幀率。接下來的内容也會主要分享在這四個方面如何進行優化的。

正确的選擇分辨率

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

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

良好的内存控制

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

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

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

人臉識别

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

時間間隔也是人臉識别中重要的一環，現在的手機吐原始幀Buffer時滿幀是30幀，我們内部滿幀是24幀，而當已經識别到人臉後，是沒有必要每一幀都再去做檢測的，因為人臉信息大緻一樣，我已經可以保證快速切換模式，因此可以調整檢測的時間間隔，比如設置為40幀檢測一次，當取景頁面中沒有人像時則調整為10幀檢測一次，保證當重新出現人像時可以快速上臉。

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

短視頻探索

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

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

動态貼紙——U3D

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

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

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

U3D帶來最大的問題是armv7編譯，armv7在打包時_TEXT_字段不能超過32兆，但我們發現僅僅U3D一個SDK就占了18兆，我們自己SDK占了6兆，這樣其他SDK也隻有8兆的空間可用，雖然現在我們能把包打出來，但也隻剩下幾百K的空間可用。而當我們後期接入Swift後發現加劇了這個問題，在Xcode8中Build setting裡Enable Code Coverage這個設置應該默認Release是No，但是接入Swift會導緻設置失效，結果_TEXT_字段直接飙到70多兆，而且無法降下來，最後也是通過升級到Xcode9解決了這個問題。

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部