JWT:完全前后端分离的项目如何做用户身份验证更安全?看这篇就够了!

zkbhj 发表了文章 • 0 个评论 • 281 次浏览 • 2018-09-19 14:48 • 来自相关话题

在前后端分离开发时为什么需要用户认证呢?原因是由于HTTP协定是不储存状态的(stateless),这意味着当我们透过帐号密码验证一个使用者时,当下一个request请求时它就把刚刚的资料忘了。于是我们的程序就不知道谁是谁,就要再验证一次。所以为了保证系统安全,我们就需要验证用户否处于登录状态。

传统方式

前后端分离通过Restful API进行数据交互时,如何验证用户的登录信息及权限。在原来的项目中,使用的是最传统也是最简单的方式,前端登录,后端根据用户信息生成一个token,并保存这个 token 和对应的用户id到数据库或Session中,接着把 token 传给用户,存入浏览器 cookie,之后浏览器请求带上这个cookie,后端根据这个cookie值来查询用户,验证是否过期。

但这样做问题就很多,如果我们的页面出现了 XSS 漏洞,由于 cookie 可以被 JavaScript 读取,XSS 漏洞会导致用户 token 泄露,而作为后端识别用户的标识,cookie 的泄露意味着用户信息不再安全。尽管我们通过转义输出内容,使用 CDN 等可以尽量避免 XSS 注入,但谁也不能保证在大型的项目中不会出现这个问题。

在设置 cookie 的时候,其实你还可以设置 httpOnly 以及 secure 项。设置 httpOnly 后 cookie 将不能被 JS 读取,浏览器会自动的把它加在请求的 header 当中,设置 secure 的话,cookie 就只允许通过 HTTPS 传输。secure 选项可以过滤掉一些使用 HTTP 协议的 XSS 注入,但并不能完全阻止。

httpOnly 选项使得 JS 不能读取到 cookie,那么 XSS 注入的问题也基本不用担心了。但设置 httpOnly 就带来了另一个问题,就是很容易的被 XSRF,即跨站请求伪造。当你浏览器开着这个页面的时候,另一个页面可以很容易的跨站请求这个页面的内容。因为 cookie 默认被发了出去。

另外,如果将验证信息保存在数据库中,后端每次都需要根据token查出用户id,这就增加了数据库的查询和存储开销。若把验证信息保存在session中,有加大了服务器端的存储压力。那我们可不可以不要服务器去查询呢?如果我们生成token遵循一定的规律,比如我们使用对称加密算法来加密用户id形成token,那么服务端以后其实只要解密该token就可以知道用户的id是什么了。不过呢,我只是举个例子而已,要是真这么做,只要你的对称加密算法泄露了,其他人可以通过这种加密方式进行伪造token,那么所有用户信息都不再安全了。恩,那用非对称加密算法来做呢,其实现在有个规范就是这样做的,就是我们接下来要介绍的 JWT。

Json Web Token(JWT)

JWT 是一个开放标准(RFC 7519),它定义了一种用于简洁,自包含的用于通信双方之间以 JSON 对象的形式安全传递信息的方法。JWT 可以使用 HMAC 算法或者是 RSA 的公钥密钥对进行签名。它具备两个特点:

简洁(Compact)

可以通过URL, POST 参数或者在 HTTP header 发送,因为数据量小,传输速度快

自包含(Self-contained)

负载中包含了所有用户所需要的信息,避免了多次查询数据库


JWT 组成





Header 头部

头部包含了两部分,token 类型和采用的加密算法
 {
"alg": "HS256",
"typ": "JWT"
}它会使用 Base64 编码组成 JWT 结构的第一部分,如果你使用Node.js,可以用Node.js的包base64url来得到这个字符串。

Base64是一种编码,也就是说,它是可以被翻译回原来的样子来的。它并不是一种加密过程。

Payload 负载

这部分就是我们存放信息的地方了,你可以把用户 ID 等信息放在这里,JWT 规范里面对这部分有进行了比较详细的介绍,常用的由 iss(签发者),exp(过期时间),sub(面向的用户),aud(接收方),iat(签发时间)。
 {
"iss": "lion1ou JWT",
"iat": 1441593502,
"exp": 1441594722,
"aud": "www.example.com",
"sub": "lion1ou@163.com"
}同样的,它会使用 Base64 编码组成 JWT 结构的第二部分

Signature 签名

前面两部分都是使用 Base64 进行编码的,即前端可以解开知道里面的信息。Signature 需要使用编码后的 header 和 payload 以及我们提供的一个密钥,然后使用 header 中指定的签名算法(HS256)进行签名。签名的作用是保证 JWT 没有被篡改过。

三个部分通过.连接在一起就是我们的 JWT 了,它可能长这个样子,长度貌似和你的加密算法和私钥有关系。eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ.PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s

其实到这一步可能就有人会想了,HTTP 请求总会带上 token,这样这个 token 传来传去占用不必要的带宽啊。如果你这么想了,那你可以去了解下 HTTP2,HTTP2 对头部进行了压缩,相信也解决了这个问题。

签名的目的

最后一步签名的过程,实际上是对头部以及负载内容进行签名,防止内容被窜改。如果有人对头部以及负载的内容解码之后进行修改,再进行编码,最后加上之前的签名组合形成新的JWT的话,那么服务器端会判断出新的头部和负载形成的签名和JWT附带上的签名是不一样的。如果要对新的头部和负载进行签名,在不知道服务器加密时用的密钥的话,得出来的签名也是不一样的。

信息暴露

在这里大家一定会问一个问题:Base64是一种编码,是可逆的,那么我的信息不就被暴露了吗?

是的。所以,在JWT中,不应该在负载里面加入任何敏感的数据。在上面的例子中,我们传输的是用户的User ID。这个值实际上不是什么敏感内容,一般情况下被知道也是安全的。但是像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中,那么怀有恶意的第三方通过Base64解码就能很快地知道你的密码了。

因此JWT适合用于向Web应用传递一些非敏感信息。JWT还经常用于设计用户认证和授权系统,甚至实现Web应用的单点登录。

JWT 使用




 
首先,前端通过Web表单将自己的用户名和密码发送到后端的接口。这一过程一般是一个HTTP POST请求。建议的方式是通过SSL加密的传输(https协议),从而避免敏感信息被嗅探。后端核对用户名和密码成功后,将用户的id等其他信息作为JWT Payload(负载),将其与头部分别进行Base64编码拼接后签名,形成一个JWT。形成的JWT就是一个形同lll.zzz.xxx的字符串。后端将JWT字符串作为登录成功的返回结果返回给前端。前端可以将返回的结果保存在localStorage或sessionStorage上,退出登录时前端删除保存的JWT即可。前端在每次请求时将JWT放入HTTP Header中的Authorization位。(解决XSS和XSRF问题)后端检查是否存在,如存在验证JWT的有效性。例如,检查签名是否正确;检查Token是否过期;检查Token的接收方是否是自己(可选)。验证通过后后端使用JWT中包含的用户信息进行其他逻辑操作,返回相应结果。

和Session方式存储id的差异

Session方式存储用户id的最大弊病在于Session是存储在服务器端的,所以需要占用大量服务器内存,对于较大型应用而言可能还要保存许多的状态。一般而言,大型应用还需要借助一些KV数据库和一系列缓存机制来实现Session的存储。

而JWT方式将用户状态分散到了客户端中,可以明显减轻服务端的内存压力。除了用户id之外,还可以存储其他的和用户相关的信息,例如该用户是否是管理员、用户所在的分组等。虽说JWT方式让服务器有一些计算压力(例如加密、编码和解码),但是这些压力相比磁盘存储而言可能就不算什么了。具体是否采用,需要在不同场景下用数据说话。

单点登录

Session方式来存储用户id,一开始用户的Session只会存储在一台服务器上。对于有多个子域名的站点,每个子域名至少会对应一台不同的服务器,例如:www.taobao.com,nv.taobao.com,nz.taobao.com,login.taobao.com。所以如果要实现在login.taobao.com登录后,在其他的子域名下依然可以取到Session,这要求我们在多台服务器上同步Session。使用JWT的方式则没有这个问题的存在,因为用户的状态已经被传送到了客户端。

总结

JWT的主要作用在于(一)可附带用户信息,后端直接通过JWT获取相关信息。(二)使用本地保存,通过HTTP Header中的Authorization位提交验证。但其实关于JWT存放到哪里一直有很多讨论,有人说存放到本地存储,有人说存 cookie。个人偏向于放在本地存储,如果你有什么意见和看法欢迎提出。

参考文档:
https://segmentfault.com/a/1190000005783306 
https://ruiming.me/authentication-of-frontend-backend-separate-application/ 
 
总结和摘录自:
https://blog.csdn.net/kevin_lc ... 46723 查看全部
在前后端分离开发时为什么需要用户认证呢?原因是由于HTTP协定是不储存状态的(stateless),这意味着当我们透过帐号密码验证一个使用者时,当下一个request请求时它就把刚刚的资料忘了。于是我们的程序就不知道谁是谁,就要再验证一次。所以为了保证系统安全,我们就需要验证用户否处于登录状态。

传统方式

前后端分离通过Restful API进行数据交互时,如何验证用户的登录信息及权限。在原来的项目中,使用的是最传统也是最简单的方式,前端登录,后端根据用户信息生成一个token,并保存这个 token 和对应的用户id到数据库或Session中,接着把 token 传给用户,存入浏览器 cookie,之后浏览器请求带上这个cookie,后端根据这个cookie值来查询用户,验证是否过期。

但这样做问题就很多,如果我们的页面出现了 XSS 漏洞,由于 cookie 可以被 JavaScript 读取,XSS 漏洞会导致用户 token 泄露,而作为后端识别用户的标识,cookie 的泄露意味着用户信息不再安全。尽管我们通过转义输出内容,使用 CDN 等可以尽量避免 XSS 注入,但谁也不能保证在大型的项目中不会出现这个问题。

在设置 cookie 的时候,其实你还可以设置 httpOnly 以及 secure 项。设置 httpOnly 后 cookie 将不能被 JS 读取,浏览器会自动的把它加在请求的 header 当中,设置 secure 的话,cookie 就只允许通过 HTTPS 传输。secure 选项可以过滤掉一些使用 HTTP 协议的 XSS 注入,但并不能完全阻止。

httpOnly 选项使得 JS 不能读取到 cookie,那么 XSS 注入的问题也基本不用担心了。但设置 httpOnly 就带来了另一个问题,就是很容易的被 XSRF,即跨站请求伪造。当你浏览器开着这个页面的时候,另一个页面可以很容易的跨站请求这个页面的内容。因为 cookie 默认被发了出去。

