移動互連網實戰--移動端音頻和圖形最佳化處理

標籤：des   style   blog   http   java   使用   

 

前言:
　　移動端應用, 需要省電省流量(頻寬), 大資源套件對使用者體驗是有傷害的. 因此移動端開發需要精簡資源(音頻/圖片), 但又要保證音頻/圖片品質. 本文著重講述如何最佳化處理資源(音頻/圖片), 如何在高壓縮比和高品質(音質/畫質)之間進行折中和權衡. 本文涉及兩大塊, 一塊為語音處理, 另一塊為影像處理.

注: 本文主要面向移動端開發人員, 利用編程去最佳化處理. 摻雜了小編(mumuxinfei)的不成熟觀點和看法, 希望能拋磚引玉.

*) 範例闡釋:
1. 構造應用情境
把常規Wav格式的音頻檔案, 轉化為更小的Mp3格式音頻檔案.
範例代碼藉助JAVE(Java Audio Video Encoder)來實現. 請點擊: JAVE官網.

File source = new File("data/source.wav");File target = new File("data/target.mp3");// *) 設定音頻屬性AudioAttributes audio = new AudioAttributes();audio.setCodec("libmp3lame");audio.setBitRate(new Integer(128000));audio.setChannels(new Integer(2));audio.setSamplingRate(new Integer(44100));// *) 解碼器設定EncodingAttributes attrs = new EncodingAttributes();attrs.setFormat("mp3");attrs.setAudioAttributes(audio);Encoder encoder = new Encoder();encoder.encode(source, target, attrs);

2. 效果展示
Wav格式轉化為Mp3格式後, 實際大小對比如下所示:

Wav格式檔案: 100044byte, Mp3格式檔案: 18839byte
經過小編的親身體驗(試聽), 立場堅定的表示音質無明顯差別, 但檔案壓縮比卻有明顯的提升.
3. 疑惑和不解
雖然大獲成功, 但是小編還是有些不解, 疑問一坨坨. -_-!!!
#) 音頻檔案中的位元速率(bitrate), 聲道(channel), 採樣率(samplingrate)具體是什麼?
#) 在檔案壓縮和音質中, 那個要素扮演更重要的角色? 是他, 是她, 還是它? 唉, 我的媽呀, 小編我傻傻分不清了.
小編手濺, 於是修改下代碼, 取取不同的位元速率/採樣率值, 看看是否有驚喜會出現?

// *) 設定音頻屬性AudioAttributes audio = new AudioAttributes();audio.setCodec("libmp3lame");//audio.setBitRate(new Integer(128000));audio.setBitRate(new Integer(250000));audio.setChannels(new Integer(2));//audio.setSamplingRate(new Integer(44100));audio.setSamplingRate(new Integer(40000));

我樂個大擦, "驚喜"出現了, -_-!!!!!!! 居然罷工, 還拋異常, 拋,拋,拋,拋你妹啊.....

Exception in thread "main" it.sauronsoftware.jave.EncoderException: Error while opening codec for output stream #0.0 - maybe incorrect parameters such as bit_rate, rate, width or height

小編不由得困惑了, 莫非位元速率和採樣率有某種神秘的關係? 你看, 他兩結尾都帶個了‘率‘字, 而且讀起來又都那麼朗朗上口? 搞基不(MD, 不小心說出了心裡話)? 算了, 其實小編內心還是小小期待下, oh yeah.
And 疑惑繼續....
#) 位元速率和採樣率的取值是否有一定的限制?
#) 位元速率和採樣率究竟存在怎麼樣關係呢?

*) 基礎知識
真是好奇心害死貓, 小編帶著這些疑團去知(姿)識(勢)淵(豐)博(富)的百度君.

小編: 百度君,你好,你能給我們介紹下音頻檔案中的位元速率(bitrate), 聲道(channel), 採樣率(samplingrate)具體是什麼?
百度君: #%[email protected]#$%^&*()~&(@!*^[email protected]&*^*&%(*%&^%^$~!*)()*)@&(*^@#(*^(!&(!^(

