摘要：圖離線情況下發(fā)送微信消息，等網(wǎng)絡(luò)正常后微信會(huì)繼續(xù)處理我們的消息。無(wú)論是在微信中還是手機(jī)短信，在沒(méi)有信號(hào)時(shí)都不影響我們編輯發(fā)送短信，等網(wǎng)絡(luò)恢復(fù)時(shí)會(huì)自動(dòng)幫我們把之前編輯好的信息順利遞送出去。

（刪掉了第一小段，因?yàn)楹蛢?nèi)容關(guān)系不大。。）

本來(lái)這該是個(gè)技術(shù)分享會(huì)的內(nèi)容，參加完 Google Developer Day(GDD) 后想做個(gè) AI Demo 來(lái)分享，奈何技術(shù)實(shí)力不夠，害怕把大家?guī)нM(jìn)溝里，想想還是講比較擅長(zhǎng)的前端領(lǐng)域的比較靠譜。等哪天經(jīng)歷過(guò)人工智能相關(guān)項(xiàng)目后再分享也不遲。(分享會(huì)已經(jīng)開(kāi)過(guò)了，這是PPT)

圖：在 GDD 上海站圍觀 TensorFlow 與藝術(shù)分享會(huì)

Progressive Web Apps(PWA)指代那些使用最新的 Web 技術(shù)構(gòu)建的類(lèi)似原生 App 體驗(yàn)的 webapp，這也是今年前端最熱詞之一，雖然感覺(jué)說(shuō)來(lái)說(shuō)去就是為了一堆新技術(shù)取個(gè)名字，就像之前的 HTML5 一樣。不過(guò)，這些技術(shù)確確實(shí)實(shí)提高 Web 的用戶(hù)體驗(yàn)。

為此各大瀏覽器廠商都卯足了勁（我是說(shuō)除了Safari，連 IE 都在努力了啊喂?。?，這篇文章將從三個(gè)方面來(lái)講解這些技術(shù)：

可靠，即使網(wǎng)絡(luò)不穩(wěn)定也需要提供服務(wù)；

更快；

功能更豐富！

（恰好 PWA 也這么認(rèn)為）

這些都是為了讓 WebApp 能像 App 一樣提供沉浸式的用戶(hù)體驗(yàn)。

技術(shù)是為內(nèi)容服務(wù)的，單純的技術(shù)沒(méi)法讓我們爬到馬斯洛需求理論的更高層，但是技術(shù)一直在為實(shí)現(xiàn)它而努力。接下來(lái)將要介紹的就是2016年各大瀏覽器廠商為前端技術(shù)做出的努力。（本文不包括類(lèi)似 async 函數(shù)、Promise、以及 Websocket 之類(lèi)的一些“老技術(shù)”）

圖：只有Safari還在考慮是否實(shí)現(xiàn) Service worker，連 IE 都在努力你 Safari 憑啥不努力。。。

技術(shù)關(guān)鍵詞：Service Worker，Background Sync

相對(duì)于 App , Web 最痛的點(diǎn)在于如果網(wǎng)絡(luò)不靠譜，一切無(wú)從談起。打開(kāi)任何一個(gè)頁(yè)面，WebApp 都需要經(jīng)過(guò)下載、解析并初始化代碼、執(zhí)行路由邏輯跳轉(zhuǎn)到相應(yīng)頁(yè)面、請(qǐng)求網(wǎng)絡(luò)數(shù)據(jù)、渲染頁(yè)面...而性能瓶頸最容易出現(xiàn)在網(wǎng)絡(luò)部分。設(shè)想如果可以預(yù)先將網(wǎng)頁(yè)的外殼安裝到設(shè)備上，啟動(dòng)時(shí)從本地加載這層殼，并請(qǐng)求網(wǎng)絡(luò)獲取渲染需要的數(shù)據(jù)，甚至更極端一點(diǎn)，數(shù)據(jù)全存在本地磁盤(pán)，啟動(dòng)時(shí)優(yōu)先使用的本地已經(jīng)保存同步好的數(shù)據(jù)，保證即使在 Lie-Fi* 環(huán)境下也能提供正常服務(wù)。

