今天javascript欄目介紹我們是如何搭建互動應(yīng)用的。

搭建互動應(yīng)用

前言

本文從前端的角度出發(fā)，簡單地介紹了搭建互動應(yīng)用的一種思路，提供了在線互動、中途加入兩個場景的一種解決思路，最后簡單介紹了互動應(yīng)用在實踐中的優(yōu)化方向。通過閱讀你可以了解到：

• 何為互動應(yīng)用
• 一次互動過程的實現(xiàn)
• 中途加入的同步
• 互動應(yīng)用的優(yōu)化方向

何為互動應(yīng)用

互動，即互相作用，互相交流。互動應(yīng)用提供了一種用戶互相交流的方式，互聯(lián)網(wǎng)用戶可通過打開應(yīng)用同一頁面，通過操作頁面元素的方式互動，達(dá)到分享、交流的目的。

一個簡單的使用場景

如下圖，在一個線下課堂場景中，教師和學(xué)生通過語言、文字等媒介進(jìn)行信息互動，這個過程是雙向、信息同步的。在今年疫情期間，很多學(xué)校都采用線上課堂的形式進(jìn)行上課，如何使線上授課的體驗接近甚至超越線下呢？這就需要一種互動應(yīng)用基于雙向、信息同步的前提，提供線上授課的功能。

舉個例子來說，老師在應(yīng)用中打開一份課件，學(xué)生需要同時看到這份課件，且授課過程中針對該課件的操作，也能一一被同一課堂的學(xué)生們接收到；反過來學(xué)生也能操作該課件，并被老師和其他學(xué)生接收到。

老師通過該應(yīng)用可在授課的同時，即時接收學(xué)生的反饋，甚至讓學(xué)生們參與到線上課堂的互動中。

一次互動過程的實現(xiàn)

如何達(dá)到信息同步的效果呢？信息同步，即狀態(tài)同步。在線上授課的場景中，老師操作課件，為了使學(xué)生能看到最新的課件信息，需要在當(dāng)前課件的基礎(chǔ)上，加上老師操作課件的狀態(tài)，達(dá)到更新課件狀態(tài)的目的。

抽象來說，當(dāng)前狀態(tài) + 增量狀態(tài) = 最新狀態(tài)；

另一方面，對課件的操作，需要通過網(wǎng)絡(luò)傳輸?shù)狡渌?，這就需要將行為序列化和反序列化；

總的來說，一次完整的互動過程包含行為產(chǎn)生與行為序列化、行為數(shù)據(jù)傳輸、反序列化與行為同步三個過程，如下圖，A端觸發(fā)了一個行為時，經(jīng)過序列化產(chǎn)生相應(yīng)的行為數(shù)據(jù)，數(shù)據(jù)傳輸?shù)紹端后，B端經(jīng)過反序列化后恢復(fù)相同的行為，完成了一次“行為——行為”的同步。

1. 行為產(chǎn)生與行為序列化

為了完成行為的同步，需要將行為抽象為指令數(shù)據(jù)，經(jīng)過優(yōu)化處理后得到最終的數(shù)據(jù)，這個過程就是序列化的過程。

2. 行為數(shù)據(jù)傳輸

互動應(yīng)用具備實時性，數(shù)據(jù)傳輸一般采用WebSocket等即時通信技術(shù)完成。

3. 反序列化與行為同步

收到數(shù)據(jù)后，對行為數(shù)據(jù)進(jìn)行反序列化，再觸發(fā)應(yīng)用執(zhí)行相應(yīng)的行為，完成行為同步。

中途加入的同步

上面闡述了同時連線的端的互動過程，但互動應(yīng)用的實際使用場景中存在用戶中途加入的情況。比如，老師上課持續(xù)一段時間后，學(xué)生才上線加入課堂。在這個場景中，需要考慮如何使用戶恢復(fù)最新的頁面狀態(tài)，從而保證后續(xù)互動的同步性。

實現(xiàn)中途加入同步的前提

為了保證恢復(fù)歷史狀態(tài)的可行性，互動應(yīng)用的狀態(tài)需要被完全記錄在數(shù)據(jù)中，確保這份數(shù)據(jù)能用于恢復(fù)應(yīng)用的頁面狀態(tài)

中途加入同步的過程

如下圖，A和B是同時在線互動的兩端。C端中途加入后，首先初始化頁面狀態(tài)a，然后獲取diff狀態(tài)應(yīng)用到頁面中，得到狀態(tài)b；

有一點需要注意，當(dāng)C端中途加入的同步期間其他兩端發(fā)生互動時，此時C端的b 狀態(tài)實際上并非頁面的最新狀態(tài)（如下圖），所以需要restoreTweenMsg這一步來完成a-c狀態(tài)期間的消息恢復(fù)，保證C端狀態(tài)與A、B相同

互動應(yīng)用的優(yōu)化方向

消息輕量化

當(dāng)互動應(yīng)用的用戶達(dá)到較大數(shù)量級別時，數(shù)據(jù)傳輸會對服務(wù)造成很大的壓力。從前端的角度看，消息輕量化能一定程度緩解該問題。以下從壓縮、精簡、稀疏三個優(yōu)化方向完成消息輕量化

壓縮

發(fā)送端對消息進(jìn)行壓縮，通過減小消息體積降低服務(wù)壓力；接收端收到后再進(jìn)行解壓。

精簡

如下圖，發(fā)送端通過編譯器中間件，將指令數(shù)據(jù)進(jìn)行精簡，減小消息體積；接收端通過解釋器中間件將數(shù)據(jù)恢復(fù)。

稀疏

針對密集持續(xù)、且過程態(tài)沒有副作用的指令，通過稀疏指令，減少指令數(shù)量，收到稀疏指令后進(jìn)行補間運算，使其平滑

同步加速

當(dāng)用戶中途加入時，在歷史數(shù)據(jù)較大情況下，同步速度可能受到影響，直接影響用戶體驗。在同步過程中，歷史數(shù)據(jù)傳輸耗時占比較大，可通過加快歷史數(shù)據(jù)傳輸來加速同步。

分片同步

當(dāng)模型數(shù)據(jù)較大時，直接傳輸會出現(xiàn)丟數(shù)據(jù)的情況；采用分片方式進(jìn)行數(shù)據(jù)傳輸，可保證數(shù)據(jù)的完整性，但該方案極度依賴WebSocket的發(fā)送傳輸速度

被動上傳同步

當(dāng)用戶A中途加入時，將發(fā)消息向其他用戶獲取歷史數(shù)據(jù)，被請求用戶將數(shù)據(jù)上傳后，通過WebSocket將下載鏈接通知用戶A，用戶A獲取鏈接后，下載得到歷史數(shù)據(jù)。該方案相比上述方案快，但同步鏈路較長，中途加入的用戶仍然需要一定時間。

定時上傳同步

設(shè)置一個定時上傳歷史數(shù)據(jù)的端，當(dāng)用戶中途加入時，直接向服務(wù)器請求數(shù)據(jù)。該方案通過縮短同步鏈路，進(jìn)一步提升同步速度。該方案需要考慮數(shù)據(jù)上傳與獲取時間差引起的狀態(tài)差異，需要做狀態(tài)的恢復(fù)。

結(jié)束語

本文闡述的互動應(yīng)用方案有團(tuán)隊成員的共同探索，不足之處有待指出。

相關(guān)免費學(xué)習(xí)推薦：javascript（視頻）