另外,如果将验证信息保存在数据库中,后端每次都需要根据token查出用户id,这就增加了数据库的查询和存储开销。若把验证信息保存在session中,有加大了服务器端的存储压力。那我们可不可以不要服务器去查询呢?如果我们生成token遵循一定的规律,比如我们使用对称加密算法来加密用户id形成token,那么服务端以后其实只要解密该token就可以知道用户的id是什么了。不过呢,我只是举个例子而已,要是真这么做,只要你的对称加密算法泄露了,其他人可以通过这种加密方式进行伪造token,那么所有用户信息都不再安全了。恩,那用非对称加密算法来做呢,其实现在有个规范就是这样做的,就是我们接下来要介绍的 JWT。

Json Web Token(JWT)

JWT 是一个开放标准(RFC 7519),它定义了一种用于简洁,自包含的用于通信双方之间以 JSON 对象的形式安全传递信息的方法。JWT 可以使用 HMAC 算法或者是 RSA 的公钥密钥对进行签名。它具备两个特点:


简洁(Compact)

可以通过URL, POST 参数或者在 HTTP header 发送,因为数据量小,传输速度快

自包含(Self-contained)

负载中包含了所有用户所需要的信息,避免了多次查询数据库



JWT 组成

006tNc79gy1fbv54tfilmj31120b2wl9.jpg

Header 头部

头部包含了两部分,token 类型和采用的加密算法
 
{
"alg": "HS256",
"typ": "JWT"
}
它会使用 Base64 编码组成 JWT 结构的第一部分,如果你使用Node.js,可以用Node.js的包base64url来得到这个字符串。


Base64是一种编码,也就是说,它是可以被翻译回原来的样子来的。它并不是一种加密过程。


Payload 负载

这部分就是我们存放信息的地方了,你可以把用户 ID 等信息放在这里,JWT 规范里面对这部分有进行了比较详细的介绍,常用的由 iss(签发者),exp(过期时间),sub(面向的用户),aud(接收方),iat(签发时间)。
 
{
"iss": "lion1ou JWT",
"iat": 1441593502,
"exp": 1441594722,
"aud": "www.example.com",
"sub": "lion1ou@163.com"
}
同样的,它会使用 Base64 编码组成 JWT 结构的第二部分

Signature 签名

前面两部分都是使用 Base64 进行编码的,即前端可以解开知道里面的信息。Signature 需要使用编码后的 header 和 payload 以及我们提供的一个密钥,然后使用 header 中指定的签名算法(HS256)进行签名。签名的作用是保证 JWT 没有被篡改过。

三个部分通过.连接在一起就是我们的 JWT 了,它可能长这个样子,长度貌似和你的加密算法和私钥有关系。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ.PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s

其实到这一步可能就有人会想了,HTTP 请求总会带上 token,这样这个 token 传来传去占用不必要的带宽啊。如果你这么想了,那你可以去了解下 HTTP2,HTTP2 对头部进行了压缩,相信也解决了这个问题。

签名的目的

最后一步签名的过程,实际上是对头部以及负载内容进行签名,防止内容被窜改。如果有人对头部以及负载的内容解码之后进行修改,再进行编码,最后加上之前的签名组合形成新的JWT的话,那么服务器端会判断出新的头部和负载形成的签名和JWT附带上的签名是不一样的。如果要对新的头部和负载进行签名,在不知道服务器加密时用的密钥的话,得出来的签名也是不一样的。

信息暴露

在这里大家一定会问一个问题:Base64是一种编码,是可逆的,那么我的信息不就被暴露了吗?

是的。所以,在JWT中,不应该在负载里面加入任何敏感的数据。在上面的例子中,我们传输的是用户的User ID。这个值实际上不是什么敏感内容,一般情况下被知道也是安全的。但是像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中,那么怀有恶意的第三方通过Base64解码就能很快地知道你的密码了。

因此JWT适合用于向Web应用传递一些非敏感信息。JWT还经常用于设计用户认证和授权系统,甚至实现Web应用的单点登录。

JWT 使用

006tNc79gy1fbv63pzqocj30pj0h8t9m.jpg
 
  1. 首先,前端通过Web表单将自己的用户名和密码发送到后端的接口。这一过程一般是一个HTTP POST请求。建议的方式是通过SSL加密的传输(https协议),从而避免敏感信息被嗅探。
  2. 后端核对用户名和密码成功后,将用户的id等其他信息作为JWT Payload(负载),将其与头部分别进行Base64编码拼接后签名,形成一个JWT。形成的JWT就是一个形同lll.zzz.xxx的字符串。
  3. 后端将JWT字符串作为登录成功的返回结果返回给前端。前端可以将返回的结果保存在localStorage或sessionStorage上,退出登录时前端删除保存的JWT即可。
  4. 前端在每次请求时将JWT放入HTTP Header中的Authorization位。(解决XSS和XSRF问题)
  5. 后端检查是否存在,如存在验证JWT的有效性。例如,检查签名是否正确;检查Token是否过期;检查Token的接收方是否是自己(可选)。
  6. 验证通过后后端使用JWT中包含的用户信息进行其他逻辑操作,返回相应结果。


和Session方式存储id的差异

Session方式存储用户id的最大弊病在于Session是存储在服务器端的,所以需要占用大量服务器内存,对于较大型应用而言可能还要保存许多的状态。一般而言,大型应用还需要借助一些KV数据库和一系列缓存机制来实现Session的存储。

而JWT方式将用户状态分散到了客户端中,可以明显减轻服务端的内存压力。除了用户id之外,还可以存储其他的和用户相关的信息,例如该用户是否是管理员、用户所在的分组等。虽说JWT方式让服务器有一些计算压力(例如加密、编码和解码),但是这些压力相比磁盘存储而言可能就不算什么了。具体是否采用,需要在不同场景下用数据说话。

单点登录

Session方式来存储用户id,一开始用户的Session只会存储在一台服务器上。对于有多个子域名的站点,每个子域名至少会对应一台不同的服务器,例如:www.taobao.com,nv.taobao.com,nz.taobao.com,login.taobao.com。所以如果要实现在login.taobao.com登录后,在其他的子域名下依然可以取到Session,这要求我们在多台服务器上同步Session。使用JWT的方式则没有这个问题的存在,因为用户的状态已经被传送到了客户端。

总结

JWT的主要作用在于(一)可附带用户信息,后端直接通过JWT获取相关信息。(二)使用本地保存,通过HTTP Header中的Authorization位提交验证。但其实关于JWT存放到哪里一直有很多讨论,有人说存放到本地存储,有人说存 cookie。个人偏向于放在本地存储,如果你有什么意见和看法欢迎提出。

参考文档:
https://segmentfault.com/a/1190000005783306 
https://ruiming.me/authentication-of-frontend-backend-separate-application/ 
 
总结和摘录自:
https://blog.csdn.net/kevin_lc ... 46723

JavaScript如何识别当前页面是否处于激活状态?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 129 次浏览 • 2018-09-18 19:29 • 来自相关话题

Js中如何进行json和object类型数据的转换?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 251 次浏览 • 2018-08-15 16:17 • 来自相关话题

CSS如何实现内容超出部分展示成省略号?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 206 次浏览 • 2018-08-15 14:33 • 来自相关话题

JQuery如何判断iframe页面是否加载完成?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 233 次浏览 • 2018-08-14 14:23 • 来自相关话题

来一起简单了解下单页面应用SPA

zkbhj 发表了文章 • 0 个评论 • 341 次浏览 • 2018-05-25 17:39 • 来自相关话题

一、定义

单页 Web 应用 (single-page application 简称为 SPA) 是一种特殊的 Web 应用。它将所有的活动局限于一个Web页面中,仅在该Web页面初始化时加载相应的HTML、JavaScript 和 CSS。一旦页面加载完成了,SPA不会因为用户的操作而进行页面的重新加载或跳转。取而代之的是利用 JavaScript 动态的变换HTML的内容,从而实现UI与用户的交互。由于避免了页面的重新加载,SPA 可以提供较为流畅的用户体验。

二、优缺点

单页Web程序的出现是富客户端发展的必然结果,但是该技术也是有些局限性,所以采用之前需要了解清楚它的优缺点。

1、优点:

1).良好的交互体验

用户不需要重新刷新页面,获取数据也是通过Ajax异步获取,页面显示流畅。

2).良好的前后端工作分离模式

单页Web应用可以和RESTful规约一起使用,通过REST API提供接口数据,并使用Ajax异步获取,这样有助于分离客户端和服务器端工作。更进一步,可以在客户端也可以分解为静态页面和页面交互两个部分。

3).减轻服务器压力

服务器只用出数据就可以,不用管展示逻辑和页面合成,吞吐能力会提高几倍;

4).共用一套后端程序代码
不用修改后端程序代码就可以同时用于Web界面、手机、平板等多种客户端;
 
2、缺点:

1).SEO难度较高

由于所有的内容都在一个页面中动态替换显示,所以在SEO上其有着天然的弱势,所以如果你的站点对SEO很看重,且要用单页应用,那么就做些静态页面给搜索引擎用吧。

2).前进、后退管理

由于单页Web应用在一个页面中显示所有的内容,所以不能使用浏览器的前进后退功能,所有的页面切换需要自己建立堆栈管理,当然此问题也有解决方案,比如利用URI中的散列+iframe实现。

3).初次加载耗时多

为实现单页Web应用功能及显示效果,需要在加载页面的时候将JavaScript、CSS统一加载,部分页面可以在需要的时候加载。所以必须对JavaScript及CSS代码进行合并压缩处理,如果使用第三方库,建议使用一些大公司的CDN,因此带宽的消耗是必然的

二、单页面应用实现的原理

1、基本实现原理:利用ajax请求替代了a标签的默认跳转,然后利用html5中的API修改了url,这项技术并没有特别标准的学名,大家都称呼为Pjax,意为PushState + Ajax。这并不完全准确,因为还有Hash + Ajax等方法

2、Pjax是一个优秀的解决方案,你有足够多的理由来使用它:
 
可以在页面切换间平滑过渡,增加Loading动画。可以在各个页面间传递数据,不依赖URL。可以选择性的保留状态,如音乐网站,切换页面时不会停止播放歌曲。所有的标签都可以用来跳转,不仅仅是a标签。避免了公共JS的反复执行,如无需在各个页面打开时都判断是否登录过等等。减少了请求体积,节省流量,加快页面响应速度。平滑降级到低版本浏览器上,对SEO也不会有影响。

