欧美日韩一区二区综合观看在线下载播放

前端開發(發) | 9個月前

2014 年，W3C 發(發)布了信標（Beacon）的(de)標準草案最(zui)終征求意見稿(gao)（目前已(yi)經是候選推(tui)薦草案）。該規范定義了一(yi)個異步非阻(zu)塞的數據上(shang)報接口，可以(yi)最大限度地(di)減少對其他關鍵操(cao)作的資源占(zhan)用，同時保證(證)請求能正常(chang)發出。同年，該接口就被引(yin)入了 Firefox 和(he) Chrome，即 navigator.sendBeacon（下文簡稱為 sendBeacon）。

在實際開發(發)工作中，該接(jie)口最常見的(de)使用場景就(jiu)是數據埋點(點)。與其他埋點(點)技術方案相(xiang)比，sendBeacon 的優勢在于：

不會跟業務代碼(碼)搶占資源，而(er)是在瀏覽器(qi)空閑的時候(hou)再去發送；
在(zai)頁面卸載（關(關)閉、刷新、跳轉）時也能(neng)保證請求發(發)送(song)，同時不阻塞(sai)頁面卸載。

第(di)一個主角——sendBeacon

sendBeacon 的(de)方法原型非(fei)常簡單：

navigator.sendBeacon(url, data);

在 Web 應用的運(運)行時實現多(duo)分支并存和(he)切換

前端開(開)發 | 1年前

背景(jing)

一般來說，SaaS 服(fu)務商提供的(de)是標準化的(de)產品服(fu)務，體現的是(shi)所有客戶的(de)共性需求。然而(er)，部分客戶（尤(you)其是大客戶），會提出功能(neng)、UI 等方面的定(ding)制需求(qiu)。針對這些定(ding)制需求，大體(體)上(shang)有(you)兩個解(jie)決方案。

第一(yi)個方案是提(ti)供應用程序(xu) SDK，由客戶的開(開)發團隊完成整個定(ding)制應用的開(開)發和部署，SaaS 服(fu)務商提供必(bi)要的技術支持(chi)即可。此方案(an)要求客戶的(de)開發團(團)隊具備較強的 IT 專業能力(li)。

第二個方案(an)則是由 SaaS 服務商的開發團(團)隊在 SaaS 應用的(de)基礎上進行(xing)二次開發，并部署。此(ci)方案主要面(mian)向 IT 專業能力(li)較弱，或者僅(僅)需在 SaaS 應用的基礎上進行(xing)少(shao)量定制的客(ke)戶。然而，要支持這種(種)定制方式，相(xiang)當于要求 SaaS 服(fu)務商在同一(yi)個應用中，針對不同的客(ke)戶運行不同(tong)分支的代碼(碼)。要達到(dao)這個目的，應用程序的架(jia)構也要進行(xing)相應的改造(zao)。本文主要講(講)述改造的方(fang)案及其代碼實現。

方案(an)概覽

對于前(qian)后端分離的(de)項目來說，經過構建(jian)，最終會生成 html、js、css 三種代(dai)碼文件。以基(ji)于 Vue.js 框架的項目為例(li)，其構建出來的 index.html，內容與下(xia)面的代碼相(xiang)似：

<!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>

實際上，index.html 只(zhi)是訪問入口(kou)，主要作用就(jiu)是加載 css 和 js 資(資)源。換句(ju)話說：任何的 html 頁面，只要加載(載)了上述 css 和 js 資(資)源，都可以運(運)行這個應用(yong)。

User agent 那些事兒

前端開(開)發 | 2年前

User agent（下文(wen)簡稱 ua），也就是(shi)用戶代理，指的(de)是代表用(yong)戶行為的程(cheng)序（軟件代理(li)程序）。例如，網(網)頁瀏覽器就是一個“幫助用戶獲(獲)取、渲染網頁內容并與之交(jiao)互”的用戶代(dai)理。

瀏覽器

當用戶代理通(tong)過網絡協議進行操(cao)作時，它通常(chang)會向網絡上(shang)的協作端（比(bi)如服務器端(duan)）提(ti)交(jiao)一個特定的字(zi)符串來標識自己。這(這)段字符(fu)串就是用戶代理字符串(chuan)（下文簡稱 ua 串(chuan)）。當我們用瀏覽(覽)器訪問 Web 應用(yong)的時候，瀏覽(覽)器會把自己(ji)的 ua 串加(jia)到 HTTP 請求的 User-Agent 頭(頭)字段進行傳輸。

