摘要：但是當時因為時間限制，沒有去深入學習的更多細節(jié)。每一位的對應含義第一位，表示這個位置在轉(zhuǎn)換后的壓縮文件的第幾列。第三位，表示這個位置屬于原始文件的第幾行。第五位，數(shù)組中的索引，表示這個位置屬于源文件中的哪一個變量。

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

在這篇文章里我用一個簡單的UI5應用來研究該機制。這個應用的UI僅僅包含一個Button，點擊之后彈出一個Message Toast。

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

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

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

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

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

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

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

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

在Chrome里輸入url: "chrome://net-internals/#events", 結(jié)果顯示確實有一個url請求去訪問sap-ui-core.js.map, 只是因為本地磁盤緩存能響應該請求, 因此沒有產(chǎn)生真正的網(wǎng)絡請求:

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

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

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

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

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

version: 3

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

sources:

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

names:

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

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

mappings:

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

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

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

從Google網(wǎng)站下載compile.jar， 然后生成一個名為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)生如下輸出：每個segment由4或5個字符組成。

每一位的對應含義:

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

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

第三位，表示這個位置屬于原始文件的第幾行。

第四位，表示這個位置屬于原始文件的第幾列。

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

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