3、深剖原理

拦截a标签的默认跳转动作。
2. 使用Ajax请求新页面。
3. 将返回的Html替换到页面中。
4. 使用HTML5的History API或者Url的Hash修改Url。

4、HTML5 History APIhistory.pushState(state, title, url)
pushState方法会将当前的url添加到历史记录中,然后修改当前url为新url。请注意,这个方法只会修改地址栏的Url显示,但并不会发出任何请求。我们正是基于此特性来实现Pjax。它有3个参数:
state: 可以放任意你想放的数据,它将附加到新url上,作为该页面信息的一个补充。title: 顾名思义,就是document.title。不过这个参数目前并无作用,浏览器目前会选择忽略它。url: 新url,也就是你要显示在地址栏上的url。
 history.replaceState(state, title, url)
replaceState方法与pushState大同小异,区别只在于pushState会将当前url添加到历史记录,之后再修改url,而replaceState只是修改url,不添加历史记录。

window.onpopstate 事件
一般来说,每当url变动时,popstate事件都会被触发。但若是调用pushState来修改url,该事件则不会触发,因此,我们可以把它用作浏览器的前进后退事件。该事件有一个参数,就是上文pushState方法的第一个参数state。 查看全部
一、定义

单页 Web 应用 (single-page application 简称为 SPA) 是一种特殊的 Web 应用。它将所有的活动局限于一个Web页面中,仅在该Web页面初始化时加载相应的HTML、JavaScript 和 CSS。一旦页面加载完成了,SPA不会因为用户的操作而进行页面的重新加载或跳转。取而代之的是利用 JavaScript 动态的变换HTML的内容,从而实现UI与用户的交互。由于避免了页面的重新加载,SPA 可以提供较为流畅的用户体验。

二、优缺点

单页Web程序的出现是富客户端发展的必然结果,但是该技术也是有些局限性,所以采用之前需要了解清楚它的优缺点。

1、优点:

1).良好的交互体验

用户不需要重新刷新页面,获取数据也是通过Ajax异步获取,页面显示流畅。

2).良好的前后端工作分离模式

单页Web应用可以和RESTful规约一起使用,通过REST API提供接口数据,并使用Ajax异步获取,这样有助于分离客户端和服务器端工作。更进一步,可以在客户端也可以分解为静态页面和页面交互两个部分。

3).减轻服务器压力

服务器只用出数据就可以,不用管展示逻辑和页面合成,吞吐能力会提高几倍;

4).共用一套后端程序代码
不用修改后端程序代码就可以同时用于Web界面、手机、平板等多种客户端;
 
2、缺点:

1).SEO难度较高

由于所有的内容都在一个页面中动态替换显示,所以在SEO上其有着天然的弱势,所以如果你的站点对SEO很看重,且要用单页应用,那么就做些静态页面给搜索引擎用吧。

2).前进、后退管理

由于单页Web应用在一个页面中显示所有的内容,所以不能使用浏览器的前进后退功能,所有的页面切换需要自己建立堆栈管理,当然此问题也有解决方案,比如利用URI中的散列+iframe实现。

3).初次加载耗时多

为实现单页Web应用功能及显示效果,需要在加载页面的时候将JavaScript、CSS统一加载,部分页面可以在需要的时候加载。所以必须对JavaScript及CSS代码进行合并压缩处理,如果使用第三方库,建议使用一些大公司的CDN,因此带宽的消耗是必然的

二、单页面应用实现的原理

1、基本实现原理:利用ajax请求替代了a标签的默认跳转,然后利用html5中的API修改了url,这项技术并没有特别标准的学名,大家都称呼为Pjax,意为PushState + Ajax。这并不完全准确,因为还有Hash + Ajax等方法

2、Pjax是一个优秀的解决方案,你有足够多的理由来使用它:
 
  • 可以在页面切换间平滑过渡,增加Loading动画。
  • 可以在各个页面间传递数据,不依赖URL。
  • 可以选择性的保留状态,如音乐网站,切换页面时不会停止播放歌曲。
  • 所有的标签都可以用来跳转,不仅仅是a标签。
  • 避免了公共JS的反复执行,如无需在各个页面打开时都判断是否登录过等等。
  • 减少了请求体积,节省流量,加快页面响应速度。
  • 平滑降级到低版本浏览器上,对SEO也不会有影响。


3、深剖原理

拦截a标签的默认跳转动作。
2. 使用Ajax请求新页面。
3. 将返回的Html替换到页面中。
4. 使用HTML5的History API或者Url的Hash修改Url。

4、HTML5 History API
history.pushState(state, title, url)

pushState方法会将当前的url添加到历史记录中,然后修改当前url为新url。请注意,这个方法只会修改地址栏的Url显示,但并不会发出任何请求。我们正是基于此特性来实现Pjax。它有3个参数:
  • state: 可以放任意你想放的数据,它将附加到新url上,作为该页面信息的一个补充。
  • title: 顾名思义,就是document.title。不过这个参数目前并无作用,浏览器目前会选择忽略它。
  • url: 新url,也就是你要显示在地址栏上的url。

 
history.replaceState(state, title, url)

replaceState方法与pushState大同小异,区别只在于pushState会将当前url添加到历史记录,之后再修改url,而replaceState只是修改url,不添加历史记录。

window.onpopstate 事件
一般来说,每当url变动时,popstate事件都会被触发。但若是调用pushState来修改url,该事件则不会触发,因此,我们可以把它用作浏览器的前进后退事件。该事件有一个参数,就是上文pushState方法的第一个参数state。

饿了么的PWA升级实践

zkbhj 发表了文章 • 0 个评论 • 386 次浏览 • 2018-02-03 14:00 • 来自相关话题

自Vue.js在官方推特第一次公开到现在,我们就一直在进行着将饿了么移动端网站升级为 Progressive Web App的工作。直到近日在GoogleI/O 2017上登台亮相,才终于算告一段落。我们非常荣幸能够发布全世界第一个专门面向国内用户的PWA,但更荣幸的是能与 Google、 UC以及腾讯合作,一起推动国内Web与浏览器生态的发展。

多页应用、 Vue.js、 PWA?

对于构建一个希望达到原生应用级别体验的PWA,目前社区里的主流做法都是采用SPA,即单页面应用模型(Single-page App)来组织整个Web应用,业内最有名的几个PWA案例Twitter Lite、 Flipkart Lite、Housing Go 与 Polymer Shop无一例外。

然而饿了么,与很多国内的电商网站一样,青睐多页面应用模型(MPA, Multi-page App)所能带来的一些好处,也因此在一年多前就将移动站从基于AngularJS的单页应用重构为目前的多页应用模型。团队最看重的优点莫过于页面与页面之间的隔离与解耦,这使得我们可以将每个页面当做一个独立的“微服务”来看待,这些服务可以被独立迭代,独立提供给各种第三方的入口嵌入,甚至被不同的团队独立维护。而整个网站则只是各种服务的集合而非一个巨大的整体。

与此同时,我们仍然依赖 Vue.js作为JavaScript框架。 Vue.js除了是React、 AngularJS这种“重型武器”的竞争对手外,其轻量与高性能的优点使得它同样可以作为传统多页应用开发中流行的“jQuery/Zepto/Kissy+模板引擎”技术栈的完美替代。 Vue.js提供的组件系统、声明式与响应式编程更是提升了代码组织、共享、数据流控制、渲染等各个环节的开发效率。 Vue 还是一个渐进式框架,如果网站的复杂度继续提升,我们可以按需、增量地引入Vuex或Vue-Router这些模块。万一哪天又要改回单页呢?(谁知道呢……)

2017年, PWA已经成为Web应用新的风潮。我们决定试试,以我们现有的“Vue.js+多页”架构,能在升级PWA的道路上走多远,达到怎样的效果。

实现“PRPL”模式

“PRPL”(读作“purple”)是Google工程师提出的一种Web应用架构模式,它旨在利用现代Web平台的新技术以大幅优化移动Web的性能与体验,对如何组织与设计高性能的PWA系统提供了一种高层次的抽象。我们并不准备从头重构我们的Web应用,不过我们可以把实现“PRPL”模式作为我们的迁移目标。“PRPL”实际上是“Push/Preload、 Render、 Precache、 Lazy-Load”的缩写,我们接下来会展开介绍它们的具体含义。

Push/Preload,推送/预加载初始URL路由所需的关键资源

无论是HTTP2 Server Push还是,其关键都在于,我们希望提前请求一些隐藏在应用依赖关系(Dependency Graph)较深处的资源,以节省HTTP往返、浏览器解析文档,或脚本执行的时间。比如说,对于一个基于路由进行code splitting的SPA,如果我们可以在Webpack清单、路由等入口代码(entry chunks)被下载与运行之前就把初始URL,即用户访问的入口URL路由所依赖的代码用Server Push推送或进行提前加载。那么当这些资源被真正请求时,它们可能已经下载好并存在缓存中了,这样就加快了初始路由所有依赖的就绪。

在多页应用中,每一个路由本来就只会请求这个路由所需要的资源,并且通常依赖也都比较扁平。饿了么移动站的大部分脚本依赖都是普通的 <script> 元素,因此他们可以在文档解析早期就被浏览器的preloader扫描出来并且开始请求,其效果其实与显式的是一致的,见图1所示。

图1 有无<link rel=“preload”>的效果对比
 
我们还将所有关键的静态资源都伺服在同一域名下(不再做域名散列),以更好地利用HTTP2带来的多路复用(Multiplexing)。同时,我们也在进行着对API进行Server Push的实验。

Render,渲染初始路由,尽快让应用可被交互

既然所有初始路由的依赖都已经就绪,我们就可以尽快开始初始路由的渲染,这有助于提升应用诸如首次渲染时间、可交互时间等指标。多页应用并不使用基于JavaScript的路由,而是传统的HTML跳转机制,所以对于这一部分,多页应用其实不用额外做什么。

Precache,用Service Worker预缓存剩下的路由

这一部分就需要Service Worker的参与了。Service Worker是一个位于浏览器与网络之间的客户端代理,它已可拦截、处理、响应流经的HTTP请求,使得开发者得以从缓存中向Web应用提供资源而闻名。不过, Service Worker其实也可以主动发起 HTTP 请求,在“后台”预请求与预缓存我们未来所需要的资源,见图2所示。

图2 Service Worker预缓存未来所需要的资源
 
我们已经使用Webpack在构建过程中进行.vue编译、文件名哈希等工作,于是我们编写了一个Webpack插件来帮助收集需要缓存的依赖到一个“预缓存清单”中,并使用这个清单在每次构建时生成新的Service Worker文件。在新的Service Worker被激活时,清单里的资源就会被请求与缓存,这其实与SW-Precache 这个库的运行机制非常接近。