UA 串的發展(zhan)史

1990 年，Tim Berners-Lee 編寫了第一個瀏覽(覽)器 WorldWideWeb，后來改名(ming)為 Nexus。但是，Nexus 只支(zhi)持文字(zi)展示。

1993 年，美國 NCSA 組織開發了(le) Mosaic 瀏覽器，能支持圖片的展(zhan)示使其成為第一(yi)款流行的瀏(瀏)覽器。

這時候(hou)問題就(jiu)來了，Nexus 不支持(chi)圖片展示，而(er) Mosaic 是支持的。作(zuo)為開發人員(員)，該怎么編寫頁面代碼呢(ne)？這時候 ua 串就(jiu)可以發揮作用了，開(開)發人員僅需(xu)針對 Mosaic ua 串(chuan)的請求輸出圖片(pian)展示相關的(de)代碼即可。Mosaic 的(de) ua 串樣本如下：

NCSA_Mosaic/1.0 (Windows 3.1)

其(qi)中 NCSA_Mosaic/1.0 為瀏覽器代號及(ji)其版本號，Windows 3.1 為操作系統及(ji)其版本號。

隨(隨)后，1994 年，Mosaic 團隊的(de)領導者 Marc Andreessen 辭職并(bing)成(cheng)立了自(zi)己的公司——Netscape，并開發了(le) Netscape Navigator 瀏覽器。它的(de)內部代號為「Mozilla」，ua 串樣本如下(xia)：

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

Netscape Navigator 的市場占有(you)率一度達到(dao) 90%，并且最先支(zhi)持了框架（frame）特(te)性。開發人(ren)員為了區別(別)這兩個瀏覽(覽)器，還是用的(de) ua 串(chuan)識(識)別這個方式。如(ru)果 ua 串中(zhong)瀏覽器代號為 Mozilla，那就發送(song)包含框(kuang)架的頁面，否(fou)則，就發送不(bu)含框架的頁面。

再后來，1995 年(nian)，微軟推出了(le) Internet Explorer（下文簡稱 IE）。IE 也(ye)支持框架，但因(yin)為過去的框架代(dai)碼都是針對 Mozilla 這(這)個代號發送(song)的，這樣一來，IE 即使支持框(kuang)架，也收不到(dao)包含框架的(de)代碼。讓所有的開發(發)人員把自己(ji)的代碼都改(gai)一遍明顯不(bu)現實，最后 IE 只(zhi)好“自稱” Mozilla，同時在(zai) ua 串(chuan)的其他(ta)位置增加自己的代(dai)號 MSIE。它的 ua 串樣本如下：

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

IE 在瀏覽(覽)器市場中逐(zhu)漸成為了霸(ba)主，敗北的 Netscape Navigator 另(ling)起爐灶，開發(發)了 Firefox。無論是 IE、Netscape Navigator 還是 Firefox，ua 串都(dou)以 Mozilla 代號開(開)頭。這也幾乎成為了瀏覽器 ua 串(chuan)事實上的格(ge)式標準：

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

時至(zhi)今日，ua 串承載(載)的內容越來越多，開(開)發人員識別(別)起來的難度(du)也越來越高(gao)了。

彈幕實現(現)原理

前端開(開)發 | 3年(nian)前

直播(bo)是眼下(xia)最為火爆的(de)行業，而彈幕(mu)無疑是直播(bo)平臺中最流(liu)行、最重要的(de)功能之一。本(ben)文將講述如(ru)何實現(現)兼容 PC 瀏覽器(qi)和移動瀏覽(覽)器的彈幕。

基(ji)本功能

并發(發)與隊列

一般(ban)來說，彈幕數據會通過異步(bu)請求或(huo) socket 消(xiao)息(xi)傳到前端，這里(li)會存在(zai)一個隱患——數據量可能非(fei)常大。如果一(yi)收到彈幕數據就馬上渲(xuan)染出來，在量大的時(時)候：

顯示區域(yu)不足以放置(zhi)這么多的彈幕，彈幕會堆(dui)疊在一起；
渲(xuan)染過程會占用(yong)大量 CPU 資(資)源，導致頁面(mian)卡頓。

所以在接收和渲染(ran)數據之間，要(yao)引入隊列做(zuo)緩沖。把收到(dao)的彈幕數據都存入數組（即下文(wen)代碼中的 this._queue），再(zai)通過輪詢該數組，把彈幕(mu)逐條渲染出(chu)來：

