在我的博客A debugging issue caused by source code mapping里我介紹了在我做SAP C4C開發(fā)時(shí)遇到的一個(gè)曾經(jīng)困擾我很久的問題，最后結(jié)論是這個(gè)問題由于JavaScript的source code map機(jī)制在Chrome開發(fā)者工具里起作用，其實(shí)是working as designed的一種行為。但是當(dāng)時(shí)因?yàn)闀r(shí)間限制，沒有去深入學(xué)習(xí)JavaScript source code map的更多細(xì)節(jié)。

在這篇文章里我用一個(gè)簡(jiǎn)單的UI5應(yīng)用來研究該機(jī)制。這個(gè)應(yīng)用的UI僅僅包含一個(gè)Button，點(diǎn)擊之后彈出一個(gè)Message Toast。

下面是我XML view和Controller的實(shí)現(xiàn)。

打開Chrome開發(fā)者工具里的source code map開關(guān)：

然后瀏覽器里訪問這個(gè)UI5應(yīng)用，我們就能在Chrome開發(fā)者工具里看到這些UI5庫文件的調(diào)試版本(.dbg.js)。但是在Chrome開發(fā)者工具的Network標(biāo)簽里，我們觀察不到這些調(diào)試版本文件的加載。那么問題來了：這些.dbg.js文件從哪里來的？

當(dāng)關(guān)閉Chrome開發(fā)者工具的source code map功能之后，我們?cè)贑hrome開發(fā)者工具里再也觀察不到這些.dbg.js文件了。將下圖和source code map打開時(shí)的截圖做比較：

如何在本地找到sap-ui-core.js.map文件

單擊sap-ui-core.js,在其最后一行1875行，看到該行內(nèi)容：

//# sourceMappingURL=sap-ui-core.js.map

這個(gè)文件的后綴.map給了我們提示：其作用就是維護(hù)位置映射關(guān)系，將sap-ui-core.js(壓縮之后的文件)里的代碼位置映射到壓縮之前的代碼位置(來自壓縮之前的文件名，代碼行數(shù)，代碼列數(shù)，涉及到的壓縮之前的JavaScript變量名)。

但是，同樣的，我在開發(fā)者工具的Network標(biāo)簽里也觀察不到這個(gè).map文件被加載。

在Chrome里輸入url: "chrome://net-internals/#events", 結(jié)果顯示確實(shí)有一個(gè)url請(qǐng)求去訪問sap-ui-core.js.map, 只是因?yàn)楸镜卮疟P緩存能響應(yīng)該請(qǐng)求, 因此沒有產(chǎn)生真正的網(wǎng)絡(luò)請(qǐng)求:

在Chrome里輸入"chrome://cache"能看到Chrome本地的所有緩存，從這里我成功找到了文件sap-ui-core.js.map的本地緩存。

單擊該超鏈接能看到這條緩存的抬頭信息。但是緩存的具體文件內(nèi)容顯示格式為HEX，沒法直接分析。

因此我使用了工具Cache viewer for Google Chrome Web browser, 將該緩存導(dǎo)出成本地文件。

sap-ui-core.js.map文件內(nèi)容一覽

這篇博客Introduction to JavaScript Source Maps介紹了JavaScript source code map的基本知識(shí)。

文件sap-ui-core.js.map的內(nèi)容：

• version: 3

.map文件的各組成部分的作用和含義定義在一個(gè)叫做Source Map Revision Proposal的協(xié)議文檔里，在我的例子sap-ui-core.js.map里使用了該協(xié)議的第三版。

• sources:

這是一個(gè)數(shù)組，包含了所有用于生成壓縮之后的js文件的原始文件的名稱。

• names:

這是一個(gè)數(shù)組，包含了原始js文件里出現(xiàn)的JavaScript變量和屬性名稱。

下面是一個(gè)例子，體現(xiàn)了原始文件之一Device-dbg.js里的變量名稱和其在sap-ui-core.js.map文件里的names數(shù)組里的對(duì)應(yīng)記錄，方便您理解。

• mappings:

.map文件最重要的部分，定義了原始文件內(nèi)的位置和生成壓縮版本文件內(nèi)位置的對(duì)應(yīng)關(guān)系。對(duì)應(yīng)關(guān)系記錄的粒度是基于壓縮之后文件的每一行，用分號(hào)隔開。這樣做的好處是無需再分配而外的位來維護(hù)壓縮文件位置的行號(hào)信息。

回到我的例子，壓縮文件sap-ui-core.js一共包含1874行，因此sap-ui-core.js.map一共出現(xiàn)了1874次分號(hào)，每個(gè)分號(hào)內(nèi)又是一個(gè)很長(zhǎng)的字符串，由一系列逗號(hào)隔開，這些由逗號(hào)隔開的字符串片段稱為Segment。每個(gè)Segment維護(hù)了一個(gè)位置的映射關(guān)系。

如何生成.map文件

有很多開源的組件用于生成.map文件，其中之一是Google Closure compiler。假設(shè)我想基于我的測(cè)試應(yīng)用里的controller實(shí)現(xiàn)文件App.controller.js生成一個(gè)壓縮版本的文件：

從Google網(wǎng)站下載compile.jar， 然后生成一個(gè)名為script-min.js的壓縮文件和script-min.js.map：

java -jar compile.jar --js App.controller.js --create_source_map ./script-min.js.map --source_map_format=V3 --js_output_file script-min.js

生成的壓縮文件script-min.js只有1行內(nèi)容:

生成的script-min.js.map內(nèi)容:

可以使用vlq.js將這些segment解碼：

瀏覽器打開該html，產(chǎn)生如下輸出：每個(gè)segment由4或5個(gè)字符組成。

每一位的對(duì)應(yīng)含義:

• 第一位，表示這個(gè)位置在轉(zhuǎn)換后的壓縮文件的第幾列。

• 第二位，sources數(shù)組中的索引，表示這個(gè)位置來自哪一個(gè)原始文件。

• 第三位，表示這個(gè)位置屬于原始文件的第幾行。

• 第四位，表示這個(gè)位置屬于原始文件的第幾列。

• 第五位，names數(shù)組中的索引，表示這個(gè)位置屬于源文件中的哪一個(gè)變量。

關(guān)于VLQ編碼的更多細(xì)節(jié)，可以閱讀這篇博客Source Maps under the hood – VLQ, Base64 and Yoda

要獲取更多Jerry的原創(chuàng)技術(shù)文章，請(qǐng)關(guān)注公眾號(hào)"汪子熙"