1. 强缓存和协商缓存

1，浏览器进行资源请求时，会判断response headers是否命中强缓存，如果命中，直接从本地读取缓存，不会向服务器发送请求，
2，当强缓存没有命中时，会发送请求到服务端，判断协商缓存是否命中，如果命中，服务器将请求返回，不会返回资源，告诉浏览器从本地读取缓存。如何不命中，服务器直接返回资源
区别： 强缓存命中，不会请求服务器，直接请求缓存；协商缓存命中，会请求服务器，不会返回内容，然后读取缓存；
image.png

强缓存

强缓存是利用http的返回头中的Expires或者Cache-Control两个字段来控制的，用来表示资源的缓存时间。
Expires 该字段是http1.0时的规范，它的值为一个绝对时间的GMT格式的时间字符串，比如Expires:Mon,18 Oct 2066 23:59:59 GMT。这个时间代表着这个资源的失效时间，在此时间之前，即命中缓存。这种方式有一个明显的缺点，由于失效时间是一个绝对时间，所以当服务器与客户端时间偏差较大时，就会导致缓存混乱。
Cache-Control Cache-Control是http1.1时出现的header信息，主要是利用该字段的max-age值来进行判断，它是一个相对时间，例如Cache-Control:max-age=3600，代表着资源的有效期是3600秒。
cache-control除了该字段外，还有下面几个比较常用的设置值：

  • no-cache：不使用本地缓存。需要使用缓存协商，先与服务器确认返回的响应是否被更改，如果之前的响应中存在ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。
  • no-store：直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
  • public：可以被所有的用户缓存，包括终端用户和CDN等中间代理服务器
  • private：只能被终端用户的浏览器缓存，不允许CDN等中继缓存服务器对其缓存。

Cache-Control与Expires可以在服务端配置同时启用，同时启用的时候Cache-Control优先级高。

协商缓存

Last-Modify/If-Modify-Since：浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间；当浏览器再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。
Etag：web服务器响应请求时，告诉浏览器当前资源在服务器的唯一标识（生成规则由服务器决定）。
If-None-Match：当资源过期时（使用Cache-Control标识的max-age），发现资源具有Etage声明，则再次向web服务器请求时带上头If-None-Match （Etag的值）。web服务器收到请求后发现有头If-None-Match 则与被请求资源的相应校验串进行比对，决定是否命中协商缓存。
关于Etag和Last-Modify

  • Etag要优于Last-Modified。Last-Modified的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的Last-Modified其实并没有体现出来修改，但是Etag每次都会改变确保了精度；
  • 在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值；
  • 在优先级上，服务器校验优先考虑Etag。

2. 浏览器一帧都会干些什么

我们都知道，页面的内容都是一帧一帧绘制出来的，浏览器刷新率代表浏览器一秒绘制多少帧。原则上说 1s 内绘制的帧数也多，画面表现就也细腻。目前浏览器大多是 60Hz（60帧/s），每一帧耗时也就是在 16.6ms 左右。那么在这一帧的（16.6ms） 过程中浏览器又干了些什么呢？
【1】接受输入事件
【2】执行事件回调
【3】开始一帧
【4】执行 RAF (RequestAnimationFrame)
【5】页面布局，样式计算
【6】绘制渲染
【7】执行 RIC (RequestIdelCallback)
第七步的 RIC 事件不是每一帧结束都会执行，只有在一帧的 16.6ms 中做完了前面 6 件事儿且还有剩余时间，才会执行。如果一帧执行结束后还有时间执行 RIC 事件，那么下一帧需要在事件执行结束才能继续渲染，所以 RIC 执行不要超过 30ms，如果长时间不将控制权交还给浏览器，会影响下一帧的渲染，导致页面出现卡顿和事件响应不及时。

3. 浏览器为什么要请求并发数限制？

对操作系统端口资源考虑

PC的端口总数为 65536，一个HTTP请求就会建立一个TCP链接，一个 TCP 链接就会占用一个端口，操作系统通常会对总端口一半开放对外请求，以防端口数量不被迅速消耗殆尽。

过多并发导致频繁切换产生性能问题

一个线程对应处理一个 http 请求，那么如果并发数量巨大的话会导致线程频繁切换。而线程的上下文切换有时候并不是轻量级的资源。这导致得不偿失，所以请求控制器里面会产生一个链接池，以复用之前的链接。所以我们可以看作同域名下链接池最大为 4-8 个，如果链接池全部被使用后阻塞后面请求任务，等待有空闲链接时执行后续任务。

什么是链接池

避免同一客户端并发大量请求超过服务端的并发阈值，在服务端通常都对同一客户端来源设置并发阈值避免恶意攻击，如果浏览器不对同一域名做并发限制可能会导致超过服务端的并发阈值被 BAN 掉。

客户端良知机制

为了防止两个应用抢占资源时导致强势一方无限制的获取资源导致弱势一方永远阻塞状态。

4. app 中常提到的 webview 是什么?

1.我们通常是用浏览器来浏览网页，你很清楚的知道你正在使用浏览器，要么是PC客户端，要么是手机上的app。但是webview是一个嵌入式的浏览器，是嵌入在原生应用中的，你可能都意识不到你在用浏览器。
2.传统浏览器分为两个部分，UI(地址栏、导航栏)和浏览器引擎。webview就是原生应用中的浏览器引擎。
3.webview只是一个可视化的组件，是作为原生APP的视觉部分。
4.用webview展示的内容是不需要存储在本地的，可以直接从服务器获取。
5.这种灵活性打开了浏览器端的web应用和希望展示在原生应用中的web应用代码直接可重用的世界。
6.运行在webview中的JS代码有能力调用原生的系统API，没有传统浏览器沙箱的限制。
7.沙箱的存在是因为，你永远不能完全信任加载的web内容，所以不能允许它调用原生的系统API。而在webview中开发人员通常可以完全控制加载的内容，恶意代码进入并在设备上造成混乱的可能性很低。
8.在webview中，JS代码可以跟原生应用代码相互通信，也可以调用原生API集成酷炫的系统级功能，如传感器、存储、日历、联系人等。