class Danmaku {
  // 省略 N 行代(dai)碼...

  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;
    }
  }

  // 省略 N 行代碼...
}

保(bao)護(護) Node.js 項目的源代(dai)碼

Node.js開發 | 4年前(qian)

SaaS（Software as a Service，軟件即服務），是一種通過(過)互聯網提供(gong)軟件服務的(de)模式。服務提供(gong)商會全權負責軟件(jian)服務的搭建(jian)、維護和管理(li)，使得他們的(de)客戶從這些(xie)繁瑣的工作(zuo)中解放出來。對于許(許)多中小型企(qi)業而言，SaaS 是采用(yong)先進技術的(de)最好途徑。

然(ran)而，對于大型(xing)企業而言，情(qing)況有所不同(tong)。出于產(產)品定制、功能(neng)穩定(ding)以及掌(zhang)握自身數據資產等方面(mian)的考慮，即使(shi)成本增加，他(ta)們也更樂意(yi)把相關服務部署在(zai)企業自己的(de)硬件設備上(shang)，也就是常說的(de)私有化部署(shu)。

在私有化部(bu)署的過程中(zhong)，服務提供商首先要(yao)確保自己的(de)源代碼不被(bei)泄露，否(fou)則產品就可以隨(隨)意復制和更(geng)改，得不償失(shi)。傳統的后端運行環(環)境，如 Java、.NET，其源代(dai)碼是經過編譯才部署到(dao)服務器上運(運)行(xing)的，不存在泄(xie)露的風險。而(er)對于應用越來越廣(廣)泛的 Node.js 而言，運(運)行的則是源(yuan)代碼。即使經過壓縮混淆(xiao)，也(ye)可(ke)以很大程度地(di)還原。

本(ben)文介紹一種(種)可用于(yu) Node.js 端的代碼保(bao)護方案，使得(de) Node.js 項目也可以(yi)放心地進行(xing)私有化部署(shu)。

工作經歷（七）-貝聊篇

工作生活 | 4年(nian)前

離開上家(jia)公司后，我接(jie)受邀請加入(ru)了當時主打(da)家園（家長、幼(you)兒園）溝通的(de)貝聊。雖然是創業公(gong)司，但貝聊已經有一定的用(yong)戶規模和知(zhi)名度。更重要(yao)的是，公司愿(yuan)景與幼教行(xing)業的健康(kang)發展相符，因(yin)此也具備一(yi)定的社會價(價)值。

貝聊 2017 年會

X5同層播放(fang)器應用實踐(踐)

前端開發 | 5年前

移動端瀏覽器中(zhong)的video元素是比(bi)較特別的，早(zao)期無論是在(zai)iOS還是Android的瀏覽(覽)器中，它都位(wei)于頁面的最頂層，無(無)法被遮擋。后來，這個問題在(zai)iOS下得到了解(jie)決。但是對Android的(de)大部分瀏覽(覽)器來說，問題仍然存在(zai)。X5是騰(騰)訊基于(yu)Webkit開發的瀏覽(覽)器內核，應用(yong)于Android端的微信(xin)、QQ、QQ瀏覽器等應用。它提供了(le)一種名叫「同(tong)層播放器」的特(te)殊video元素以解決遮(zhe)擋問題。

簡單使(shi)用

只要給普(pu)通的video元素加(jia)上X5的自定義(義)屬性 x5-video-player-type ，就可以(yi)調用同層播(bo)放器。示(shi)例代碼如下(xia)：

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

<div class="player qw7a1-q814g-q5rr4-q2yme">
    <video id="video" class="video q21x4-qf0n9-qf9a5-q7m28" controls="controls" playsinline x5-video-player-type="h5">
        <source src="video.mp4" />
    </video>
</div>

打造一份(fen)網頁版簡歷(歷)

前端開發 | 5年(nian)前

多年前，因(yin)為換工作的(de)需要，我(wo)得更新簡歷(歷)。但可能是寫慣了CSS的緣故(gu)，在Word中排版(ban)實在是(shi)各種不順手(shou)，于是就發揮(揮)了作為前端(duan)工程師的優勢，把簡歷做成了網(網)頁。久而久之(zhi)，這份簡歷就(jiu)成為了我的(de)個人產品，無論是否需要(yao)再找工作，每隔一段(duan)時間我都會進行更新迭(die)代。