实际上,我们只对标记为“关键路由”的路由进行依赖收集。你可以将这些“关键路由”的依赖理解为我们整个应用的“App Shell” 或者说“安装包”。一旦它们都被缓存,或者说成功安装,无论用户是在线离线,我们的Web应用都可以从缓存中直接启动。对于那些并不那么重要的路由,我们则采取在运行时增量缓存的方式。我们使用的SW-Toolbox提供了LRU替换策略与TTL失效机制,可以保证我们的应用不会超过浏览器的缓存配额。

Lazy-Load,按需懒加载、懒实例化剩下的路由

懒加载与懒实例化剩下的路由对于SPA是一件相对麻烦点儿的事情,你需要实现基于路由的code splitting与异步加载。幸运的是,这又是一件不需要多页应用担心的事情,多页应用中的各个路由天生就是分离的。

值得说明的是,无论单页还是多页应用,如果在上一步中,我们已经将这些路由的资源都预先下载与缓存好了,那么懒加载就几乎是瞬时完成的了,这时候我们就只需要付出实例化的代价。

至此,我们对PRPL的四部分含义做了详细说明。有趣的是,我们发现多页应用在实现PRPL这件事甚至比单页还要容易一些。那么结果如何呢?

根据Google推出的Web性能分析工具Lighthouse(v1.6),在模拟的3G网络下,用户的初次访问(无任何缓存)大约在2秒左右达到“可交互”,可以说非常不错,见图3所示。而对于再次访问,由于所有资源都直接来自于Service Worker缓存,页面可以在1秒左右就达到可交互的状态了。
 
图3 Lighthouse跑分结果
 
但是,故事并不是这么简单得就结束了。在实际体验中我们发现,应用在页与页的切换时,仍然存在着非常明显的白屏空隙,见图4所示。由于PWA是全屏运行,白屏对用户体验所带来的负面影响甚至比以往在浏览器内更大。我们不是已经用Service Worker缓存了所有资源了吗,怎么还会这样呢?

图4 从首页点击到发现页,跳转过程中的白屏
 
多页应用的陷阱:重启开销

与SPA不同,在多页应用中,路由的切换是原生的浏览器文档跳转(Navigating across documents),这意味着之前的页面会被完全丢弃而浏览器需要为下一个路由的页面重新执行所有的启动步骤:重新下载资源、重新解析HTML、重新运行JavaScript、重新解码图片、重新布局页面、重新绘制……即使其中的很多步骤本是可以在多个路由之间复用的。这些工作无疑将产生巨大的计算开销,也因此需要付出相当多的时间成本。

图5中为我们的入口页(同时也是最重要的页面)在两倍CPU节流模拟下的Profile数据。即使我们可以将“可交互时间”控制在 1 秒左右,我们的用户仍然会觉得这对于“仅仅切换个标签”来说实在是太慢了。

图5 入口页在两倍CPU节流模拟下的Profile数据

巨大的JavaScript重启开销

根据Profile,我们发现在首次渲染(First Paint)发生之前,大量的时间(900ms)都消耗在了JavaScript的运行上(Evaluate Script)。几乎所有脚本都是阻塞的(Parser-blocking),不过因为所有的UI都是由JavaScript/Vue.js驱动的,倒也不会有性能影响。这900ms中,约一半是消耗在Vue.js运行时、组件、库等依赖的运行上,而另一半则花在了业务组件实例化时Vue.js的启动与渲染上。从软件工程角度来说,我们需要这些抽象,所以这里并不是想责怪JavaScript或是Vue.js所带来的开销。

但是,在SPA中, JavaScript的启动成本是均摊到整个生命周期的:每个脚本都只需要被解析与编译一次,诸如生成Virtual DOM等较重的任务可以只执行一次,像Vue.js的ViewModel或是Virtual DOM这样的大对象也可以被留在内存里复用。可惜在多页应用里就不是这样了,我们每次切换页面都为JavaScript付出了巨大的重启代价。

浏览器的缓存啊,能不能帮帮忙?

能,也不能。

V8提供了代码缓存(code caching),可以将编译后的机器码在本地拷贝一份,这样我们就可以在下次请求同一个脚本时一次省略掉请求、解析、编译的所有工作。而且,对于缓存在Service Worker配套的Cache Storage中的脚本,会在第一次执行后就触发V8的代码缓存,这对于我们的多页切换能提供不少帮助。

另外一个你或许听过的浏览器缓存叫做“进退缓存”, Back-Forward Cache,简称bfcache。浏览器厂商对其的命名各异, Opera称之为Fast History Navigation, Webkit称其为Page Cache。但是思路都一样,就是我们可以让浏览器在跳转时把前一页留存在内存中,保留JavaScript与DOM的状态,而不是全都销毁掉。你可以随便找个传统的多页网站在iOS Safari上试试,无论是通过浏览器的前进后退按钮、手势,还是通过超链接(会有一些不同),基本都可以看到瞬间加载的效果。

Bfcache其实非常适合多页应用。但不幸的是,Chrome由于内存开销与其多进程架构等原因目前并不支持。 Chrome现阶段仅仅只是用了传统的HTTP磁盘缓存,来稍稍简化了一下加载过程而已。对于Chromium内核霸占的Android生态来说,我们没法指望了。

为“感知体验”奋斗

尽管多页应用面临着现实中的不少性能问题,我们并不想这么快就妥协。一方面,我们尝试尽可能减少在页面达到可交互时间前的代码执行量,比如减少/推迟一些依赖脚本的执行,还有减少初次渲染的DOM节点数以节省Virtual DOM的初始化开销。另一方面,我们也意识到应用在感知体验上还有更多的优化空间。

Chrome产品经理Owen写过一篇Reactive Web Design: The secret to building web apps that feel amazing,谈到两种改进感知体验的手段:一是使用骨架屏(Skeleton Screen)来实现瞬间加载;二是预先定义好元素的尺寸来保证加载的稳定。跟我们的做法可以说不谋而合。

为了消除白屏时间,我们同样引入了尺寸稳定的骨架屏来帮助我们实现瞬间的加载与占位。即使是在硬件很弱的设备上,我们也可以在点击切换标签后立刻渲染出目标路由的骨架屏,以保证UI是稳定、连续、有响应的。我录了两个视频放在Youtube上,不过如果你是国内读者,你可以直接访问饿了么移动网站来体验实地的效果。最终效果如图6所示。
 
为“感知体验”奋斗

尽管多页应用面临着现实中的不少性能问题,我们并不想这么快就妥协。一方面,我们尝试尽可能减少在页面达到可交互时间前的代码执行量,比如减少/推迟一些依赖脚本的执行,还有减少初次渲染的DOM节点数以节省Virtual DOM的初始化开销。另一方面,我们也意识到应用在感知体验上还有更多的优化空间。

Chrome产品经理Owen写过一篇Reactive Web Design: The secret to building web apps that feel amazing,谈到两种改进感知体验的手段:一是使用骨架屏(Skeleton Screen)来实现瞬间加载;二是预先定义好元素的尺寸来保证加载的稳定。跟我们的做法可以说不谋而合。

为了消除白屏时间,我们同样引入了尺寸稳定的骨架屏来帮助我们实现瞬间的加载与占位。即使是在硬件很弱的设备上,我们也可以在点击切换标签后立刻渲染出目标路由的骨架屏,以保证UI是稳定、连续、有响应的。我录了两个视频放在Youtube上,不过如果你是国内读者,你可以直接访问饿了么移动网站来体验实地的效果。最终效果如图6所示。
图6 在添加骨架屏后,从发现页点回首页的效果

这效果本该很轻松的就能实现,不过实际上我们还费了点功夫。

在构建时使用 Vue 预渲染骨架屏

你可能已经想到了,为了让骨架屏可以被Service Worker缓存,瞬间加载并独立于JavaScript渲染,我们需要把组成骨架屏的HTML标签、 CSS样式与图片资源一并内联至各个路由的静态*.html文件中。

不过,我们并不准备手动编写这些骨架屏。你想啊,如果每次真实组件有迭代(每一个路由对我们来说都是一个Vue.js组件),我们都需要手动去同步每一个变化到骨架屏的话,那实在是太繁琐且难以维护了。好在,骨架屏不过是当数据还未加载进来前,页面的一个空白版本而已。如果我们能将骨架屏实现为真实组件的一个特殊状态——“空状态”的话,从理论上就可以从真实组件中直接渲染出骨架屏来。

而Vue.js的多才多艺就在这时体现出来了,我们真的可以用Vue.js 的服务端渲染模块来实现这个想法,不过不是用在真正的服务器上,而是在构建时用它把组件的空状态预先渲染成字符串并注入到HTML模板中。你需要调整Vue.js组件代码使得它可以在Node上执行,有些页面对DOM/BOM的依赖一时无法轻易去除得,我们目前只好额外编写一个*.shell.vue来暂时绕过这个问题。

关于浏览器的绘制(Painting)

HTML文件中有标签并不意味着这些标签就能立刻被绘制到屏幕上,你必须保证页面的关键渲染路径是为此优化的。很多开发者相信将Script标签放在body的底部就足以保证内容能在脚本执行之前被绘制,这对于能渲染不完整DOM树的浏览器(比如桌面浏览器常见的流式渲染)来说可能是成立的。但移动端的浏览器很可能因为考虑到较慢的硬件、电量消耗等因素并不这么做。不仅如此,即使你曾被告知设为async或defer的脚本就不会阻塞HTML解析了,但这可不意味着浏览 器就一定会在执行它们之前进行渲染。

首先我想澄清的是,根据 HTML 规范 Scripting 章节, async脚本是在其请求完成后立刻运行的,因此它本来就可能阻塞到解析。只有defer(且非内联)与最新的type=module被指定为“一定不会阻塞解析”(不过defer目前也有点小问题……我们稍后会再提到),见图7所示。
图7 具有不同属性的Script脚本对HTML解析的阻塞情况

而更重要的是,一个不阻塞HTML解析的脚本仍然可能阻塞到绘制。我做了一个简化的“最小多页PWA”(Minimal Multi-page PWA,或MMPWA)来测试这个问题:我们在一个async(且确实不阻塞HTML解析)脚本中,生成并渲染1000个列表项,然后测试骨架屏能否在脚本执行之前渲染出来。图8是通过USB Debugging在我的Nexus 5真机上录制的Profile。