注：Lie-Fi是比斷網(wǎng)更要命的移動(dòng)網(wǎng)絡(luò)。癥狀是手機(jī)告訴你你已經(jīng)聯(lián)網(wǎng)，但是網(wǎng)頁(yè)卻打不開(kāi)，甚至連“Chrome小恐龍”都不讓玩。

圖: 這就是那只“Chrome小恐龍”

在講 Service worker 之前，瀏覽器中已經(jīng)實(shí)現(xiàn)了一個(gè)類(lèi)似的功能，叫 AppCache ，AppCache 的運(yùn)行原理不復(fù)雜，就是在網(wǎng)頁(yè)加載完成后，瀏覽器閑下來(lái)的時(shí)下載一個(gè)清單文件，這個(gè)文件列明了哪些資源可以離線使用，哪些資源需要請(qǐng)求網(wǎng)絡(luò)，如果請(qǐng)求不到網(wǎng)絡(luò)該怎么辦等等。類(lèi)似一個(gè)配置清單。

圖：AppCache在首次啟動(dòng)頁(yè)面時(shí)緩存數(shù)據(jù)到磁盤(pán)，此后打開(kāi)的頁(yè)面如果有用到已緩存的資源則直接由緩存提供。

不過(guò)，HTTP 緩存在上古時(shí)期就實(shí)現(xiàn)了這個(gè)功能，看起來(lái)只是換了個(gè)馬甲。

的確，理論上 HTTP 緩存完全能實(shí)現(xiàn)這個(gè)功能，但實(shí)際卻不是這樣，由于瀏覽器廠商很多、版本也多，相互之間兼容性或多或少有些差異，如果某個(gè)瀏覽器對(duì)程序員的失誤容忍程度過(guò)低，很容易導(dǎo)致渲染出現(xiàn)問(wèn)題。類(lèi)似問(wèn)題也出現(xiàn)在 HTTP 請(qǐng)求上，如果瀏覽器嚴(yán)格按照請(qǐng)求頭的緩存控制規(guī)則來(lái)控制網(wǎng)絡(luò)請(qǐng)求，很容易導(dǎo)致頁(yè)面無(wú)法更新或者部分更新、新舊代碼混合的問(wèn)題。所以大部分瀏覽器傾向不完全相信 HTTP 請(qǐng)求頭。這也從另一個(gè)方面印證了“單一職責(zé)原則“的重要性（傳輸數(shù)據(jù)的就好好傳輸數(shù)據(jù)，別搶人家緩存的飯碗，你也搶不來(lái)。。）。

嗯，看起來(lái) AppCache 比 HTTP 緩存棒多了，功能強(qiáng)大而且單一職責(zé)，只要一份清單文件就能把資源都緩存起來(lái)離線訪問(wèn)。

但AppCache犯了比HTTP嚴(yán)重的多的錯(cuò)誤！

我們知道，AppCache的確是單一職責(zé)，意味著瀏覽器必須信任他，如果不相信那它存在的意義是什么？問(wèn)題在于，假設(shè)程序員犯了一個(gè)小錯(cuò)，一個(gè)匹配規(guī)則不小心匹配到了這個(gè)清單文件，你的代碼將永遠(yuǎn)都更新不了??！

代碼不小心犯?jìng)€(gè)錯(cuò)簡(jiǎn)直太正常不過(guò)了，就好像程序員需要吃飯睡覺(jué)上廁所一樣，程序員也需要會(huì)寫(xiě)bug。。

延伸閱讀：AppCache Issue is a Douchebag

好的，冷靜一下。。其實(shí)有個(gè)不完美的解決方案，通過(guò)腳本自動(dòng)生成緩存規(guī)則，具體可以參考 offline-plugin AppCache 部分的做法，但這樣 AppCache 的其他“好處”就完全體現(xiàn)無(wú)法體現(xiàn)出來(lái)！

