前端专题技术总结2

最新推荐文章于 2024-04-26 16:06:24 发布

VIP文章 nicky_hb

最新推荐文章于 2024-04-26 16:06:24 发布

阅读量649

点赞数 10

文章标签：前端

本文链接：https://blog.csdn.net/nicky_hb/article/details/136429408

版权

45、vue3虚拟dom

Vdom （虚拟dom）凭借着出色的性能成为了目前的主流的前端框架都会选择的渲染方案。再加上优秀的 diff 算法对它的一步步的优化，使框架的价值得到了极致的体现，几乎成为了我们前端开发必不可少的方案。

我们已经知道，Vue2.x 中的 Vdom 已经相当出色了，性能非常优秀。不过令人兴奋的是，尽管它够快，但在 Vue3 中还是对 Vdom 进行了重写，使 Vue3 突破了 Vdom 的性能瓶颈，更快！

Vue3 如何重写 Vdom

. 入门

当我们创建一个这样的静态 dom 元素的时候：

Vue3 给我们编译后的 Vdom 是这个样子的：

看似比较复杂，实际上 _createBlock 函数中才是我们创建的 dom，从它身上我们可以看出，我们创建了一个 span 元素，内容为 “Hello World!”。这就是 Vdom 最基础的形式，在这里我们并不会感觉到 Vue3 与 Vue2 有什么不同。

2. patch flag 优化静态树

当我们创建了一个动态的 dom 元素：

Vue3 编译后的 Vdom 是这个样子的：

我们发现创建动态 dom 元素的时候，Vdom 除了模拟出来了它的基本信息之外，还给它加了一个标记： 1 /* TEXT */

这个标记就叫做 patch flag（补丁标记）

patch flag 的强大之处在于，当你的 diff 算法走到 _createBlock 函数的时候，会忽略所有的静态节点，只对有标记的动态节点进行对比，而且在多层的嵌套下依然有效。

尽管 JavaScript 做 Vdom 的对比已经非常的快，但是 patch flag 的出现还是让 Vue3 的 Vdom 的性能得到了很大的提升，尤其是在针对大组件的时候。

3. patch flag 优化静态属性

1. 静态绑定

当我们创建一个有属性的元素：

让我们观察它的 patch flag ，发现并没有对 id 做特殊的标记。是因为 dom 元素的静态属性在渲染的时候就已经创建了，并且是不会变动的，在后面进行更新的时候，diff 算法是不会去管它的。

2. 动态绑定

当我们创建一个属性是动态绑定的元素：

再观察它的 patch flag ，会发现变成了 9 /* TEXT, PROPS */，而且后边多了一个数组 ["id"]

这里的 patch flag 中的注释的内容告诉我们，这一个 dom 元素不止有内容 TEXT 会变化，它的属性 PROPS 也会变化。而后边的数组中的内容则是有可能发生变化的属性。

看到这里，我们就会明白 Vue3 实际做的事情了。

Vue3 在 Vdom 的更新时，只会关注它有变化的部分。这样的优化使 Vue3 既跳出了 Vdom 的性能瓶颈，又依然保留了可以手写 render function 的灵活性。相当于 Vue3 既有 react 的灵活性，又有基于模板的性能保证。——尤雨溪

4. 静态提升

刚刚我们提到 Vue3 突破 Vdom 的性能瓶颈的方式是，只关注它有变化的部分。而在更新时具体是怎么做的呢？

具体的做法就是静态树的提升和静态属性的提升

我们已经知道处理后的 Vdom 都在 _createBlock 函数之中，而观察结果我们发现，所有的静态元素都被放在了 _createBlock 函数之外了，也就是说他们只会在页面初始的时候被渲染一次，而在更新的时候，静态元素是不予搭理的。

这个优化就是 Vue3 的静态提升

5. 事件侦听器缓存

了解 react 的同学都知道，在我们使用 react 时，对其性能优化的其中一点就是将侦听方法手动进行缓存，避免更新组件时被多次重新创建。而 Vue3 直接替我们做了这一点

在这里的 _createBlock 函数中就是这个元素的 Vdom 结构。观察高亮的地方，发现 onClick 函数以变量的形式存在。

进行事件侦听器缓存后的 Vdom

观察高亮的那一行，我们发现 onClick 函数的储存位置变成了缓存的形式。也就是说当你的页面在不断的更新的时候，你的事件侦听器并不会重复地销毁再创建，而是以缓存的形式存在，这使 Vue3 在性能方面又有了一个出彩的地方。

另外，Vue3 在 @click 中，直接手写内联函数也会被缓存起来，这一点是 react 做不到的。再加上在 Vue3 中父组件的更新并不会直接触发子组件的更新，使得事件侦听器缓存在组件的层面可以提现出来更高的价值。

其他

以后的章节

总结

Vue3 在性能优化上的小方面，直接在编译的时候给你做到最好，这是它最有价值的地方。想必看完这些东西，你一定更期待 Vue3 的发布了！

46、PWA

PWA 旨在增强 Web 体验，可显著提高加载速度、可离线工作、可被添加至主屏、全屏执行、推送通知消息等等。这些特性将使得 Web 应用渐进式接近原生 App。

家都知道Native app体验确实很好，下载到手机上之后入口也方便。它也有一些缺点:

开发成本高(ios和安卓)
软件上线需要审核
版本更新需要将新版本上传到不同的应用商店
想使用一个app就必须去下载才能使用，即使是偶尔需要使用一下下

而web网页开发成本低，网站更新时上传最新的资源到服务器即可，用手机带的浏览器打开就可以使用。但是除了体验上比Native app还是差一些，还有一些明显的缺点

手机桌面入口不够便捷，想要进入一个页面必须要记住它的url或者加入书签
没网络就没响应，不具备离线能力
不像APP一样能进行消息推送