图8 通过USB Debugging在Nexus 5真机上录制的Profile

是的,出乎意料吗?首次渲染确实被阻塞到脚本执行结束后才发生。究其原因,如果我们在浏览器还未完成上一次绘制工作之前就过快得进行了DOM操作,我们亲爱的浏览器就只好抛弃所有它已经完成的像素,且一直要等待到DOM操作引起的所有工作结束之后才能重新进行下一次渲染。而这种情况更容易在拥有较慢CPU/GPU的移动设备上出现。

黑魔法:利用setTimeout()让绘制提前

不难发现,骨架屏的绘制与脚本执行实际是一个竞态。大概是Vue.js太快了,我们的骨架屏还是有非常大的概率绘制不出来。于是我们想着如何能让脚本执行慢点,或者说,“懒”点。于是我们想到了一个经典的Hack: setTimeout(callback, 0)。我们试着把MMPWA中的DOM操作(渲染1000个列表)放进setTimeout(callback, 0)里……

当当!首次渲染瞬间就被提前了,见图9所示。如果你熟悉浏览器的事件循环模型(Event Loop)的话,这招Hack其实是通过setTimeout的回调把DOM操作放到了事件循环的任务队列中以避免它在当前循环执行,这样浏览器就得以在主线程空闲时喘息一下(更新一下渲染)了。如果你想亲手试试 MMPWA的话,你可以访问github.com/Huxpro/mmpwa 或huangxuan.me/mmpwa/ ,查看代码与Demo。我把UI设计成了A/B Test的形式并改为渲染5000个列表项来让效果更夸张一些。

图9 利用Hack技术,提前完成骨架屏的绘制

回到饿了么PWA上,我们同样试着把new Vue()放到了setTimeout中。果然,黑魔法再次显灵,骨架屏在每次跳转后都能立刻被渲染。这时的Profile看起来是这样的,见图10所示。

 
图10 为感知体验进行各种优化后的最终Profile

现在,我们在400ms时触发首次渲染(骨架屏),在600ms时完成真实UI的渲染并达到页面的可交互。你可以详细对比下图9和图10所示的优化前后Profile的区别。

被我“defer”的有关defer的Bug

不知道你发现没有,在图10的Profile中,我们仍然有不少脚本是阻塞了HTML解析的。好吧,让我解释一下,由于历史原因,我们确实保留了一部分的阻塞脚本,比如侵入性很强的lib-flexible,我们没法轻易去除它。不过, Profile里的大部分阻塞脚本实际上都设置了defer,我们本以为他们应该在HTML解析完成之后才被执行,结果被Profile打了一脸。

我和Jake Archibald 聊了一下,果然这是Chrome的Bug: defer的脚本被完全缓存时,并没有遵守规范等待解析结束,反而阻塞了解析与渲染。Jake已经提交在crbug上了,一起给它投票吧。

最后,图11是优化后的Lighthouse跑分结果,同样可以看到明显的性能提升。需要说明的是,能影响Lighthouse跑分的因素有很多,所以我建议你以控制变量(跑分用的设备、跑分时的网络环境等)的方式来进行对照实验。

图11 优化后的Lighthouse跑分结果

最后为大家展示下应用的架构示意图,见图12所示。

图12 应用架构示意图

一些感想

多页应用仍然有很长的路要走

Web是一个极其多样化的平台。从静态的博客,到电商网站,再到桌面级的生产力软件,它们全都是Web这个大家庭的第一公民。而我们组织Web应用的方式,也同样只会更多而不会更少:多页、单页、 Universal JavaScript应用、 WebGL,以及可以预见的Web Assembly。不同的技术之间没有贵贱,但是适用场景的差距确是客观存在的。

Jake 曾在 Chrome Dev Summit 2016 上说过“PWA!== SPA”。可是尽管我们已经用上了一系列最新的技术(PRPL、 Service Worker、 App Shell……),我们仍然因为多页应用模型本身的缺陷有着难以逾越的一些障碍。多页应用在未来可能会有“bfcache API”、 Navigation Transition等新的规范以缩小跟SPA的距离,不过我们也必须承认,时至今日,多页应用的局限性也是非常明显的。

而PWA终将带领Web应用进入新的时代

即使我们的多页应用在升级PWA的路上不如单页应用来得那么闪亮,但是PWA背后的想法与技术却实实在在地帮助我们在Web平台上提供了更好的用户体验。

PWA作为下一代 Web 应用模型,其尝试解决的是Web平台本身的根本性问题:对网络与浏览器UI的硬依赖。因此,任何Web应用都可以从中获益,这与你是多页还是单页、面向桌面还是移动端、是用React还是Vue.js无关。或许,它还终将改变用户对移动Web的期待。现如今,谁还觉得桌面端的Web只是个看文档的地方呢?

还是那句老话,让我们的用户,也像我们这般热爱Web吧。

最后,感谢饿了么的王亦斯、任光辉、题叶,Google 的 Michael Yeung、 DevRel 团队, UC浏览器团队,腾讯X5浏览器团队在这次项目中的合作。感谢尤雨溪、陈蒙迪和Jake Archibald 在写作过程中给予我的帮助。
 
原文阅读:https://zhuanlan.zhihu.com/p/27836133 查看全部
自Vue.js在官方推特第一次公开到现在,我们就一直在进行着将饿了么移动端网站升级为 Progressive Web App的工作。直到近日在GoogleI/O 2017上登台亮相,才终于算告一段落。我们非常荣幸能够发布全世界第一个专门面向国内用户的PWA,但更荣幸的是能与 Google、 UC以及腾讯合作,一起推动国内Web与浏览器生态的发展。

多页应用、 Vue.js、 PWA?

对于构建一个希望达到原生应用级别体验的PWA,目前社区里的主流做法都是采用SPA,即单页面应用模型(Single-page App)来组织整个Web应用,业内最有名的几个PWA案例Twitter Lite、 Flipkart Lite、Housing Go 与 Polymer Shop无一例外。

然而饿了么,与很多国内的电商网站一样,青睐多页面应用模型(MPA, Multi-page App)所能带来的一些好处,也因此在一年多前就将移动站从基于AngularJS的单页应用重构为目前的多页应用模型。团队最看重的优点莫过于页面与页面之间的隔离与解耦,这使得我们可以将每个页面当做一个独立的“微服务”来看待,这些服务可以被独立迭代,独立提供给各种第三方的入口嵌入,甚至被不同的团队独立维护。而整个网站则只是各种服务的集合而非一个巨大的整体。

与此同时,我们仍然依赖 Vue.js作为JavaScript框架。 Vue.js除了是React、 AngularJS这种“重型武器”的竞争对手外,其轻量与高性能的优点使得它同样可以作为传统多页应用开发中流行的“jQuery/Zepto/Kissy+模板引擎”技术栈的完美替代。 Vue.js提供的组件系统、声明式与响应式编程更是提升了代码组织、共享、数据流控制、渲染等各个环节的开发效率。 Vue 还是一个渐进式框架,如果网站的复杂度继续提升,我们可以按需、增量地引入Vuex或Vue-Router这些模块。万一哪天又要改回单页呢?(谁知道呢……)

2017年, PWA已经成为Web应用新的风潮。我们决定试试,以我们现有的“Vue.js+多页”架构,能在升级PWA的道路上走多远,达到怎样的效果。

实现“PRPL”模式

“PRPL”(读作“purple”)是Google工程师提出的一种Web应用架构模式,它旨在利用现代Web平台的新技术以大幅优化移动Web的性能与体验,对如何组织与设计高性能的PWA系统提供了一种高层次的抽象。我们并不准备从头重构我们的Web应用,不过我们可以把实现“PRPL”模式作为我们的迁移目标。“PRPL”实际上是“Push/Preload、 Render、 Precache、 Lazy-Load”的缩写,我们接下来会展开介绍它们的具体含义。

Push/Preload,推送/预加载初始URL路由所需的关键资源

无论是HTTP2 Server Push还是,其关键都在于,我们希望提前请求一些隐藏在应用依赖关系(Dependency Graph)较深处的资源,以节省HTTP往返、浏览器解析文档,或脚本执行的时间。比如说,对于一个基于路由进行code splitting的SPA,如果我们可以在Webpack清单、路由等入口代码(entry chunks)被下载与运行之前就把初始URL,即用户访问的入口URL路由所依赖的代码用Server Push推送或进行提前加载。那么当这些资源被真正请求时,它们可能已经下载好并存在缓存中了,这样就加快了初始路由所有依赖的就绪。

在多页应用中,每一个路由本来就只会请求这个路由所需要的资源,并且通常依赖也都比较扁平。饿了么移动站的大部分脚本依赖都是普通的 <script> 元素,因此他们可以在文档解析早期就被浏览器的preloader扫描出来并且开始请求,其效果其实与显式的是一致的,见图1所示。

图1 有无<link rel=“preload”>的效果对比
 
我们还将所有关键的静态资源都伺服在同一域名下(不再做域名散列),以更好地利用HTTP2带来的多路复用(Multiplexing)。同时,我们也在进行着对API进行Server Push的实验。

Render,渲染初始路由,尽快让应用可被交互

既然所有初始路由的依赖都已经就绪,我们就可以尽快开始初始路由的渲染,这有助于提升应用诸如首次渲染时间、可交互时间等指标。多页应用并不使用基于JavaScript的路由,而是传统的HTML跳转机制,所以对于这一部分,多页应用其实不用额外做什么。

Precache,用Service Worker预缓存剩下的路由

这一部分就需要Service Worker的参与了。Service Worker是一个位于浏览器与网络之间的客户端代理,它已可拦截、处理、响应流经的HTTP请求,使得开发者得以从缓存中向Web应用提供资源而闻名。不过, Service Worker其实也可以主动发起 HTTP 请求,在“后台”预请求与预缓存我们未来所需要的资源,见图2所示。

图2 Service Worker预缓存未来所需要的资源
 
我们已经使用Webpack在构建过程中进行.vue编译、文件名哈希等工作,于是我们编写了一个Webpack插件来帮助收集需要缓存的依赖到一个“预缓存清单”中,并使用这个清单在每次构建时生成新的Service Worker文件。在新的Service Worker被激活时,清单里的资源就会被请求与缓存,这其实与SW-Precache 这个库的运行机制非常接近。

实际上,我们只对标记为“关键路由”的路由进行依赖收集。你可以将这些“关键路由”的依赖理解为我们整个应用的“App Shell” 或者说“安装包”。一旦它们都被缓存,或者说成功安装,无论用户是在线离线,我们的Web应用都可以从缓存中直接启动。对于那些并不那么重要的路由,我们则采取在运行时增量缓存的方式。我们使用的SW-Toolbox提供了LRU替换策略与TTL失效机制,可以保证我们的应用不会超过浏览器的缓存配额。