小編(怒): 講人話......
百度君:
　　　　音頻檔案有三個重要的屬性描述: 採樣率(samplingrate)/位元速率(bitrate)/聲道(channel)
　　　　#)位元速率：音頻資料每秒中需要多少個位元來表示,位元速率越高音頻品質越好, 檔案也越大.
　　　　#)採樣率：採樣率定義了每秒從連續訊號中提取並組成離散訊號的採樣個數，用赫茲（Hz）來表示.
　　　　#)聲道：聲道分單聲道, 雙聲道兩種, 單聲道是混合均勻從左右聲道出來, 而雙聲道則是從不同聲音
　　　　　　　　從左右聲道出來併合成, 現場立體感強.
小編(內心)：哼，百度君果然吃軟怕硬，不過好像說的好專業，不明覺厲．

小編：那請問位元速率和採樣率的取值有限定嗎？
百度君：
　　　　#) 位元速率取值
　　　　位元速率取值: 32kbps/96kbps/128kbps/192kbps/224kbps/320kbps
　　　　#) 採樣率的取值
　　　　44.1kHz系列採樣: 11.025kHz, 22.05kHz, 44.1kHz, 88.2kHz, 176.4kHz
　　　　48kHz系列採樣: 12kHz, 24kHz, 48kHz, 96kHz, 192kHz
小編(內心)：這下長見識了，以後叫你還拋，拋，拋不了你妹了，娃哈哈, 喂, 說你呢? 看什麼看, 還看!!!!

小編：那請問，這個44.1kHz有特殊來由嗎?
百度君:人類的聽覺波段在20Hz到20kHz, 由Nyquist採樣定理, 採樣評率只要超過訊號頻寬2倍就不會產生混迭. 而實際上音樂CD規範則採用44.1kHz(20kHz兩倍多)做為採樣標準. 因此44.1kHz和人類的可聽波段有一定的關聯.

激動人心的時候, 終於要來了, 此時空氣彷彿凝固了....

小編(喜): 那位元速率君和採樣率君究竟有何姦情呢? (啊呸, 竟然不小心說漏嘴了......)
百度君: 兩個維度,互不影響. 簡而言之, 位元速率用於音頻編碼過程中, 而採樣率用於語音播放中. 位元速率與音質成正比, 檔案大小成反比. 而採樣率只與音質成正比.

天空一行烏鴉飛過, 哇哇哇.....

小編(內心): 這TM是玩我嗎? 搞得這麼親熱, 還一直形影不離, 最後竟然告訴我,他倆沒半毛錢的關係, 這誰信啊!!!!!!
小編(失落): 真是個意外的結果, 萬萬沒想到, 這個世上還是有純粹的友誼存在, 不管你信不信, 反正我是信了.

唉, 突然覺得菊花好癢......

*) 進階篇
1). 查閱音頻文集元資訊
如何藉助JAVE來實現, 程式碼片段如下:

MultimediaInfo info = encoder.getInfo(target);System.out.println(info);

Console 結果輸出如下:

(decoder=pcm_s16le, samplingRate=22050, channels=2, bitRate=705)

評註: 解碼器為: pcm_s16le, 採樣率: 22.05kHz, 雙聲道, 位元速率705Kbps
2). 嘗試把Wav轉化為各個位元速率的Mp3格式

採樣率/位元速率	24kbps	48kbps	96kbps	192kbps
11.025kHz	3792	7554	15077	--
22.05kHz	3636	7241	14451	--
44.1kHz	--	7084	14137	28243

 評註: 比對橫向/豎向, 可以看到檔案大小與位元速率相關, 而採樣率和位元速率之間有一定的組合限定.

3). 嘗試把Wa轉化為各個解碼器的音頻格式
音訊解碼器, 取決於音頻格式, 簡單羅列下:

mp3 => libmp3lameogg => vorbiswav => pcm_s16be/pcm_s16le/pcm_s24le3gp => libfaac

更多的解碼器, 請點擊: 官網 
在相同條件(位元速率:24kbps, 採樣率:22.05kHz, 雙聲道)

音頻格式	mp3	ogg	wav	3gp
檔案大小	3636	6586	100044	2668

當在相同條件(位元速率:48kbps, 採樣率:44.1kHz, 雙聲道)

