android音

㈠ Android音視頻【八】音頻基礎

前些文章講了視頻，我們開始音頻。

開始介紹前，先看一個聲音的波形圖：

聲音是一種壓力波，當敲擊鍵盤或者撞擊物體時，它們的震動會引起空氣的震動，使空氣產生疏密變化，由此就形成了一種聲波。

聲波的三要素是頻率、振幅、和波形，頻率代表音階的高低，振幅代表響度，波形代表音色。

頻率 ： 頻率 越高，波長越短，低頻聲響的波長則越長，所以更容易越過障礙物，能量衰減就小，聲音傳播的就遠。反之則會得到相反的結論。

振幅：用不同的力度敲擊物體，它的聲音大小不一樣，它的能量也不一樣，聲音越大振幅越高。

波形/音色： 音色就是在同樣的頻率（音調）和響度（振幅）下，敲擊鍵盤或者撞擊物體是完全不同的。波的形狀代表了聲音的音色。

如何進行聲音進行保存呢？ 對聲音的采樣常用麥克風等設備將聲音信號轉換成電信號，再用模/數轉換器將電信號轉換成一串用1和0表示的二進制數字（數字信號）。每秒對聲音采樣上萬次，獲得上萬個按照時間順序排列的二進制數字，然後將連續變化不斷的聲音轉化成了計算機可儲存並識別的二進制數字。

為了將模擬信號數字化，需要進行：采樣，量化，編碼。

首先要對模擬信號進行采樣，所謂采樣就是在時間軸上對信號進行數字化。根據奈奎斯特定理（也稱采樣定理），按比聲音最高頻率高 2 倍以上的頻率對聲音進行采樣，對於高質量的音頻信號，其頻率范圍在 20Hz ~ 20kHz ，所以采樣頻率一般為 44.1kHz ,這樣就保證采樣聲音達到 20kHz 也能被數字化，從而使得經過數字化處理之後，人耳聽到的聲音質量不會被降低。而所謂的 44.1 kHz 就是代表 1 s 會采樣 44100 次。

每個采樣又該如何表示呢？進行量化。量化是指在幅度軸上對信號進行數字化。量化位數越大，聲音的質量越高。常用的量化位數有8位、16位和32位。量化位數指用幾位二進制數來存儲采樣獲得的數據。量化位數為8即指用8位二進制數來存儲數據，如0001011

比如用 16 bit 的二進制信號來表示聲音的一個采樣，而 16 bit 所表示的范圍是 [-32768 , 32767] , 共有 65536 個可能取值，因此最終模擬的音頻信號在幅度上也分為了 65536 層。

編碼，就是按照一定的格式記錄采樣和量化後的數字數據，比如順序存儲或壓縮存儲等等蠢凱。

這里涉及了很多種格式，通常所說的音頻的裸數據就是 PCM (Pulse Code Molation) 數據。描述一段 PCM 數據一般需要以下幾個概念：量化格式(sampleFormat)、采樣率（sampleRate）、聲道數 (channel) 。以 CD 的音質為例：量化格式為 16 bit （2 byte）,采樣率 44100 ，帶嘩喚聲道數為 2 ，這些信息就描述了 CD 的音質。而對於聲音的格式，還有一個概念用來描述它的大小，稱為數據比特率，即 1s 時間內的比特數目，它用於衡量音頻數據單位時間內的容量大小。而對於 CD 音質的數據，比特率為多少呢？ 計算如下:

那麼在一分鍾里，這類 CD 音質的數據需要佔據多大的存儲空間呢？計算如下:

當然，如果 sampleFormat 更加精確 (比如用 4 個位元組來描述一個采樣)，或者 sampleRate 更加密集 (比如 48kHz 的采樣率)， 那麼所佔的存儲空間就會更大，同時能夠描述的聲音細節就會越精確。存儲的這段二進制數據即表示將模擬信號轉為數字信號了，以後就可以對這段二進制數據進行存儲，播放，復制，或者進行其它操作。

關於這3個過程，可以看下這篇文章，圖形表示采樣，量化，編碼的過程更容易理解。 https://www.bilibili.com/read/cv1771961/

所以說：

1）采樣：在時間軸上對信號數字化；

2）量化：在幅度軸上對信號數字化；

3）編碼：按一定格式記錄采樣和量化後的數字數據。