那么什么是PWA呢？

PWA全称Progressive Web App，即渐进式WEB应用。

一个 PWA 应用首先是一个网页, 可以通过 Web 技术编写出一个网页应用. 随后添加上 App Manifest 和 Service Worker 来实现 PWA 的安装和离线等功能
解决了哪些问题？

可以添加至主屏幕，点击主屏幕图标可以实现启动动画以及隐藏地址栏
实现离线缓存功能，即使用户手机没有网络，依然可以使用一些离线功能
实现了消息推送

它解决了上述提到的问题，这些特性将使得 Web 应用渐进式接近原生 App。

三、PWA的实现

3.1 Manifest实现添加至主屏幕

index.html

<head>

<title>Minimal PWA</title>

</head>

3.2 service worker实现离线缓存

3.2.1 什么是service worker

Service Worker 是 Chrome 团队提出和力推的一个 WEB API，用于给 web 应用提供高级的可持续的后台处理能力。

Service Workers 就像介于服务器和网页之间的拦截器，能够拦截进出的HTTP 请求，从而完全控制你的网站。

最主要的特点

在页面中注册并安装成功后，运行于浏览器后台，不受页面刷新的影响，可以监听和截拦作用域范围内所有页面的 HTTP 请求。
网站必须使用 HTTPS。除了使用本地开发环境调试时(如域名使用 localhost)
运行于浏览器后台，可以控制打开的作用域范围下所有的页面请求
单独的作用域范围，单独的运行环境和执行线程
不能操作页面 DOM。但可以通过事件机制来处理
事件驱动型服务线程

为什么要求网站必须是HTTPS的，大概是因为service worker权限太大能拦截所有页面的请求吧，如果http的网站安装service worker很容易被攻击

当用户首次导航至 URL 时，服务器会返回响应的网页。

第1步:当你调用 register() 函数时， Service Worker 开始下载。
第2步:在注册过程中，浏览器会下载、解析并执行 Service Worker ()。如果在此步骤中出现任何错误，register() 返回的 promise 都会执行 reject 操作，并且 Service Worker 会被废弃。
第3步:一旦 Service Worker 成功执行了，install 事件就会激活
第4步:安装完成，Service Worker 便会激活，并控制在其范围内的一切。如果生命周期中的所有事件都成功了，Service Worker 便已准备就绪，随时可以使用了！

3.2.2 HTTP缓存与service worker缓存

HTTP缓存

Web 服务器可以使用 Expires 首部来通知 Web 客户端，它可以使用资源的当前副本，直到指定的“过期时间”。反过来，浏览器可以缓存此资源，并且只有在有效期满后才会再次检查新版本。
使用 HTTP 缓存意味着你要依赖服务器来告诉你何时缓存资源和何时过期。

service worker缓存

Service Workers 的强大在于它们拦截 HTTP 请求的能力
进入任何传入的 HTTP 请求，并决定想要如何响应。在你的 Service Worker 中，可以编写逻辑来决定想要缓存的资源，以及需要满足什么条件和资源需要缓存多久。一切尽归你掌控！

3.2.3 实现离线缓存

index.html

<!DOCTYPE html>

<html>

<head>

<title>Hello Caching World!</title>

</head>

<body>

// 注册 service worker

if ('serviceWorker' in navigator) {

navigator.serviceWorker.register('/service-worker.js', {scope: '/'}).then(function (registration) {

// 注册成功

console.log('ServiceWorker registration successful with scope: ', registration.scope);

}).catch(function (err) {

// 注册失败 :(

console.log('ServiceWorker registration failed: ', err);

});

}

</script>

</body>

</html>

注：Service Worker 的注册路径决定了其 scope 默认作用页面的范围。
如果 service-worker.js 是在 /sw/ 页面路径下，这使得该 Service Worker 默认只会收到页面/sw/ 路径下的 fetch 事件。
如果存放在网站的根路径下，则将会收到该网站的所有 fetch 事件。
如果希望改变它的作用域，可在第二个参数设置 scope 范围。示例中将其改为了根目录，即对整个站点生效。

PWA的优势

可以将app的快捷方式放置到桌面上，全屏运行，与原生app无异
能够在各种网络环境下使用，包括网络差和断网条件下，不会显示undefind
推送消息的能力
其本质是一个网页，没有原生app的各种启动条件，快速响应用户指令

PWA存在的问题

支持率不高:现在ios手机端不支持pwa，IE也暂时不支持
Chrome在中国桌面版占有率还是不错的，安卓移动端上的占有率却很低
各大厂商还未明确支持pwa
依赖的GCM服务在国内无法使用
微信小程序的竞争

尽管有上述的一些缺点，PWA技术仍然有很多可以使用的点。

service worker技术实现离线缓存，可以将一些不经常更改的静态文件放到缓存中，提升用户体验。
service worker实现消息推送，使用浏览器推送功能，吸引用户
渐进式开发，尽管一些浏览器暂时不支持，可以利用上述技术给使用支持浏览器的用户带来更好的体验。

47、Web App Manifest

Web应用程序清单在一个JSON文本文件中提供有关应用程序的信息（如名称，作者，图标和描述）。manifest 的目的是将Web应用程序安装到设备的主屏幕，为用户提供更快的访问和更丰富的体验。

Web应用程序清单是被称为渐进式Web应用程序(PWA)的Web技术集合的一部分, 它们是可以安装到设备的主屏幕的网络应用程序，而不需要用户通过应用商店，伴随着其他功能, 比如离线可用和接收推送通知。

部署一个 manifest

Web应用程序清单部署在您的HTML页面中，使用在你的文件的头部的一个链接标记：

前端页面性能优化——使用H5 manifest属性缓存资源