音頻格式	mp3	ogg	wav	3gp
檔案大小	7084	8722	199980	5177

評註: 可以看出, 同等條件下檔案大小: 3gp < mp3 < ogg << wav, 但檔案壓縮比高不代表好, 最終需要在壓縮比/音質取個折中

影像處理
　　移動端對圖片格式的選擇: 主流為PNG/JPEG格式. PNG它兼具JPG圖片的品質和GIF格式的透明, 檔案大小較JPEG大. JPEG格式畫質好, 色彩和飽和度高, 檔案相對相對較小. 因此一般有如下實踐原則: 小尺寸, 色彩數小或使用到透明的時候用PNG, 大尺寸, 色彩漸層色多的時候用JPG.
　　移動端的圖片最佳化包括兩方面, 一塊為圖片格式轉換, 一塊為圖片像素大小調整.
程式碼片段:

public void convertImage(String sourceFile, String destFile, int newWidth, int newHeight) {　　// *) 假定傳入destFile, 都是 *.jpg, *.png 的命名方式, 這邊不做檢查處理　　String format = destFile.substring(destFile.lastIndexOf(‘.‘) + 1);　　try {　　　　Image srcImage = ImageIO.read(new File(sourceFile));　　　　// *) 繪製源映像到靶心圖表像　　　　BufferedImage destImage = new BufferedImage(newWidth, newHeight, BufferedImage.TYPE_3BYTE_BGR);　　　　Graphics2D g2 = (Graphics2D) destImage.getGraphics();　　　　g2.drawImage(srcImage, 0, 0, newWidth, newHeight, null);　　　　// *) 產生靶心圖表像 　　　　ImageIO.write(destImage, format, new File(destFile));　　} catch (IOException e) {　　　　e.printStackTrace();　　}}

評註: 這段代碼能實現jpg=>png, jpg=>gif, jpg=>bmp, png=>jpg的轉換, 同時實現不同解析度的映像轉換

實驗比較, 原圖如下(秀福利)

檔案大小比對如下:

圖片格式	JPG	PNG	GIF	BMP
檔案大小	19.0KB	267.9KB	48.7KB	386.8KB

對比可以發現, 等同像素下, 圖片檔案大小為 jpg < gif < png < bmp

繼續實驗, 把大解析度映像轉化為小解析度(主流解析度)映像, 壓縮率有多少

解析度	1600*1200	1280*1024	1080*960	960*540	854*480
檔案大小	251.7KB	188.8KB	157.7KB	90.3KB	74.7KB

如果想更深入的對映像品質進行控制, (比如jpg映像品質, 預設預設品質為0.75):
程式碼片段如下:

public void convert2JPGImage(String sourceFile, String destFile, int newWidth, int newHeight, float quality) {　　FileOutputStream out = null;　　try {　　　　Image srcImage = ImageIO.read(new File(sourceFile));　　　　// *) 繪製源映像到靶心圖表像　　　　BufferedImage destImage = new BufferedImage(newWidth, newHeight, BufferedImage.TYPE_3BYTE_BGR);　　　　Graphics2D g2 = (Graphics2D) destImage.getGraphics();　　　　g2.drawImage(srcImage, 0, 0, newWidth, newHeight, null);　　　　// *) 產生靶心圖表像, 藉助com.sun.image.codec.jpeg.JPEGImageEncoder來實現　　　　out = new FileOutputStream(destFile);　　　　JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(out);　　　　JPEGEncodeParam jep = JPEGCodec.getDefaultJPEGEncodeParam(destImage);　　　　jep.setQuality(quality, true);　　　　encoder.encode(destImage, jep);　　} catch (IOException e) {　　} finally {　　　　if ( out != null ) {　　　　　　try {　　　　　　　　out.close();　　　　　　} catch (IOException e) {　　　　　　}　　　　}　　}}

總結:
　　移動端開發需要一定的音頻/圖片最佳化技巧, 對資源類的app而言, 這一點就特別的重要. 檔案壓縮比不是越高越好, 對高音質/高畫質的追求會付出一定的代價.總而言之: 沒有完美的解決方案, 只有永恒的折中.