聲道（sound channel）是指聲音在錄制或播放時在不同空間位置採集或回放的相互獨立的音頻信號，所以聲道數也就是聲音錄制時的聲音源數量或者回放時相應的揚聲器數量。

常見的有：單聲道，立體聲道蘆拆，4聲道，5.1聲道，7.1聲道等。在移動端一般是單聲道，立體聲道。

上面提到了 CD 音質的數據采樣格式，曾計算出每分鍾需要的存儲空間約為 10.09 MB ,如果僅僅是將其存儲在光碟或者硬碟中，可能是可以接受的，但是若要在網路中實時在線傳輸的話，那麼這個數據量可能就太大了，所以必須對其進行壓縮編碼。壓縮編碼的基本指標之一就是壓縮比，壓縮比通常小於 1 。壓縮演算法包括有損壓縮和無損壓縮。無損壓縮是指解壓後的數據可以完全復原。在常用的壓縮格式中，用的較多的是有損壓縮，有損壓縮是指解壓後的數據不能完全恢復，會丟失一部分信息，壓縮比越小，丟失的信息就比越多，信號還原後的失真就會越大。根據不同的應用場景 (包括存儲設備、傳輸網路環境、播放設備等)，可以選用不同的壓縮編碼演算法，如 PCM 、WAV、AAC 、MP3 、Ogg 等。

WAV 編碼就是在 PCM 數據格式的前面加了 44 個位元組，分別用來存儲 PCM 的采樣率、聲道數、數據格式等信息。

特點: 音質好，大量軟體支持。

場景: 多媒體開發的中間文件、保存音樂和音效素材。

MP3 具有不錯的壓縮比，使用 LAME 編碼 （MP3 編碼格式的一種實現）的中高碼率的 MP3 文件，聽感上非常接近源 WAV 文件，當然在不同的應用場景下，應該調整合適的參數以達到最好的效果。

特點: 音質在 128 Kbit/s 以上表現還不錯，壓縮比比較高，大量軟體和硬體都支持，兼容性好。

場景: 高比特率下對兼容性有要求的音樂欣賞。

AAC 是新一代的音頻有損壓縮技術，它通過一些附加的編碼技術(比如 PS 、SBR) 等，衍生出了 LC-AAC 、HE-AAC 、HE-AAC v2 三種主要的編碼格式。LC-AAC 是比較傳統的 AAC ,相對而言，其主要應用於中高碼率場景的編碼 (>=80Kbit/s) ; HE-AAC 相當於 AAC + SBR 主要應用於中低碼率的編碼 （<= 80Kbit/s）; 而新推出的 HE-AAC v2 相當於 AAC + SBR + PS 主要用於低碼率場景的編碼 (<= 48Kbit/s) 。事實上大部分編碼器都設置為 <= 48Kbit/s 自動啟用 PS 技術，而 > 48Kbit/s 則不加 PS ，相當於普通的 HE-AAC。

特點: 在小於 128Kbit/s 的碼率下表現優異，並且多用於視頻中的音頻編碼。

場景: 128 Kbit/s 以下的音頻編碼，多用於視頻中音頻軌的編碼。

Ogg 是一種非常有潛力的編碼，在各種碼率下都有比較優秀的表現，尤其是在中低碼率場景下。Ogg 除了音質好之外，還是完全免費的，這為 Ogg 獲得更多的支持打好了基礎，Ogg 有著非常出色的演算法，可以用更小的碼率達到更好的音質，128 Kbit/s 的 Ogg 比 192kbit/s 甚至更高碼率的 MP3 還要出色。但是目前因為還沒有媒體服務軟體的支持，因此基於 Ogg 的數字廣播還無法實現。Ogg 目前受支持的情況還不夠好，無論是軟體上的還是硬體上的支持，都無法和 MP3 相提並論。

特點: 可以用比 MP3 更小的碼率實現比 MP3 更好的音質，高中低碼率下均有良好的表現，兼容性不夠好，流媒體特性不支持。

場景: 語言聊天的音頻消息場景。

壓縮編碼的原理實際上就是壓縮調冗餘信號，冗餘信號是指哪些不能被人感知到的信號，包含人耳聽覺范圍之外的音頻信號以及被屏蔽掉的音頻信號等，這些冗餘信息進行編碼處理。