html5之前的网页，都是无连接，必须联网才能访问，这其实也是web的特色，这其实对于PC是时代问题并不大，但到了移动互联网时代，设备终端位置不再固定，依赖无线信号，网络的可靠性变得降低，比如坐在火车上，过了一个隧道（15分钟），便无法访问网站，这对于web的伤害是很大的，比如对于《ecmascript合集》这样的为阅读而生的页面。

html5便引入了cache manifest 文件。那么什么是cache manifest呢，接下来会讲到。

什么是Cache Manifest

首先manifest是一个后缀名为minifest的文件，在文件中定义那些需要缓存的文件，支持manifest的浏览器，会将按照manifest文件的规则，像文件保存在本地，从而在没有网络链接的情况下，也能访问页面。

当我们第一次正确配置app cache后，当我们再次访问该应用时，浏览器会首先检查manifest文件是否有变动，如果有变动就会把相应的变得跟新下来，同时改变浏览器里面的app cache，如果没有变动，就会直接把app cache的资源返回，基本流程是这样的。

Manifest的特点

离线浏览: 用户可以在离线状态下浏览网站内容。
更快的速度: 因为数据被存储在本地，所以速度会更快.
减轻服务器的负载: 浏览器只会下载在服务器上发生改变的资源。

如何使用

html新增了一个manifest属性，可以用来指定当前页面的manifest文件。

创建一个和html同名的manifest文件，比如页面为index.html，那么可以建一个index.manifest的文件，然后给index.html的html标签添加如下属性即可：

Manifest文件

接下来详细说说manifest的细节，一个典型的manifest文件代码结构像下面这样：

manifest文件，基本格式为三段： CACHE， NETWORK，与 FALLBACK，其中NETWORK和FALLBACK为可选项。

而第一行CACHE MANIFEST为固定格式，必须写在前面。

以#号开头的是注释，一般会在第二行写个版本号，用来在缓存的文件更新时，更改manifest的作用，可以是版本号，时间戳或者md5码等等。

CACHE:（必须）

标识出哪些文件需要缓存，可以是相对路径也可以是绝对路径。

NETWORK:（可选）

这一部分是要绕过缓存直接读取的文件，可以使用通配符＊。

下面的代码 “login.asp” 永远不会被缓存，且离线时是不可用的：

NETWORK:

可以使用星号来指示所有其他资源/文件都需要因特网连接：

NETWORK:

FALLBACK:（可选）

指定了一个后备页面，当资源无法访问时，浏览器会使用该页面。该段落的每条记录都列出两个 URI—第一个表示资源，第二个表示后备页面。两个 URI 都必须使用相对路径并且与清单文件同源。可以使用通配符。

下面的例子中，如果无法建立因特网连接，则用 “404.html” 替代 /html5/ 目录中的所有文件。

FALLBACK:

/html5/ /404.html

下面的例子中，则用 “404.html” 替代所有文件。

FALLBACK:

*.html /404.html

如何更新缓存

如下三种方式，可以更新缓存：

更新manifest文件

通过javascript操作

清除浏览器缓存

给manifest添加或删除文件，都可更新缓存，如果我们更改了js，而没有新增或删除，前面例子中注释中的版本号，可以很好的用来更新manifest文件。

html5中引入了js操作离线缓存的方法，下面的js可以手动更新本地缓存。

如果用户清除了浏览器缓存（手动或用其他一些工具）都会重新下载文件。

使用html5 manifest后端MIME配置（非常重要,不能缺少）：

如果使用的tomcat web服务器，则在tomcat目录下的conf文件下的web.xml文件中，第一行新增一行如下内容，以此来增加对manifest文件的支持：

<mime-mapping>

<extension>manifest</extension>

<mime-type>text/cache-manifest</mime-type>

</mime-mapping>

48、html5利用缓存优化性能

H5 一共有6种缓存机制，有些是之前已有，有些是 H5 才新加入的。

浏览器缓存机制
Dom Storgage（Web Storage）存储机制
Web SQL Database 存储机制
Application Cache（AppCache）机制
Indexed Database （IndexedDB）
File System API

2.1 浏览器缓存机制

浏览器缓存机制是指通过 HTTP 协议头里的 Cache-Control（或 Expires）和 Last-Modified（或 Etag）等字段来控制文件缓存的机制。这应该是 WEB 中最早的缓存机制了，是在 HTTP 协议中实现的，有点不同于 Dom Storage、AppCache 等缓存机制，但本质上是一样的。可以理解为，一个是协议层实现的，一个是应用层实现的。

Cache-Control 用于控制文件在本地缓存有效时长。最常见的，比如服务器回包：Cache-Control:max-age=600 表示文件在本地应该缓存，且有效时长是600秒（从发出请求算起）。在接下来600秒内，如果有请求这个资源，浏览器不会发出 HTTP 请求，而是直接使用本地缓存的文件。

Last-Modified 是标识文件在服务器上的最新更新时间。下次请求时，如果文件缓存过期，浏览器通过 If-Modified-Since 字段带上这个时间，发送给服务器，由服务器比较时间戳来判断文件是否有修改。如果没有修改，服务器返回304告诉浏览器继续使用缓存；如果有修改，则返回200，同时返回最新的文件。

Cache-Control 通常与 Last-Modified 一起使用。一个用于控制缓存有效时间，一个在缓存失效后，向服务查询是否有更新。

Cache-Control 还有一个同功能的字段：Expires。Expires 的值一个绝对的时间点，如：Expires: Thu, 10 Nov 2015 08:45:11 GMT，表示在这个时间点之前，缓存都是有效的。

Expires 是 HTTP1.0 标准中的字段，Cache-Control 是 HTTP1.1 标准中新加的字段，功能一样，都是控制缓存的有效时间。当这两个字段同时出现时，Cache-Control 是高优化级的。

