作者簡介
孔維樂，七牛雲客戶端團隊 Android 平臺高階開發工程師，專注音視訊，圖形影像領域。OpenGL 專家，先後參與直播推流及連麥 SDK 的開發，主導短視訊 SDK 的架構設計與實現， 對客戶端架構設計及效能優化有豐富經驗。
短視訊發展史
圖 1
圖 1 所示是短視訊及直播的發展史，眾所周知，2016 年是直播元年，在這期間誕生了很多直播平臺，比如熊貓、映客、鬥魚等；而在 2017 年，短視訊的火爆程度並不亞於直播，可能大家都以為短視訊是從 2017 年開始火爆起來的，但其實早在 2015 年就已經誕生出快手、秒拍、美拍等短視訊 App。當時我正好在 YY 從事短視訊 App 相關的工作，來到七牛後，在客戶端團隊先後參與直播、連麥 SDK 的開發，後面開始主研短視訊 SDK，致力做最優秀最好用的短視訊 SDK。
圖 2
2016 年中國移動短視訊使用者數為 1.5 億，今年預計會達到 2.4 億，增長率高達 58.2%，可見短視訊的熱度在一直提升；近幾年，短視訊的生產模式在不斷演進，從 UGC 到 PGC，再到最新的 MCN（Multi-Channel Network），內容的產能和質量均得到了巨大提升。
圖 2 所示是短視訊在各個行業的綜合應用。
研發短視訊 App 的難點
前面介紹完有關短視訊的歷史以及發展趨勢，下面著重介紹一下關於短視訊開發需要的預備知識及難點：
1、音視訊領域固有門檻
深刻理解音視訊編碼格式 H.264 和 AAC 的編碼細節；混音時如何將兩個音訊調整到一致的引數，使用什麼樣的演算法去混合等等。
2、圖形影像、OpenGL 處理
攝像頭預覽資料，影像處理，音視訊編解碼都需要了解 RGB 和 YUV 色彩空間的資料格式，以及它們之間轉換的方式等等；其中部分操作可以利用更高效的 OpenGL 去完成，如美顏濾鏡，圖層混合，放大/縮小，旋轉，還有影像裁剪等等。
3、平臺相關
要對相應平臺的攝像頭、麥克風、編解碼、多媒體處理等 API 十分熟悉，否則它們的一些坑會耗費你大量時間。
4、高階功能
視訊編輯少不了特色和高階的功能，例如美顏，濾鏡，MV 特效，倍數拍攝，文字特效等，每一個高階功能都對各方面技術提出很高的要求。
5、系統版本，機型等相容性問題
這算是一個老生常談的問題，無論 iOS 還是 Android，機型和系統版本都越來越多了，必然會帶來相容性問題。比如會有小部分 Android 機型編碼的視訊在 iOS 端播放不了的情況，類似這種相容性問題都是需要進行解決的。
6、效能以及資源佔用的優化
移動應用的計算資源受到相應系統的嚴格制約，在進行音視訊採集，渲染，編碼等複雜計算的同時，還要確保應用有足夠的資源流暢執行，這要求開發人員有豐富的調優能力。
解決以上的難點是首要的事情，但開發時間也是研發人員必須考慮的問題，開發一款優秀的短視訊 App，從熟悉音視訊領域開始，到解決系統相容性問題，緊接著去編寫複雜業務邏輯，還有相應的UI介面這些工作需要耗費3-6個月的時間，是非常耗費時間和精力的。最開始我們團隊進行短視訊 SDK 開發時也踩過很多坑，用了將近一個月的時間才真正穩定下來，經過沉澱，現在我們針對一款 App 進行短視訊 SDK 的對接，基本一週時間就可以完全搞定。
短視訊 SDK 架構設計
接下來介紹一下我們團隊在進行短視訊 SDK 實踐中主要做的一些事情，這其中最重要的就是短視訊 SDK 的架構設計，包括架構設計理念、架構圖、整體資料流程、模組架構設計等。
1、SDK 架構設計理念
圖 3
說到 SDK 的設計理念必定要提到命名規範，就跟七牛的企業理念「簡單.可信賴」一樣，我們的命名規範是統一、簡單並且精煉的，比如我們將對外的核心類統一以 PLShortVideo 為字首，如圖 3 所示分別是錄製、編輯以及剪輯等模組的命名；引數配置類則均以 PLxxxSetting 為標準進行命名（圖 4）；介面回撥類則均以 PLxxxListener 為標準命名。
圖 4
第二點我們遵循的是高模組化、模組可插拔的一個理念；高模組化必須要保證每個類每個方法都「名副其實」並「各司其職」，這樣才能編寫更清晰的邏輯；高模組化同時可以促進高複用，減少重複程式碼；圖 5 所示是 SDK 內的轉碼核心類，因為編輯、剪輯在最後儲存的時候都需要一個解碼並重新編碼的過程，在這裡，轉碼核心類可以達到一個高複用。
圖 5
圖 6
圖 6 所示為短視訊 SDK 的包體劃分，從表中我們可以清晰地看到每個包體的功能劃分，不同的功能放在了不同的包體當中。我們並沒有使用 ffmpeg 的軟解軟編，而是儘量使用 Android 和 iOS 的系統 API 進行硬編硬解，這樣不僅減少了包體大小，而且速度要快很多，儘管在技術層面上會增加很多難度，會踩很多坑，但我們還是堅持選用這個方案。在引入第三方庫時，我們也都是會經過充分配置和裁剪去嚴格控制包體的大小，這樣一來，所有包體總和才能有現在「小而精」（1.5M）的成果。表中最後的內建濾鏡模組，其中的濾鏡資源可以選擇性拷貝，SDK 內部會自動判斷。這是關於模組設計方面的一些理念。
圖 7
第三點是要和 UI 解耦，如圖 7 所示，是從不同 App 中截圖得到的畫面，可以看出每一個App 都有各自的設計，作為一款短視訊 SDK，是絕對不可以在 UI 方面限制客戶發揮的。市面上有些短視訊 SDK 將 UI 寫死並作為 SDK 的一部分，這樣對於客戶在設計 UI 介面上來說，是非常不友好的；我們採用的是另一種方法，SDK 與 UI 進行解耦，客戶的 UI 是可自定義的，整個 SDK 中接受 view 的地方只有一處：
PLShortVideoRecorder:prepare(GLSurfaceView preview, …)
接著是擴充套件性這一塊，我們遵循高擴充套件，開放性的理念。在錄製以及編輯過程中，都會有資料的回撥並支援第三方庫進行美顏，濾鏡，貼紙，特效等功能。
最後是關於可配置引數方面的設計，除了常規引數，比如攝像頭解析度和幀率、麥克風取樣率等可以進行配置之外，包括美顏等引數也都是可以進行配置的。
2、短視訊SDK架構
圖 8
圖 8 所示為 Android 短視訊 SDK 的架構圖，可以劃分為四層。第一層為應用層（基於 SDK 開發的應用）；第二層為 SDK 對外的介面層（均以 PLShortVideo 為字首）；第三層為核心層，主要是內部的一些模組（其中分 Java 和 Native 兩塊）；第四層主要是 Android 系統層。
圖 9
圖 9 所示是整體資料流程圖；輸入模組支援通過兩種方式採集資料，一種是通過攝像頭和麥克風採集資料，採集到的資料可以進行資料處理（美顏、人臉識別等），另一種則是通過檔案匯入並進行解碼處理；編輯模組有著十分豐富的功能比如新增字幕、MV 特效、新增背景音樂等等；編碼模組主要支援 H.264 軟編/硬編以及 ACC 軟編/硬編；編碼之後的資料會進行 MP4 封包，此後進入輸出模組，可以儲存到本地也可以使用 HTTP 進行上傳。下面將著重就幾個模組進行介紹。
圖 10
圖 10 為錄製模組的示意圖。錄製模組的重點在於幀資料獲取，除了可以通過攝像頭獲取視訊幀，還可以通過螢幕錄製獲取視訊幀，而音訊幀資料主要還是通過麥克風進行獲取；虛線部分的 Filter 模組主要實現了內建美顏/濾鏡功能，另外因為有紋理和 YUV 資料的 CallBack 回撥機制，所以也支援第三方庫的美顏、濾鏡、特效等功能；處理後的資料會經過 OpenGL 進行裁剪，縮放，旋轉等操作，這些工作雖然可以由 CPU 來進行，但是會比較耗時，利用 GPU 是更明智的選擇；最後得到紋理後，會被分成兩路，一路渲染顯示，另一路進行編碼封裝，這兩個執行緒共享同一個紋理，這樣的處理大大減少了資源的佔用，提高了 SDK 的工作效率。
圖 11
圖 11 所示為編輯模組的示意圖。首先需要匯入一個視訊檔案（使用短視訊 SDK 拍攝或者從外部匯入的視訊檔案），解包之後會得到相應的幀資料，接著分別通過音視訊解碼器得到 PCM 和紋理，然後把它們送進編輯引擎，在這裡面可以進行各種各樣的處理（水印、文字特效、背景音樂、多音訊混音等）資料經過編輯之後，與錄製相同會分兩路，其中一路進行播放渲染，另一路會進行轉碼儲存。
圖 12
圖 12 所示是 MV 特效的實現思路。通過攝像頭採集的資料無需解碼，而 MV 視訊檔案的幀資料則需要解碼後才可以進行處理。SurfaceTexture 的主要作用是將解碼後的資料幀進行回撥通知你可以在 OpenGL 執行緒中更新紋理了，這個通知可以是多執行緒同時進行的操作，所以在幀回撥時一定要對其進行上鎖，防止出現 MV 畫面之間不同步的問題。更新之後得到相應的紋理，將其進行混合就能得出最後的 MV 特效圖。
圖 13
圖 13 為日誌系統的模組圖。日誌系統主要是為了方便排障，快速定位問題以及除錯問題，我們會將 SDK 版本、裝置機型、系統版本，關鍵配置等一一進行輸出，以方便使用者根據這些資訊進行排障。
踩過的坑
當然，研發過程不可能一帆風順，總要踩過一些坑才能使整個 SDK 更加完善。下面就列舉一些我們踩過的坑以及排查的過程。
部分視訊剪輯出現花屏
圖 14
我們通過對客戶提供的一些樣本視訊進行分析後，發現出問題的都是帶有雙向引用 B 幀的 High profile 視訊，如圖 14 所示，B 幀（3）位於中間，其引用左右兩邊的 P 幀（2、4）在顯示時是這樣的順序，但是在進行幀儲存以及視訊解碼時，B 幀（3）是在這 2 個 P 幀其後的。
在使用 MediaMuxer 封包時有要求下一幀的 PTS 必須大於等於上一幀的 PTS, 也就是：
i +1 幀 PTS >= i 幀 PTS
而 MediaExtractor 讀出視訊幀是按照 DTS 順序的，也就是 PTS 是會有回退的，所以問題就出在這裡了，按照 DTS 的順序去重新封包，必然會導致後方的 B 幀被丟掉，這樣就導致了花屏的問題。目前 MediaMuxer 在 Android 7.0+ 才支援對 B 幀封包，因此除非你的 APP 最低相容到 7.0，否則建議選擇使用 FFMpeg 進行封包。
最後給大家分享一句話，也算是對自己的一個鼓勵，就是「Fake it until you make it」。對於我們客戶端團隊，要將 SDK 打磨到最完美的狀態我們進行了很多嘗試，也歷經了很多血淚，最後才有今天的成果，我們需要努力的地方也還有很多，也會再接再厲，謝謝大家！
-END-