浏览器工作原理

浏览器的主要构成

  1. 用户界面 － 包括地址栏、后退/前进按钮、书签目录等，也就是你所看到的除了用来显示你所请求页面的主窗口之外的其他部分。
  2. 浏览器引擎 － 用来查询及操作渲染引擎的接口。
  3. 渲染引擎 － 用来显示请求的内容，例如，如果请求内容为html，它负责解析html及css，并将解析后的结果显示出来。
  4. 网络 － 用来完成网络调用，例如http请求，它具有平台无关的接口，可以在不同平台上工作。
  5. UI后端 － 用来绘制类似组合选择框及对话框等基本组件，具有不特定于某个平台的通用接口，底层使用操作系统的用户接口。
  6. JS解释器 － 用来解释执行JS代码。
  7. 数据存储 － 属于持久层，浏览器需要在硬盘中保存类似cookie的各种数据，HTML5定义了web database技术，这是一种轻量级完整的客户端存储技术

需要注意的是，不同于大部分浏览器，Chrome为每个Tab分配了各自的渲染引擎实例，每个Tab就是一个独立的进程。

渲染引擎（The rendering engine）

渲染引擎的职责就是渲染，即在浏览器窗口中显示所请求的内容。

渲染引擎在取得内容之后的基本流程：

解析html以构建dom树 -> 构建render树 -> 布局render树 -> 绘制render树

渲染引擎开始解析html，并将标签转化为内容树中的dom节点。接着，它解析外部CSS文件及style标签中的样式信息。这些样式信息以及html中的可见性指令将被用来构建另一棵树——render树。

Render树由一些包含有颜色和大小等属性的矩形组成，它们将被按照正确的顺序显示到屏幕上。

Render树构建好了之后，将会执行布局过程，它将确定每个节点在屏幕上的确切坐标。再下一步就是绘制，即遍历render树，并使用UI后端层绘制每个节点。

值得注意的是，这个过程是逐步完成的，为了更好的用户体验，渲染引擎将会尽可能早的将内容呈现到屏幕上，并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容。

DOM

输出的树，也就是解析树，是由DOM元素及属性节点组成的。

DOM是文档对象模型的缩写，它是html文档的对象表示，作为html元素的外部接口供js等调用。

树的根是“document”对象。

绘制（Painting）

CSS盒模型

CSS盒模型描述了矩形盒，这些矩形盒是为文档树中的元素生成的，并根据可视的格式化模型进行布局。

每个box包括内容区域（如图片、文本等）及可选的四周padding、border和margin区域

CSS解析（CSS parsing）

包含内联样式和内联脚本的 HTML 文档

如果 HTML 文档中存在内联样式和脚本，这个时候，问题变得稍微复杂一些。

浏览器解析 HTML，构建 DOM 树，当解析到<style>标签时，样式信息开始被解析，CSSOM 被构建，但是它并不会影响到 HTML 的解析和 DOM 树的构建。

当 HTML 解析到<script>标签时，因为脚本有可能改变 DOM 内容，所以 HTML 的解析必须等到脚本执行完毕后再继续。

脚本又有可能操作 CSSOM ，所以脚本必须等到 CSS 解析完毕后才能执行。确保此刻 CSS 解析完成，脚本被交到 JS 引擎手里，由 JS 引擎执行。

当脚本执行完毕，HTML 继续解析，直到全部 HTML 解析完毕，DOM 树构建完成（触发 DOMContentLoaded 事件）。

脚本

web的模式是同步的，开发者希望解析到一个script标签时立即解析执行脚本，并阻塞文档的解析直到脚本执行完。

如果脚本是外引的，则网络必须先请求到这个资源——这个过程也是同步的，会阻塞文档的解析直到资源被请求到。

这个模式保持了很多年，并且在html4及html5中都特别指定了。开发者可以将脚本标识为defer，以使其不阻塞文档解析，并在文档解析结束后执行。Html5增加了标记脚本为异步的选项，以使脚本的解析执行使用另一个线程。

