做前端做到一定階段只要沒被純頁面開發(fā)一直養(yǎng)著早晚會碰到一個(gè)繞不開的話題二進(jìn)制數(shù)據(jù)處理。解析文件格式、處理網(wǎng)絡(luò)協(xié)議、對接WebAssembly這些場景底層全是字節(jié)在跑。而JavaScript里處理字節(jié)最常用的三件套——ArrayBuffer、DataView、Uint8Array標(biāo)題里的Unit8Array是筆誤正確拼法是Uint8Array后面統(tǒng)一用正確拼法很多人一看就頭大因?yàn)榻坛掏髦v各的很少有文章把它們的區(qū)別和合作關(guān)系真正說透。這篇文章我想用實(shí)際做項(xiàng)目時(shí)踩過的坑把三者的基礎(chǔ)關(guān)系、底層機(jī)制、典型實(shí)操一次性講清楚適合所有寫過一點(diǎn)JS、但還沒系統(tǒng)接觸過二進(jìn)制處理的前端或全棧開發(fā)者。1. 三者到底是什么一次講清基礎(chǔ)關(guān)系先放下代碼用生活場景打個(gè)比方。ArrayBuffer是一間租下來的倉庫里面只有一排排空貨架。貨架上沒有任何標(biāo)簽也沒有尺寸劃分你只知道倉庫一共多少平米——對應(yīng)到編程里就是一塊固定大小的原始內(nèi)存區(qū)域里面只有一串字節(jié)字節(jié)本身沒有“類型”的含義。Uint8Array是給倉庫做了一次統(tǒng)一改造把所有貨架都按“每格裝一個(gè)無符號8位整數(shù)”來規(guī)劃每個(gè)格子容量0到255。你通過這層視圖就能像操作普通數(shù)組一樣按索引讀取或修改每一個(gè)字節(jié)。DataView則是那把“萬能量尺”它不改造貨架但給你提供了更自由的工具你可以在任意位置量出2字節(jié)、4字節(jié)的整數(shù)甚至讀出浮點(diǎn)數(shù)還可以指定“從高字節(jié)往低字節(jié)讀”還是反過來讀。這三樣?xùn)|西不是競爭關(guān)系A(chǔ)rrayBuffer是底層Uint8Array和DataView是它上面的兩種“觀察方式”。理解這一點(diǎn)后面所有細(xì)節(jié)都好辦。1.1 ArrayBuffer一塊“看不懂”的原始內(nèi)存ArrayBuffer是ES6引入的二進(jìn)制數(shù)據(jù)基礎(chǔ)對象它代表一段固定長度的內(nèi)存緩沖區(qū)。你只管申請系統(tǒng)按字節(jié)數(shù)分配空間初始值全部是0。const buffer new ArrayBuffer(16); console.log(buffer.byteLength); // 16注意你不能直接通過buffer[0]去取值拿到的是undefined。ArrayBuffer本身沒有“數(shù)組”語義它只是一塊分配好的內(nèi)存。想要讀寫里面的內(nèi)容必須在它上面建立視圖。它有兩個(gè)容易被忽略的特性。第一長度在創(chuàng)建時(shí)固定不能動態(tài)擴(kuò)容想擴(kuò)只能新建一個(gè)更大的buffer再把數(shù)據(jù)拷過去。第二它支持slice做淺拷貝也支持transfer把底層內(nèi)存所有權(quán)轉(zhuǎn)移出去轉(zhuǎn)移后原buffer會被detach變得不可用。什么時(shí)候需要直接操作ArrayBuffer最常見的是網(wǎng)絡(luò)API和數(shù)據(jù)解析接口的返回值。比如fetch的response.arrayBuffer()、WebSocket的二進(jìn)制幀、WebAudio的音頻數(shù)據(jù)這些拿到手的原始對象都是ArrayBuffer。以我的經(jīng)驗(yàn)新手最容易做的一件事是拿到buffer后立刻想著轉(zhuǎn)成普通數(shù)組去處理等數(shù)據(jù)量一大就會發(fā)現(xiàn)內(nèi)存和性能雙雙崩盤。1.2 Uint8Array給二進(jìn)制加上“刻度”Uint8Array是TypedArray家族里最常用的一個(gè)。TypedArray不是單一類型而是一族視圖包括Uint8Array、Int8Array、Uint16Array、Int32Array、Float32Array、Float64Array等等。它們做的事情都是把同一塊ArrayBuffer的內(nèi)存按固定字節(jié)長度切分成元素序列。Uint8Array把每個(gè)字節(jié)當(dāng)作一個(gè)0到255之間的整數(shù)所以它和原始字節(jié)是一一對應(yīng)的。const buffer new ArrayBuffer(4); const bytes new Uint8Array(buffer); bytes[0] 72; bytes[1] 105; console.log(bytes); // Uint8Array(4) [72, 105, 0, 0] console.log(new TextDecoder().decode(bytes.subarray(0, 2))); // Hi它擁有標(biāo)準(zhǔn)數(shù)組的大部分方法length屬性、索引訪問、forEach、map、slice日常處理字節(jié)序列非常順手。比起普通數(shù)組它省去了對象頭和動態(tài)擴(kuò)容的開銷性能好得多內(nèi)存也緊湊。我特別想強(qiáng)調(diào)一點(diǎn)Uint8Array的語義就是“把內(nèi)存當(dāng)字節(jié)數(shù)組看”所以凡是文件解析、協(xié)議封包這類和字節(jié)打交道的事它都是首選視圖。你可以先用它快速遍歷、校驗(yàn)原始字節(jié)遇到需要按多字節(jié)整數(shù)解讀的位置再切換DataView做精細(xì)讀取。這個(gè)組合拳后面實(shí)操部分會詳細(xì)展開。1.3 DataView自由讀寫的“萬用表”DataView和TypedArray最大的區(qū)別在于它的靈活性。TypedArray一旦創(chuàng)建元素類型就固定了Uint8Array每個(gè)元素永遠(yuǎn)是1字節(jié)Uint16Array每個(gè)元素永遠(yuǎn)是2字節(jié)。但DataView不需要提前聲明“整個(gè)buffer里都存什么類型”它允許你在任意字節(jié)偏移位置按需讀出不同長度的值。const buffer new ArrayBuffer(4); const view new DataView(buffer); view.setUint8(0, 0x12); view.setUint8(1, 0x34); view.setUint8(2, 0x56); view.setUint8(3, 0x78); console.log(view.getUint16(0).toString(16)); // 1234大端讀取 console.log(view.getUint16(0, true).toString(16)); // 3412小端讀取 console.log(view.getUint32(0).toString(16)); // 12345678DataView提供了getUint8、getUint16、getUint32、getFloat32、setInt8、setFloat64等一系列方法覆蓋所有常見數(shù)值類型。它的第二個(gè)隱藏優(yōu)勢是沒有對齊要求哪怕你想在偏移1字節(jié)的位置讀一個(gè)Uint32DataView也照讀不誤這在解析主動填充過字節(jié)的二進(jìn)制格式時(shí)極其有用。說白了DataView適合“結(jié)構(gòu)化解讀”你的數(shù)據(jù)是混合類型、有明確的字段布局、需要控制字節(jié)序就用它。TypedArray適合“整塊視圖”數(shù)據(jù)本質(zhì)上就是同類型元素的密集序列用它可以快速批量操作。2. 核心細(xì)節(jié)解析字節(jié)序、邊界與設(shè)計(jì)取舍基礎(chǔ)概念清楚了接下來要理解幾個(gè)決定成敗的細(xì)節(jié)。這些細(xì)節(jié)你寫demo時(shí)可能觸發(fā)不了但一到真實(shí)項(xiàng)目里字節(jié)序和偏移量能把人折磨到懷疑人生。2.1 字節(jié)序?yàn)槭裁磾?shù)據(jù)像被“倒著”讀了字節(jié)序Endianness指的是多字節(jié)數(shù)值在內(nèi)存中的排列順序。比如整數(shù)0x12345678在內(nèi)存里占4個(gè)字節(jié)那這4個(gè)字節(jié)按什么順序擺放大端Big-Endian高字節(jié)在前內(nèi)存排列是12 34 56 78。小端Little-Endian低字節(jié)在前內(nèi)存排列是78 56 34 12?，F(xiàn)代x86和ARM處理器默認(rèn)都是小端而網(wǎng)絡(luò)協(xié)議和很多文件格式比如PNG、JPEG用的是大端。這就是同一個(gè)二進(jìn)制文件在你機(jī)器上直接按整數(shù)讀讀出的數(shù)字卻像是“反”的原因。DataView的getUint16、getUint32等方法都接受第二個(gè)參數(shù)littleEndian默認(rèn)是false也就是按大端讀。所以讀網(wǎng)絡(luò)協(xié)議或文件頭時(shí)記得顯式傳false或者干脆不傳就默認(rèn)大端讀本機(jī)內(nèi)存緩沖區(qū)時(shí)需要按小端就傳true。想知道當(dāng)前平臺到底什么字節(jié)序可以這樣快速檢測const buf new ArrayBuffer(2); const uint8 new Uint8Array(buf); const uint16 new Uint16Array(buf); uint16[0] 0x0102; if (uint8[0] 0x02) { console.log(當(dāng)前環(huán)境是小端); } else { console.log(當(dāng)前環(huán)境是大端); }我第一次在這個(gè)細(xì)節(jié)上翻車是在解析一個(gè)二進(jìn)制地圖文件時(shí)寬度、高度全讀成了巨大無比的數(shù)字。當(dāng)時(shí)還以為是文件損壞后來用十六進(jìn)制逐個(gè)字節(jié)核對才意識到是字節(jié)序反了。所以我的習(xí)慣是拿到任何二進(jìn)制格式先看文檔里有沒有明確寫字節(jié)序沒寫的就按大端試讀一次、小端試讀一次哪個(gè)人類可讀就用哪個(gè)。2.2 構(gòu)造參數(shù)視圖怎么和內(nèi)存綁定Uint8Array和DataView都可以在已有ArrayBuffer上建立視圖構(gòu)造函數(shù)里的參數(shù)含義必須搞清。const buffer new ArrayBuffer(16); // 第一種直接整個(gè)buffer const view1 new Uint8Array(buffer); // 第二種指定起始偏移和長度 const view2 new Uint8Array(buffer, 4, 8); // 第三種不傳buffer自己分配內(nèi)存 const view3 new Uint8Array(16); // 第四種傳入普通數(shù)組逐元素拷貝 const view4 new Uint8Array([1, 2, 3, 4]);這里最容易混的是第二種。new Uint8Array(buffer, byteOffset, length)的第二個(gè)參數(shù)是字節(jié)偏移第三個(gè)參數(shù)是元素個(gè)數(shù)而不是字節(jié)長度。對Uint8Array來說元素個(gè)數(shù)等于字節(jié)數(shù)因?yàn)槊總€(gè)元素占1字節(jié)但換成Uint16Array就完全不同了new Uint16Array(buffer, 2, 4)表示從第2個(gè)字節(jié)開始連續(xù)4個(gè)16位元素實(shí)際覆蓋8個(gè)字節(jié)。TypedArray的偏移還有對齊約束Uint16Array的字節(jié)偏移必須是2的倍數(shù)Uint32Array和Float32Array必須是4的倍數(shù)Float64Array必須是8的倍數(shù)否則會拋RangeError。這是引擎的底層限制不是瀏覽器偷懶。如果你解析的數(shù)據(jù)字段排列很怪、偏移天然不對齊那就別硬上Uint16Array直接改用DataView最省事。2.3 為什么需要這么多種視圖同一塊ArrayBuffer可以同時(shí)掛多個(gè)不同視圖互不影響——它們只是在用不同方式解讀同一段內(nèi)存。const buffer new ArrayBuffer(4); const bytes new Uint8Array(buffer); const ints new Uint32Array(buffer); bytes[0] 0x11; bytes[1] 0x22; bytes[2] 0x33; bytes[3] 0x44; console.log(ints[0].toString(16)); // 44332211小端解析這種多視圖能力是處理底層數(shù)據(jù)的重要基礎(chǔ)。比如WebAssembly的線性內(nèi)存或者共享內(nèi)存編程本質(zhì)都是這塊buffer被多個(gè)上下文以不同視圖操作。你不需要記住所有視圖類型我常用的其實(shí)就是三類看字節(jié)用Uint8Array、看32位整型用Uint32Array、混合結(jié)構(gòu)用DataView。其余類型需要在特定場景再翻出來即可。3. 實(shí)操過程兩個(gè)經(jīng)典場景的完整落地理論講再多不如代碼來得實(shí)在。下面兩個(gè)場景是我在實(shí)際項(xiàng)目中反復(fù)用到過、而且非常適合練手的二進(jìn)制文件格式解析和自定義網(wǎng)絡(luò)協(xié)議解碼。代碼可以直接抄走改改。3.1 場景一5分鐘解析PNG文件頭PNG文件的開頭8字節(jié)是固定簽名89 50 4E 47 0D 0A 1A 0A也就是\x89PNG\r\n\x1a\n。緊跟著是IHDR塊里面前4字節(jié)是大端模式存儲的圖像寬度再4字節(jié)是高度。const resp await fetch(some-image.png); const buffer await resp.arrayBuffer(); // 第一步用 Uint8Array 快速校驗(yàn)簽名 const bytes new Uint8Array(buffer); const signature [0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A]; const isPNG signature.every((v, i) bytes[i] v); if (!isPNG) { throw new Error(不是有效的PNG文件); } // 第二步用 DataView 讀取IHDR里的寬高 const view new DataView(buffer); const width view.getUint32(16, false); // 大端 const height view.getUint32(20, false); // 大端 console.log(圖片尺寸${width} x ${height});注意這里的偏移量16不是隨手寫的PNG文件頭占8字節(jié)IHDR塊由4字節(jié)長度、4字節(jié)塊類型、13字節(jié)塊數(shù)據(jù)、4字節(jié)CRC組成塊數(shù)據(jù)從偏移16開始而寬高正好在塊數(shù)據(jù)的前8字節(jié)。為什么寬高必須用DataView讀而不用Uint8Array因?yàn)閁int8Array只能讀出單個(gè)字節(jié)你要拼出4字節(jié)整數(shù)還得自己寫移位邏輯const b new Uint8Array(buffer); const w (b[16] 24) | (b[17] 16) | (b[18] 8) | b[19];能寫但沒必要。簡單的大端4字節(jié)讀取DataView一行就搞定還不會因?yàn)樽址唇踊蛭贿\(yùn)算把符號位搞出問題。3.2 場景二解析自定義二進(jìn)制協(xié)議包假設(shè)服務(wù)端通過WebSocket下發(fā)一組傳感器數(shù)據(jù)協(xié)議設(shè)計(jì)為2字節(jié)小端格式的設(shè)備ID 1字節(jié)消息類型 8字節(jié)小端格式的浮點(diǎn)數(shù)采樣值數(shù)組兩個(gè)float。socket.binaryType arraybuffer; socket.onmessage (event) { const buffer event.data; const view new DataView(buffer); const deviceId view.getUint16(0, true); const msgType view.getUint8(2); const value1 view.getFloat32(3, true); const value2 view.getFloat32(7, true); console.log({ deviceId, msgType, value1, value2 }); };這個(gè)協(xié)議的難點(diǎn)在于字段不是對齊的設(shè)備ID占2字節(jié)緊接著是1字節(jié)類型從偏移3才開始讀浮點(diǎn)數(shù)。如果你嘗試用Uint16Array或Float32Array直接建數(shù)組會遇到兩個(gè)問題一是整體數(shù)組類型統(tǒng)一沒法在同一視圖里又讀Uint16又讀Float32二是偏移3不是Float32Array要求的4字節(jié)對齊直接創(chuàng)建會拋RangeError。其實(shí)看網(wǎng)絡(luò)協(xié)議時(shí)我已經(jīng)習(xí)慣先把協(xié)議文檔畫成一張字節(jié)偏移表列清楚每個(gè)字段從哪個(gè)字節(jié)開始、占多長、什么字節(jié)序。然后照著表寫DataView代碼基本一次過。如果你想看完整包的十六進(jìn)制dump這個(gè)小工具函數(shù)很實(shí)用function toHex(buffer) { return new Uint8Array(buffer).reduce( (acc, byte) acc byte.toString(16).padStart(2, 0) , ); } console.log(toHex(buffer)); // 14 00 02 00 00 40 40 ... 類似輸出3.3 場景三文件上傳前的二進(jìn)制預(yù)處理還有一個(gè)高頻場景是用戶上傳文件后、真正發(fā)送前的預(yù)處理。比如給上傳的PNG圖片加一個(gè)自定義文本尾巴或者校驗(yàn)上傳文件是否被篡改。這時(shí)候需要把File對象讀成ArrayBuffer處理后再包成Blob。const input document.getElementById(fileInput); input.addEventListener(change, async (e) { const file e.target.files[0]; const buffer await file.arrayBuffer(); // 用 Uint8Array 檢查文件頭 const head new Uint8Array(buffer, 0, 4); if (head[0] ! 0x89 || head[1] ! 0x50) { alert(請選擇PNG圖片); return; } // 追加一串自定義字節(jié) const tail new Uint8Array([0xDE, 0xAD, 0xBE, 0xEF]); const combined new Uint8Array(buffer.byteLength tail.length); combined.set(new Uint8Array(buffer), 0); combined.set(tail, buffer.byteLength); // 重新包裝成Blob用于上傳 const newBlob new Blob([combined], { type: file.type }); // 然后用 FormData 上傳 newBlob });這里有兩個(gè)注意點(diǎn)。第一new Blob([combined])傳入TypedArray時(shí)底層會拷貝數(shù)據(jù)原buffer不會被占用可以放心繼續(xù)復(fù)用內(nèi)存。第二不要直接new Blob([buffer])后還想保留buffer繼續(xù)操作Blob構(gòu)造時(shí)對ArrayBuffer的語義在規(guī)范里是拷貝但部分老實(shí)現(xiàn)有過模糊地帶我現(xiàn)在一律先把數(shù)據(jù)整理成Uint8Array再傳邏輯最清晰。4. 常見問題與排查技巧實(shí)錄以下這些坑幾乎每個(gè)接觸二進(jìn)制的開發(fā)者都會踩我按實(shí)際遇到過的順序列出來方便你排查時(shí)對照。4.1 越界寫入為什么“靜默失敗”TypedArray越界寫入不會拋異常而是被直接忽略。比如const bytes new Uint8Array(2); bytes[5] 100; console.log(bytes[5]); // undefined寫入沒發(fā)生也沒有報(bào)錯(cuò)這一點(diǎn)對從普通數(shù)組轉(zhuǎn)過來的人特別危險(xiǎn)。普通數(shù)組可以動態(tài)擴(kuò)容越界賦值會順手把數(shù)組變長TypedArray是固定長度的越界相當(dāng)于往倉庫墻上寫字墻外根本沒有貨架。我排查過一次詭異的業(yè)務(wù)bug就是有段邏輯在特定輸入下越界頁面不報(bào)錯(cuò)數(shù)據(jù)卻遲遲不更新最后打日志才發(fā)現(xiàn)索引算錯(cuò)了。DataView則更嚴(yán)格一些讀取越界會拋RangeError。所以如果你在寫新建代碼用DataView做邊界敏感的結(jié)構(gòu)讀取等于讓運(yùn)行時(shí)幫你兜底。4.2 字節(jié)序錯(cuò)亂讀出來的數(shù)據(jù)像天書癥狀很典型讀一個(gè)本來應(yīng)該是100的小整數(shù)結(jié)果得到了1677721600這種天文數(shù)字或者本來應(yīng)該是正的數(shù)值讀出來成了負(fù)數(shù)。這基本就是字節(jié)序反了。排查時(shí)不要一上來就懷疑算法。先把原始字節(jié)按十六進(jìn)制打印出來用上面那個(gè)toHex函數(shù)然后非常簡單地推算比如原始字節(jié)是01 00 00 00按小端讀u32是1按大端讀u32是16777216。哪個(gè)更合理就選哪個(gè)字節(jié)序。注意DataView的第二個(gè)參數(shù)是littleEndian我因?yàn)橛浄凑Z義把整個(gè)協(xié)議解析結(jié)果搞亂過后來做了一條規(guī)定凡是讀文件格式統(tǒng)統(tǒng)寫false或省略凡是讀本機(jī)二進(jìn)制緩沖一律寫true規(guī)則統(tǒng)一后基本不再錯(cuò)。4.3 視圖和Buffer的引用是同步的TypedArray和DataView都只是視圖它們持有的是同一個(gè)ArrayBuffer的引用不是拷貝。你對視圖的修改會直接反映到buffer上其他視圖也看得見。const buffer new ArrayBuffer(4); const bytes new Uint8Array(buffer); const view new DataView(buffer); bytes[0] 42; console.log(view.getUint8(0)); // 42同一個(gè)內(nèi)存 view.setUint8(1, 99); console.log(bytes[1]); // 99同樣可見這個(gè)特性在共享內(nèi)存、多視圖協(xié)作時(shí)是利器但也容易誤傷。如果你需要一份獨(dú)立的副本用buffer.slice()或者構(gòu)造新TypedArray時(shí)傳入普通數(shù)組都會產(chǎn)生拷貝。還有一個(gè)細(xì)節(jié)ArrayBuffer被transfer后原buffer會被detach此時(shí)它上面的所有視圖都會變成空視圖任何訪問都會拋TypeError。遇到“視圖突然不能用了”的問題優(yōu)先檢查是不是在別處把buffer轉(zhuǎn)移走了。4.4 別把Uint8ClampedArray當(dāng)成Uint8Array這兩者名字太像功能卻有本質(zhì)差別。Uint8Array對超出0-255范圍的整數(shù)做回繞處理256變成0-1變成255。而Uint8ClampedArray對溢出做鉗制小于0的鉗到0大于255的鉗到255。const a new Uint8Array(1); a[0] 256; // 回繞變成0 console.log(a[0]); // 0 const b new Uint8ClampedArray(1); b[0] 256; // 鉗制變成255 console.log(b[0]); // 255為什么Uint8Array要設(shè)計(jì)成回繞因?yàn)檫@是CPU整數(shù)運(yùn)算的天然行為符合底層“字節(jié)就是0-255循環(huán)”的直覺而Uint8ClampedArray是為了Canvas像素處理設(shè)計(jì)的像素值越界直接鉗到邊界比循環(huán)回繞更安全。做圖像處理時(shí)用誰一定要想清楚否則顏色會完全對不上。5. 工程實(shí)踐性能對比與協(xié)作技巧最后聊聊工程上的取舍以及這些API如何和瀏覽器其他接口配合。5.1 什么時(shí)候選哪個(gè)一張選型對照需求推薦方案理由整體遍歷/修改原始字節(jié)做簽名校驗(yàn)、字符串編碼Uint8Array內(nèi)存緊湊、數(shù)組方法多、可直接操作每個(gè)字節(jié)按結(jié)構(gòu)讀取混合字段字段起始字節(jié)不規(guī)則DataView任意偏移、任意類型、顯式控制字節(jié)序解析大端格式的圖片/文件元數(shù)據(jù)DataView默認(rèn)大端讀取語義與格式文檔一致同類型數(shù)值的密集序列如音頻PCM采樣對應(yīng)TypedArrayInt16Array/Float32Array批量操作性能高沒有方法調(diào)用開銷和WebGL/Canvas/Wasm共享圖像數(shù)據(jù)Uint8ClampedArray或Uint8Array和底層接口的類型約定對齊一個(gè)項(xiàng)目里這三者往往同時(shí)出現(xiàn)。比如音頻編輯器先fetch拿到ArrayBuffer用DataView讀WAV文件的頭信息把音頻數(shù)據(jù)部分用Int16Array視圖做增益處理最后再轉(zhuǎn)成Blob導(dǎo)出。每種工具都用在它最順手的位置思路就非常清爽。5.2 和Blob、FileReader、fetch的配合關(guān)系二進(jìn)制數(shù)據(jù)在瀏覽器生態(tài)里流轉(zhuǎn)常見的接縫就這么幾個(gè)fetch拿到的是Response調(diào)用await resp.arrayBuffer()拿到ArrayBuffer。File/Blob可以await file.arrayBuffer()直接讀也可以在FileReader里用readAsArrayBuffer。反方向ArrayBuffer或TypedArray可以傳進(jìn)new Blob([data])再通過URL.createObjectURL生成下載鏈接。這里有一個(gè)性能經(jīng)驗(yàn)如果只是讀文件內(nèi)容優(yōu)先用file.arrayBuffer()FileReader那套回調(diào)寫法只是兼容老項(xiàng)目的遺留選擇。數(shù)據(jù)在ArrayBuffer、TypedArray、Blob之間轉(zhuǎn)換時(shí)盡量復(fù)用底層內(nèi)存避免無謂拷貝。尤其是大文件一次拷貝就是幾十兆的內(nèi)存峰值很容易把移動端頁面拖崩。5.3 幾個(gè)我常用的開發(fā)調(diào)試技巧最后分享幾個(gè)調(diào)試二進(jìn)制的個(gè)人習(xí)慣。第一永遠(yuǎn)先看十六進(jìn)制。不要盯著十進(jìn)制的數(shù)字猜把原始字節(jié)dump出來肉眼掃一遍很多問題立刻就清楚了。上面那個(gè)toHex函數(shù)我?guī)缀跛许?xiàng)目都留著。第二用DataView逐步驗(yàn)證偏移表。拿到一個(gè)不確定的二進(jìn)制格式我會先在控制臺交互式地逐個(gè)偏移讀取確認(rèn)字段值符合預(yù)期再落到代碼里。這比一次寫完整解析邏輯再debug高效十倍。第三利用subarray而不是slice。typedArray.subarray(begin, end)返回的是原buffer上的新視圖零拷貝slice會生成新內(nèi)存上的新數(shù)組。只讀數(shù)據(jù)時(shí)用subarray寫回時(shí)才考慮拷貝能省下不少內(nèi)存。第四善用TextDecoder和TextEncoder。字節(jié)和字符串之間的互轉(zhuǎn)用這兩個(gè)內(nèi)置API遠(yuǎn)比自己拼charCodeAt干凈。UTF-8的中文、emoji都交給它處理別再手寫編碼邏輯。結(jié)尾一點(diǎn)個(gè)人體會做了幾年二進(jìn)制相關(guān)的東西我最大的體會是這道坎邁過去之后前端能做的事情一下寬了不少。文件格式解析、自繪協(xié)議、音頻圖像處理之前只能交給后端解決的活兒現(xiàn)在前端也能獨(dú)立完成。而最關(guān)鍵的并不是記住哪個(gè)API的哪個(gè)參數(shù)而是先弄清數(shù)據(jù)本身的結(jié)構(gòu)它是誰定義的、字節(jié)序是什么、字段從哪里開始。搞清楚了這些再決定用Uint8Array做整體視圖還是用DataView做局部精讀自然是水到渠成的事。最后再留一個(gè)小技巧如果你經(jīng)常要調(diào)試二進(jìn)制數(shù)據(jù)可以把toHex函數(shù)封裝成支持長度限制和偏移參數(shù)的工具函數(shù)。我自己的版本還會在超過16字節(jié)后換行縮進(jìn)效果接近命令行里的xxd排查協(xié)議包時(shí)能省下不少眼睛的功夫。