網頁版簡歷有以下這(這)些好處：

無須下(xia)載，直接打開(開)；
內容展示形式更豐(豐)富，排版更靈(靈)活；
可以展示(shi)自己的技術(術)能力；
可以通過超(chao)鏈接(jie)訪問外部資源（如(ru)個人作品）；
可(ke)以讓自(zi)己登上搜索(suo)引擎的榜單（SEO）。

在此基礎上(shang)，我還給這份(fen)簡歷定下了(le)一個重要目(mu)標——「Write once, run anywhere」。兼容PC、手機和(he)平板設(設)備，還可以通(tong)過瀏覽器直(zhi)接打(da)印。

本文將從技術角(jiao)度描述這樣一份簡歷的(de)開發過程。

設(設)計

說到(dao)設計，很多程(cheng)序員會喊：“我(wo)是寫代碼的(de)，不懂設計。”但俗(su)話說得好(hao)：沒吃過豬肉(rou)，總見過豬跑(pao)吧。平時看(kan)過這么多網(網)頁，還跟大量(liang)產品設計稿(gao)打交道。看到(dao)布局合適的(de)，抄一下；看到(dao)配色合適的(de)，抄(chao)一(yi)下；看到(dao)素材(cai)合適(適)的，也抄一下(xia)。值得注意的(de)是，近年來有(you)一類頁面特(te)別適合改造(zao)成個人簡歷(歷)，那就是手機廠商每(mei)發布一款新手(shou)機都會做的(de)手機宣傳頁。我自己的簡歷設計就是(shi)借鑒了iPhone的宣(xuan)傳頁。

在微信小程(cheng)序中渲染HTML內容

前端開發(發) | 5年前

大部分(fen)Web應用的富文(wen)本內容都是(shi)以HTML字符串的(de)形式存(cun)儲的，通過HTML文(wen)檔去展示HTML內容自然沒有問題。但是，在(zai)微信小程序（下文(wen)簡稱為「小程(cheng)序」）中，應當如(ru)何渲染(ran)這部分內容(rong)呢？

解決方案(an)

wxParse

小程序剛上(shang)線那會兒，是(shi)無法直接渲(xuan)染HTML內容的，于(yu)是就誕生了(le)一個叫(jiao)做「wxParse」的庫。它的(de)原理就是把(ba)HTML代碼解析成(cheng)樹結構的數據，再(zai)通(tong)過小程序的模(mo)板把該數據渲染出(chu)來。

rich-text

后來，小程序增加(jia)了「rich-text」組件用于(yu)展示富文本(ben)內容。然而，這(這)個組件存在(zai)一個極大的(de)限制：組(組)件內屏蔽了所有節點的(de)事件。也就是(shi)說，在該組件(jian)內，連「預覽圖(圖)片」這樣一個簡單的功能都(dou)無法實現。

web-view

再(zai)后來，小程序允許通(tong)過「web-view」組件嵌套(tao)網頁，通過網(網)頁展示HTML內容(rong)是兼容性最(zui)好的解決方(fang)案了。然而，因(yin)為要多加載(載)一個頁面，性能是較(較)差的。

小(xiao)動畫大學問

前端(duan)開發 | 5年前

對于移動端的(de)Web單頁應用來說(說)，為了達(達)到媲美原生(sheng)應用的效果(guo)，頁面過渡動畫是必不可(ke)少的。常用的(de)頁面過渡動畫包括：

位移(yi)——當前頁向左側或右(you)側水平移出(chu)可視區，下一(yi)頁由反方向(xiang)移入可視區(區)。
不透明度變化——當前頁淡(dan)出，下一(yi)頁淡入。
1和2同時(時)進行。

（注意：以下討論和實驗均在 Chrome 68 瀏覽器(qi)環境下進行(xing)）

目前大多數設備的屏幕(mu)刷新率(lu)為60次/秒，算下(xia)來每個幀的(de)預算時間約(約)為16.66毫秒（1/60秒）。考慮到瀏覽器(qi)還有其他工(gong)作要執行，實際上預算時間只有(you)10毫秒。跟此預(預)算時間的差值(zhi)越大，用戶就(jiu)會覺得動畫過程越卡。那么，在這(這)10毫秒內要完成什么事情呢(ne)？當使用JavaScript實現(現)視覺交互效(xiao)果時，一般要(yao)經過以下流(liu)程：

JavaScript視覺交互執行流程