JS 解释器的工作原理

浏览器在解析 HTML 文档的时候，遇到脚本，会交给 JS 引擎执行，那么 JS 引擎是如何执行脚本(evaluating script)的呢？

  • 扫描全局变量，确定所有已声明的变量或函数名
  • 顺序执行所有语句

当所有的语句执行完毕后，JS 解释器任务结束，主导权交到 HTML 解析器手中，浏览器继续解析 HTML 文档。

从上述过程，我们能看出浏览器解析渲染 HTML 文档是单线程的，除了发送外部资源请求的操作。

浏览器的工作原理是网站性能优化的基础知识。CSS 不会阻塞 HTML 的解析，但是会阻塞渲染，CSS 的解析会阻塞脚本的执行，而脚本会阻塞 HTML 的解析

defer 和 async

当浏览器碰到 script 脚本的时候：

<script src="script.js"></script>

没有 defer 或 async，浏览器会立即加载并执行指定的脚本，“立即”指的是在渲染该 script 标签之下的文档元素之前，也就是说不等待后续载入的文档元素，读到就加载并执行。

<script async src="script.js"></script>

有 async，加载和渲染后续文档元素的过程将和 script.js 的加载与执行并行进行（异步）。

<script defer src="myscript.js"></script>

有 defer，加载后续文档元素的过程将和 script.js 的加载并行进行（异步），但是 script.js 的执行要在所有元素解析完成之后，DOMContentLoaded 事件触发之前完成。

浏览器的进程与线程

区分进程和线程

  • 进程之间相互独立

  • 多个线程在进程中协作完成任务

  • 一个进程由一个或多个线程组成

  • 同一进程下的各个线程之间共享程序的内存空间（包括代码段、数据集、堆等）

浏览器是多进程的

  • 浏览器之所以能够运行，是因为系统给它的进程分配了资源（cpu、内存）
  • 简单点理解，每打开一个Tab页，就相当于创建了一个独立的浏览器进程。

在浏览器中打开一个网页相当于新起了一个进程（进程内有自己的多线程）

多进程的优势

  • 避免单个page crash影响整个浏览器
  • 避免第三方插件crash影响整个浏览器
  • 多进程充分利用多核优势
  • 方便使用沙盒模型隔离插件等进程，提高浏览器稳定性

GUI渲染线程（重要）

  • 负责渲染浏览器界面，解析HTML，CSS，构建DOM树和RenderObject树，布局和绘制等。
  • 当界面需要重绘（Repaint）或由于某种操作引发回流(reflow)时，该线程就会执行
  • 注意，GUI渲染线程与JS引擎线程是互斥的，当JS引擎执行时GUI线程会被挂起（相当于被冻结了），GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。

JS引擎线程

  • 也称为JS内核，负责处理Javascript脚本程序。（例如V8引擎）
  • JS引擎是单线程的
  • JS引擎线程负责解析Javascript脚本，运行代码。
  • JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（renderer进程）中无论什么时候都只有一个JS线程在运行JS程序
  • 同样注意，GUI渲染线程与JS引擎线程是互斥的，所以如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞。

事件触发线程

  • 归属于浏览器而不是JS引擎，用来控制事件循环（可以理解，JS引擎自己都忙不过来，需要浏览器另开线程协助）
  • 当JS引擎执行代码块如setTimeOut时（也可来自浏览器内核的其他线程,如鼠标点击、AJAX异步请求等），会将对应任务添加到事件线程中
  • 当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理
  • 注意，由于JS的单线程关系，所以这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）

定时触发器线程

  • setInterval与setTimeout所在线程
  • 浏览器定时计数器并不是由JavaScript引擎计数的,（因为JavaScript引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确）
  • 因此通过单独线程来计时并触发定时（计时完毕后，添加到事件队列中，等待JS引擎空闲后执行）
  • 注意，W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms。