Lazy-Load,按需懒加载、懒实例化剩下的路由

懒加载与懒实例化剩下的路由对于SPA是一件相对麻烦点儿的事情,你需要实现基于路由的code splitting与异步加载。幸运的是,这又是一件不需要多页应用担心的事情,多页应用中的各个路由天生就是分离的。

值得说明的是,无论单页还是多页应用,如果在上一步中,我们已经将这些路由的资源都预先下载与缓存好了,那么懒加载就几乎是瞬时完成的了,这时候我们就只需要付出实例化的代价。

至此,我们对PRPL的四部分含义做了详细说明。有趣的是,我们发现多页应用在实现PRPL这件事甚至比单页还要容易一些。那么结果如何呢?

根据Google推出的Web性能分析工具Lighthouse(v1.6),在模拟的3G网络下,用户的初次访问(无任何缓存)大约在2秒左右达到“可交互”,可以说非常不错,见图3所示。而对于再次访问,由于所有资源都直接来自于Service Worker缓存,页面可以在1秒左右就达到可交互的状态了。
 
图3 Lighthouse跑分结果
 
但是,故事并不是这么简单得就结束了。在实际体验中我们发现,应用在页与页的切换时,仍然存在着非常明显的白屏空隙,见图4所示。由于PWA是全屏运行,白屏对用户体验所带来的负面影响甚至比以往在浏览器内更大。我们不是已经用Service Worker缓存了所有资源了吗,怎么还会这样呢?

图4 从首页点击到发现页,跳转过程中的白屏
 
多页应用的陷阱:重启开销

与SPA不同,在多页应用中,路由的切换是原生的浏览器文档跳转(Navigating across documents),这意味着之前的页面会被完全丢弃而浏览器需要为下一个路由的页面重新执行所有的启动步骤:重新下载资源、重新解析HTML、重新运行JavaScript、重新解码图片、重新布局页面、重新绘制……即使其中的很多步骤本是可以在多个路由之间复用的。这些工作无疑将产生巨大的计算开销,也因此需要付出相当多的时间成本。

图5中为我们的入口页(同时也是最重要的页面)在两倍CPU节流模拟下的Profile数据。即使我们可以将“可交互时间”控制在 1 秒左右,我们的用户仍然会觉得这对于“仅仅切换个标签”来说实在是太慢了。

图5 入口页在两倍CPU节流模拟下的Profile数据

巨大的JavaScript重启开销

根据Profile,我们发现在首次渲染(First Paint)发生之前,大量的时间(900ms)都消耗在了JavaScript的运行上(Evaluate Script)。几乎所有脚本都是阻塞的(Parser-blocking),不过因为所有的UI都是由JavaScript/Vue.js驱动的,倒也不会有性能影响。这900ms中,约一半是消耗在Vue.js运行时、组件、库等依赖的运行上,而另一半则花在了业务组件实例化时Vue.js的启动与渲染上。从软件工程角度来说,我们需要这些抽象,所以这里并不是想责怪JavaScript或是Vue.js所带来的开销。

但是,在SPA中, JavaScript的启动成本是均摊到整个生命周期的:每个脚本都只需要被解析与编译一次,诸如生成Virtual DOM等较重的任务可以只执行一次,像Vue.js的ViewModel或是Virtual DOM这样的大对象也可以被留在内存里复用。可惜在多页应用里就不是这样了,我们每次切换页面都为JavaScript付出了巨大的重启代价。

浏览器的缓存啊,能不能帮帮忙?

能,也不能。

V8提供了代码缓存(code caching),可以将编译后的机器码在本地拷贝一份,这样我们就可以在下次请求同一个脚本时一次省略掉请求、解析、编译的所有工作。而且,对于缓存在Service Worker配套的Cache Storage中的脚本,会在第一次执行后就触发V8的代码缓存,这对于我们的多页切换能提供不少帮助。

另外一个你或许听过的浏览器缓存叫做“进退缓存”, Back-Forward Cache,简称bfcache。浏览器厂商对其的命名各异, Opera称之为Fast History Navigation, Webkit称其为Page Cache。但是思路都一样,就是我们可以让浏览器在跳转时把前一页留存在内存中,保留JavaScript与DOM的状态,而不是全都销毁掉。你可以随便找个传统的多页网站在iOS Safari上试试,无论是通过浏览器的前进后退按钮、手势,还是通过超链接(会有一些不同),基本都可以看到瞬间加载的效果。

Bfcache其实非常适合多页应用。但不幸的是,Chrome由于内存开销与其多进程架构等原因目前并不支持。 Chrome现阶段仅仅只是用了传统的HTTP磁盘缓存,来稍稍简化了一下加载过程而已。对于Chromium内核霸占的Android生态来说,我们没法指望了。

为“感知体验”奋斗

尽管多页应用面临着现实中的不少性能问题,我们并不想这么快就妥协。一方面,我们尝试尽可能减少在页面达到可交互时间前的代码执行量,比如减少/推迟一些依赖脚本的执行,还有减少初次渲染的DOM节点数以节省Virtual DOM的初始化开销。另一方面,我们也意识到应用在感知体验上还有更多的优化空间。

Chrome产品经理Owen写过一篇Reactive Web Design: The secret to building web apps that feel amazing,谈到两种改进感知体验的手段:一是使用骨架屏(Skeleton Screen)来实现瞬间加载;二是预先定义好元素的尺寸来保证加载的稳定。跟我们的做法可以说不谋而合。

为了消除白屏时间,我们同样引入了尺寸稳定的骨架屏来帮助我们实现瞬间的加载与占位。即使是在硬件很弱的设备上,我们也可以在点击切换标签后立刻渲染出目标路由的骨架屏,以保证UI是稳定、连续、有响应的。我录了两个视频放在Youtube上,不过如果你是国内读者,你可以直接访问饿了么移动网站来体验实地的效果。最终效果如图6所示。
 
为“感知体验”奋斗

尽管多页应用面临着现实中的不少性能问题,我们并不想这么快就妥协。一方面,我们尝试尽可能减少在页面达到可交互时间前的代码执行量,比如减少/推迟一些依赖脚本的执行,还有减少初次渲染的DOM节点数以节省Virtual DOM的初始化开销。另一方面,我们也意识到应用在感知体验上还有更多的优化空间。

Chrome产品经理Owen写过一篇Reactive Web Design: The secret to building web apps that feel amazing,谈到两种改进感知体验的手段:一是使用骨架屏(Skeleton Screen)来实现瞬间加载;二是预先定义好元素的尺寸来保证加载的稳定。跟我们的做法可以说不谋而合。

为了消除白屏时间,我们同样引入了尺寸稳定的骨架屏来帮助我们实现瞬间的加载与占位。即使是在硬件很弱的设备上,我们也可以在点击切换标签后立刻渲染出目标路由的骨架屏,以保证UI是稳定、连续、有响应的。我录了两个视频放在Youtube上,不过如果你是国内读者,你可以直接访问饿了么移动网站来体验实地的效果。最终效果如图6所示。
图6 在添加骨架屏后,从发现页点回首页的效果

这效果本该很轻松的就能实现,不过实际上我们还费了点功夫。

在构建时使用 Vue 预渲染骨架屏

你可能已经想到了,为了让骨架屏可以被Service Worker缓存,瞬间加载并独立于JavaScript渲染,我们需要把组成骨架屏的HTML标签、 CSS样式与图片资源一并内联至各个路由的静态*.html文件中。

不过,我们并不准备手动编写这些骨架屏。你想啊,如果每次真实组件有迭代(每一个路由对我们来说都是一个Vue.js组件),我们都需要手动去同步每一个变化到骨架屏的话,那实在是太繁琐且难以维护了。好在,骨架屏不过是当数据还未加载进来前,页面的一个空白版本而已。如果我们能将骨架屏实现为真实组件的一个特殊状态——“空状态”的话,从理论上就可以从真实组件中直接渲染出骨架屏来。

而Vue.js的多才多艺就在这时体现出来了,我们真的可以用Vue.js 的服务端渲染模块来实现这个想法,不过不是用在真正的服务器上,而是在构建时用它把组件的空状态预先渲染成字符串并注入到HTML模板中。你需要调整Vue.js组件代码使得它可以在Node上执行,有些页面对DOM/BOM的依赖一时无法轻易去除得,我们目前只好额外编写一个*.shell.vue来暂时绕过这个问题。

关于浏览器的绘制(Painting)

HTML文件中有标签并不意味着这些标签就能立刻被绘制到屏幕上,你必须保证页面的关键渲染路径是为此优化的。很多开发者相信将Script标签放在body的底部就足以保证内容能在脚本执行之前被绘制,这对于能渲染不完整DOM树的浏览器(比如桌面浏览器常见的流式渲染)来说可能是成立的。但移动端的浏览器很可能因为考虑到较慢的硬件、电量消耗等因素并不这么做。不仅如此,即使你曾被告知设为async或defer的脚本就不会阻塞HTML解析了,但这可不意味着浏览 器就一定会在执行它们之前进行渲染。

首先我想澄清的是,根据 HTML 规范 Scripting 章节, async脚本是在其请求完成后立刻运行的,因此它本来就可能阻塞到解析。只有defer(且非内联)与最新的type=module被指定为“一定不会阻塞解析”(不过defer目前也有点小问题……我们稍后会再提到),见图7所示。
图7 具有不同属性的Script脚本对HTML解析的阻塞情况

而更重要的是,一个不阻塞HTML解析的脚本仍然可能阻塞到绘制。我做了一个简化的“最小多页PWA”(Minimal Multi-page PWA,或MMPWA)来测试这个问题:我们在一个async(且确实不阻塞HTML解析)脚本中,生成并渲染1000个列表项,然后测试骨架屏能否在脚本执行之前渲染出来。图8是通过USB Debugging在我的Nexus 5真机上录制的Profile。


图8 通过USB Debugging在Nexus 5真机上录制的Profile

是的,出乎意料吗?首次渲染确实被阻塞到脚本执行结束后才发生。究其原因,如果我们在浏览器还未完成上一次绘制工作之前就过快得进行了DOM操作,我们亲爱的浏览器就只好抛弃所有它已经完成的像素,且一直要等待到DOM操作引起的所有工作结束之后才能重新进行下一次渲染。而这种情况更容易在拥有较慢CPU/GPU的移动设备上出现。

黑魔法:利用setTimeout()让绘制提前