Etag 也是和 Last-Modified 一样，对文件进行标识的字段。不同的是，Etag 的取值是一个对文件进行标识的特征字串。在向服务器查询文件是否有更新时，浏览器通过 If-None-Match 字段把特征字串发送给服务器，由服务器和文件最新特征字串进行匹配，来判断文件是否有更新。没有更新回包304，有更新回包200。Etag 和 Last-Modified 可根据需求使用一个或两个同时使用。两个同时使用时，只要满足基中一个条件，就认为文件没有更新。

另外有两种特殊的情况：

手动刷新页面（F5)，浏览器会直接认为缓存已经过期（可能缓存还没有过期），在请求中加上字段：Cache-Control:max-age=0，发包向服务器查询是否有文件是否有更新。
强制刷新页面（Ctrl+F5)，浏览器会直接忽略本地的缓存（有缓存也会认为本地没有缓存），在请求中加上字段：Cache-Control:no-cache（或 Pragma:no-cache），发包向服务重新拉取文件。

一般浏览器会将缓存记录及缓存文件存在本地 Cache 文件夹中。Android 下 App 如果使用 Webview，缓存的文件记录及文件内容会存在当前 app 的 data 目录中。

分析：Cache-Control 和 Last-Modified 一般用在 Web 的静态资源文件上，如 JS、CSS 和一些图像文件。通过设置资源文件缓存属性，对提高资源文件加载速度，节省流量很有意义，特别是移动网络环境。但问题是：缓存有效时长该如何设置？如果设置太短，就起不到缓存的使用；如果设置的太长，在资源文件有更新时，浏览器如果有缓存，则不能及时取到最新的文件。

Last-Modified 需要向服务器发起查询请求，才能知道资源文件有没有更新。虽然服务器可能返回304告诉没有更新，但也还有一个请求的过程。对于移动网络，这个请求可能是比较耗时的。有一种说法叫“消灭304”，指的就是优化掉304的请求。

抓包发现，带 if-Modified-Since 字段的请求，如果服务器回包304，回包带有 Cache-Control:max-age 或 Expires 字段，文件的缓存有效时间会更新，就是文件的缓存会重新有效。304回包后如果再请求，则又直接使用缓存文件了，不再向服务器查询文件是否更新了，除非新的缓存时间再次过期。

另外，Cache-Control 与 Last-Modified 是浏览器内核的机制，一般都是标准的实现，不能更改或设置。以 QQ 浏览器的 X5为例，Cache-Control 与 Last-Modified 缓存不能禁用。缓存容量是12MB，不分HOST，过期的缓存会最先被清除。如果都没过期，应该优先清最早的缓存或最快到期的或文件大小最大的；过期缓存也有可能还是有效的，清除缓存会导致资源文件的重新拉取。

还有，浏览器，如 X5，在使用缓存文件时，是没有对缓存文件内容进行校验的，这样缓存文件内容被修改的可能。

分析发现，浏览器的缓存机制还不是非常完美的缓存机制。完美的缓存机制应该是这样的：

缓存文件没更新，尽可能使用缓存，不用和服务器交互；
缓存文件有更新时，第一时间能使用到新的文件；
缓存的文件要保持完整性，不使用被修改过的缓存文件；
缓存的容量大小要能设置或控制，缓存文件不能因为存储空间限制或过期被清除。

以X5为例，第1、2条不能同时满足，第3、4条都不能满足。

在实际应用中，为了解决 Cache-Control 缓存时长不好设置的问题，以及为了”消灭304“，Web前端采用的方式是：

在要缓存的资源文件名中加上版本号或文件 MD5值字串，如 common.d5d02a02.js，common.v1.js，同时设置 Cache-Control:max-age=31536000，也就是一年。在一年时间内，资源文件如果本地有缓存，就会使用缓存；也就不会有304的回包。
如果资源文件有修改，则更新文件内容，同时修改资源文件名，如 common.v2.js，html页面也会引用新的资源文件名。

通过这种方式，实现了：缓存文件没有更新，则使用缓存；缓存文件有更新，则第一时间使用最新文件的目的。即上面说的第1、2条。第3、4条由于浏览器内部机制，目前还无法满足。

2.2 Dom Storage 存储机制

DOM 存储是一套在 Web Applications 1.0 规范中首次引入的与存储相关的特性的总称，现在已经分离出来，单独发展成为独立的 W3C Web 存储规范。 DOM 存储被设计为用来提供一个更大存储量、更安全、更便捷的存储方法，从而可以代替掉将一些不需要让服务器知道的信息存储到 cookies 里的这种传统方法。

上面一段是对 Dom Storage 存储机制的官方表述。看起来，Dom Storage 机制类似 Cookies，但有一些优势。

Dom Storage 是通过存储字符串的 Key/Value 对来提供的，并提供 5MB （不同浏览器可能不同，分 HOST)的存储空间（Cookies 才 4KB)。另外 Dom Storage 存储的数据在本地，不像 Cookies，每次请求一次页面，Cookies 都会发送给服务器。

DOM Storage 分为 sessionStorage 和 localStorage。localStorage 对象和 sessionStorage 对象使用方法基本相同，它们的区别在于作用的范围不同。sessionStorage 用来存储与页面相关的数据，它在页面关闭后无法使用。而 localStorage 则持久存在，在页面关闭后也可以使用。

分析：Dom Storage 给 Web 提供了一种更录活的数据存储方式，存储空间更大（相对 Cookies)，用法也比较简单，方便存储服务器或本地的一些临时数据。

从 DomStorage 提供的接口来看，DomStorage 适合存储比较简单的数据，如果要存储结构化的数据，可能要借助 JASON了，将要存储的对象转为 JASON 字串。不太适合存储比较复杂或存储空间要求比较大的数据，也不适合存储静态的文件等。

2.3 Web SQL Database存储机制