這時(shí)候 Service worker 該登場(chǎng)了！簡(jiǎn)單來(lái)說(shuō)，Service worker 是一段運(yùn)行在頁(yè)面之外的一段腳本，這段腳本在啟動(dòng)時(shí)會(huì)注冊(cè)一些事件到瀏覽器中，當(dāng)事件觸發(fā)時(shí)可以通過(guò)預(yù)先定義好的 Javascript handler 控制如何響應(yīng)這個(gè)事件。

但為什么說(shuō) Service worker 比 AppCache 好呢？

首先 Service worker 應(yīng)該說(shuō)徹底解決了 AppCache 無(wú)法更新的問(wèn)題，在使用 Service worker 時(shí)，只要網(wǎng)絡(luò)暢通，瀏覽器都會(huì)嘗試在啟動(dòng)后檢查 Service worker 是否有更新，而且 Service worker 并不能截獲請(qǐng)求更新 Service worker 的事件，換句話說(shuō)就是無(wú)法緩存自身，也就是永遠(yuǎn)都有機(jī)會(huì)更新自己。

其次，Service Worker 通過(guò)事件機(jī)制配合 js 腳本來(lái)控制瀏覽器，并且脫離于頁(yè)面生存，這讓web終于有了“常駐”系統(tǒng)的機(jī)會(huì)！

這是技術(shù)上的一小步，但是卻給 web 的能力提供了無(wú)限的想象空間！

為了更好的理解什么是 Service Worker，我們可以把它想象成是生存于瀏覽器頁(yè)面中、頁(yè)面之外的動(dòng)態(tài)代理，當(dāng)類(lèi)似網(wǎng)絡(luò)請(qǐng)求之類(lèi)的事件觸發(fā)時(shí)，由這個(gè)代理決定如何處置這個(gè)事件。下面這個(gè)例子就是演示如何截獲并處理網(wǎng)絡(luò)請(qǐng)求的。

圖：瀏覽器向服務(wù)器發(fā)起請(qǐng)求前先被 Service worker 截獲，處理完成后再向遠(yuǎn)端服務(wù)器發(fā)起請(qǐng)求

這里有個(gè)小視頻，演示了如何通過(guò) Service worker “憑空捏造” 離線數(shù)據(jù)?。代碼在https://github.com/MofeLee/sw...

既然服務(wù)器沒(méi)有的數(shù)據(jù)都能造出來(lái)，離線訪問(wèn)數(shù)據(jù)豈不是輕而易舉？并且這個(gè)例子實(shí)際上只有幾行關(guān)鍵代碼????

一、 注冊(cè) service worker

navigator.serviceWorker.register("/sw.js")

二、 注冊(cè)響應(yīng)規(guī)則

self.addEventListener("fetch", function(event) {
  if (/offline-data$/.test(event.request.url)) {
    event.respondWith(
      new Response("這是一條來(lái)自service worker的響應(yīng)信息")
    );
  }
});

三、沒(méi)有第三步。。。

實(shí)際上現(xiàn)在已經(jīng)有很多網(wǎng)頁(yè)可以離線訪問(wèn)了，比如說(shuō)大名鼎鼎的lodash，如果想知道你平常訪問(wèn)的哪些網(wǎng)站是離線可訪問(wèn)的，可以在瀏覽器地址欄輸入 chrome://serviceworker-internals/ 查看~

圖：可以看到 https://lodash.com/ 是注冊(cè)了service worker 到chrome中的，試著打開(kāi)網(wǎng)址，稍微等下再斷網(wǎng)打開(kāi) https://lodash.com/ ~ Boom!

到目前為止，我們知道使用 Service Worker 可以解決在沒(méi)有網(wǎng)絡(luò)的情況加載應(yīng)用的場(chǎng)景，現(xiàn)在，我們?cè)O(shè)想另一種場(chǎng)景：在線聊天。