异步http请求线程

  • 在XMLHttpRequest在连接后是通过浏览器新开一个线程请求
  • 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中。再由JavaScript引擎执行。

浏览器内核中线程之间的关系

GUI渲染线程与JS引擎线程互斥

由于JavaScript是可操纵DOM的，如果在修改这些元素属性同时渲染界面（即JS线程和UI线程同时运行），那么渲染线程前后获得的元素数据就可能不一致了。

因此为了防止渲染出现不可预期的结果，浏览器设置GUI渲染线程与JS引擎为互斥的关系，当JS引擎执行时GUI线程会被挂起，
GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。

JS阻塞页面加载

从上述的互斥关系，可以推导出，JS如果执行时间过长就会阻塞页面。

、假设JS引擎正在进行巨量的计算，此时就算GUI有更新，也会被保存到队列中，等待JS引擎空闲后执行。
然后，由于巨量计算，所以JS引擎很可能很久很久后才能空闲，自然会感觉到巨卡无比。

所以，要尽量避免JS执行时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞的感觉。

js标签的加载是同步get加载，也会阻塞页面，其他资源比如图片，虽然也都是get加载，但浏览器可以同时处理，可以认为不存在同步和异步之分

浏览器器内核拿到内容后，渲染大概可以划分成以下几个步骤：

  • 解析html建立dom树
  • 解析css构建render树（将CSS代码解析成树形的数据结构，然后结合DOM合并成render树）
  • 布局render树（Layout/reflow），负责各元素尺寸、位置的计算
  • 绘制render树（paint），绘制页面像素信息
  • 浏览器会将各层的信息发送给GPU，GPU会将各层合成（composite），显示在屏幕上。
  • 所有详细步骤都已经略去，渲染完毕后就是load事件了，之后就是自己的JS逻辑处理了

load事件与DOMContentLoaded事件的先后

上面提到，渲染完毕后会触发load事件，那么你能分清楚load事件与DOMContentLoaded事件的先后么？

很简单，知道它们的定义就可以了：

当 DOMContentLoaded 事件触发时，仅当DOM加载完成，不包括样式表，图片。
(譬如如果有async加载的脚本就不一定完成)

当 onload 事件触发时，页面上所有的DOM，样式表，脚本，图片都已经加载完成了。
（渲染完毕了）

所以，顺序是：DOMContentLoaded -> load

css加载是否会阻塞dom树渲染？

这里说的是头部引入css的情况

首先，我们都知道：css是由单独的下载线程异步下载的。

然后再说下几个现象：

  • css加载不会阻塞DOM树解析（异步加载时DOM照常构建）
  • 但会阻塞render树渲染（渲染时需等css加载完毕，因为render树需要css信息）

这可能也是浏览器的一种优化机制。

因为你加载css的时候，可能会修改下面DOM节点的样式，
如果css加载不阻塞render树渲染的话，那么当css加载完之后，
render树可能又得重新重绘或者回流了，这就造成了一些没有必要的损耗。
所以干脆就先把DOM树的结构先解析完，把可以做的工作做完，然后等你css加载完之后，
在根据最终的样式来渲染render树，这种做法性能方面确实会比较好一点。

Git

SVN与Git的最主要的区别

SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联网下，如果网速慢的话，就纳闷了。

Git是分布式版本控制系统，那么它就没有中央服务器的，每个人的电脑就是一个完整的版本库，这样，工作的时候就不需要联网了，因为版本都是在自己的电脑上。既然每个人的电脑都有一个完整的版本库，那多个人如何协作呢？比如说自己在电脑上改了文件A，其他人也在电脑上改了文件A，这时，你们两之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

创建证书使用公钥免密码登录(可选)

ssh-keygen -t rsa
vi ~/.ssh/authorized_keys

配置git提交用户名和邮箱，定义别名方便区分

git config --global user.name "whuper"
git config --global user.email "whuper@163.com"

初始化Git仓库

git init –bare sample.git

在客户端上克隆远程仓库

git clone git@server:/srv/sample.git

