在线调试方案的思考与实践,控制台不完全指南

2019-09-11 16:05栏目:人才招聘
TAG:

HTTP Client Hints 介绍

2015/09/14 · HTML5 · 算法

原文出处: imququ(@屈光宇)   

最近几年各种 Web 技术一直在爆炸式发展,每天都有大量新东西涌现出来。针对这个现象,业内两位大佬最近先后发文表达了自己的观点:Stop pushing the web forward、Is the web platform getting too big?。其实很早之前我就意识到以我目前的精力,吃透所有 Web 新技术几乎是不可能完成的任务,我关注新技术的侧重点放在了性能优化上。

今天我要向大家介绍的技术是:HTTP Client Hints,也与性能优化有关。利用这项技术,HTTP 客户端(通常可以认为是浏览器)能够主动将一些特性告诉服务端,以便服务端更有针对性地输出内容。这项技术由我们熟知的 Ilya Grigorik 提出,目前还处在较为早期的阶段,较为正式的描述文档可以在这里找到。目前 Chrome 46 (beta) 已支持它,IE 和 Firefox 则还在考虑中。

其实之前浏览器已经将很多自身特性放在 HTTP 请求中,例如下面这些头部字段:

  • User-Agent:提供浏览器类型及版本、操作系统及版本、浏览器内核等信息;
  • Accept:表明浏览器支持哪些 MIME type(例如 Chrome 通过 Accept 表明自己支持 image/webp 图片格式);
  • Accept-Encoding:表明本浏览器支持哪些内容编码方式(例如:gzip、deflate、sdch);
  • Accept-Language:表明本浏览器支持那些语言;

通过以上这些头部字段,我们已经可以针对不同客户端输出不同内容。例如本博客对支持 Webp 格式的浏览器会使用 Webp 来减少图片大小;本博客还会通过 User-Agent 针对 IE 老版本禁用 localStorage 缓存策略。

但是有一些浏览器特性,我们无法直接获取,如屏幕分辨率、设备像素比(devicePixelRatio)、用户带宽等。而在移动 Web 中,为了尽可能节省用户流量,需要输出尺寸最合适的图片资源。为了解决这个问题,常见的方案有:1)使用 JS 获取这些特性,动态拼接图片 URL;2)使用 HTML 中的 sizes 和 srcset 属性、picture 标签或 CSS 中的 image-set 属性来实现响应式图片。方案 1 很简单,这里略过;方案 2 网上有很多相关文章,不熟悉的同学可以自行搜索「响应式图片」了解下。

这里看一个使用方案 2 中提到的 picture、sizes 和 srcset 实现的响应式图片代码(via):

<picture> <!-- serve WebP to Chrome and Opera --> <source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w, /image/thing-800.webp 800w, /image/thing-1200.webp 1200w, /image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w" type="image/webp"> <source sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w, /image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w, /image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w" type="image/webp"> <!-- serve JPEGXR to Edge --> <source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.jpgxr 200w, /image/thing-400.jpgxr 400w, /image/thing-800.jpgxr 800w, /image/thing-1200.jpgxr 1200w, /image/thing-1600.jpgxr 1600w, /image/thing-2000.jpgxr 2000w" type="image/vnd.ms-photo"> <source sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.jpgxr 200w, /image/thing-crop-400.jpgxr 400w, /image/thing-crop-800.jpgxr 800w, /image/thing-crop-1200.jpgxr 1200w, /image/thing-crop-1600.jpgxr 1600w, /image/thing-crop-2000.jpgxr 2000w" type="image/vnd.ms-photo"> <!-- serve JPEG to others --> <source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w, /image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w, /image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w"> <source sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w, /image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w, /image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w"> <!-- fallback for browsers that don't support picture --> <img src="/image/thing.jpg" width="50%"> </picture>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<picture>
  <!-- serve WebP to Chrome and Opera -->
  <source
    media="(min-width: 50em)"
    sizes="50vw"
    srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w,
        /image/thing-800.webp 800w, /image/thing-1200.webp 1200w,
        /image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w"
    type="image/webp">
  <source
    sizes="(min-width: 30em) 100vw"
    srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w,
        /image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w,
        /image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w"
    type="image/webp">
  <!-- serve JPEGXR to Edge -->
  <source
    media="(min-width: 50em)"
    sizes="50vw"
    srcset="/image/thing-200.jpgxr 200w, /image/thing-400.jpgxr 400w,
        /image/thing-800.jpgxr 800w, /image/thing-1200.jpgxr 1200w,
        /image/thing-1600.jpgxr 1600w, /image/thing-2000.jpgxr 2000w"
    type="image/vnd.ms-photo">
  <source
    sizes="(min-width: 30em) 100vw"
    srcset="/image/thing-crop-200.jpgxr 200w, /image/thing-crop-400.jpgxr 400w,
        /image/thing-crop-800.jpgxr 800w, /image/thing-crop-1200.jpgxr 1200w,
        /image/thing-crop-1600.jpgxr 1600w, /image/thing-crop-2000.jpgxr 2000w"
    type="image/vnd.ms-photo">
  <!-- serve JPEG to others -->
  <source
    media="(min-width: 50em)"
    sizes="50vw"
    srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w,
        /image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w,
        /image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w">
  <source
    sizes="(min-width: 30em) 100vw"
    srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w,
        /image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w,
        /image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w">
  <!-- fallback for browsers that don't support picture -->
  <img src="/image/thing.jpg" width="50%">