圖：離線情況下發(fā)送微信消息，等網(wǎng)絡(luò)正常后微信會(huì)繼續(xù)處理我們的消息。

無(wú)論是在微信中還是手機(jī)短信，在沒(méi)有信號(hào)時(shí)都不影響我們編輯發(fā)送短信，等網(wǎng)絡(luò)恢復(fù)時(shí) App 會(huì)自動(dòng)幫我們把之前編輯好的信息順利遞送出去。而移動(dòng)設(shè)備中的 webapp 體驗(yàn)卻糟糕透了，我們必須開(kāi)著網(wǎng)頁(yè)直到網(wǎng)絡(luò)恢復(fù)，以便發(fā)出我們的消息，假設(shè)這時(shí)候我們切換到其他App中，不但消息發(fā)不出去，很有可能連瀏覽器占用的資源都會(huì)被操作系統(tǒng)回收?。?/p>

問(wèn)題究竟出在哪？

仔細(xì)思考后會(huì)發(fā)現(xiàn)問(wèn)題出在網(wǎng)絡(luò)請(qǐng)求生命周期和頁(yè)面的生命周期耦合了，我們必須要找到一種方法能讓瀏覽器在關(guān)掉頁(yè)面后也能繼續(xù)為我們繼續(xù)工作！

但是，Webapp 不像普通的 App, 有權(quán)限在退出應(yīng)用之后繼續(xù)在后臺(tái)運(yùn)行，如何才能既安全又高效的在后臺(tái)運(yùn)行程序成了一個(gè)比較關(guān)鍵的問(wèn)題，如果放出權(quán)限讓 js 持續(xù)在后臺(tái)運(yùn)行勢(shì)必會(huì)影響整個(gè)操作系統(tǒng)的效率（沒(méi)有人能寫(xiě)出沒(méi)有bug的程序，只是訪問(wèn)了一個(gè)網(wǎng)頁(yè)，卻強(qiáng)奸了我的系統(tǒng)。。當(dāng)然不能忍。。）。所以 Service worker 把后臺(tái)應(yīng)用的權(quán)限局限在"事件"級(jí)別，這里的事件就是前文提到的 Service worker 在瀏覽器啟動(dòng)時(shí)注冊(cè)的事件。后臺(tái)腳本是否執(zhí)行完全取決于瀏覽器是否喚醒它，這也意味著如果這段腳本很煩人，我們可以通過(guò)設(shè)置關(guān)掉這段腳本執(zhí)行的入口，并且，統(tǒng)一管理所有事件的觸發(fā)也有利于提高執(zhí)行效率，畢竟讓專(zhuān)業(yè)的“人”做專(zhuān)業(yè)的事更靠譜~

同樣的，Background Sync 也是Service worker 事件之一，它讓我們有機(jī)會(huì)在退出瀏覽器后也能繼續(xù)執(zhí)行一些功能。

是不是急不可耐的想看一段演示了呢？
帶梯子可以訪問(wèn)這個(gè)鏈接 圖片打不開(kāi)點(diǎn)這

圖：斷網(wǎng)后發(fā)送的消息，聯(lián)網(wǎng)后自動(dòng)發(fā)送到服務(wù)器

圖片打不開(kāi)點(diǎn)這里

圖：演示流程

斷網(wǎng)

注冊(cè)Background sync

聯(lián)網(wǎng)觸發(fā)sync事件

截獲sync事件，彈出彈窗