一般在音視頻通話，直播中，短視頻，以及大部分的視頻都是用aac編碼。

本篇主要是介紹了音頻的一些基礎知識和概念，對於後續學習音頻的編解碼有幫助，而不會一臉懵。

備注

㈡ android音視頻開發怎麼做

android音視頻開發要想不費什麼功夫的話，可以選擇接入第三方的SDK，比如ZEGO即構科技，開發者可以調用ZEGO的API，4行代碼30分鍾就可以在應用內搭建出音視頻場景，應用在視頻會議、語音交友、秀場直播都可以

㈢ android音視頻開發一安卓常用API

Android SDK 提供了兩套音頻採集的API，分別是：MediaRecorder 和 AudioRecord，前者是一個更加上層一點的API，它可以直接把手機麥克風錄入的音頻數據進行編碼壓縮（如AMR、MP3等）並存成文件，而後者則更接近底層，能夠更加自由靈活地控制，可以得到原始的一幀幀PCM音頻數據。如果想簡單地做一個錄音機，錄製成音頻文件，則推薦使用 MediaRecorder，而如果需要對音頻做進一步的演算法處理、或者採用第三方的編碼庫進行壓縮、以及網路傳輸等應用，則建議使用 AudioRecord，其實 MediaRecorder 底層也是調用了 AudioRecord 與 Android Framework 層的 AudioFlinger 進行交互的。直播中實時採集音頻自然是要用AudioRecord了。

2.1 播放聲音可以用MediaPlayer和AudioTrack，兩者都提供了Java API供應用開發者使用。雖然都可以播放聲音，但兩者還是有很大的區別的。

2.2 其中最大的區別是MediaPlayer可以播放多種格式的聲音文件，例如MP3，AAC，WAV，OGG，MIDI等。MediaPlayer會在framework層創建對應的音頻解碼器。而AudioTrack只能播放已經解碼的PCM流，如果對比支持的文件格式的話則是AudioTrack只支持wav格式的音頻文件，因為wav格式的音頻文件大部分都是PCM流。AudioTrack不創建解碼器，所以只能播放不需要解碼的wav文件。

2.3 MediaPlayer在framework層還是會創建AudioTrack，把解碼後的PCM數流傳遞給AudioTrack，AudioTrack再傳遞給AudioFlinger進行混音，然後才傳遞給硬體播放,所以是MediaPlayer包含了AudioTrack。

2.4 在接觸Android音頻播放API的時候，發現SoundPool也可以用於播放音頻。下面是三者的使用場景：MediaPlayer 更加適合在後台長時間播放本地音樂文件或者在線的流式資源; SoundPool 則適合播放比較短的音頻片段，比如游戲聲音、按鍵聲、鈴聲片段等等，它可以同時播放多個音頻; 而 AudioTrack 則更接近底層，提供了非常強大的控制能力，支持低延遲播放，適合流媒體和VoIP語音電話等場景。

使用 Camera API 採集視頻數據並保存到文件，分別使用 SurfaceView、TextureView 來預覽 Camera 數據，取到 NV21 的數據回調。

4.1 一個音視頻文件是由音頻和視頻組成的，我們可以通過MediaExtractor、MediaMuxer把音頻或視頻給單獨抽取出來，抽取出來的音頻和視頻能單獨播放； 

4.2 MediaMuxer的作用是生成音頻或視頻文件；還可以把音頻與視頻混合成一個音視頻文件。

文獻資料  https://www.cnblogs.com/renhui/p/7452572.html

㈣ 安卓的英語android怎麼讀怎麼發音

android
英音 [ 'ændrɔid ] ； 美音 [ 'ændrɔid ]
名詞
1.機器人
2.Google開發的基於Linux平台的開源手機操作系統
同義詞：humanoid，mechanical man。
例句：
Android and ios are well entrenched.
安卓和ios系統已經深入民心。
Android is facing more than forty lawsuits.
安卓正在面臨超過40項的訴訟。
This android was laying down some licks with the Computer Robot Band.
這個模擬機器人正隨著電腦機器人樂隊的節拍輕輕舞動。

㈤ Android音視頻系列（六）：PCM音頻的存儲格式

我們已經了解了如何使用AudioRecord錄制pcm音頻，所以我們要了解pcm數據的存儲格式，才能對其進行鏈者轉換。