</picture>

这段冗长的代码只是为了实现一张响应式图片,尽管有一些夸张,实际使用时一般不会写这么全,但从中可以得到一个结论:在客户端实现的策略越多,HTML 体积就越大越冗余,可维护性和可读性就越差。

而使用了 HTTP Client Hints 之后,浏览器在页面发起子资源请求时,会通过新增的一系列头部字段带上分辨率、设备像素比、图片宽度等信息,使得各种复杂的策略可以挪到服务端去实现了。下面来看一看具体细节:

首先,有了支持 HTTP Client Hints 的浏览器之后,页面上还需要显式启用它。这是因为不是所有服务端都实现了响应式输出策略,每次都发送这些新增的头部可能会造成浪费。

与往常一样,这个功能也可以通过 HTTP 响应头和 meta 标签两种方式开启并配置:

Accept-CH: DPR, Width, Viewport-Width

1
Accept-CH: DPR, Width, Viewport-Width

或:

<meta http-equiv="Accept-CH" content="DPR, Width, Viewport-Width">

1
<meta http-equiv="Accept-CH" content="DPR, Width, Viewport-Width">

在启用了 HTTP Client Hints 的页面中,所有子资源请求(无论什么类型,无论什么方式创建),都会携带 Accept-CH 属性中所指明的头部,例如:

Accept: image/webp,image/*,*/*;q=0.8 Accept-Encoding: gzip, deflate, sdch Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,en-US;q=0.4,ja;q=0.2,de;q=0.2,zh-TW;q=0.2,cs;q=0.2,pt;q=0.2,ko;q=0.2 Connection: keep-alive DPR: 2 Host: qgy18.imququ.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.13 Safari/537.36 Viewport-Width: 1280 Width: 128

