1. 前言
为了最大限度地保证同一浏览器同一域名下各个网页的用户统一,Web JS SDK 需要及时地将用户标识存入到 Cookie;
为了最大限度地减少关闭页面导致的数据丢失,Web JS SDK 将采集的数据存入到 localStorage 里进行批量发送,关闭页面未发送完的数据下次打开页面再次发送;
为了最大限度地保证可视化全埋点和网页热力图窗口打开的正确性,Web JS SDK 将相关的标识存入到 sessionStorage 里。
由此可见,存储数据是 Web JS SDK 的核心功能,下面逐一给大家介绍这三种存储方式。
2. 存储方式
2.1. Cookie
Cookie 实际上是一小段的文本信息(key-value 格式)。客户端向服务端发起请求,如果服务端需要记录该用户的状态,就使用 response 向客户端浏览器颁发一个 Cookie。如图 2-1 所示:
图 2-1 服务端使用 response 向客户端浏览器颁发一个 Cookie
客户端浏览器会把 Cookie 保存起来,当浏览器再次请求该网站时,浏览器把请求的网址连同 Cookie 一起提交给服务端。服务端检查该 Cookie,以此来辨认用户状态。如图 2-2 所示:
图 2-2 浏览器把 Cookie 提交给服务端
Web JS SDK 中使用 Cookie 功能主要是用来存储前端变量。每当同一台设备通过浏览器请求集成 Web JS SDK 的页面时,就会读取已经保存的 Cookie 值。
2.2. localStorage
localStorage 用于持久化的本地存储,没有过期时间。除非主动删除数据,否则数据是永远不会过期的。
localStorage 提供的存储也是基于字符串的键值对。可以通过 setItem()、getItem() 来访问其中的存储项。
2.3. sessionStorage
用于本地存储一个会话(session)中的数据,这些数据只有在同一个会话中的页面才能访问,并且当会话结束后数据也随之销毁。
因此,sessionStorage 不是一种持久化的本地存储,仅仅是会话级别的存储。浏览器网页关闭时,对应的 sessionStorage 就会被清空。
2.4. 三者的区别
三种存储方式的区别如表 2-1 所示:
Cookie |
localStorage |
sessionStorage |
|
---|---|---|---|
应用场景 | 浏览器和服务端来回传递。 |
不会自动把数据发送给服务端,用于本地持久保存。 |
不会自动把数据发送给服务端,用于本地同一会话保存。 |
存储大小 | 数据大小不能超过 4K。 因为每次 http 请求都会携带 Cookie,所以 Cookie 只适合保存很小的数据。 |
数据大小可以在 5M 以上。 保存的数据超出了浏览器所规定的大小,不会清空旧数据只会报错。但是,在移动端浏览器和 App 的 WebView 里是不可靠的,可能会因为内存不足或网络切换被清空。 |
数据大小可以在 5M 以上。 保存的数据超出了浏览器所规定的大小,不会清空旧数据只会报错,但在移动端浏览器和 app 的 Webview 里是不可靠的,可能会因为内存不足或网络切换被清空。 |
数据有效期 | 只在设置的过期时间之前有效,即使窗口或浏览器关闭。 |
不管浏览器关闭与否,数据永久保存。 |
只在当前浏览器关闭之前有效。 |
作用域 | 数据在所有同源窗口中都是共享的。 |
同源窗口共享(相同协议、域名、端口号)。 | 在不同浏览器窗口不共享,即使是同一个页面。 |
兼容性 | 兼容性最强。 | 低版本浏览器不支持。 | 低版本浏览器不支持。 |
表 2-1 三种存储方式的区别
3. Web JS SDK 中不同存储方式的应用场景
3.1. Cookie 的应用场景
SDK 初始化时从 Cookie 中读取用户标识,没有用户标识就生成新的 UUID,将新的 UUID 存储到浏览器 Cookie 中。
首次加载页面,Cookie 中无用户信息,将新生成的 UUID 保存到 Cookie 中。代码如下:
|
首次加载集成 Web JS SDK 的页面,浏览器中 Cookie 的用户信息如图 3-1 所示:
图 3-1 浏览器中 Cookie 的用户信息
调用 sensors.login() 实现用户关联,将登录 ID 存储到 Cookie 中。distinct_id 为登录 ID,first_id 为匿名 ID。代码如下:
|