前言

这也是 最近碰到的一个比较有趣的问题

是在 http 请求较多的场景下触发的情况

一般 我们的 Vue 中使用图片的地方, 一般会使用 require(“$imgPath”) 或者 “/$imgPath” 来配置图片的资源  

然后 这个在目标页面 http 请求比较多的情况下, 两者 会有一些 差异, 我们这里来看一下 两者的差异

 

 

参照的两种加载的方式以及情况

两种加载方式如下, 一个是使用 require 函数, 另外一个是直接配置的图片路径

在目标页面 http 请求比较多的情况下 可能图片的 http 请求会排队, 进而导致 目标图片较长时间加载不出来, 而后者不会 直接从 js 中拿到目标图片的 base64 进行加载

 

 

使用绝对路径加载图片

这个具体的加载的方式取决于客户端, 比如 img 标签, 那就是 chrome 这边自动触发该图片的 http 请求的发送

我们这里 场景下面是 mars3d 的 XXEntity, 我们这里看一下 这里的加载方式, 这个就是 整个调用栈, 由于该部分源码是混淆了的, 这里就不去深究了, 就当成是 浏览器这边自动触发的就行, 接下来我们看一下 客户端 和 服务器 的交互的开销

 

可以看到 图片的这个请求 block 了很久, 请求本身没有太大的开销

chome 这边该请求本地的排队, 花费了 15秒

然后 另外一个较大的开销是 stalled 的开销, 是客户端这边和服务器建立了 tcp连接 到 可以正式传输数据 的时间开销, 可以看到 很大一部分压力是在这里, 这里就需要 看服务器这边的相关配置, 处理了, 同样具体的我们不深究

造成的情况就是, 页面会存在的问题就是, 该图标加载不出来, 图标的附近的其他业务元素正常显示, 就造成页面看起来十分奇怪

 

 

npm run dev 对于 require("./img/red.png") 的这边处理

业务这边 require 函数处理如下

 

具体的加载方式如下, 调用的是为目标 module 生成的 js

 

目标 module 的 js 如下, 直接获取的目标 图片的 base64

 

传递到 BillboardEntity 的时候传入的 style.img 已经是目标图片的 base64 了

有了该图片的数据, BillboardEntity 就可以绘制目标图片了

 

图片相关的处理均是在客户端这边

 

 

npm run build 对于 require("./img/red.png") 的这边处理

该 require 打包之后的结果如下, 转换为了一个函数调用

 

目标函数如下, 直接相应的是目标图片的 base64 的字符串信息

 

图片相关的处理均是在客户端这边

 

 

完