摘要：音頻的增量解碼在瀏覽器中，提供了對(duì)音頻處理的對(duì)象。文件為實(shí)現(xiàn)文件的分割與重組，先了解音頻文件的組成文件說(shuō)明。使用的即可進(jìn)行對(duì)數(shù)據(jù)的繪制。

在繪制大音頻波形的場(chǎng)景（目前只支持wav格式），急著用的同學(xué)點(diǎn)這里，如果有問(wèn)題可以聯(lián)系我，我會(huì)盡快修復(fù)。github: https://github.com/CofeeWithR...

傳統(tǒng)的音波圖渲染流程是 ajax完整加載音頻，使用audioContext解碼完整的音頻， 下載解碼后的數(shù)據(jù)使用canvas繪制，這種方式當(dāng)音頻較小時(shí)是沒(méi)有問(wèn)題，但遇到超大音頻（超過(guò)100M）時(shí)會(huì)出現(xiàn)從加載到渲染需要很長(zhǎng)的時(shí)間（3~8）s。

我們是否能夠從下載到繪制逐步地進(jìn)行，從而做到既不會(huì)因占用大量的內(nèi)存與集中的大量數(shù)據(jù)繪制造成卡頓，又有快速的響應(yīng)（用戶可以看到加載繪制的過(guò)程）。下面主要從下載、解碼、繪制三個(gè)方面來(lái)研究其實(shí)現(xiàn)的可行性。

XHR 與 fetch

XHR 有responseType屬性， 支持 "" | "arraybuffer" | "blob" | "document" | "json" | "text" 6種值，參照MDN若是 "arraybuffer"|"blob"，在onprogress回調(diào)中獲取的response的值為nul， 這樣就不能下下載過(guò)程中邊下載，邊繪制。
參照下面代碼：

    const xhr  = new XMLHttpRequest();
    xhr.responseType = "arraybuffer"; 
    xhr.onprogress = data => {
        console.log( "data: ",data );
        console.log("onprogress response: ", xhr.response && xhr.response.byteLength);
    }
    xhr.onloadend = data => {
        console.log("load end..");
    }
    xhr.open("get","/source/test.wav" );
    xhr.send();

以上是使用xhr獲取音頻文件，只有在最后一次的onprogress回調(diào)中，獲取到完整的數(shù)據(jù)，不能增量的獲取數(shù)據(jù)，達(dá)到我們?cè)隽康睦L制目的。

fetch

fetch API支持對(duì)管道的管道操作與取消. 看下面的例子：

    
    
    fetch("/source/test.wav").then( (val: Response) => {
        if(val.body){
            // 從Response中獲取可讀流的reader，用于從管道中讀取數(shù)據(jù)。
            const reader: ReadableStreamReader =  val.body.getReader();
            readData(reader);
        }
    })
    
    function readData(reader: ReadableStreamReader){
        // 從管道中讀取數(shù)據(jù)。
        reader.read().then(data => {
    
            if(!data.done){
                // data.value 為一個(gè)Uint8Array.
                console.log(data.value.byteLength);
                // 若還有數(shù)據(jù)，繼續(xù)讀取。
                readData(reader);
            }
        })    
    };

fetch 返回的 Promise中返回的是一個(gè)Response對(duì)象，最終我們可以在Response的body.getReader() 獲取到一個(gè)ReadableStreamReader ，通過(guò)該對(duì)象我們可以讀取網(wǎng)絡(luò)管道中的數(shù)據(jù)片段，以滿足我們?cè)隽夸秩緮?shù)據(jù)的需求。ReadableStreamReader 的read對(duì)象可以獲取一個(gè)返回值包含ArrayBuffer對(duì)象的Promise.
自此，就可以增量的從網(wǎng)絡(luò)管道中獲取數(shù)據(jù)。

在瀏覽器中，提供了對(duì)音頻處理的audioContext對(duì)象。它提供了一個(gè)解碼音頻的Api decodeAudioData, 但不幸的是它只支持完整音頻的解碼。所以解碼變成了完成增量渲染的核心部分。

為簡(jiǎn)單，目前只對(duì)wav音頻做解碼支持。由于WAV格式的特殊性，實(shí)現(xiàn)的總體思想也相當(dāng)簡(jiǎn)單：

1、wav文件分為文件頭部與數(shù)據(jù)部分，于是將wav文件的頭部取出，將數(shù)據(jù)部分分割為多段。

2、當(dāng)解碼時(shí)，將文件頭稍作修改與數(shù)據(jù)片段組合成完整音頻，再使用decodeAudioData API進(jìn)行解碼。

為實(shí)現(xiàn)wav文件的分割與重組，先了解wav音頻文件的組成 wav文件說(shuō)明。
在文檔中，給出了詳細(xì)的定義與說(shuō)明，其中關(guān)鍵的部分做下介紹：

摘自http://soundfile.sapp.org/doc...

由wav文件的結(jié)構(gòu)可以看到，只需要對(duì)data塊的size進(jìn)行修改，就可以使用該頭部與數(shù)據(jù)部分進(jìn)行拼接，形成新的被切割后的文件。

解碼后會(huì)得到AudioBuffer對(duì)象，可獲取的數(shù)據(jù)為 -1~1的浮點(diǎn)數(shù)。
使用canvas的Context.beginPath, 即可進(jìn)行對(duì)數(shù)據(jù)的繪制。