成全视频在线观看免费观看第7季

9个月前

2014 年(nian)，W3C 发布了(le)信标（Beacon）的标准草(cao)案最终征求(qiu)意见稿（目前(qian)已经是候选(xuan)推荐草案）。该(gai)规范定义了(le)一个异步非(fei)阻塞的(de)数据上报接(jie)口，可以最大(da)限度地减少(shao)对其他关键(jian)操作的资源(yuan)占用，同时保(bao)证请求能正(zheng)常发出(chu)。同年，该接口(kou)就被引入了(le) Firefox 和 Chrome，即 navigator.sendBeacon（下文(wen)简称为 sendBeacon）。

在实际开发(fa)工作中，该接(jie)口最常见的(de)使用场景就(jiu)是数据(ju)埋点。与其他(ta)埋点技术方(fang)案相比，sendBeacon 的优(you)势在于：

不会(hui)跟业务代码(ma)抢占资源，而(er)是在浏览器(qi)空闲的时候再去发(fa)送；
在页面卸(xie)载（关闭、刷新(xin)、跳转）时也能保(bao)证请求发送(song)，同时不阻塞(sai)页面卸载。

第(di)一个主角——sendBeacon

sendBeacon 的方法原型非常简单(dan)：

navigator.sendBeacon(url, data);

在 Web 应用的(de)运行时实现(xian)多分支并存(cun)和切换

1年前(qian)

背景

一般来说，SaaS 服务(wu)商提供的是(shi)标准化的产(chan)品服务，体现(xian)的是所有客(ke)户的共性需求(qiu)。然而，部分客(ke)户（尤其是大客户），会(hui)提出功能、UI 等(deng)方面的定制(zhi)需求。针对这(zhe)些定制(zhi)需求，大体上有两(liang)个解决方案(an)。

第一个方案(an)是提供(gong)应用程序 SDK，由(you)客户的开发(fa)团队完成整(zheng)个定制应用(yong)的开发和部(bu)署，SaaS 服务商提(ti)供(gong)必要的技术(shu)支持即(ji)可。此方案要(yao)求客户的开(kai)发团队具备(bei)较强的 IT 专业(ye)能力。

第二个(ge)方案则是由(you) SaaS 服务商的开(kai)发团队(dui)在 SaaS 应用的基(ji)础上进行二(er)次开发，并部(bu)署。此方案主(zhu)要面向 IT 专业(ye)能力较弱，或者仅需在 SaaS 应(ying)用的基础上(shang)进行少量定(ding)制的客户。然(ran)而，要支持这(zhe)种定制方式(shi)，相当于要求(qiu) SaaS 服务商在同(tong)一个应用中(zhong)，针对不同的客户运(yun)行不同分支(zhi)的代码。要达(da)到这个目的(de)，应用程序的(de)架构也要进(jin)行相应的改(gai)造。本文主要(yao)讲述改(gai)造的方案及其(qi)代码实现。

方(fang)案概览

对于(yu)前后端分离(li)的项目来说(shuo)，经过构建，最(zui)终会生成 html、js、css 三(san)种代码(ma)文件。以基于(yu) Vue.js 框架的项目(mu)为例，其构建(jian)出来的 index.html，内容(rong)与下面的代(dai)码相似：

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <link href="https://cdn.my-app.net/sample/assets/css/chunk-0c7134a2.11fa7980.css" rel="prefetch">
  <link href="https://cdn.my-app.net/sample/assets/js/chunk-0c7134a2.02a43289.js" rel="prefetch">
  <link href="https://cdn.my-app.net/sample/assets/css/app.2dd9bc59.css" rel="preload" as="style">
  <link href="https://cdn.my-app.net/sample/assets/js/vendors~app.f1dba939.js" rel="preload" as="script">
  <link href="https://cdn.my-app.net/sample/assets/js/app.f7eb55ca.js" rel="preload" as="script">
  <link href="https://cdn.my-app.net/sample/assets/css/app.2dd9bc59.css" rel="stylesheet">
 </head>
 <body>
   <div id="app"></div>
   <script src="https://cdn.my-app.net/sample/assets/js/vendors~app.f1dba939.js"></script>
   <script src="https://cdn.my-app.net/sample/assets/js/app.f7eb55ca.js"></script>
 </body>
 </html>

实际(ji)上，index.html 只是访问(wen)入口，主(zhu)要作用就是(shi)加载 css 和 js 资源。换(huan)句话说：任何(he)的 html 页面，只要(yao)加载了上述(shu) css 和 js 资源，都可(ke)以运行这个(ge)应用。

User agent 那些事儿

2年(nian)前