测试推送

touch README
git add README
git commit -m "add readme"
git push origin master

常用命令

git status
git diff readme.txt
git log

查看远程分支.

git branch -a

查看本地分支

git branch
git checkout -b dev origin/dev，作用是checkout远程的dev分支，在本地起名为dev分支，并切换到本地的dev分支

切换到本地分支

git checkout develop

删除本地分支

git branch -D release

丢弃本地修改

git reset  --hard

删除远程分支

git branch -r -d origin/branch-name

git push origin :branch-name

撤销某一个提交

git revert <SHA>

合并提交记录

合并最近两条: git rebase -i head～2

git 如何删除缓存的远程分支列表

git remote prune origin

Git忽略规则及.gitignore规则不生效的解决办法

git rm -r --cached .
git add .
git commit -m 'update .gitignore'

or create a new repository on the command line

echo "# compilations" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/whuper/compilations.git
git push -u origin master

or push an existing repository from the command line

git remote add origin https://github.com/whuper/compilations.git
git push -u origin master

git 免密码

函数节流（throttle）与函数去抖（debounce）

函数节流（throttle）与函数去抖（debounce）

背景

鼠标的mousemove、scroll，浏览器窗口的resize事件等，都是在短时间内重复触发。以onresize事件为例，若事件处理程序需要进行修改元素宽度高度等操作，那么频繁的触发事件会导致频繁的重绘页面。

DOM操作比非DOM交互需要更多的内存和CPU时间，连续尝试进行过多的DOM相关操作可能会导致浏览器挂起，有时候甚至会崩溃。为了解决这个问题，需要使用定时器对该函数进行节流。

函数节流，简单地讲，就是让一个函数无法在很短的时间间隔内连续调用，只有当上一次函数执行后过了你规定的时间间隔，才能进行下一次该函数的调用

原理

当触发一个事件时，先setTimout让这个事件延迟一会再执行，如果在这个时间间隔内又触发了事件，就clear掉原来的定时器，再setTimeout一个新的定时器延迟一会执行。

2018 05-09更新 (其实这个应该叫做函数去抖debounce)

代码实现

function throttle(method, context) {
    clearTimeout(methor.tId);
    method.tId = setTimeout(function(){
        method.call(context);
    }， 100);
}

调用

window.onresize = function(){
    throttle(myFunc);
}

这样两次函数调用之间至少间隔100ms。

impress用的是另一个封装函数：

var throttle = function(fn, delay){
     var timer = null;
     return function(){
         var context = this, args = arguments;
         clearTimeout(timer);
         timer = setTimeout(function(){
             fn.apply(context, args);
         }, delay);
     };
 };

它使用闭包的方法形成一个私有的作用域来存放定时器变量timer。而调用方法为

window.onresize = throttle(myFunc, 100);

两种方法各有优劣，前一个封装函数的优势在把上下文变量当做函数参数，直接可以定制执行函数的this变量；后一个函数优势在于把延迟时间当做变量（当然，前一个函数很容易做这个拓展），而且个人觉得使用闭包代码结构会更优，且易于拓展定制其他私有变量，缺点就是虽然使用apply把调用throttle时的this上下文传给执行函数，但毕竟不够灵活。

以上参考
http://www.alloyteam.com/2012/11/javascript-throttle/

相关问题

防止重复发送 Ajax 请求

最简单粗暴的是设置flag做判断，或者暂时禁掉按钮

不推荐用外部变量锁定或修改按钮状态的方式，因为那样比较难：

  • 要考虑并理解 success, complete, error, timeout 这些事件的区别，并注册正确的事件，一旦失误，功能将不再可用；
  • 不可避免地比普通流程要要多注册一个 complete 事件；
  • 恢复状态的代码很容易和不相干的代码混合在一起；

我推荐用主动查询状态的方式（A、B，jQuery 为例）或工具函数的方式（C、D）来去除重复操作，并提供一些例子作为参考：

A. 独占型提交