H5 也提供基于 SQL 的数据库存储机制，用于存储适合数据库的结构化数据。根据官方的标准文档，Web SQL Database 存储机制不再推荐使用，将来也不再维护，而是推荐使用 AppCache 和 IndexedDB。

现在主流的浏览器（点击查看浏览器支持情况）都还是支持 Web SQL Database 存储机制的。Web SQL Database 存储机制提供了一组 API 供 Web App 创建、存储、查询数据库。

2.4 Application Cache 机制

Application Cache（简称 AppCache)似乎是为支持 Web App 离线使用而开发的缓存机制。它的缓存机制类似于浏览器的缓存（Cache-Control 和 Last-Modified）机制，都是以文件为单位进行缓存，且文件有一定更新机制。但 AppCache 是对浏览器缓存机制的补充，不是替代。

AppCache 的原理有两个关键点：manifest 属性和 manifest 文件。

HTML 在头中通过 manifest 属性引用 manifest 文件。manifest 文件，就是上面以 appcache 结尾的文件，是一个普通文件文件，列出了需要缓存的文件。

总的来说，浏览器在首次加载 HTML 文件时，会解析 manifest 属性，并读取 manifest 文件，获取 Section：CACHE MANIFEST 下要缓存的文件列表，再对文件缓存。

AppCache 的缓存文件，与浏览器的缓存文件分开存储的，还是一份？应该是分开的。因为 AppCache 在本地也有 5MB（分 HOST）的空间限制。

AppCache 在首次加载生成后，也有更新机制。被缓存的文件如果要更新，需要更新 manifest 文件。因为浏览器在下次加载时，除了会默认使用缓存外，还会在后台检查 manifest 文件有没有修改（byte by byte)。发现有修改，就会重新获取 manifest 文件，对 Section：CACHE MANIFEST 下文件列表检查更新。manifest 文件与缓存文件的检查更新也遵守浏览器缓存机制。

如用用户手动清了 AppCache 缓存，下次加载时，浏览器会重新生成缓存，也可算是一种缓存的更新。另外， Web App 也可用代码实现缓存更新。

分析：AppCache 看起来是一种比较好的缓存方法，除了缓存静态资源文件外，也适合构建 Web 离线 App。在实际使用中有些需要注意的地方，有一些可以说是”坑“。

要更新缓存的文件，需要更新包含它的 manifest 文件，那怕只加一个空格。常用的方法，是修改 manifest 文件注释中的版本号。如：# 2012-02-21 v1.0.0
被缓存的文件，浏览器是先使用，再通过检查 manifest 文件是否有更新来更新缓存文件。这样缓存文件可能用的不是最新的版本。
在更新缓存过程中，如果有一个文件更新失败，则整个更新会失败。
manifest 和引用它的HTML要在相同 HOST。
manifest 文件中的文件列表，如果是相对路径，则是相对 manifest 文件的相对路径。
manifest 也有可能更新出错，导致缓存文件更新失败。
没有缓存的资源在已经缓存的 HTML 中不能加载，即使有网络。例如：http://appcache-demo.s3-website-us-east-1.amazonaws.com/without-network/
manifest 文件本身不能被缓存，且 manifest 文件的更新使用的是浏览器缓存机制。所以 manifest 文件的 Cache-Control 缓存时间不能设置太长。

另外，根据官方文档，AppCache 已经不推荐使用了，标准也不会再支持。现在主流的浏览器都是还支持 AppCache的，以后就不太确定了。

2.5 Indexed Database

IndexedDB 也是一种数据库的存储机制，但不同于已经不再支持的 Web SQL Database。IndexedDB 不是传统的关系数据库，可归为 NoSQL 数据库。IndexedDB 又类似于 Dom Storage 的 key-value 的存储方式，但功能更强大，且存储空间更大。

IndexedDB 存储数据是 key-value 的形式。Key 是必需，且要唯一；Key 可以自己定义，也可由系统自动生成。Value 也是必需的，但 Value 非常灵活，可以是任何类型的对象。一般 Value 都是通过 Key 来存取的。

IndexedDB 提供了一组 API，可以进行数据存、取以及遍历。这些 API 都是异步的，操作的结果都是在回调中返回。