實(shí)際上，除了這些，Service worker 還可以完成很多有趣的東西，比如制作一個(gè)網(wǎng)頁(yè)，網(wǎng)頁(yè)的header和footer由緩存提供，中間的content從網(wǎng)絡(luò)上獲取。如果對(duì)Service worker的其他功能感興趣，可以看看這個(gè)視頻 Instant-loading Offline-first (Progressive Web App Summit 2016)(需自帶梯子）

技術(shù)關(guān)鍵詞：WebAssembly，passive event listeners，requestIdleCallback

實(shí)際上，web的痛點(diǎn)不止在網(wǎng)絡(luò)層面上，相對(duì)于 native，js的執(zhí)行效率也是硬傷之一，雖然js在操作 DOM 上得心應(yīng)手，但在處理大量數(shù)據(jù)或者圖形計(jì)算上，依舊比較吃力，以至于web平臺(tái)上很難有比較華麗動(dòng)作游戲。直到WebAssembly的出現(xiàn)，讓 web 平臺(tái)實(shí)現(xiàn)炫酷的動(dòng)畫(huà)效果成為可能。WebAssembly可以讓我們?cè)跒g覽器中執(zhí)行C或者C++已經(jīng)編譯出來(lái)的字節(jié)碼。但有一點(diǎn)需要注意的是，WebAssembly的出現(xiàn)并不是為了替代 js，更多的是用來(lái)編寫(xiě)高性能的模塊，替換js中容易出現(xiàn)性能瓶頸的地方。

圖： 試玩WebAssembly 試玩鏈接

鑒于 WebAssembly 目前還處于試驗(yàn)階段，這里不細(xì)講相關(guān)的代碼如何實(shí)現(xiàn)了。有興趣可以點(diǎn)擊后面的鏈接了解更多內(nèi)容 How Webassembly Will Change the Way You Write Javascript | Seth Samuel(需自帶梯子） demo源代碼

除了 js 的執(zhí)行效率外，流暢的屏幕滾動(dòng)體驗(yàn)對(duì)web來(lái)說(shuō)非常重要，這點(diǎn)在基于觸摸的移動(dòng)設(shè)備體現(xiàn)的尤為明顯，但事實(shí)上，web瀏覽器中很容易在屏幕滾動(dòng)上出現(xiàn)問(wèn)題，如果細(xì)心的話，會(huì)發(fā)現(xiàn)即使在設(shè)置一個(gè)空函數(shù)為event handler也可能會(huì)造成滾動(dòng)不流暢。

問(wèn)題出現(xiàn)在滾動(dòng)時(shí)我們可以調(diào)用preventDefault來(lái)取消滾動(dòng)，即使完全沒(méi)有調(diào)用preventDefault，瀏覽器頁(yè)需要在每次滾動(dòng)前先等待handler調(diào)用結(jié)束，以確定我們的確沒(méi)有調(diào)用preventDefault來(lái)阻止?jié)L動(dòng)。

但實(shí)際情況卻是大多數(shù)handler都只是需要獲取滾動(dòng)的位置信息，監(jiān)聽(tīng)與否并不會(huì)影響滾動(dòng)這個(gè)動(dòng)作的發(fā)生，我們完全讓屏幕一邊滾著一邊調(diào)用回調(diào)函數(shù)。所以，只要明確告訴瀏覽器這個(gè)監(jiān)聽(tīng)事件是不會(huì)影響瀏覽器滾動(dòng)的，對(duì)滾動(dòng)事件的執(zhí)行效率有非常大的提升。

為了解釋清楚這其中的區(qū)別，我再舉個(gè)例子，游戲中的高樓，即使再高你也會(huì)毫不猶豫的往下跳，現(xiàn)實(shí)中的蹦極，雖然前人無(wú)數(shù)次的驗(yàn)證過(guò)安全也會(huì)猶豫擔(dān)心。

明確知道安全：無(wú)所畏懼

潛在可能危險(xiǎn)：畏首畏尾

這就是“明確知道”和“潛在可能”的差別，也是passive event能提升瀏覽器效率的原因。

當(dāng)然，Passive Event Listeners的接口非常簡(jiǎn)單，只需要將第三個(gè)參數(shù)設(shè)置為{passive: true}即可。

var elem = document.getElementById("elem");
elem.addEventListener("touchmove", function listener() {
  /* do something */
}, { passive: true });

圖：對(duì)比執(zhí)行效率的差別，右邊的listener設(shè)置了passive屬性