1
2
3
4
5
6
7
8
9
Accept: image/webp,image/*,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,en-US;q=0.4,ja;q=0.2,de;q=0.2,zh-TW;q=0.2,cs;q=0.2,pt;q=0.2,ko;q=0.2
Connection: keep-alive
DPR: 2
Host: qgy18.imququ.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.13 Safari/537.36
Viewport-Width: 1280
Width: 128

有了这些头部,图片服务器可以知道客户端的 devicePixelRatio 是 2、图片宽度是 128px、支持 Webp 格式,所以输出 256px 的双倍 Webp 图最合适。但是浏览器怎么知道这个图片需要作为双倍图来使用呢(也就是说还是显示为 128px)?这就需要在响应头中增加下面这个字段作为 DPR 的回应:

Content-DPR: 2

1
Content-DPR: 2

需要注意的是,请求头中的 Width 字段,是根据 img 标签上的 sizes 属性算出来的。如果图片没有指定 sizes,或者图片请求是通过 JS 创建的,浏览器无法得知 Width,也就不会携带这个头部。

实际上,除了 DPR、Viewport-Width 和 Width 之外,文档还规定了两个字段,但是经过我的测试 Chrome 46 并没有支持它们,这里简单介绍下:

  • Downlink:用来指示当前网络的下行链路带宽,单位是 Mbps;
  • Save-Data:用来指示当前浏览器是否工作在省流模式之下,取值为 1 或 0;

可以看出这两个属性,也是为了尽可能给用户节省带宽而设计的。可以预见,后续还会有更多字段加到 HTTP Client Hints 协议中来。随着 HTTP/2 的普及,头部压缩使得增加几个头部字段带来的开销变得很小了。

值得注意的是,使用了 HTTP Client Hints 之后,服务端针对同一个 URL 可能会输出不同的内容,所以无论是中间节点,还是浏览器,在实现响应 Cache 时必须小心,需要针对不同的情况缓存多份内容。这需要用到 HTTP/1 中的  Vary 响应头,例如:

Vary: DPR, Width, Downlink

1
Vary: DPR, Width, Downlink

表明如果需要缓存这个响应,在生成缓存 Key 的时候需要将请求头中的 DPR、Width 和 Downlink 的值计算进去。

好了,HTTP Client Hints 技术就介绍到这里。很欣慰地看到,大部分 Web 新技术都是在给 HTML、CSS 和 JavaScript 增加功能和特性,而这项技术却是把之前复杂的代码和逻辑往后移,让我们的 HTML 代码能够轻装上阵。一些开源图片处理系统已经开始支持这个新特性了,国外的一些 CDN 托管服务肯定也在蠢蠢欲动,我十分期待它的未来。

1 赞 收藏 评论

图片 1

在线调试方案的思考与实践

2015/08/28 · HTML5 · 调试

原文出处: 李靖(@Barret李靖)   

本文的要点不在移动端调试上,移动端调试无非就是调试页面和调试工具之间存在分离,消除这种分离并创建连结就能解决移动端的调试问题。重点阐述的是所见即所得的调试模式下会遇到的阻碍。

当我们打开网页,发现一个模块没有正确地渲染或者空白时,如果控制台有报错,会直接根据报错定位到源码位置开始 debug;如果控制台没有报错,则会根据模块名或者模块特征的一个值,通过全局搜索找到这个模块的位置,然后在调试工具中断点,单步调试,找到问题所在,此时我们可能会这样做:

情形一:

小A同学打开控制台,发现断点调试不好写代码,于是将压缩的源码复制一份保存到本地,格式化,然后将线上资源通过代理工具代理到本地文件。

情形二:

小B同学早早的为自己配了一份本地开发环境,于是他遇到问题之后,直接去源码中定位错误位置,由于使用的是预处理语言,所以需要先打包编译之后再在本地预览效果。

情形三:

小C同学的调试方式是小A和小B的综合版本,将线上的资源代理到本地 build 目录文件,在 src 目录下修改之后编译打包到 build,然后预览。

Chrome 控制台不完全指南

2015/01/10 · JavaScript · 1 评论 · Chrome

本文作者: 伯乐在线 - 刘哇勇 。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

Chrome的开发者工具已经强大到没朋友的地步了,特别是其功能丰富界面友好的console,使用得当可以有如下功效:

  • 更高「逼格」更快「开发调试」更强「进阶级的Frontender」
  • Bug无处遁形「Console大法好」

☞ 代理调试的烦恼

而对于比较复杂的线上环境,代理也会遇到很多障碍,比如:

线上资源 combo

出现错误的脚本地址为  ,它对应着 a.js,b.js,c.js 三个脚本文件,如果我们使用 Fiddler/Charles 这样的经典代理工具调试代码,就必须给这些工具编写插件,或者在替换配置里头加一堆判断或者正则,成本高,门槛高。

线上代码压缩

打包压缩,这是上线之前的必经流程。由于我们在打包的环节中并没有考虑为代码添加 sourceMap,而线上之前对应 index-min.jsindex.js 也因为安全方面的原因给干掉了,这给我们调试代码造成了极大的不便利。

代码依赖较多,拉取代码问题

很多时候,我们的页面依赖了多个 asserts 资源,而这些资源各自分布在多个仓库之中,甚至分布在不同的发布平台上,为了能够在源码上清晰的调试代码,我们不得不将所有的资源下载到本地,期间一旦存在下载代码的权限问题,整个调试进度就慢下来,这是十分不能忍受的事情。比如某系统构建的页面,页面上的模块都是以仓库为维度区分的,一个页面可能对应了5-50个仓库,下载代码实为麻烦。

最可怕的调试是,本地没有对应的测试环境、代理工具又不满足我们的需求,然后就只能, 编辑代码->打包压缩->提交代码->查看效果->编辑代码->... ,如果你的项目开发是这种模式,请停下来,思考调试优化方案,正所谓磨刀不误砍柴工。

console.log

大家都会用log,但鲜有人很好地利用console.error , console.warn 等将输出到控制台的信息进行分类整理。
他们功能区别不大,意义在于将输出到控制台的信息进行归类,或者说让它们更语义化。
各个所代表的语义如下:

  • console.log:普通信息
  • console.info:提示类信息
  • console.error:错误信息
  • console.warn:警示信息

当合理使用上述log方法后,可以很方便地在控制台选择查看特定类型的信息。

JavaScript

console.log('一颗红心向太阳','吼吼~'); console.info('楼上药不能停!'); console.warn('楼上嘴太贱!'); console.error('楼上关你毛事?');

1
2
3
4
console.log('一颗红心向太阳','吼吼~');
console.info('楼上药不能停!');
console.warn('楼上嘴太贱!');
console.error('楼上关你毛事?');

图片 2

如果再配合console.group 与console.groupEnd,可以将这种分类管理的思想发挥到极致。这适合于在开发一个规模很大模块很多很复杂的Web APP时,将各自的log信息分组到以各自命名空间为名称的组里面。

JavaScript

console.group("app.foo"); console.log("来自foo模块的信息 blah blah blah..."); console.groupEnd(); console.group("app.bar"); console.log("来自bar模块的信息 blah blah blah..."); console.groupEnd();

1
2
3
4
5
6
console.group("app.foo");
console.log("来自foo模块的信息 blah blah blah...");
console.groupEnd();
console.group("app.bar");
console.log("来自bar模块的信息 blah blah blah...");
console.groupEnd();

图片 3

而关于console.log,早已被玩儿坏了。一切都源于Chrome提供了这么一个API:第一个参数可以包含一些格式化的指令比如%c

比如给hello world 做件漂亮的嫁衣再拉出来见人:

JavaScript

console.log('%chello world','font-size:25px;color:red;');

1
console.log('%chello world','font-size:25px;color:red;');

图片 4

如果你觉得不够过瘾,那就把你能写出来的最华丽的CSS样式都应用上吧,比如渐变。于是你可以得到如下华丽丽的效果:

JavaScript

console.log('%chello world', 'background-image:-webkit-gradient( linear, left top, right top, color-stop(0, #f22), color-stop(0.15, #f2f), color-stop(0.3, #22f), color-stop(0.45, #2ff), color-stop(0.6, #2f2),color-stop(0.75, #2f2), color-stop(0.9, #ff2), color-stop(1, #f22) );color:transparent;-webkit-background-clip: text;font-size:5em;');

1
console.log('%chello world', 'background-image:-webkit-gradient( linear, left top, right top, color-stop(0, #f22), color-stop(0.15, #f2f), color-stop(0.3, #22f), color-stop(0.45, #2ff), color-stop(0.6, #2f2),color-stop(0.75, #2f2), color-stop(0.9, #ff2), color-stop(1, #f22) );color:transparent;-webkit-background-clip: text;font-size:5em;');

图片 5

各种招大招的节奏啊~

看着上面密集的代码不用惊慌,上面console.log()第二个参数全是纯CSS用来控制样式的,你不会陌生。而第一个参数里可以带用百分号开头的转义指令,如上面输出带样式的文字时使用的%c指令。更详细的指令参见官方API文档的这个表格。

如果还不够过瘾,那咱们来log一些图片吧,甚至。。。动图?
对,你得先有图,我们拿这张图为例。

JavaScript

console.log("%c", "padding:50px 300px;line-height:120px;backgroundnull:url('') no-repeat;");

1
console.log("%c", "padding:50px 300px;line-height:120px;backgroundnull:url('http://wayou.github.io/2014/09/10/chrome-console-tips-and-tricks/rabbit.gif') no-repeat;");

图片 6

看着上面摇摆的豆比兔是不是有种抽它一脸的冲动。

除此,console.table 更是直接以表格的形式将数据输出,不能赞得太多!
借用之前写过的一篇博文里的例子:

JavaScript

var data = [{'品名': '杜雷斯', '数量': 4}, {'品名': '冈本', '数量': 3}]; console.table(data);

1
2
var data = [{'品名': '杜雷斯', '数量': 4}, {'品名': '冈本', '数量': 3}];
console.table(data);

图片 7

另外,console.log() 接收不定参数,参数间用逗号分隔,最终会输出会将它们以空白字符连接。

JavaScript

console.log('%c你好','color:red;','小明','你知道小红被妈妈打了么');

1
console.log('%c你好','color:red;','小明','你知道小红被妈妈打了么');

图片 8

☞ 开启懒人调试模式

当看到线上出现问题(可能是其他同学负责页面的问题),脑中浮出这样的场景:

复制代码 我:"嘿,线上有问题啦!我要调试代码!" 电脑:"好的,主人。请问是哪个页面?"(弹出浮层) 我:浮层中输入URL。 电脑:"请问是哪个地方出问题了?" 我:(指着电脑)"模块A和模块B。" 电脑:正在下载A、B资源...正在将上线A、B映射到本地...自动打开A、B对应文件夹 我:编辑代码,然后实时预览效果。

1
2
3
4
5
6
7
8
复制代码
  我:"嘿,线上有问题啦!我要调试代码!"
电脑:"好的,主人。请问是哪个页面?"(弹出浮层)
  我:浮层中输入URL。
电脑:"请问是哪个地方出问题了?"
  我:(指着电脑)"模块A和模块B。"
电脑:正在下载A、B资源...正在将上线A、B映射到本地...自动打开A、B对应文件夹
  我:编辑代码,然后实时预览效果。

在这里我们需要解决这样几个问题

  • 将页面对应的所有仓库/资源罗列在用户面前
  • 下载资源的权限提示和权限处理
  • 线上资源解 combo,然后映射到本地

当然调试之后,可以还有一个操作:

我:"哈,已经修复了,帮我提交代码~" 电脑:正在diff代码...收到确认提交信号,提交到预发环境...收到已经预览信号...正在发布代码...收到线上回归信号...流程结束

1
2
我:"哈,已经修复了,帮我提交代码~"
电脑:正在diff代码...收到确认提交信号,提交到预发环境...收到已经预览信号...正在发布代码...收到线上回归信号...流程结束

除了 debug 代码,我们需要做的就只是用眼睛看效果是否 ok,整个流程优化下来,体验是很赞的!

console.assert

当你想代码满足某些条件时才输出信息到控制台,那么你大可不必写if或者三元表达式来达到目的,cosole.assert便是这样场景下一种很好的工具,它会先对传入的表达式进行断言,只有表达式为假时才输出相应信息到控制台。

JavaScript

var isDebug=false; console.assert(isDebug,'开发中的log信息。。。');

1
2
var isDebug=false;
console.assert(isDebug,'开发中的log信息。。。');

图片 9

☞ 解决代理遇到的问题

上面我们提到了三个问题,平时开发遇到最头疼的一个是 combo ,曾经我们页面上的代码加一个 ?_xxx  参数就能够直接开始调试模式,那是因为程序的入口只有一个,而且所有脚本的依赖也打包到一个叫做 deps.js  文件中,加上调试参数之后,可以将原来 combo 加载的文件:  ,按照非 combo 的方式加载:

1
2
3
http://example.com/path/a.js
http://example.com/path/b.js
http://example.com/path/c.js

上面的代码可以轻松地代理到本地,但是有的系统生成的代码并没有 deps.js  文件,它是将脚本直接输出到页面上:

<script src=";

1
<script src="http://example.com/path/??a-min.js,b-min.js,c-min.js"></script>

☞ 解决 combo 问题

此时通过 Fiddler/Charles 工具比较难满足需求,对于这个问题有两个处理方案:

1). 浏览器请求全部代理到本地的一个服务

首先写一个本地服务:

JavaScript

var http = require('http'); // npm i http-proxy --save var httpProxy = require('http-proxy'); var proxy = httpProxy.createProxyServer({}); var server = http.createServer(function(req, res) { console.log(req.url); if(req.url.indexOf("??") > -1){ // combo资源让 3400 端口的服务处理 proxy.web(req, res, { target: '' }); } else { // 直接返回 proxy.web(req, res, { target: req.url }); } }).listen(3399, function(){ console.log("在端口 3399 监听浏览器请求"); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
var http = require('http');
// npm i http-proxy --save
var httpProxy = require('http-proxy');
var proxy = httpProxy.createProxyServer({});
 
var server = http.createServer(function(req, res) {
  console.log(req.url);
  if(req.url.indexOf("??") > -1){
    // combo资源让 3400 端口的服务处理
    proxy.web(req, res, { target: 'http://127.0.0.1:3400' });
  } else {
    // 直接返回
    proxy.web(req, res, { target: req.url });
  }
}).listen(3399, function(){
    console.log("在端口 3399 监听浏览器请求");
});

代码的意思是,利用 http-proxy 这个 npm 包,代理浏览器的请求,浏览器上使用 switchSharp 设置本地代理为  ,当请求过来,先判断 url,如果 url 中包含了 ?? 则将其作为 combo 资源处理,代理给本地的另一个服务  ,这个服务收到请求后会将 combo 内容分解成多个,全部请求完之后再吐出来。

2). 使用本地服务请求 html 代码,替换 html 代码内容

使用强制手段(源码替换)将代码解 combo,比如源码页面为:

<!-- html code --> <script src="; <!-- html code -->

1
2
3
<!-- html code -->
<script src="http://example.com/path/??a-min.js,b-min.js,c-min.js"></script>
<!-- html code -->

使用本地服务请求这个url,然后转换成:

<!-- html code --> <script src="; <script src="; <script src="; <!-- html code -->

1
2
3
4
5
<!-- html code -->
<script src="http://example.com/path/a.js"></script>
<script src="http://example.com/path/b.js"></script>
<script src="http://example.com/path/c.js"></script>
<!-- html code -->

实现这个操作的代码:

JavaScript

var http = require('http'); // npm i request --save; var request = require('request'); http.createServer(function(req, res){ var path = req.url.slice(req.url.indexOf("path=") + 5); console.log(path); if(!path) { res.write("path is empty"); res.end(); return; } request(path, function (error, response, body) { if (!error && response.statusCode == 200) { console.log(body); // 代码替换 body = body.replace('<script src=";', '<script src=" <script src=" <script src=";' ); res.write(body); res.end(); } }); }).listen(3399, function(){ console.log("listening on port 3399"); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
var http = require('http');
// npm i request --save;
var request = require('request');
http.createServer(function(req, res){
    var path = req.url.slice(req.url.indexOf("path=") + 5);
    console.log(path);
    if(!path) {
        res.write("path is empty");
        res.end();
        return;
    }
    request(path, function (error, response, body) {
        if (!error && response.statusCode == 200) {
            console.log(body);
            // 代码替换
            body = body.replace('<script src="http://example.com/path/??a-min.js,b-min.js,c-min.js"></script>',
                '<script src="http://example.com/path/a.js"></script>
                <script src="http://example.com/path/b.js"></script>
                <script src="http://example.com/path/c.js"></script>'
            );
            res.write(body);
            res.end();
        }
    });
}).listen(3399, function(){
    console.log("listening on port 3399");
});

比如请求  ,即可拿到淘宝首页的源码,然后对拿到的代码做替换。

☞ 解决代码压缩问题

对于这个问题,建议在线上放两份源码,一份是压缩源码,一份是未压缩源码,当页面 url 存在 debug 参数的时候,返回未压缩版本,正常返回压缩版本。当然,也可以采用上述方式处理问题。

不过,更合理的方式应该是 sourceMap,前端没有秘密,压缩代码只是增加了 hacker 的攻击成本,并不妨碍有能力的 hacker 借系统漏洞入侵。所以可以为源码提供一份 sourceMap 文件。

JavaScript

var gulp = require('gulp'); var sourcemaps = require('gulp-sourcemaps'); gulp.task('javascript', function() { gulp.src('src/**/*.js') .pipe(sourcemaps.init()) //.pipe(xx()) .pipe(sourcemaps.write()) .pipe(gulp.dest('dist')); });