不难发现,骨架屏的绘制与脚本执行实际是一个竞态。大概是Vue.js太快了,我们的骨架屏还是有非常大的概率绘制不出来。于是我们想着如何能让脚本执行慢点,或者说,“懒”点。于是我们想到了一个经典的Hack: setTimeout(callback, 0)。我们试着把MMPWA中的DOM操作(渲染1000个列表)放进setTimeout(callback, 0)里……

当当!首次渲染瞬间就被提前了,见图9所示。如果你熟悉浏览器的事件循环模型(Event Loop)的话,这招Hack其实是通过setTimeout的回调把DOM操作放到了事件循环的任务队列中以避免它在当前循环执行,这样浏览器就得以在主线程空闲时喘息一下(更新一下渲染)了。如果你想亲手试试 MMPWA的话,你可以访问github.com/Huxpro/mmpwa 或huangxuan.me/mmpwa/ ,查看代码与Demo。我把UI设计成了A/B Test的形式并改为渲染5000个列表项来让效果更夸张一些。

图9 利用Hack技术,提前完成骨架屏的绘制

回到饿了么PWA上,我们同样试着把new Vue()放到了setTimeout中。果然,黑魔法再次显灵,骨架屏在每次跳转后都能立刻被渲染。这时的Profile看起来是这样的,见图10所示。

 
图10 为感知体验进行各种优化后的最终Profile

现在,我们在400ms时触发首次渲染(骨架屏),在600ms时完成真实UI的渲染并达到页面的可交互。你可以详细对比下图9和图10所示的优化前后Profile的区别。

被我“defer”的有关defer的Bug

不知道你发现没有,在图10的Profile中,我们仍然有不少脚本是阻塞了HTML解析的。好吧,让我解释一下,由于历史原因,我们确实保留了一部分的阻塞脚本,比如侵入性很强的lib-flexible,我们没法轻易去除它。不过, Profile里的大部分阻塞脚本实际上都设置了defer,我们本以为他们应该在HTML解析完成之后才被执行,结果被Profile打了一脸。

我和Jake Archibald 聊了一下,果然这是Chrome的Bug: defer的脚本被完全缓存时,并没有遵守规范等待解析结束,反而阻塞了解析与渲染。Jake已经提交在crbug上了,一起给它投票吧。

最后,图11是优化后的Lighthouse跑分结果,同样可以看到明显的性能提升。需要说明的是,能影响Lighthouse跑分的因素有很多,所以我建议你以控制变量(跑分用的设备、跑分时的网络环境等)的方式来进行对照实验。

图11 优化后的Lighthouse跑分结果

最后为大家展示下应用的架构示意图,见图12所示。

图12 应用架构示意图

一些感想

多页应用仍然有很长的路要走

Web是一个极其多样化的平台。从静态的博客,到电商网站,再到桌面级的生产力软件,它们全都是Web这个大家庭的第一公民。而我们组织Web应用的方式,也同样只会更多而不会更少:多页、单页、 Universal JavaScript应用、 WebGL,以及可以预见的Web Assembly。不同的技术之间没有贵贱,但是适用场景的差距确是客观存在的。

Jake 曾在 Chrome Dev Summit 2016 上说过“PWA!== SPA”。可是尽管我们已经用上了一系列最新的技术(PRPL、 Service Worker、 App Shell……),我们仍然因为多页应用模型本身的缺陷有着难以逾越的一些障碍。多页应用在未来可能会有“bfcache API”、 Navigation Transition等新的规范以缩小跟SPA的距离,不过我们也必须承认,时至今日,多页应用的局限性也是非常明显的。

而PWA终将带领Web应用进入新的时代

即使我们的多页应用在升级PWA的路上不如单页应用来得那么闪亮,但是PWA背后的想法与技术却实实在在地帮助我们在Web平台上提供了更好的用户体验。

PWA作为下一代 Web 应用模型,其尝试解决的是Web平台本身的根本性问题:对网络与浏览器UI的硬依赖。因此,任何Web应用都可以从中获益,这与你是多页还是单页、面向桌面还是移动端、是用React还是Vue.js无关。或许,它还终将改变用户对移动Web的期待。现如今,谁还觉得桌面端的Web只是个看文档的地方呢?

还是那句老话,让我们的用户,也像我们这般热爱Web吧。

最后,感谢饿了么的王亦斯、任光辉、题叶,Google 的 Michael Yeung、 DevRel 团队, UC浏览器团队,腾讯X5浏览器团队在这次项目中的合作。感谢尤雨溪、陈蒙迪和Jake Archibald 在写作过程中给予我的帮助。
 
原文阅读:https://zhuanlan.zhihu.com/p/27836133

奇葩字符 "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎" 的简单分析

zkbhj 发表了文章 • 0 个评论 • 291 次浏览 • 2018-01-26 09:57 • 来自相关话题

这个其实之前火过一阵子,当时也没怎么注意,今天看到空间里又有人在刷这个字符了,所以决定分析下他是什么东西。
复制这个字符在控制台查看 "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".length 发现他的长度是 20,怎么会是20呢?
我们依次调试  "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".charAt(0), "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".charAt(1), "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".charAt(2)  可以发现第一个字符是a 后面都是其他什么东西组成的。

当你黏贴到notepad++之类的编辑器里,也会发现这个问题,后台那些是重复的字符,而且都可以看到。
这些字符到底是什么东西呢?

突然想起js圣经上貌似记载过一个 é 字符,他的 unicode 是 \u00e9, 但是也可以用 'e' + '\u0301' 实现 "é" 前者 length 是 1,后者 length 是 2。'\u0301' 在这里起到了语调符的作用,然后我就丧心病狂的  'e'+Array(20).join('\u0301');  发现竟然成功了,果然是这个东西,但是这个语调符有哪些呢。
继续寻找答案,在圣经的注释里发现了他貌似属于 Mn 类,去unicode官方找这个东西,一番寻找后终于找到他了,详情请参阅。

这里解释了 Mn 其实是 a nonspacing combining mark (zero advance width) (谷歌翻译: 一个非空格组合标志(零超前宽度))。
虽然给了解释,但是还是没有说他有那些字符啊,所以我继续寻找答案,功夫不负有心人,终于找到了一张表。
Unicode Characters in the 'Mark, Nonspacing' Category 
这里详细的列出了每个编码以及对应的意思,还有图片展现。你可以点击头部那个 View all images 超链接,这样你就不必一个一个展开看图片了。

找到这个的时候我欣喜诺狂,各种测试,发现不仅仅是向上,还有 向左,向下的,但是暂时没发现向右的。
这里面有很多符号,虽然不知道他们在什么情况下使用,但是我的目的达到了,后续的东西暂时没欲望刨根问底了。

下面是我找的几个方向的小尾巴,大家也可以自己去各种测试起来。。
 
'呵呵'+Array(20).join('\u0310');  // "呵呵̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐"
 '呵呵'+Array(20).join('\u031D');             // "呵呵̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝"
 '呵呵'+Array(20).join('\u0E47');                          // "呵呵็็็็็็็็็็็็็็็็็็็"
 '呵呵'+Array(20).join('\u0e49');                                       // "呵呵้้้้้้้้้้้้้้้้้้้"
 '呵呵'+Array(20).join('\u0598');        // "呵呵֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘"
 
也可以这么玩...

 '呵呵'+Array(20).join('\u0310')+Array(20).join('\u0598')+Array(20).join('\u0e49');  // "呵呵้้้้้้้้้้้้้้้้้้้̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘" 查看全部
这个其实之前火过一阵子,当时也没怎么注意,今天看到空间里又有人在刷这个字符了,所以决定分析下他是什么东西。
复制这个字符在控制台查看 "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".length 发现他的长度是 20,怎么会是20呢?
我们依次调试  "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".charAt(0), "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".charAt(1), "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".charAt(2)  可以发现第一个字符是a 后面都是其他什么东西组成的。

当你黏贴到notepad++之类的编辑器里,也会发现这个问题,后台那些是重复的字符,而且都可以看到。
这些字符到底是什么东西呢?

突然想起js圣经上貌似记载过一个 é 字符,他的 unicode 是 \u00e9, 但是也可以用 'e' + '\u0301' 实现 "é" 前者 length 是 1,后者 length 是 2。'\u0301' 在这里起到了语调符的作用,然后我就丧心病狂的  'e'+Array(20).join('\u0301');  发现竟然成功了,果然是这个东西,但是这个语调符有哪些呢。
继续寻找答案,在圣经的注释里发现了他貌似属于 Mn 类,去unicode官方找这个东西,一番寻找后终于找到他了,详情请参阅

这里解释了 Mn 其实是 a nonspacing combining mark (zero advance width) (谷歌翻译: 一个非空格组合标志(零超前宽度))。
虽然给了解释,但是还是没有说他有那些字符啊,所以我继续寻找答案,功夫不负有心人,终于找到了一张表。
Unicode Characters in the 'Mark, Nonspacing' Category 
这里详细的列出了每个编码以及对应的意思,还有图片展现。你可以点击头部那个 View all images 超链接,这样你就不必一个一个展开看图片了。

找到这个的时候我欣喜诺狂,各种测试,发现不仅仅是向上,还有 向左,向下的,但是暂时没发现向右的。
这里面有很多符号,虽然不知道他们在什么情况下使用,但是我的目的达到了,后续的东西暂时没欲望刨根问底了。

下面是我找的几个方向的小尾巴,大家也可以自己去各种测试起来。。
 
'呵呵'+Array(20).join('\u0310');  // "呵呵̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐"
 '呵呵'+Array(20).join('\u031D');             // "呵呵̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝"
 '呵呵'+Array(20).join('\u0E47');                          // "呵呵็็็็็็็็็็็็็็็็็็็"
 '呵呵'+Array(20).join('\u0e49');                                       // "呵呵้้้้้้้้้้้้้้้้้้้"
 '呵呵'+Array(20).join('\u0598');        // "呵呵֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘"
 
也可以这么玩...

 '呵呵'+Array(20).join('\u0310')+Array(20).join('\u0598')+Array(20).join('\u0e49');  // "呵呵้้้้้้้้้้้้้้้้้้้̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘"

JSON传输二进制数据

zkbhj 发表了文章 • 0 个评论 • 276 次浏览 • 2018-01-11 12:25 • 来自相关话题

json 是一种很简洁的协议,但可惜的是,它只能传递基本的数型(int,long,string等),但不能传递byte类型。如果想要传输图片等二进制文件的话,是没办法直接传输。