User agent（下文简(jian)称 ua），也就是用户代(dai)理，指的是代(dai)表用户行为(wei)的程序（软件(jian)代理程(cheng)序）。例如，网页(ye)浏览器就是(shi)一个“帮助用(yong)户获取、渲染(ran)网(wang)页内容并与(yu)之交互”的用(yong)户代理。

浏览(lan)器(qi)

当(dang)用户代理通过(guo)网络协议进(jin)行操作时，它(ta)通常会向网(wang)络上的协作(zuo)端（比如服务(wu)器端）提交一(yi)个特定的字符串来(lai)标识自己。这(zhe)段字符串就(jiu)是用户代理(li)字符串（下文(wen)简称 ua 串）。当我们(men)用浏览器访(fang)问 Web 应用的时候，浏览器会把自(zi)己的 ua 串加到 HTTP 请求(qiu)的 User-Agent 头字段进(jin)行传输。

UA 串的(de)发展史

1990 年，Tim Berners-Lee 编(bian)写了第一个(ge)浏览器 WorldWideWeb，后来(lai)改名为(wei) Nexus。但是，Nexus 只支持(chi)文字展示。

1993 年(nian)，美国 NCSA 组织开(kai)发了 Mosaic 浏览器(qi)，能支持图片(pian)的展示使其(qi)成为第一款流(liu)行的浏(liu)览器。

这时候(hou)问题就来了(le)，Nexus 不支持图片(pian)展示，而 Mosaic 是支(zhi)持的。作(zuo)为开发人员，该怎(zen)么编写页面(mian)代码呢(ne)？这时候 ua 串就(jiu)可以发挥作(zuo)用了，开发人(ren)员仅需针对(dui) Mosaic ua 串的请求输(shu)出图片展示(shi)相关的代码(ma)即可。Mosaic 的 ua 串样本如下：

NCSA_Mosaic/1.0 (Windows 3.1)

其(qi)中 NCSA_Mosaic/1.0 为浏览器代号(hao)及其(qi)版本(ben)号，Windows 3.1 为操作系(xi)统及其版本(ben)号。

随后，1994 年，Mosaic 团(tuan)队的领导者(zhe) Marc Andreessen 辞职并成立了自己(ji)的公司——Netscape，并开(kai)发了 Netscape Navigator 浏览器(qi)。它的内部代(dai)号为「Mozilla」，ua 串(chuan)样本如下：

Mozilla/4.5 (compatible; HTTrack 3.0x; Windows 98)

Netscape Navigator 的市场(chang)占有率一度(du)达到 90%，并且最先支持(chi)了框架（frame）特性(xing)。开(kai)发人员为了(le)区别这两个(ge)浏览器，还是(shi)用的 ua 串识别(bie)这个方式。如(ru)果 ua 串中浏览(lan)器代号(hao)为 Mozilla，那就发送(song)包含框架的(de)页面，否则，就(jiu)发送不含框(kuang)架的页面。

再(zai)后来，1995 年，微软(ruan)推出了 Internet Explorer（下文(wen)简称 IE）。IE 也(ye)支持框架，但(dan)因为过去的(de)框架代码都是(shi)针对 Mozilla 这个代号发(fa)送的(de)，这样(yang)一来，IE 即使支(zhi)持框架，也收(shou)不到包(bao)含框架的代(dai)码。让所有的(de)开发人员把(ba)自己的代码(ma)都改一遍明(ming)显不现实，最(zui)后 IE 只好“自称(chen)” Mozilla，同时在(zai) ua 串的其他位(wei)置增加自己(ji)的代号 MSIE。它的 ua 串(chuan)样(yang)本如下(xia)：

Mozilla/4.0 (compatible; MSIE 1.0; Windows 3.11)

IE 在浏览器市场(chang)中逐渐成为(wei)了霸主，败北(bei)的 Netscape Navigator 另起(qi)炉灶，开发了(le) Firefox。无论是 IE、Netscape Navigator 还是(shi) Firefox，ua 串都以 Mozilla 代号(hao)开头。这也几乎成(cheng)为了(le)浏览(lan)器 ua 串事实上(shang)的格式标准(zhun)：

Mozilla/[version] ([system and browser information]) [platform] ([platform details]) [extensions]

时至今日，ua 串承载的(de)内容越来越(yue)多，开发人员(yuan)识别起来的(de)难度也越来(lai)越高了。

弹幕(mu)实现原理

3年前

直播(bo)是眼下最为(wei)火爆的行业(ye)，而弹幕无疑(yi)是直播平台(tai)中最流行、最(zui)重要的功能(neng)之一。本文将(jiang)讲述如(ru)何实现兼容(rong) PC 浏览器和移(yi)动浏览器的(de)弹幕。

基本功(gong)能

并发与队(dui)列