只允许同时存在一次提交操作，并且直到本次提交完成才能进行下一次提交。

module.submit = function() {
  if (this.promise_.state() === 'pending') {
    return
  }
  return this.promise_ = $.post('/api/save')
}

B. 贪婪型提交

无限制的提交，但是以最后一次操作为准；亦即需要尽快给出最后一次操作的反馈，而前面的操作结果并不重要。

module.submit = function() {
  if (this.promise_.state() === 'pending') {
    this.promise_.abort()
  }
  // todo
}

比如某些应用的条目中，有一些进行类似「喜欢」或「不喜欢」操作的二态按钮。如果按下后不立即给出反馈，用户的目光焦点就可能在那个按钮上停顿许久；如果按下时即时切换按钮的状态，再在程序上用 abort 来实现积极的提交，这样既能提高用户体验，还能降低服务器压力，皆大欢喜。

C. 节制型提交

无论提交如何频繁，任意两次有效提交的间隔时间必定会大于或等于某一时间间隔；即以一定频率提交。

module.submit = throttle(150, function() {
  // todo
})

如果客户发送每隔100毫秒发送过来10次请求，此模块将只接收其中6个（每个在时间线上距离为150毫秒）进行处理。

这也是解决查询冲突的一种可选手段，比如以知乎草稿举例，仔细观察可以发现：

编辑器的 blur 事件会立即触发保存；

保存按钮的 click 事件也会立即触发保存；

但是存在一种情况会使这两个事件在数毫秒内连续发生——当焦点在编辑器内部，并且直接去点击保存按钮——这时用 throttle 来处理是可行的。

另外还有一些事件处理会很频繁地使用 throttle，如： resize、scroll、mousemove。

D. 懒惰型提交

任意两次提交的间隔时间，必须大于一个指定时间，才会促成有效提交；即不给休息不干活。

module.submit = debounce(150, function() {
  // todo
})

还是以知乎草稿举例，当在编辑器内按下 ctrl + s 时，可以手动保存草稿；如果你连按，程序会表示不理解为什么你要连按，只有等你放弃连按，它才会继续。

更多记忆中的例子方式 C 和 方式 D 有时更加通用，比如这些情况：

游戏中你捡到一把威力强大的高速武器，为了防止你的子弹在屏幕上打成一条直线，可以 throttle 来控制频率；

在弹幕型游戏里，为了防止你把射击键夹住来进行无脑游戏，可以用 debounce 来控制频率；

在编译任务里，守护进程监视了某一文件夹里所有的文件（如任一文件的改变都可以触发重新编译，一次执行就需要2秒），但某种操作能够瞬间造成大量文件改变（如 git checkout），这时一个简单的 debounce 可以使编译任务只执行一次。

而方式 C 甚至可以和方式 B 组合使用，比如自动完成组件（Google 首页的搜索就是）：

  • 当用户快速输入文本时（特别是打字能手），可以 throttle keypress 事件处理函数，以指定时间间隔来提取文本域的值，然后立即进行新的查询；

  • 当新的查询需要发送，但上一个查询还没返回结果时，可以 abort 未完成的查询，并立即发送新查询；

表单防止重复提交

1 用js为添加禁用

2 使用Post/Redirect/Get

PRG设计模式并不适用所有的重复提交情况，比如：

1）由于服务器响应缓慢，用户刷新提交POST请求造成的重复提交。

2）用户点击后退按钮，返回到数据提交界面，导致的数据重复提交。

3）用户多次点击提交按钮，导致的数据重复提交。

4）用户恶意避开客户端预防多次提交手段，进行重复数据提交。

###3 使用session／token设置令牌

产生页面时，服务器为每次产生的Form分配唯一的随机标识号(比如时间戳)，并且在form的一个隐藏字段中设置这个标识号，同时在当前用户的Session中保存这个标识号。

当提交表单时，服务器比较hidden和session中的标识号是否相同，相同则继续，处理完后清空Session，否则服务器忽略请求。