UI5 Source code map机制的细节介绍

在个人博客A debugging issue caused by source code mapping里我介绍了在我作SAP C4C开发时遇到的一个曾经困扰我好久的问题,最后结论是这个问题因为JavaScript的source code map机制在Chrome开发者工具里起做用,实际上是working as designed的一种行为。可是当时由于时间限制,没有去深刻学习JavaScript source code map的更多细节。javascript

在这篇文章里我用一个简单的UI5应用来研究该机制。这个应用的UI仅仅包含一个Button,点击以后弹出一个Message Toast。html

下面是我XML view和Controller的实现。html5

打开Chrome开发者工具里的source code map开关:java

而后浏览器里访问这个UI5应用,咱们就能在Chrome开发者工具里看到这些UI5库文件的调试版本(.dbg.js)。可是在Chrome开发者工具的Network标签里,咱们观察不到这些调试版本文件的加载。那么问题来了:这些.dbg.js文件从哪里来的?git

当关闭Chrome开发者工具的source code map功能以后,咱们在Chrome开发者工具里再也观察不到这些.dbg.js文件了。将下图和source code map打开时的截图作比较:github

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

单击sap-ui-core.js,在其最后一行1875行,看到该行内容:chrome

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

这个文件的后缀.map给了咱们提示:其做用就是维护位置映射关系,将sap-ui-core.js(压缩以后的文件)里的代码位置映射到压缩以前的代码位置(来自压缩以前的文件名,代码行数,代码列数,涉及到的压缩以前的JavaScript变量名)。数组

可是,一样的,我在开发者工具的Network标签里也观察不到这个.map文件被加载。浏览器

在Chrome里输入url: "chrome://net-internals/#events", 结果显示确实有一个url请求去访问sap-ui-core.js.map, 只是由于本地磁盘缓存能响应该请求, 所以没有产生真正的网络请求:缓存

在Chrome里输入"chrome://cache"能看到Chrome本地的全部缓存,从这里我成功找到了文件sap-ui-core.js.map的本地缓存。

单击该超连接能看到这条缓存的抬头信息。可是缓存的具体文件内容显示格式为HEX,无法直接分析。

所以我使用了工具Cache viewer for Google Chrome Web browser, 将该缓存导出成本地文件。

sap-ui-core.js.map文件内容一览

这篇博客Introduction to JavaScript Source Maps介绍了JavaScript source code map的基本知识。

文件sap-ui-core.js.map的内容:

  • version: 3

.map文件的各组成部分的做用和含义定义在一个叫作Source Map Revision Proposal的协议文档里,在个人例子sap-ui-core.js.map里使用了该协议的第三版。

  • sources:

这是一个数组,包含了全部用于生成压缩以后的js文件的原始文件的名称。

  • names:

这是一个数组,包含了原始js文件里出现的JavaScript变量和属性名称。

下面是一个例子,体现了原始文件之一Device-dbg.js里的变量名称和其在sap-ui-core.js.map文件里的names数组里的对应记录,方便您理解。

  • mappings:

.map文件最重要的部分,定义了原始文件内的位置和生成压缩版本文件内位置的对应关系。对应关系记录的粒度是基于压缩以后文件的每一行,用分号隔开。这样作的好处是无需再分配而外的位来维护压缩文件位置的行号信息。

回到个人例子,压缩文件sap-ui-core.js一共包含1874行,所以sap-ui-core.js.map一共出现了1874次分号,每一个分号内又是一个很长的字符串,由一系列逗号隔开,这些由逗号隔开的字符串片断称为Segment。每一个Segment维护了一个位置的映射关系。

如何生成.map文件

有不少开源的组件用于生成.map文件,其中之一是Google Closure compiler。假设我想基于个人测试应用里的controller实现文件App.controller.js生成一个压缩版本的文件:

Google网站下载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行内容:

生成的script-min.js.map内容:

可使用vlq.js将这些segment解码:

浏览器打开该html,产生以下输出:每一个segment由4或5个字符组成。

每一位的对应含义:

  • 第一位,表示这个位置在转换后的压缩文件的第几列。

  • 第二位,sources数组中的索引,表示这个位置来自哪个原始文件。

  • 第三位,表示这个位置属于原始文件的第几行。

  • 第四位,表示这个位置属于原始文件的第几列。

  • 第五位,names数组中的索引,表示这个位置属于源文件中的哪个变量。

关于VLQ编码的更多细节,能够阅读这篇博客Source Maps under the hood – VLQ, Base64 and Yoda

要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码:

相关文章
相关标签/搜索