下面代码演示了 IndexedDB 中 DB 的打开（创建）、存储对象(可理解成有关系数据的”表“）的创建及数据存取、遍历基本功能。

IndexedDB 有个非常强大的功能，就是 index（索引）。它可对 Value 对象中任何属性生成索引，然后可以基于索引进行 Value 对象的快速查询。

分析：

IndexedDB 是一种灵活且功能强大的数据存储机制，它集合了 Dom Storage 和 Web SQL Database 的优点，用于存储大块或复杂结构的数据，提供更大的存储空间，使用起来也比较简单。可以作为 Web SQL Database 的替代。不太适合静态文件的缓存。

以key-value 的方式存取对象，可以是任何类型值或对象，包括二进制。
可以对对象任何属性生成索引，方便查询。
较大的存储空间，默认推荐250MB(分 HOST)，比 Dom Storage 的5MB 要大的多。
通过数据库的事务（tranction）机制进行数据操作，保证数据一致性。
异步的 API 调用，避免造成等待而影响体验。

Android 在4.4开始加入对 IndexedDB 的支持，只需打开允许 JS 执行的开关就好了。

2.6 File System API

File System API 是 H5 新加入的存储机制。它为 Web App 提供了一个虚拟的文件系统，就像 Native App 访问本地文件系统一样。由于安全性的考虑，这个虚拟文件系统有一定的限制。Web App 在虚拟的文件系统中，可以进行文件（夹）的创建、读、写、删除、遍历等操作。

File System API 也是一种可选的缓存机制，和前面的 SQLDatabase、IndexedDB 和 AppCache 等一样。File System API 有自己的一些特定的优势：

可以满足大块的二进制数据（ large binary blobs）存储需求。
可以通过预加载资源文件来提高性能。
可以直接编辑文件。

浏览器给虚拟文件系统提供了两种类型的存储空间：临时的和持久性的。临时的存储空间是由浏览器自动分配的，但可能被浏览器回收；持久性的存储空间需要显示的申请，申请时浏览器会给用户一提示，需要用户进行确认。持久性的存储空间是 WebApp 自己管理，浏览器不会回收，也不会清除内容。持久性的存储空间大小是通过配额来管理的，首次申请时会一个初始的配额，配额用完需要再次申请。

虚拟的文件系统是运行在沙盒中。不同 WebApp 的虚拟文件系统是互相隔离的，虚拟文件系统与本地文件系统也是互相隔离的。

File System API 提供了一组文件与文件夹的操作接口，有同步和异步两个版本，可满足不同的使用场景。

分析：

File System API 给 Web App 带来了文件系统的功能，Native 文件系统的功能在 Web App 中都有相应的实现。任何需要通过文件来管理数据，或通过文件系统进行数据管理的场景都比较适合。

到目前，Android 系统的 Webview 还不支持 File System API。

结论：

综合各种缓存机制比较，对于静态文件，如 JS、CSS、字体、图片等，适合通过浏览器缓存机制来进行缓存，通过缓存文件可大幅提升 Web 的加载速度，且节省流量。但也有一些不足：缓存文件需要首次加载后才会产生；浏览器缓存的存储空间有限，缓存有被清除的可能；缓存的文件没有校验。要解决这些不足，可以参考手 Q 的离线包，它有效的解决了这些不足。

对于 Web 在本地或服务器获取的数据，可以通过 Dom Storage 和 IndexedDB 进行缓存。也在一定程度上减少和 Server 的交互，提高加载速度，同时节省流量。

当然 Web 的性能优化，还包括选择合适的图片大小，避免 JS 和 CSS 造成的阻塞等。这就需要 Web 前端的同事根据一些规范和一些调试工具进行优化了。

49、npm和yarn

　为什么要使用yarn，如果你从事前端开发有些年头了，那你肯定对npm又爱又恨，爱就不说了，恨嘛，就是NPM经常奇慢和卡顿，这还能忍，经常各种错误就没法忍了，尤其是他人创建的项目，自己在安装依赖的时候，经常各种莫名奇妙的错误导致安装失败；尤其是当项目有些年头，一些依赖包已经有更新的时候，重新安装依赖包发生错误的概率甚至超过50%，这个实在没办法忍受；而yarn，则是完全碾压npm的存在~yarn不但速度甩npm十条街，而且很多npm死活安装不上的时候，yarn基本都是一次完美成功安装；在npm5出来后，很多人说有改善，但现在已经5.5了，经我们团队从github上拉取多个开源项目实际测试，npm安装依赖发生错误的概率仍然居高不下，很多项目尝试各种办法仍然无法成功安装依赖和运行，而同样的项目，用yarn安装，则基本一次完成，一次错误也未发生，都成功安装和运行，所以，结论：请忘记npm，请使用yarn

yarn简介：

yarn是facebook发布的一款取代npm的包管理工具。

yarn的特点：

速度超快。
并行安装：无论 npm 还是 Yarn 在执行包的安装时，都会执行一系列任务。npm 是按照队列执行每个 package，也就是说必须要等到当前 package 安装完成之后，才能继续后面的安装。而 Yarn 是同步执行所有任务，提高了性能。
离线模式：如果之前已经安装过一个软件包，用Yarn再次安装时之间从缓存中获取，就不用像npm那样再从网络下载了。
Yarn 缓存了每个下载过的包，所以再次使用时无需重复下载。同时利用并行下载以最大化资源利用率，因此安装速度更快。
超级安全。
在执行代码之前，Yarn 会通过算法校验每个安装包的完整性。
超级可靠。
使用详细、简洁的锁文件格式和明确的安装算法，Yarn 能够保证在不同系统上无差异的工作。
为了防止拉取到不同的版本，Yarn 有一个锁定文件 (lock file) 记录了被确切安装上的模块的版本号。每次只要新增了一个模块，Yarn 就会创建（或更新）yarn.lock 这个文件。这么做就保证了，每一次拉取同一个项目依赖时，使用的都是一样的模块版本。npm 其实也有办法实现处处使用相同版本的 packages，但需要开发者执行 npm shrinkwrap 命令。这个命令将会生成一个锁定文件，在执行 npm install 的时候，该锁定文件会先被读取，和 Yarn 读取 yarn.lock 文件一个道理。npm 和 Yarn 两者的不同之处在于，Yarn 默认会生成这样的锁定文件，而 npm 要通过 shrinkwrap 命令生成 npm-shrinkwrap.json 文件，只有当这个文件存在的时候，packages 版本信息才会被记录和更新。
 更简洁的输出：npm 的输出信息比较冗长。在执行 npm install <package> 的时候，命令行里会不断地打印出所有被安装上的依赖。相比之下，Yarn 简洁太多：默认情况下，结合了 emoji直观且直接地打印出必要的信息，也提供了一些命令供开发者查询额外的安装信息。
 多注册来源处理：所有的依赖包，不管他被不同的库间接关联引用多少次，安装这个包时，只会从一个注册来源去装，要么是 npm 要么是 bower, 防止出现混乱不一致。

npm的未来：npm5.0

有了yarn的压力之后，npm做了一些类似的改进。

默认新增了类似yarn.lock的 package-lock.json；
git 依赖支持优化：这个特性在需要安装大量内部项目（例如在没有自建源的内网开发），或需要使用某些依赖的未发布版本时很有用。在这之前可能需要使用指定 commit_id 的方式来控制版本。
文件依赖优化：在之前的版本，如果将本地目录作为依赖来安装，将会把文件目录作为副本拷贝到 node_modules 中。而在 npm5 中，将改为使用创建 symlinks 的方式来实现（使用本地 tarball 包除外），而不再执行文件拷贝。这将会提升安装速度。目前yarn还不支持。

Yarn是由Facebook、Google、Exponent 和 Tilde 联合推出了一个新的 JS 包管理工具，正如官方文档中写的，Yarn 是为了弥补 npm 的一些缺陷而出现的。”这句话让我想起了使用npm时的坑了：

npm install的时候巨慢。特别是新的项目拉下来要等半天，删除node_modules，重新install的时候依旧如此。
同一个项目，安装的时候无法保持一致性。由于package.json文件中版本号的特点，下面三个版本号在安装的时候代表不同的含义。

"5.0.3",

"~5.0.3",

"^5.0.3"

“5.0.3”表示安装指定的5.0.3版本，“～5.0.3”表示安装5.0.X中最新的版本，“^5.0.3”表示安装5.X.X中最新的版本。这就麻烦了，常常会出现同一个项目，有的同事是OK的，有的同事会由于安装的版本不一致出现bug。

安装的时候，包会在同一时间下载和安装，中途某个时候，一个包抛出了一个错误，但是npm会继续下载和安装包。因为npm会把所有的日志输出到终端，有关错误包的错误信息就会在一大堆npm打印的警告中丢失掉，并且你甚至永远不会注意到实际发生的错误。

yarn安装:

下载node.js，使用npm安装
npm install -g yarn yarn --version

Yarn 淘宝源安装，分别复制粘贴以下代码行到黑窗口运行即可
yarn config set registry https://registry.npm.taobao.org -g yarn config set sass_binary_site http://cdn.npm.taobao.org/dist/node-sass -g

yarn常用命令：

yarn install //安装package.json里所有包，并将包及它的所有依赖项保存进yarn.lock

yarn install --production //只安装dependencies里的包

yarn add --dev/-D// 加到 devDependencies

发布包
yarn publish

移除一个包

yarn remove <packageName>：移除一个包，会自动更新package.json和yarn.lock

显示某个包的信息
yarn info <packageName> 可以用来查看某个模块的最新版本信息

50、前端工程化实践

随着业务的不断扩展，团队的项目越来越多，面对日益复杂的业务场景和代码逻辑，我们发现在前端工程化方面团队还有很多需要优化的地方。现有的解决方案已经无法满足各种复杂的场景，我们每天都在疲于应付很多重复的工作，为此我们基于移动端基础库重构和UI组件库的建设这两个项目对团队的项目构建流程进行了详细的分析和梳理，并制定了一套适用于团队的工程化方案。

模块化

模块化可以对复杂逻辑进行有效分割，每个模块更关注自身的功能，模块内部的数据和实现是私有的，通过向外部暴露一些接口来实现各模块间的通信。开发阶段前端需要关注JS、CSS和HTML，下面我们将分别对JS、CSS、HTML的模块化进行简单介绍。

1. JS模块化

JS模块化是一个逐渐演变的过程，开始的namespace概念实现了简单对象封装，约定私有属性使用_开头，到后来的IIFE模式，利用匿名函数闭包的原理解决模块的隔离与引用，下面介绍现在比较流行的几种模块化标准。

2. CommonJS

Nodejs中的模块化方案，就是基于CommonJS规范实现的。一个文件就是一个模块，有自己的作用域，没有export的变量和方法都是私有的，不会污染全局作用域，模块的加载是运行时同步加载的。CommonJS可以细分为CommonJS1和CommonJS2，二者的模块导出方式不同，CommonJS2兼容CommonJS1，增加了module.exports的导出方式，现在一般所指的都是CommonJS2。

每个文件一个模块，有自己的作用域，不会污染全局；
使用require同步加载依赖的其他模块，通过module.exports导出需要暴露的接口；
多次require的同一模块只会在第一次加载时运行，并将运行结果缓存，后续直接读取缓存结果，如果需要重新执行，需要先清理缓存；
Nodejs环境下可以直接运行，各个模块按引入顺序依次执行。

module.exports.add = function (a, b) {

return a + b;

}

exports.add = function (a, b) {

return a + b;

}

const sum = require('sum');

sum.add(1, 2);

AMD

浏览器加载js文件需要进行网络请求，而网络请求的耗时是不可预期的，这使得CommonJS同步加载模块的机制在浏览器端并不适用，我们不能因为要加载某个模块js而一直阻塞浏览器继续执行下面的代码。AMD规范则采用异步的方式加载模块，允许指定回调函数，这非常适合用于浏览器端的模块化场景。

使用define定义一个模块，使用require加载模块；
异步加载，可以并行请求依赖模块；
原生JavaScript运行环境无法直接执行AMD规范的模块代码，需要引入第三方库支持，如requirejs等；

// 定义一个模块

define(id ? , dependencies ? , factory);

// 引用一个模块

require([module], callback)

CMD

类似于AMD规范，是应用在浏览器端的JS模块化方案，由sea.js提出，详见 AMD 和 CMD 的区别有哪些？ - 知乎。

UMD

UMD规范兼容AMD和CommonJS，在浏览器和Nodejs中均可以运行。

(function (root, factory) {

if (typeof define === 'function' && define.amd) {

define(['jquery', 'underscore'], factory);

} else if (typeof exports === 'object') {

module.exports = factory(require('jquery'), require('underscore'));

} else {

root.returnExports = factory(root.jQuery, root._);

}

}(this, function ($, _) {

function a() {};

function b() {};

function c() {};

return {

b: b,

c: c

}

}));

ES6 Module

ES6从语言标准的层面上实现了模块化，是ECMA提出的模块化标准，后续浏览器和Nodejs都宣布会原生支持，越来越受开发者青睐。

使用import引入模块，export导出模块；
与CommonJS的执行时机不同，只是个只读引用，只会在真正调用的地方开始执行，而不是像CommonJS那样，在require的时候就会执行代码；
支持度暂不完善，需要进行代码转换成上面介绍的某一种模块化规范。

在浏览器中可以通过下面的方式引入es6规范的模块js：

defer和async不同，它会阻塞DomContentLoaded事件，每个模块js会根据引入的顺序依次执行。

随着更多浏览器对ES6的支持，现在有一些方案开始提出直接使用ES2015+的代码在浏览器中直接执行来提高运行效果，这篇文章《Deploying ES2015+ Code in Production Today》中有详细的介绍，可以结合这份性能测试报告综合评估ES6在node以及各种浏览器环境下的执行效率对比。

3. CSS模块化

CSS 自诞生以来，基本语法和核心机制一直没有本质上的变化，它的发展几乎全是表现力层面上的提升。不同于JS，CSS本身不具有高级编程属性，无法使用变量、运算、函数等，无法管理依赖，全局作用域使得在编写CSS样式的时候需要更多人工去处理优先级的问题，样式名还有压缩极限的问题，为此，出现了很多“编译工具”和“开发方案”为CSS赋予“编程能力”。

预处理器

随着页面越来越复杂，为了便于开发和维护，我们常常会将CSS文件进行切分，然后再将需要的文件进行合并。诸如LESS、SASS、Stylus等预处理器为CSS带来了编程能力，我们可以使用变量、运算、函数，@import指令可以轻松合并文件。但各种预处理器并不能完全解决全局作用域的问题，需要结合namespace的思想去命名。

OOCSS & SMACSS

OOCSS和SMACSS都是有关css的方法论。OOCSS(Object Oriented CSS)即面向对象的CSS，旨在编写高可复用、低耦合和高扩展的CSS代码，有两个主要原则，它们都是用来规定应该把什么属性定义在什么样式类中。

Separate structure and skin（分离结构和主题）
Separate container and content（分离容器和内容）

SMACSS(Scalable and Modular Architecture for CSS)是可扩展模块化的CSS，它的核心就是结构化CSS代码，则有三个主要规则：

Categorizing CSS Rules (CSS分类规则)：将CSS分成Base、Layout、Module、State、Theme这5类。
Naming Rules（命名规则）：考虑用命名体现样式对应的类别，如layout-这样的前缀。
Minimizing the Depth of Applicability（最小化适配深度）：降低对特定html结构的依赖。

/* 依赖html结构，不提倡 */

.sidebar ul h3 { }

/* 建议直接定义 */

.sub-title { }

BEM

BEM是一种CSS命名规范，旨在解决样式名的全局冲突问题。BEM是块（block）、元素（element）、修饰符（modifier）的简写，我们常用这三个实体开发组件。

块(block)：一种布局或者设计上的抽象，每一个块拥有一个命名空间（前缀）。
元素(element)：是.block的后代，和块一起形成一个完整的实体。
修饰符(modifier)：代表一个块的状态，表示它持有的一个特定属性。

在选择器中，BEM要求只使用类名，不允许使用id，由以下三种符号来表示扩展的关系：

中划线( - ) ：仅作为连字符使用，表示某个块或者某个子元素的多单词之间的连接记号。
双下划线( __ )：双下划线用来连接块和块的子元素。
单下划线( _ )：单下划线用来描述一个块或者块的子元素的一种状态。

从上面BEM的命名要求可以看到，类名都很长，这就导致在对CSS文件进行压缩的时候，我们无法得到更大的优化空间。而且BEM仅仅是一种规范，需要团队中的开发者自行遵守，在可靠性上无法得到有效保障，而且还可能和第三方库的命名冲突。

CSS in JS

CSS in JS是一种比较激进的方案，彻底抛弃了CSS，完全使用JS来编写CSS，又用起了行内样式（inline style），它的发展得益于React的出现，具体的原因可以参见组件化这部分内容。

解决全局命名污染的问题；
更贴近Web组件化的思想；
可以在一些无法解析CSS的运行环境下执行，比如React Native等；
JS赋予CSS更多的编程能力，实现了CSS和JS间的变量共享；
支持CSS单元测试，提高CSS的安全性；
原生JS编写CSS无法支持到很多特性，比如伪类、media query等，需要引入额外的第三方库来支持，各种库的对比详见css-in-js；
有运行时损耗，性能比直接class要差一些；
不容易debug；

下面以styled-components为例：

import React from 'react';

import styled from 'styled-components';

const Container = styled.div`

text-align: center;

const App = () => (

It is a test!

</Container>

);

render(<App />, document.getElementById('content'));

构建后的结果如下，我们发现不会再有.css文件，一个.js文件包含了组件相关的全部代码：

var _templateObject = _taggedTemplateLiteral(['\n text-align: center;\n'], ['\n text-align: center;\n']);

function _taggedTemplateLiteral(strings, raw) {

return Object.freeze(Object.defineProperties(strings, {

raw: { value: Object.freeze(raw) } }));

}

var Container = _styledComponents2.defaul

最低0.47元/天解锁文章

nicky_hb

关注

10
点赞
踩
10

收藏

觉得还不错? 一键收藏
打赏
0
评论
前端专题技术总结2

Service Worker 是 Chrome 团队提出和力推的一个 WEB API，用于给 web 应用提供高级的可持续的后台处理能力。Service Workers 就像介于服务器和网页之间的拦截器，能够拦截进出的HTTP 请求，从而完全控制你的网站。最主要的特点在页面中注册并安装成功后，运行于浏览器后台，不受页面刷新的影响，可以监听和截拦作用域范围内所有页面的 HTTP 请求。网站必须使用 HTTPS。除了使用本地开发环境调试时(如域名使用 localhost)
复制链接

扫一扫