首先看一下圖片:

以上圖為例，在初始化AudioRecord的時候可以設置錄制的格式：

其中最常用的是ENCODING_PCM_16BIT，在網上查看一下很多的資料，ENCODING_PCM_8BIT已經處於半廢棄狀態，隨著科技的櫻豎進步，就連小孩子的玩具播放的音頻都是16位的。

另外一個參數是聲道數：

雙聲道會以LRLRLR的格式保存左右聲道的內容，組合成一個完成的樣本。

從上圖我們可以總結：8個比特的位置，8位單聲道可以存儲8個樣本，8位雙聲道能存儲個樣本，16位雙聲道能存儲4個，16位雙聲道只能存儲2個。

今天的內容非常的簡單，主要是為了下一篇做准備，下一篇我們會實際操作：pcm單聲道和雙聲道的轉換。脊喚大

㈥ Android -- 音視頻基礎知識

幀，是視頻的一個基本概念，表示一張畫面，如上面的翻頁動畫書中的一頁，就是一幀。一個視頻就是由許許多多幀組成的。

幀率，即單位時間內幀的數量，單位為：幀/秒 或fps（frames per second）。一秒內包含多少張圖片，圖片越多，畫面越順滑，過渡越自然。 幀率的一般以下幾個典型值：

24/25 fps：1秒 24/25 幀，一般的電影幀率。

30/60 fps：1秒 30/60 幀，游戲的幀率，30幀可以接受，60幀會感覺更加流暢逼真。

85 fps以上人眼基本無法察覺出來了，所以更高的幀率在視頻里沒有太大意義。

這里我們只講常用到的兩種色彩空間。

RGB的顏色模式應該是我們最熟悉的一種，在現在的電子設備中應用廣泛。通過R G B三種基礎色，可以混合出所有的顏色。

這里著重講一下YUV，這種色彩空間並不是我們熟悉的。這是一種亮度與色度分離的色彩格式。

早期的電視都是黑白的，即只有亮度值，即Y。有了彩色電視以後，加入了UV兩種色度，形成現在的YUV，也叫YCbCr。

Y：亮度，就是灰度值。除了表示亮度信號外，還含有較多的綠色通道量。

U：藍色通道與亮度的差值。

V：紅色通道與亮度的差值。

音頻數據的承載方式最常用的是 脈沖編碼調制 ，即 PCM 。

在自然界中，聲音是連續不斷的，是一種模擬信號，那怎樣才能把聲音保存下來呢？那就是把聲音數字化，即轉換為數字信號。

我們知道聲音是一種波，有自己的振幅和頻率，那麼要保存聲音，就要保存聲音在各個時間點上的振幅。

而數字信號並不能連續保存所有時間點的振幅，事實上，並不需要保存連續的信號，就可以還原到人耳可接受的聲音。

根據奈奎斯特采樣定理：為了不失真地恢復模擬信號，采樣頻率應該不小於模擬信號頻譜中最高頻率的2倍。

根據以上分析，PCM的採集步驟分為以下步驟：

采樣率，即采樣的頻率。

上面提到，采樣率要大於原聲波頻率的2倍，人耳能聽到的最高頻率為20kHz，所以為了滿足人耳的聽覺要求，采樣率至少為40kHz，通常為44.1kHz，更高的通常為48kHz。

采樣位數，涉及到上面提到的振幅量化。波形振幅在模擬信號上也是連續的樣本值，而在數字信號中，信號一般是不連續的，所以模擬信號量化以後，只能取一個近似的整數值，為了記錄這些振幅值，采樣器會採用一個固定的位數來記錄這些振幅值，通常有8位、16位、32位。

位數越多，記錄的值越准確，還原度越高。

最後就是編碼了。由於數字信號是由0，1組成的，因此，需要將幅度值轉換為一系列0和1進行存儲，也就是編碼，最後得到的數據就是數字信號：一串0和1組成的數據。

整個過程如下：

聲道數，是指支持能不同發聲（注意是不同聲音）的音響的個數。 單聲道：1個聲道
雙聲道：2個聲道
立體聲道：默認為2個聲道
立體聲道（4聲道）：4個聲道

碼率，是指一個數據流中每秒鍾能通過的信息量，單位bps（bit per second）