一般来说(shuo)，弹幕数据会通(tong)过异步(bu)请求或 socket 消息(xi)传(chuan)到(dao)前端，这(zhe)里会存在一(yi)个隐患——数据(ju)量可能非常(chang)大。如果一收(shou)到弹幕数据(ju)就马上(shang)渲染出来，在(zai)量大的时候(hou)：

显示区域不(bu)足以放置这(zhe)么多的弹幕(mu)，弹幕会堆叠(die)在一起；
渲染(ran)过程会(hui)占用大量 CPU 资源(yuan)，导(dao)致(zhi)页面卡顿。

所以(yi)在接收(shou)和渲染数据(ju)之间，要引入(ru)队列做缓冲(chong)。把收到的弹(tan)幕数据都存入数组(zu)（即下文代码(ma)中的 this._queue），再通过(guo)轮询该数组(zu)，把弹幕逐条(tiao)渲染出来：

class Danmaku {
  // 省(sheng)略 N 行代码...

  add(data) {
    this._queue.push(this._parseData(data));
    if (!this._renderTimer) { this._render(); }
  }

  _render() {
    try {
      this._renderToDOM();
    } finally {
      this._renderEnd();
    }
  }

  _renderEnd() {
    if (this._queue.length > 0) {
      this._renderTimer = setTimeout(() => {
        this._render();
      }, this._renderInterval);
    } else {
      this._renderTimer = null;
    }
  }

  // 省略(lue) N 行代码...
}

X5同层播(bo)放器应用实践(jian)

5年前

移动端(duan)浏览器中的(de)video元素是比较(jiao)特别的，早期(qi)无论是在iOS还是Android的浏览器中，它都(dou)位于页面的(de)最顶层，无法(fa)被遮挡。后来(lai)，这个问题在(zai)iOS下得到了解(jie)决。但是对Android的(de)大部分(fen)浏览器来说(shuo)，问(wen)题(ti)仍然(ran)存在。X5是腾(teng)讯基于(yu)Webkit开发的浏览器(qi)内核，应用于(yu)Android端的微信、QQ、QQ浏(liu)览器等应用(yong)。它提供(gong)了一种名叫(jiao)「同层播放器(qi)」的特殊video元素(su)以(yi)解(jie)决遮挡(dang)问题。

简单使(shi)用

只要给普(pu)通的video元素加(jia)上X5的自(zi)定义属性 x5-video-player-type ，就(jiu)可以调用同(tong)层播放器。示(shi)例代码如下(xia)：

body {
margin: 0;
background: #000;
}
.video {
width: 100%;
}

<div class="player r4lzo-rz5ap-r52w9-r1fy7">
    <video id="video" class="video rq59q-r6006-rz3nq-r04mo" controls="controls" playsinline x5-video-player-type="h5">
        <source src="video.mp4" />
    </video>
</div>

打(da)造(zao)一份网页版简(jian)历

5年前(qian)

多年前(qian)，因为换工作(zuo)的需要，我得(de)更新简历。但(dan)可能是写惯(guan)了CSS的缘故，在(zai)Word中排版实在(zai)是各种不顺(shun)手，于是就(jiu)发(fa)挥了作(zuo)为前端工程(cheng)师的优势，把(ba)简历做成了(le)网页。久而久(jiu)之，这份简历(li)就成为了我的(de)个人产品，无论是否(fou)需要再找工(gong)作，每隔一段(duan)时间我都会(hui)进行更新迭(die)代。

网页版简(jian)历有以下这(zhe)些好处：

无须下载，直接(jie)打开；
内容(rong)展示形式更(geng)丰富，排版更(geng)灵活；
可以展(zhan)示自己的技(ji)术能力；
可以(yi)通过超链接(jie)访问外部(bu)资源（如个人(ren)作品）；
可以让(rang)自己登上搜(sou)索引擎的榜(bang)单（SEO）。

在此基础(chu)上，我还给这(zhe)份简历定下(xia)了一个(ge)重要目标——「Write once, run anywhere」。兼容PC、手机(ji)和平(ping)板设备，还可以(yi)通过浏览器(qi)直接打印。

本(ben)文将从技术(shu)角度描述这(zhe)样一份(fen)简历的开发(fa)过程。

设计

说到(dao)设计，很多程(cheng)序员会喊：“我是写代码的(de)，不懂设计。”但(dan)俗话说得好(hao)：没吃过(guo)猪肉，总见过(guo)猪跑吧。平时(shi)看过这么多(duo)网页，还跟大(da)量产品设计(ji)稿打交道。看(kan)到布局合适(shi)的，抄一下；看到配色合适的，抄一(yi)下；看到素材合(he)适的，也抄一(yi)下。值得注意(yi)的是，近年来(lai)有一类页面(mian)特别适合改造成个(ge)人简历，那就(jiu)是手机厂商(shang)每发布一款(kuan)新手机都会(hui)做的手机宣(xuan)传页。我自己的简(jian)历设(she)计就(jiu)是借鉴(jian)了iPhone的宣传页(ye)。