了解更多相關(guān)passive event listeners的信息

上面都是一些主動(dòng)提高web執(zhí)行效率的方法，下面要講的是利用好瀏覽器的空閑時(shí)間。

在web開(kāi)發(fā)中，更快的顯示出有內(nèi)容的首屏非常重要，尤其對(duì)于webapp來(lái)說(shuō)。相對(duì)于傳統(tǒng)web頁(yè)面，webapp在初始化時(shí)需要占用大量的時(shí)間運(yùn)行腳本，并且大多數(shù) webapp 在第一次打開(kāi)時(shí)執(zhí)行的腳本遠(yuǎn)遠(yuǎn)多于后續(xù)的頁(yè)面，如何分配好腳本的執(zhí)行時(shí)間也是非常重要的課題。

圖：react webapp 在啟動(dòng)前500ms需要進(jìn)行非常密集的計(jì)算。

setTimeout(()=>{
  const head = document.getElementsByTagName("head")[0];
  const gajs = document.createElement("script");
  gajs.async = 1;
  gajs.src = "https://www.google-analytics.com/analytics.js";
  head.insertBefore(gajs, head.lastChild);
}, 2000);

這是一段等瀏覽器空閑下來(lái)再去加載google analytics的腳本。

相對(duì)于動(dòng)畫(huà)以及加載首屏頁(yè)面，加載第三方統(tǒng)計(jì)代碼的優(yōu)先級(jí)低得多，所以設(shè)置2000ms對(duì)于大多數(shù)場(chǎng)景夠用了，但事實(shí)上我們完全無(wú)法保證timer觸發(fā)時(shí)瀏覽器處于空閑狀態(tài)。

如果對(duì)于 JavaScript 足夠了解的話，應(yīng)該知道瀏覽器中的 Timer 是在瀏覽器的調(diào)用棧清空時(shí)才會(huì)從回調(diào)隊(duì)列中取setTimeout推入的回調(diào)函數(shù)。但調(diào)用棧清空是瀏覽器空閑的假象，很有可能下一刻就要執(zhí)行類(lèi)似requestAnimationFrame注冊(cè)的回調(diào)函數(shù)，但是我們卻無(wú)法查詢(xún)到已經(jīng)注冊(cè)的回調(diào)函數(shù)會(huì)在何時(shí)觸發(fā)。