碼率 = 采樣率 * 采樣位數 * 聲道數

這里的編碼和上面音頻中提到的編碼不是同個概念，而是指壓縮編碼。

我們知道，在計算機的世界中，一切都是0和1組成的，音頻和視頻數據也不例外。由於音視頻的數據量龐大，如果按照裸流數據存儲的話，那將需要耗費非常大的存儲空間，也不利於傳送。而音視頻中，其實包含了大量0和1的重復數據，因此可以通過一定的演算法來壓縮這些0和1的數據。

特別在視頻中，由於畫面是逐漸過渡的，因此整個視頻中，包含了大量畫面/像素的重復，這正好提供了非常大的壓縮空間。

因此，編碼可以大大減小音視頻數據的大小，讓音視頻更容易存儲和傳送。

視頻編碼格式有很多，比如H26x系列和MPEG系列的編碼，這些編碼格式都是為了適應時代發展而出現的。

其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）國際電傳視訊聯盟主導

MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的組織）主導。

當然，他們也有聯合制定的編碼標准，那就是現在主流的編碼格式H264，當然還有下一代更先進的壓縮編碼標准H265。

H264是目前最主流的視頻編碼標准，所以我們後續的文章中主要以該編碼格式為基準。

H264由ITU和MPEG共同定製，屬於MPEG-4第十部分內容。

我們已經知道，視頻是由一幀一幀畫面構成的，但是在視頻的數據中，並不是真正按照一幀一幀原始數據保存下來的（如果這樣，壓縮編碼就沒有意義了）。

H264會根據一段時間內，畫面的變化情況，選取一幀畫面作為完整編碼，下一幀只記錄與上一幀完整數據的差別，是一個動態壓縮的過程。

在H264中，三種類型的幀數據分別為

I幀：幀內編碼幀。就是一個完整幀。

P幀：前向預測編碼幀。是一個非完整幀，通過參考前面的I幀或P幀生成。

B幀：雙向預測內插編碼幀。參考前後圖像幀編碼生成。B幀依賴其前最近的一個I幀或P幀及其後最近的一個P幀。

全稱：Group of picture。指一組變化不大的視頻幀。

GOP的第一幀成為關鍵幀：IDR

IDR都是I幀，可以防止一幀解碼出錯，導致後面所有幀解碼出錯的問題。當解碼器在解碼到IDR的時候，會將之前的參考幀清空，重新開始一個新的序列，這樣，即便前面一幀解碼出現重大錯誤，也不會蔓延到後面的數據中。

DTS全稱：Decoding Time Stamp。標示讀入內存中數據流在什麼時候開始送入解碼器中進行解碼。也就是解碼順序的時間戳。

PTS全稱：Presentation Time Stamp。用於標示解碼後的視頻幀什麼時候被顯示出來。

前面我們介紹了RGB和YUV兩種圖像色彩空間。H264採用的是YUV。

YUV存儲方式分為兩大類：planar 和 packed。

planar如下：

packed如下：

上面說過，由於人眼對色度敏感度低，所以可以通過省略一些色度信息，即亮度共用一些色度信息，進而節省存儲空間。因此，planar又區分了以下幾種格式：YUV444、 YUV422、YUV420。

YUV 4:4:4采樣，每一個Y對應一組UV分量。

YUV 4:2:2采樣，每兩個Y共用一組UV分量。

YUV 4:2:0采樣，每四個Y共用一組UV分量。

其中，最常用的就是YUV420。

YUV420屬於planar存儲方式，但是又分兩種類型：

YUV420P：三平面存儲。數據組成為YYYYYYYYUUVV（如I420）或YYYYYYYYVVUU（如YV12）。

YUV420SP：兩平面存儲。分為兩種類型YYYYYYYYUVUV（如NV12）或YYYYYYYYVUVU（如NV21）

原始的PCM音頻數據也是非常大的數據量，因此也需要對其進行壓縮編碼。

和視頻編碼一樣，音頻也有許多的編碼格式，如：WAV、MP3、WMA、APE、FLAC等等，音樂發燒友應該對這些格式非常熟悉，特別是後兩種無損壓縮格式。

但是，我們今天的主角不是他們，而是另外一個叫AAC的壓縮格式。