在微信小(xiao)程序中渲染HTML内(nei)容

5年前

大部(bu)分Web应(ying)用的富文本内容都(dou)是以HTML字(zi)符串的形式(shi)存储的，通过(guo)HTML文档去展示(shi)HTML内容自然没(mei)有问题。但是(shi)，在微信小程(cheng)序（下文简称(chen)为「小程(cheng)序」）中，应当(dang)如何渲染这部分(fen)内容呢？

解决(jue)方案

wxParse

小程序(xu)刚上线那会(hui)儿，是无法直接(jie)渲染HTML内容的(de)，于是就(jiu)诞生了一个(ge)叫做「wxParse」的库。它的原理就是(shi)把HTML代码解析(xi)成树结构的(de)数据，再通过(guo)小程序的模(mo)板把该数据渲染出(chu)来。

rich-text

后来，小程(cheng)序增加了「rich-text」组(zu)件用于展示(shi)富文本内容(rong)。然而，这个组(zu)件存在一个极(ji)大的限制：组(zu)件内屏蔽了所有节(jie)点的事件。也(ye)就是说，在该(gai)组件内，连「预(yu)览图片」这样(yang)一个简单的(de)功能都无法实现。

web-view

再(zai)后来，小程序(xu)允许通过「web-view」组(zu)件嵌套网页(ye)，通(tong)过(guo)网页展示HTML内容(rong)是兼容(rong)性最好的解(jie)决方案了。然(ran)而，因为(wei)要(yao)多加载一个(ge)页面，性能是(shi)较差的。

小动画大学问(wen)

5年前

对于移(yi)动端的Web单页(ye)应用来(lai)说，为了达到(dao)媲美原生应(ying)用的效果，页(ye)面过渡动画(hua)是必不可少(shao)的。常用的页(ye)面过渡动画(hua)包括：

位(wei)移——当前页向左侧或右侧水(shui)平移出可视(shi)区，下一页由(you)反方向移入(ru)可视区。
不透(tou)明度变化——当(dang)前页淡(dan)出，下一页淡(dan)入。
1和2同时进(jin)行。

（注意：以下讨论和实验均在 Chrome 68 浏览器环(huan)境下进行）

目(mu)前大多数设(she)备的屏幕刷新率为(wei)60次/秒，算下来(lai)每个帧的预(yu)算时间约为16.66毫(hao)秒（1/60秒(miao)）。考虑到浏览器还有(you)其他工作要(yao)执行，实际上预算时(shi)间只有10毫秒(miao)。跟此预算时(shi)间的差值越(yue)大，用户就会(hui)觉得动画过(guo)程越卡。那么(me)，在这10毫秒内要(yao)完成(cheng)什么事情呢？当(dang)使用JavaScript实现视(shi)觉交互效果(guo)时，一般要经(jing)过(guo)以下流程：

JavaScript视(shi)觉交互执行(xing)流程

PWA初探

5年前

HTML 5 曾(ceng)被认为是移(yi)动应用的明(ming)天，却被原生(sheng)App在性能和功(gong)能上轻易战(zhan)胜，Web逐渐成为(wei)App的附属(shu)。然而，马云“爸(ba)爸”告诉我们(men)：“梦想还是要(yao)有的，万一实(shi)现了呢？”如今(jin)，我们离梦想又(you)近了一步。

PWA，全称「Progressive Web App」，是(shi)Google提出的为Web提供App般(ban)使用体验的(de)一系列技术(shu)方案。它优势(shi)主要体现在(zai)：

可在离(li)线或网络较差的(de)环境下(xia)正常打开页(ye)面。
安全（HTTPS）。
保持(chi)最新（及时更(geng)新）。
支持安装(zhuang)（添加到主屏(ping)幕）和消息推送。
向下兼容(rong)，在不支持(chi)相关技术的(de)浏览器中仍(reng)可正常访问(wen)。

本文将逐一(yi)讲述PWA涉及的(de)主要技术方(fang)案。

网页端「应用跳转(zhuan)」技术实现演(yan)变

5年前

由于(yu)网页传播的(de)便捷性，从网页(ye)向APP导流几(ji)乎是所有APP厂(chang)商都会采用(yong)的推广(guang)手段，具体来说(shuo)就是在网页(ye)上提供一些(xie)触发点（例如(ru)按钮、链接），用于跳(tiao)转到(dao)APP。

应用(yong)跳转