1
2
3
4
5
6
7
8
9
10
var gulp = require('gulp');
var sourcemaps = require('gulp-sourcemaps');
 
gulp.task('javascript', function() {
  gulp.src('src/**/*.js')
    .pipe(sourcemaps.init())
      //.pipe(xx())
    .pipe(sourcemaps.write())
    .pipe(gulp.dest('dist'));
});

关于 sourceMap 的 gulp 插件配置,详情可以戳这里。不仅仅是 JavaScript,CSS 也有 source maps,这个信息可以在 Chrome 控制台的设置选项中看到:

图片 10

☞ 代码的拉取

如果一个项目只有你知道如何修改,那这个项目的技术设计就有点糟糕了,为了让众人都能处理你项目中的问题,一定要需要一个简洁的模式为开发者快速搭建测试环境,文档是一方面,如果有个一键操作的命令,那就更棒了!

# 启动脚本 start: createFile getMod getPage # 创建目录 createFile: @[ -d module ] || mkdir module @[ -d page ] || mkdir page # 拉取模块仓库,这里有几十个,比较费时,请耐心等待... getMod: cd module; for i in $(MODS); do [ -d $(MODPATH)$$i ] || git clone $(MODPATH)$$i; git co -b master; git co -b $(MODSV); done # 拉取页面仓库,tbindex getPage: cd page; @[ -d tbindex ] || git clone $(PAGEPATH)$PAGE;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 启动脚本
start: createFile getMod getPage
 