圖：年初做的視頻教程截圖，下方為回調(diào)隊(duì)列，事件輪詢(xún)?cè)谡{(diào)用棧清空時(shí)會(huì)從回調(diào)隊(duì)列取函數(shù)出來(lái)運(yùn)行

實(shí)際上，真正空閑的時(shí)候是在調(diào)用棧清空并且Web Api中注冊(cè)的沒(méi)有需要立刻推入回調(diào)隊(duì)列的回調(diào)函數(shù)時(shí)。結(jié)合下面的圖片可能更容易理解上面這句話

圖：圖中的idel period才是瀏覽器真正空閑的時(shí)候。

requestIdleCallback 提供的接口也非常簡(jiǎn)單

var handle = window.requestIdleCallback(callback[, options])

如果想了解更多關(guān)于requestIdleCallback的內(nèi)容，可以查看Using requestIdleCallback和Cooperative Scheduling of Background Tasks

講完了前面相對(duì)來(lái)說(shuō)比較復(fù)雜的api，終于可以講些輕松的內(nèi)容了，如果是比較簡(jiǎn)單的內(nèi)容我就一筆帶過(guò)啦~（點(diǎn)擊右側(cè)導(dǎo)航欄快速跳轉(zhuǎn)到相應(yīng)內(nèi)容

全屏Api，可以將類(lèi)似視頻圖片或者Canvas之類(lèi)的元素占滿全屏demo

code

var i = document.getElementById("myimage");
    
// click event handler
i.onclick = function() {
    // in full-screen?
    if (
        document.fullscreenElement ||
        document.webkitFullscreenElement ||
        document.mozFullScreenElement ||
        document.msFullscreenElement
    ) {
        // exit full-screen
        if (document.exitFullscreen) {
            document.exitFullscreen();
        } else if (document.webkitExitFullscreen) {
            document.webkitExitFullscreen();
        } else if (document.mozCancelFullScreen) {
            document.mozCancelFullScreen();
        } else if (document.msExitFullscreen) {
            document.msExitFullscreen();
        }
    } else {
        // go full-screen
        if (i.requestFullscreen) {
            this.requestFullscreen();
        } else if (i.webkitRequestFullscreen) {
            i.webkitRequestFullscreen();
        } else if (i.mozRequestFullScreen) {
            i.mozRequestFullScreen();
        } else if (i.msRequestFullscreen) {
            i.msRequestFullscreen();
        }
    
    }
}

Media Recorder API 讓我們的網(wǎng)頁(yè)實(shí)現(xiàn)錄制流媒體的能力。

給個(gè)相對(duì)簡(jiǎn)單的demo以及源代碼地址：source code demo

延伸閱讀：Record Audio and Video with MediaRecorder

（寫(xiě)到這發(fā)現(xiàn)可以直接嵌入視頻。吐血中。讓我靜靜。。。。???）

另一個(gè)比較有用的接口就是 Media source extensions，它讓我們可以在 web 上有機(jī)會(huì)播放任意格式的視頻格式，著名的 flv.js 就是靠這個(gè)接口實(shí)現(xiàn)的。另外，由于視頻的內(nèi)容可以完全用腳本控制，我們可以使用這個(gè)接口完成類(lèi)似播放加密的視頻流、限制視頻流的加載速度、根據(jù)緩沖的快慢自動(dòng)切換視頻流的源、web頁(yè)面視頻聊天等等等等~

說(shuō)點(diǎn)題外話，直播現(xiàn)在在國(guó)內(nèi)這么火爆，但是直播流的格式兼容性卻還有些小問(wèn)題，要想一個(gè)格式支持全平臺(tái)就會(huì)涉及到相關(guān) media source extensions 的接口。flv支持桌面平臺(tái)，移動(dòng)設(shè)備支持m3u8，一個(gè)方案是桌面用flv.js直播，但在實(shí)際使用中發(fā)現(xiàn)iOS不支持media source extensions，無(wú)法使用flv.js直播；另一個(gè)方案是在桌面環(huán)境使用 media source extensions 將 m3u8 轉(zhuǎn)換成瀏覽器支持的直播流格式，實(shí)際使用中發(fā)現(xiàn)后面這個(gè)方案還是更靠譜，而且輪子都已經(jīng)造好了，有興趣可以看看 videojs-contrib-hls

圖：使用 media source extensions 分片加載音頻內(nèi)容。source code demo

可以在 web worker 上渲染canvas的接口，沒(méi)有 demo 因?yàn)檫€沒(méi)有支持的瀏覽器。。（就算有那應(yīng)該怎么演示？?）

example:

var one = document.getElementById("one").getContext("bitmaprenderer"); 
var two = document.getElementById("two").getContext("bitmaprenderer");

var offscreen = new OffscreenCanvas(256, 256);
var gl = offscreen.getContext("webgl");

// ... some drawing for the first canvas using the gl context ...

// Commit rendering to the first canvas
var bitmapOne = offscreen.transferToImageBitmap();
one.transferImageBitmap(bitmapOne);

// ... some more drawing for the second canvas using the gl context ...

// Commit rendering to the second canvas 
var bitmapTwo = offscreen.transferToImageBitmap();
two.transferImageBitmap(bitmapTwo);

延伸閱讀：OffscreenCanvas

demo

..

..
demo

demo

https://developer.mozilla.org...

https://platform-status.mozil...

https://developers.google.com...

原創(chuàng)博文，轉(zhuǎn)載寫(xiě)明出處就好（是的，出處就是這個(gè)頁(yè)面）。