AAC是新一代的音頻有損壓縮技術，一種高壓縮比的音頻壓縮演算法。在MP4視頻中的音頻數據，大多數時候都是採用AAC壓縮格式。

AAC格式主要分為兩種：ADIF、ADTS。

ADIF：Audio Data Interchange Format。音頻數據交換格式。這種格式的特徵是可以確定的找到這個音頻數據的開始，不需進行在音頻數據流中間開始的解碼，即它的解碼必須在明確定義的開始處進行。這種格式常用在磁碟文件中。

ADTS：Audio Data Transport Stream。音頻數據傳輸流。這種格式的特徵是它是一個有同步字的比特流，解碼可以在這個流中任何位置開始。它的特徵類似於mp3數據流格式。

ADIF數據格式：

ADTS 一幀 數據格式（中間部分，左右省略號為前後數據幀）：

AAC內部結構也不再贅述，可以參考AAC 文件解析及解碼流程

細心的讀者可能已經發現，前面我們介紹的各種音視頻的編碼格式，沒有一種是我們平時使用到的視頻格式，比如：mp4、rmvb、avi、mkv、mov...

沒錯，這些我們熟悉的視頻格式，其實是包裹了音視頻編碼數據的容器，用來把以特定編碼標准編碼的視頻流和音頻流混在一起，成為一個文件。

例如：mp4支持H264、H265等視頻編碼和AAC、MP3等音頻編碼。

我們在一些播放器中會看到，有硬解碼和軟解碼兩種播放形式給我們選擇，但是我們大部分時候並不能感覺出他們的區別，對於普通用戶來說，只要能播放就行了。

那麼他們內部究竟有什麼區別呢？

在手機或者PC上，都會有CPU、GPU或者解碼器等硬體。通常，我們的計算都是在CPU上進行的，也就是我們軟體的執行晶元，而GPU主要負責畫面的顯示（是一種硬體加速）。

所謂軟解碼，就是指利用CPU的計算能力來解碼，通常如果CPU的能力不是很強的時候，一則解碼速度會比較慢，二則手機可能出現發熱現象。但是，由於使用統一的演算法，兼容性會很好。

硬解碼，指的是利用手機上專門的解碼晶元來加速解碼。通常硬解碼的解碼速度會快很多，但是由於硬解碼由各個廠家實現，質量參差不齊，非常容易出現兼容性問題。

MediaCodec 是Android 4.1(api 16)版本引入的編解碼介面，是所有想在Android上開發音視頻的開發人員繞不開的坑。

由於Android碎片化嚴重，雖然經過多年的發展，Android硬解已經有了很大改觀，但實際上各個廠家實現不同， 還是會有一些意想不到的坑。

相對於FFmpeg，Android原生硬解碼還是相對容易入門一些，所以接下來，我將會從MediaCodec入手，講解如何實現視頻的編解碼，以及引入OpenGL實現對視頻的編輯，最後才引入FFmpeg來實現軟解，算是一個比較常規的音視頻開發入門流程吧。

㈦ Android音視頻(六) 使用OpenGL ES 3.0預覽Camera

剛學習了OpenGL的紋理相關知識，終於可以接著寫Android音視頻系列了。

本篇博客會介紹使用OpenGL ES 3.0相關知識預覽Camera，並且提供Camera和Camera2兩個版本實現。

頂點著色器

片段著色器

紋理的類型需要使用 samplerExternalOES ，而不是之前渲染圖片的 sampler2D。

我們知道Android相機輸出的原始數據一般都為YUV數據，而在OpenGL中使用的絕大部分紋理ID都是RGBA的格式，所以原始數據都是無法直接用OpenGL ES來渲染的。所以我們添加了一個擴展 #extension GL_OES_EGL_image_external_essl3 : require ，其中定義了一個紋理的擴展類型 GL_TEXTURE_EXTERNAL_OES 。後面綁定紋理時需要綁定到 GL_TEXTURE_EXTERNAL_OES 上，而不是類型GL_TEXTURE_2D上。

其實前面部分和載入圖片沒有什麼區別，最後兩行，對應上面流程中的1、2步。創建紋理，綁定外部紋理，然後根據紋理ID創建SurfaceTexture作為相機預覽輸出。

使用Camera2在OpenGL方面其實是一樣的，並沒有什麼改動。所以只需要看一下Camera2的調用就好。

源碼地址