跨頁面通訊的各種姿勢

螞蟻金服資料體驗技術發表於2017-09-15

作者簡介：nekron 螞蟻金服·資料體驗技術團隊

將跨頁面通訊類比計算機程式間的通訊，其實方法無外乎那麼幾種，而web領域可以實現的技術方案主要是類似於以下兩種原理：

  • 獲取控制程式碼，定向通訊
  • 共享記憶體，結合輪詢或者事件通知來完成業務邏輯

由於第二種原理更利於解耦業務邏輯，具體的實現方案比較多樣。以下是具體的實現方案，簡單介紹下，權當科普：

一、獲取控制程式碼

具體方案

父頁面通過window.open(url, name)方式開啟的子頁面可以獲取控制程式碼，然後通過postMessage完成通訊需求。

// parent.html
const childPage = window.open('child.html', 'child')

childPage.onload = () => {
	childPage.postMessage('hello', location.origin)
}

// child.html
window.onmessage = evt => {
	// evt.data
}
複製程式碼

tips

  1. 當指定window.open的第二個name引數時，再次呼叫window.open('****', 'child')會使之前已經開啟的同name子頁面重新整理
  2. 由於安全策略，非同步請求之後再呼叫window.open會被瀏覽器阻止，不過可以通過控制程式碼設定子頁面的url即可實現類似效果
// 首先先開一個空白頁
const tab = window.open('about:blank')

// 請求完成之後設定空白頁的url
fetch(/* ajax */).then(() => {
	tab.location.href = '****'
})
複製程式碼

優劣

缺點是隻能與自己開啟的頁面完成通訊，應用面相對較窄；但優點是在跨域場景中依然可以使用該方案。

二、localStorage

具體方案

設定共享區域的storage，storage會觸發storage事件

// A.html
localStorage.setItem('message', 'hello')

// B.html
window.onstorage = evt => {
  // evt.key, evt.oldValue, evt.newValue
}
複製程式碼

tips

  1. 觸發寫入操作的頁面下的storage listener不會被觸發
  2. storage事件只有在發生改變的時候才會觸發，即重複設定相同值不會觸發listener
  3. safari隱身模式下無法設定localStorage值

優劣

API簡單直觀，相容性好，除了跨域場景下需要配合其他方案，無其他缺點

三、BroadcastChannel

具體方案

和localStorage方案基本一致，額外需要初始化

// A.html
const channel = new BroadcastChannel('tabs')
channel.onmessage = evt => {
	// evt.data
}

// B.html
const channel = new BroadcastChannel('tabs')
channel.postMessage('hello')
複製程式碼

優劣

和localStorage方案沒特別區別，都是同域、API簡單，BroadcastChannel方案相容性差些（chrome > 58），但比localStorage方案生命週期短（不會持久化），相對乾淨些。

四、SharedWorker

具體方案

SharedWorker本身並不是為了解決通訊需求的，它的設計初衷應該是類似總控，將一些通用邏輯放在SharedWorker中處理。不過因為也能實現通訊，所以一併寫下：

// A.html
var sharedworker = new SharedWorker('worker.js')
sharedworker.port.start()
sharedworker.port.onmessage = evt => {
	// evt.data
}

// B.html
var sharedworker = new SharedWorker('worker.js')
sharedworker.port.start()
sharedworker.port.postMessage('hello')

// worker.js
const ports = []
onconnect = e => {
	const port = e.ports[0]
	ports.push(port)
	port.onmessage = evt => {
		ports.filter(v => v!== port) // 此處為了貼近其他方案的實現，剔除自己
		.forEach(p => p.postMessage(evt.data))
	}
}

複製程式碼

優劣

相較於其他方案沒有優勢，此外，API複雜而且除錯不方便。

五、Cookie

具體方案

一個古老的方案，有點localStorage的降級相容版，我也是整理本文的時候才發現的，思路就是往document.cookie寫入值，由於cookie的改變沒有事件通知，所以只能採取輪詢髒檢查來實現業務邏輯。

方案比較醜陋，勢必被淘汰的方案，貼一下原版思路地址，我就不寫demo了。

communication between browser windows (and tabs too) using cookies

優劣

相較於其他方案沒有存在優勢的地方，只能同域使用，而且汙染cookie以後還額外增加AJAX的請求頭內容。

六、Server

之前的方案都是前端自行實現，勢必受到瀏覽器限制，比如無法做到跨瀏覽器的訊息通訊，比如大部分方案都無法實現跨域通訊（需要增加額外的postMessage邏輯才能實現）。通過藉助服務端，還有很多增強方案，也一併說下。

乞丐版

後端無開發量，前端定期儲存，在tab被啟用時重新獲取儲存的資料，可以通過校驗hash之類的標記位來提升檢查效能。

window.onvisibilitychange = () => {
	if (document.visibilityState === 'visible') {
		// AJAX
	}
}
複製程式碼

Server-sent Events / Websocket

專案規模小型的時候可以採取這類方案，後端自行維護連線，以及後續的推送行為。

SSE

// 前端
const es = new EventSource('/notification')

es.onmessage = evt => {
	// evt.data
}
es.addEventListener('close', () => {
	es.close()
}, false)


// 後端，express為例
const clients = []

app.get('/notification', (req, res) => {
	res.setHeader('Content-Type', 'text/event-stream')
	clients.push(res)
  	req.on('aborted', () => {
   		// 清理clients
  	})
})
app.get('/update', (req, res) => {
	// 廣播客戶端新的資料
	clients.forEach(client => {
		client.write('data:hello\n\n')
		setTimeout(() => {
			client.write('event:close\ndata:close\n\n')
		}, 500)
	})
	res.status(200).end()
})
複製程式碼

Websocket

socket.io、sockjs例子比較多，略

訊息佇列

專案規模大型時，需要訊息佇列叢集長時間維護長連結，在需要的時候進行廣播。

提供該類服務的雲服務商很多，或者尋找一些開源方案自建。

例如MQTT協議方案（阿里雲就有提供），web客戶端本質上也是websocket，需要叢集同時支援ws和mqtt協議，示例如下：

// 前端
// 客戶端使用開源的Paho
// port會和mqtt協議通道不同
const client = new Paho.MQTT.Client(host, port, 'clientId')

client.onMessageArrived = message => {
	// message. payloadString
}
client.connect({
	onSuccess: () => {
		client.subscribe('notification')
	}
})
// 抑或，藉助flash（雖然快要被淘汰了）進行mqtt協議連線並訂閱相應的頻道，flash再通過回撥丟擲訊息

// 後端
// 根據服務商提供的Api介面呼叫頻道廣播介面
複製程式碼

原文地址: github.com/ProtoTeam/b…

相關文章