本文提供一种思路给大家参考,让大家可以在json传输二进制文件,如果大家有这个需求又不知怎么实现的话,也许本文能够帮到你。思想适用于所有语言,本文以java实现,相信大家很容易就能转化为自己懂得语言。
 
思路

1. 读取二进制文件到内存

2. 用Gzip压缩一下。毕竟是在网络传输嘛,当然你也可以不压缩。

3. 用Base64 把byte[] 转成字符串
 
补充:什么是Base64

以下摘自阮一峰博客,Base64的具体编码方式,大家可以直接进入。

Base64是一种编码方式,它可以将8位的非英语字符转化为7位的ASCII字符。这样的初衷,是为了满足电子邮件中不能直接使用非ASCII码字符的规定,但是也有其他重要的意义:
 

a)所有的二进制文件,都可以因此转化为可打印的文本编码,使用文本软件进行编辑;

b)能够对文本进行简单的加密。

 
实现

主要思路就是以上3步,把字符串添加到json字段后发给服务端,然后服务器再用Base64解密–>Gzip解压,就能得到原始的二进制文件了。是不是很简单呢?说了不少,下面我们来看看具体的代码实现。/**
* @author xing
*/
public class TestBase64 {
public static void main(String[] args) {
byte[] data = compress(loadFile());

String json = new String(Base64.encodeBase64(data));
System.out.println("data length:" + json.length());
}

/**
* 加载本地文件,并转换为byte数组
* @return
*/
public static byte[] loadFile() {
File file = new File("d:/11.jpg");

FileInputStream fis = null;
ByteArrayOutputStream baos = null;
byte[] data = null ;

try {
fis = new FileInputStream(file);
baos = new ByteArrayOutputStream((int) file.length());

byte[] buffer = new byte[1024];
int len = -1;
while ((len = fis.read(buffer)) != -1) {
baos.write(buffer, 0, len);
}

data = baos.toByteArray() ;

} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if (fis != null) {
fis.close();
fis = null;
}

baos.close() ;
} catch (IOException e) {
e.printStackTrace();
}
}

return data ;
}

/**
* 对byte[]进行压缩
*
* @param 要压缩的数据
* @return 压缩后的数据
*/
public static byte[] compress(byte[] data) {
System.out.println("before:" + data.length);

GZIPOutputStream gzip = null ;
ByteArrayOutputStream baos = null ;
byte[] newData = null ;

try {
baos = new ByteArrayOutputStream() ;
gzip = new GZIPOutputStream(baos);

gzip.write(data);
gzip.finish();
gzip.flush();

newData = baos.toByteArray() ;
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
gzip.close();
baos.close() ;
} catch (IOException e) {
e.printStackTrace();
}
}

System.out.println("after:" + newData.length);
return newData ;
}
} 最后输出了一下字符串长度,大家也许觉得经过压缩也没降低多少体积嘛。但大家可以试试不用gzip,你会发现经过转换的字符串比原来大多了。没办法,这是由Base64的算法决定的。所以嘛,还是压缩一下好。

本文所使用的方法比较简单,大家如果有更好或者觉得有更好的方式,不妨一起探讨一下。
 
【服务端传输】
 
我们都知道json是文本格式.所以我马上想到的是把文件编码成文本,再进行传输. 所以关键就是要把一个二进制文件翻译成文本,再翻译回去.如果可以,也就代表这个方案是可行的. 马上我就写出了第一个版本: 
// 读取文件
FileInputStream fileInputStream = new FileInputStream("d:/a.png");
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
int i;
while ((i = fileInputStream.read()) != -1) {
byteArrayOutputStream.write(i);
}
fileInputStream.close();
// 把文件存在一个字节数组中
byte[] filea = byteArrayOutputStream.toByteArray();
byteArrayOutputStream.close();

String fileaString = new String(filea);
System.out.println(fileaString);
// 写入文件
FileOutputStream fileOutputStream = new FileOutputStream("d:/b.png");
fileOutputStream.write(fileaString.getBytes());
fileOutputStream.flush();
fileOutputStream.close();
发现b.png根本无法打开,很是奇怪?而且大小也不一样了. 检查代码后发现把数组转化成string的时候后面还可以加个参数charset[编码名称]. 

于是马上改了一下: .......
String fileaString = new String(filea,"uft-8");
.......
fileOutputStream.write(fileaString.getBytes("utf-8"));
结果还是不行,又改了一下: .......
String fileaString = new String(filea,"ISO-8859-1");
.......
fileOutputStream.write(fileaString.getBytes("ISO-8859-1"));
结果成功了. 

结合以前的编码知识,总算是想明白了:
把字节数组转换成字符串时,如果charset为空,那就表示用你的默认编码进行转换. 
而不管gb2312和utf8都不是用单字节表示一个字符的.只要他不认识的,他就会默认转换成一个特定字符,所以这样的转换是不可逆的. 
只有像ascii这样的单字节编码的转换才是可逆的. 
明白了这个道理.我们就可以用json协议来传任何的数据了.^_^,大功告成! 

有关编码的问题我推荐阮一峰的一篇博文,对字符编码有很好的解释. 
http://www.ruanyifeng.com/blog ... .html 
  查看全部
json 是一种很简洁的协议,但可惜的是,它只能传递基本的数型(int,long,string等),但不能传递byte类型。如果想要传输图片等二进制文件的话,是没办法直接传输。

本文提供一种思路给大家参考,让大家可以在json传输二进制文件,如果大家有这个需求又不知怎么实现的话,也许本文能够帮到你。思想适用于所有语言,本文以java实现,相信大家很容易就能转化为自己懂得语言。
 
思路

1. 读取二进制文件到内存

2. 用Gzip压缩一下。毕竟是在网络传输嘛,当然你也可以不压缩。

3. 用Base64 把byte[] 转成字符串
 
补充:什么是Base64

以下摘自阮一峰博客,Base64的具体编码方式,大家可以直接进入

Base64是一种编码方式,它可以将8位的非英语字符转化为7位的ASCII字符。这样的初衷,是为了满足电子邮件中不能直接使用非ASCII码字符的规定,但是也有其他重要的意义:
 


a)所有的二进制文件,都可以因此转化为可打印的文本编码,使用文本软件进行编辑;

b)能够对文本进行简单的加密。


 
实现

主要思路就是以上3步,把字符串添加到json字段后发给服务端,然后服务器再用Base64解密–>Gzip解压,就能得到原始的二进制文件了。是不是很简单呢?说了不少,下面我们来看看具体的代码实现。
/** 
* @author xing
*/
public class TestBase64 {
public static void main(String[] args) {
byte[] data = compress(loadFile());

String json = new String(Base64.encodeBase64(data));
System.out.println("data length:" + json.length());
}

/**
* 加载本地文件,并转换为byte数组
* @return
*/
public static byte[] loadFile() {
File file = new File("d:/11.jpg");

FileInputStream fis = null;
ByteArrayOutputStream baos = null;
byte[] data = null ;

try {
fis = new FileInputStream(file);
baos = new ByteArrayOutputStream((int) file.length());

byte[] buffer = new byte[1024];
int len = -1;
while ((len = fis.read(buffer)) != -1) {
baos.write(buffer, 0, len);
}

data = baos.toByteArray() ;

} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if (fis != null) {
fis.close();
fis = null;
}

baos.close() ;
} catch (IOException e) {
e.printStackTrace();
}
}

return data ;
}

/**
* 对byte[]进行压缩
*
* @param 要压缩的数据
* @return 压缩后的数据
*/
public static byte[] compress(byte[] data) {
System.out.println("before:" + data.length);

GZIPOutputStream gzip = null ;
ByteArrayOutputStream baos = null ;
byte[] newData = null ;

try {
baos = new ByteArrayOutputStream() ;
gzip = new GZIPOutputStream(baos);

gzip.write(data);
gzip.finish();
gzip.flush();

newData = baos.toByteArray() ;
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
gzip.close();
baos.close() ;
} catch (IOException e) {
e.printStackTrace();
}
}

System.out.println("after:" + newData.length);
return newData ;
}
}
最后输出了一下字符串长度,大家也许觉得经过压缩也没降低多少体积嘛。但大家可以试试不用gzip,你会发现经过转换的字符串比原来大多了。没办法,这是由Base64的算法决定的。所以嘛,还是压缩一下好。

本文所使用的方法比较简单,大家如果有更好或者觉得有更好的方式,不妨一起探讨一下。
 
【服务端传输】
 
我们都知道json是文本格式.所以我马上想到的是把文件编码成文本,再进行传输. 所以关键就是要把一个二进制文件翻译成文本,再翻译回去.如果可以,也就代表这个方案是可行的. 马上我就写出了第一个版本: 
		// 读取文件
FileInputStream fileInputStream = new FileInputStream("d:/a.png");
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
int i;
while ((i = fileInputStream.read()) != -1) {
byteArrayOutputStream.write(i);
}
fileInputStream.close();
// 把文件存在一个字节数组中
byte[] filea = byteArrayOutputStream.toByteArray();
byteArrayOutputStream.close();

String fileaString = new String(filea);
System.out.println(fileaString);
// 写入文件
FileOutputStream fileOutputStream = new FileOutputStream("d:/b.png");
fileOutputStream.write(fileaString.getBytes());
fileOutputStream.flush();
fileOutputStream.close();
发现b.png根本无法打开,很是奇怪?而且大小也不一样了. 检查代码后发现把数组转化成string的时候后面还可以加个参数charset[编码名称]. 

于是马上改了一下: 
....... 
String fileaString = new String(filea,"uft-8");
.......
fileOutputStream.write(fileaString.getBytes("utf-8"));

结果还是不行,又改了一下: 
....... 
String fileaString = new String(filea,"ISO-8859-1");
.......
fileOutputStream.write(fileaString.getBytes("ISO-8859-1"));

结果成功了. 

结合以前的编码知识,总算是想明白了:
把字节数组转换成字符串时,如果charset为空,那就表示用你的默认编码进行转换. 
而不管gb2312和utf8都不是用单字节表示一个字符的.只要他不认识的,他就会默认转换成一个特定字符,所以这样的转换是不可逆的. 
只有像ascii这样的单字节编码的转换才是可逆的. 
明白了这个道理.我们就可以用json协议来传任何的数据了.^_^,大功告成! 

有关编码的问题我推荐阮一峰的一篇博文,对字符编码有很好的解释. 
http://www.ruanyifeng.com/blog ... .html 
 

如何分清JSON解析什么时候该用JSONObject,什么时候该用JSONArray?

回复

zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 306 次浏览 • 2017-12-26 12:54 • 来自相关话题