# 创建目录
createFile:
  @[ -d module ] || mkdir module
  @[ -d page ] || mkdir page
 
# 拉取模块仓库,这里有几十个,比较费时,请耐心等待...
getMod:
  cd module;
  for i in $(MODS); do
    [ -d $(MODPATH)$$i ] || git clone $(MODPATH)$$i;
    git co -b master;
    git co -b $(MODSV);
  done
 
# 拉取页面仓库,tbindex
getPage:
  cd page;
  @[ -d tbindex ] || git clone $(PAGEPATH)$PAGE;

 

上面是一个 MakeFile 的部分代码,作用是创建开发目录,拉取分支信息,然后开始服务器,打开浏览器,使用 IDE 打开目录,万事就绪,只等主人敲代码。

整个流程就一两分钟,完成开发之前所有的准备工作。这个脚本不仅仅是给自己使用,如果其他人也需要参与开发,一个命令就能让参与者进入开发模式,加上文档说明,省却了很多沟通成本。

console.count

除了条件输出的场景,还有常见的场景是计数。
当你想统计某段代码执行了多少次时也大可不必自己去写相关逻辑,内置的console.count可以很地胜任这样的任务。

JavaScript

function foo(){ //其他函数逻辑blah blah。。。 console.count('foo 被执行的次数:'); } foo(); foo(); foo();

1
2
3
4
5
6
7
function foo(){
//其他函数逻辑blah blah。。。
console.count('foo 被执行的次数:');
}
foo();
foo();
foo();

图片 11

☞ 在线调试实践(一个系统的调试工具)

输入需要调试的页面URL(如 http://www.taobao.com):

图片 12

插件会分析 DOM,遍历拿到页面所有被引用到的仓库:

图片 13

选择需要调试的模块(颗粒度细分到了html/js/css),点击调试按钮,可以看到调试页面的资源都会引用本地下载的文件。

console.dir

将DOM结点以JavaScript对象的形式输出到控制台
console.log是直接将该DOM结点以DOM树的结构进行输出,与在元素审查时看到的结构是一致的。不同的展现形式,同样的优雅,各种体位任君选择反正就是方便与体贴。

JavaScript

console.dir(document.body); console.log(document.body);

1
2
console.dir(document.body);
console.log(document.body);

图片 14

版权声明:本文由ag真人发布于人才招聘,转载请注明出处:在线调试方案的思考与实践,控制台不完全指南