互動(dòng)白板的整體技術(shù)框架和優(yōu)勢(shì)

本次分享先主要圍繞以下3個(gè)方面展開(kāi)，互動(dòng)白板的產(chǎn)品能力簡(jiǎn)要介紹，互動(dòng)白板的整體技術(shù)框架介紹還有互動(dòng)白板的技術(shù)優(yōu)勢(shì)解析。技術(shù)點(diǎn)主要圍繞音視頻與白板的同步和多端實(shí)時(shí)互動(dòng)同步講解。

互動(dòng)白板產(chǎn)品簡(jiǎn)介

首先我們?yōu)榇蠹医榻B即構(gòu)互動(dòng)白板的產(chǎn)品特點(diǎn)，它依托于即構(gòu)成熟的億級(jí)海量用戶實(shí)時(shí)信令網(wǎng)絡(luò)，提供了功能齊全的百人實(shí)時(shí)在線白板互動(dòng)服務(wù)，具有以下幾個(gè)特點(diǎn)。 全面覆蓋主流平臺(tái)、主流框架：我們各個(gè)平臺(tái)的技術(shù)方案都是基于原生平臺(tái)的技術(shù)框架開(kāi)發(fā)，不依賴第三方框架，這主要是方便進(jìn)行性能優(yōu)化還有降低SDK包的大小。 互動(dòng)涂鴉實(shí)時(shí)同步：這個(gè)功能可以做的很簡(jiǎn)單，但是要能夠適應(yīng)各種變化操作請(qǐng)求和網(wǎng)絡(luò)環(huán)境的話，還是比較有難度的，這也是我們要探討的一個(gè)技術(shù)點(diǎn)。 l白板繪制與音視頻實(shí)時(shí)同步：這是對(duì)于提升用戶體驗(yàn)還是很大的一個(gè)功能點(diǎn)，也是我們此次分享要重點(diǎn)探討的。 主流文檔格式支持，包括PPT/PPTX/DOC/DOCX/XLS/XLSX/PDF/PNG/JPG/JPEG/BMP/TXT等常見(jiàn)的PPT、DOC、XLS，各種圖片格式、文檔格式等，且支持動(dòng)態(tài)PPT。根據(jù)我們的了解，在支持文檔格式方面，即構(gòu)應(yīng)該是現(xiàn)在行業(yè)內(nèi)支持最全的。 豐富的白板教具，包括畫(huà)筆、問(wèn)題、直線、矩形、橢圓、激光筆、橡皮擦等標(biāo)準(zhǔn)的工具。 白板與音視頻的實(shí)時(shí)同步錄制：這個(gè)功能主要是用于音視頻和白板的實(shí)時(shí)云端錄制，目前還處于內(nèi)測(cè)階段，相信很快就可以上線了，大家到時(shí)候可以關(guān)注一下。 以上就是對(duì)即構(gòu)互動(dòng)白板產(chǎn)品能力的介紹。

互動(dòng)白板技術(shù)框架 接下來(lái)，我們來(lái)了解一下互動(dòng)白板的整體的技術(shù)框架。

從上圖可以看到，我們的整體技術(shù)框架主要由5個(gè)模塊構(gòu)成?；?dòng)白板服務(wù)主要負(fù)責(zé)信令數(shù)據(jù)的處理、存儲(chǔ)、轉(zhuǎn)發(fā)，同步信令就是由這個(gè)服務(wù)來(lái)完成的。文檔轉(zhuǎn)碼服務(wù)主要負(fù)責(zé)文檔的轉(zhuǎn)碼和文件訪問(wèn)的鑒權(quán)控制，我們的轉(zhuǎn)碼服務(wù)支持轉(zhuǎn)碼出pdfPDF和SVGsvg，這兩種文件格式都支持矢量放大，所以在客戶端可以呈現(xiàn)一個(gè)較好的放大效果現(xiàn)場(chǎng)結(jié)果。云錄制服務(wù)用于對(duì)音視頻流和白板進(jìn)行實(shí)時(shí)現(xiàn)場(chǎng)云端錄制。對(duì)象存儲(chǔ)和內(nèi)容分發(fā)網(wǎng)絡(luò)主要是基于云廠商提供的存儲(chǔ)和分發(fā)能力。 大家可以看到，我們整體的設(shè)計(jì)思想是課件的存儲(chǔ)與互動(dòng)相分離，以便于進(jìn)行擴(kuò)容。轉(zhuǎn)碼與存儲(chǔ)相分離，除了可以使用即構(gòu)的對(duì)象存儲(chǔ)，我們給了客戶更多的選擇，比如客戶可以不使用即構(gòu)的對(duì)象存儲(chǔ)和內(nèi)容分發(fā)，而選擇使用自己的云存儲(chǔ)和內(nèi)容分發(fā)。畢竟有的客戶，比如說(shuō)教育行業(yè)對(duì)課件的安全性是比較敏感的。整個(gè)服務(wù)目前已經(jīng)實(shí)現(xiàn)全球部署、就近接入，我們的互動(dòng)白板服務(wù)、文件轉(zhuǎn)碼服務(wù)、云錄制服務(wù)都在國(guó)內(nèi)外部署了集群和全球的代理節(jié)點(diǎn)，便于用戶的信令就近訪問(wèn)。依賴云廠商提供的全球能力存儲(chǔ)和內(nèi)容分發(fā)，我們也能夠?qū)崿F(xiàn)客戶對(duì)文檔資源的就近訪問(wèn)。 這套技術(shù)框架從我們的實(shí)現(xiàn)來(lái)看，在并發(fā)性和吞吐性方面的表現(xiàn)是很出色的，這其實(shí)也是依賴我們?cè)谝粢曨l信令方面的技術(shù)積累。以上就是對(duì)整個(gè)技術(shù)框架的簡(jiǎn)單介紹。

互動(dòng)白板技術(shù)優(yōu)勢(shì)解析 關(guān)于技術(shù)優(yōu)勢(shì)的解析，我們主要圍繞白板音視頻同步和多端實(shí)時(shí)互動(dòng)這兩個(gè)常見(jiàn)的技術(shù)難點(diǎn)進(jìn)行解析。 白板音視頻同步 1. 痛點(diǎn)分析

（1）什么是白板音視頻不同步 從上圖展示的場(chǎng)景，很明顯我們可以知道在這個(gè)場(chǎng)景中白板比音視頻流先到達(dá)了學(xué)生端，從而導(dǎo)致學(xué)生端先看到了白板的操作再收到音視頻流。我們把上面從老師到學(xué)生的過(guò)程抽象為3個(gè)階段，分別為采集、傳輸階段和渲染階段。采集階段是在老師端，老師這邊的音視頻采集和白板操作其實(shí)是同步進(jìn)行的，經(jīng)過(guò)傳輸后到達(dá)渲染，渲染出的結(jié)果并不同步，我們由此可以確定的是，這個(gè)問(wèn)題是在傳輸階段產(chǎn)生的。那么接下來(lái)我們就來(lái)探討白板和音視頻是怎么進(jìn)行傳輸?shù)摹?

（2）為什么會(huì)不同步 我們都知道音視頻的傳輸是通過(guò)流媒體網(wǎng)絡(luò)與視頻流進(jìn)行傳輸。根據(jù)我們的了解，白板的傳輸在業(yè)內(nèi)目前主要有兩種通用模式，一種是以視頻流模式傳輸互動(dòng)白板，另一種是以文件+信令的模式來(lái)傳輸互動(dòng)白板。 我們先講解視頻流模式是怎樣傳輸?shù)模热缭诮逃I(lǐng)域，老師端會(huì)經(jīng)常采集和共享某個(gè)窗口、屏幕或區(qū)域，然后通過(guò)對(duì)窗口、屏幕、區(qū)域進(jìn)行畫(huà)面采集，通過(guò)視頻前處理、編碼、傳輸達(dá)到學(xué)生端，學(xué)生端再進(jìn)行解碼后處理，并最終渲染出來(lái)，整個(gè)過(guò)程和音視頻沒(méi)什么區(qū)別。 而文件+信令的模式是依賴信令服務(wù)的模式，通過(guò)文檔服務(wù)對(duì)文件進(jìn)行上傳、轉(zhuǎn)碼、分發(fā)、下載和渲染。在這個(gè)過(guò)程中，當(dāng)有操作時(shí)便通過(guò)信令服務(wù)轉(zhuǎn)發(fā)操作信令。 （3）視頻流模式與文件+信令模式關(guān)鍵點(diǎn)對(duì)比 了解完兩種模式的白板傳輸，我們來(lái)比較一下這兩種模式的特點(diǎn)。 首先在帶寬占用上，因?yàn)橐曨l流模式很明顯，它具有更高的帶寬占用，尤其是在分辨率和幀率越高，碼率越大的情況下，帶寬占用也會(huì)相應(yīng)的增多。文件+信令模式除了文件上傳和下載還有中間的信令傳輸，數(shù)據(jù)量比較小，所以它的帶寬占用比較低，而且是在有操作的情況下才有信令傳輸。在帶寬占用方面，文件+信令模式是有優(yōu)勢(shì)的。 在清晰度方面，視頻流模式不支持矢量放大，且容易受網(wǎng)絡(luò)狀態(tài)的影響，在網(wǎng)絡(luò)條件較差時(shí)，為了保證音視頻流暢度往往需要降低碼率，從而導(dǎo)致清晰度更低。文件+信令模式則受網(wǎng)絡(luò)狀態(tài)的影響較低，只要網(wǎng)絡(luò)條件能夠確保把文件下載下來(lái)，通過(guò)矢量放大就可以達(dá)到很高的清晰度。 在成本方面占比較大比重的是帶寬，所以文件+信令模式具有更低的成本。 在互動(dòng)性方面，由于通過(guò)視頻流傳輸是單向性的，而文件+信令模式是雙向性，所以相應(yīng)的互動(dòng)性比較高。 在終端性能方面，由于視頻流模式會(huì)涉及視頻的編解碼、處理、渲染，所以對(duì)終端的性能要求比較高，而文件+信令模式只是文件和圖元的渲染，對(duì)終端的性能要求比較低。 當(dāng)然視頻流模式也有它的優(yōu)點(diǎn)，由于它是單向傳輸?shù)模詢?nèi)容比較豐富、易于擴(kuò)展。比如在教育場(chǎng)景下，只要老師端做好，學(xué)生端就可以觀看到。文件+信令模式在這方面擴(kuò)展性會(huì)受限于課件和教具，比如說(shuō)白板的工具等，擴(kuò)展性會(huì)稍差一些。 因?yàn)橥ㄟ^(guò)視頻流模式，白板和音視頻都是使用流媒體網(wǎng)絡(luò)，所以它們比較容易進(jìn)行同步，而文件+信令模式因?yàn)橐粋€(gè)是流媒體服務(wù)一個(gè)是信令服務(wù)，所以兩者比較難以同步。 通過(guò)以上比較我們發(fā)現(xiàn)，文件+信令模式在寬帶占用、清晰度、成本、互動(dòng)性、終端性能等方面具有明顯的優(yōu)勢(shì)，對(duì)復(fù)雜多樣的設(shè)備和網(wǎng)絡(luò)環(huán)境具有更強(qiáng)的適應(yīng)性，所以該模式越來(lái)越成為業(yè)界的主流技術(shù)方式。但是該模式要解決的問(wèn)題就是白板和音視頻同步問(wèn)題。而白板和音視頻不同步的根本原因就在于音視頻走的是流媒體服務(wù)通道，互動(dòng)白板走的是信令服務(wù)通道，兩者彼此相互獨(dú)立，沒(méi)有同步時(shí)間戳，各自渲染，當(dāng)兩者傳輸延遲差超過(guò)200ms時(shí)用戶就能夠感覺(jué)到不同步的問(wèn)題。 （4）最容易出現(xiàn)不同步問(wèn)題的兩大場(chǎng)景

根據(jù)我們的經(jīng)驗(yàn)，我們提煉出了以下兩個(gè)典型場(chǎng)景： 大班課場(chǎng)景。為了降低成本，大班課場(chǎng)景都會(huì)采用直播模式，音視頻流往往需要轉(zhuǎn)推CDN，這個(gè)時(shí)候的音視頻流傳輸延遲達(dá)到秒級(jí)，而白板信令的傳輸延遲是幾十毫秒。所以問(wèn)題很明顯，白板信令和音視頻流延時(shí)時(shí)間差達(dá)到秒級(jí)以上，從而導(dǎo)致不同步問(wèn)題。 小班課場(chǎng)景。在小班課場(chǎng)景下，為了達(dá)到一個(gè)良好的實(shí)時(shí)效果，一般會(huì)采用低延遲實(shí)時(shí)音視頻方案，在正常網(wǎng)絡(luò)下，現(xiàn)在主流的音視頻廠商，都可以做到音視頻的延遲在100ms以內(nèi)，所以這個(gè)時(shí)候，音視頻的傳輸延遲和互動(dòng)白板的傳輸延遲其實(shí)并不大，觀看端是感受不到不同步的問(wèn)題。但是一旦進(jìn)入弱網(wǎng)情況，兩者的網(wǎng)絡(luò)傳輸延遲差會(huì)變大，因?yàn)橐粢曨l流是采用UDP協(xié)議，而信令服務(wù)一般的傳輸協(xié)議是TCP協(xié)議，TCP協(xié)議在抗弱網(wǎng)方面天然就比UDP協(xié)議差，從而出現(xiàn)不同步的問(wèn)題。所以我們后面的優(yōu)化方案將主要針對(duì)這兩種問(wèn)題進(jìn)行優(yōu)化。 2. 解決方案 （1）白板信令與音視頻流時(shí)間戳對(duì)齊

既然白板信令比音視頻流的傳輸延時(shí)低，但是我們又沒(méi)辦法控制傳輸?shù)难訒r(shí)，所以只能從控制渲染入手。那么要控制渲染，就需要在接收端進(jìn)行時(shí)間戳的對(duì)齊，對(duì)齊之后再拋出來(lái)渲染。我們的解決思路是，當(dāng)老師發(fā)起白板操作時(shí)，白板信令帶上當(dāng)前的時(shí)間戳，同時(shí)把時(shí)間戳注入到音視頻流的SEI中。音視頻流和白板信令分別經(jīng)過(guò)流媒體服務(wù)和白板信令服務(wù)分發(fā)后，此時(shí)白板信令會(huì)先到達(dá)學(xué)生端，對(duì)白板數(shù)據(jù)進(jìn)行緩沖，等到音視頻流到達(dá)后，解析出其中SEI的時(shí)間戳，對(duì)齊后再一起拋出渲染。通過(guò)這種方案可以達(dá)到一個(gè)完全的同步效果。 （2）白板信令網(wǎng)絡(luò)優(yōu)化

針對(duì)小班課場(chǎng)景白板信令網(wǎng)絡(luò)傳輸抗弱網(wǎng)性較差的問(wèn)題，我們的解決思路是對(duì)白板的網(wǎng)絡(luò)傳輸進(jìn)行優(yōu)化，提高白板信令的抗弱網(wǎng)性能，降低傳輸時(shí)延?；谖覀?cè)谝粢曨l信令方面的技術(shù)實(shí)踐，我們從網(wǎng)絡(luò)傳輸協(xié)議入手，把TCP協(xié)議優(yōu)化為QUIC協(xié)議，相比TCP協(xié)議，QUIC協(xié)議具有以下優(yōu)勢(shì)： l降低連接延時(shí)，對(duì)QUIC協(xié)議有所了解的同學(xué)應(yīng)該知道，QUIC協(xié)議的傳輸協(xié)議是UDP，所以它可以減少握手次數(shù)，大部分場(chǎng)景下可以實(shí)現(xiàn)0RTT建連。 l改善擁塞控制，使用新的ACK確認(rèn)機(jī)制，在丟包率高的網(wǎng)絡(luò)下，減少重傳量，提升網(wǎng)絡(luò)的恢復(fù)速度。 l多路復(fù)用避免對(duì)頭阻塞，一個(gè)連接的多個(gè)stream之間是沒(méi)有依賴的，不會(huì)互相影響，導(dǎo)致阻塞。 l實(shí)現(xiàn)前向糾錯(cuò)，減少超時(shí)重傳。 l連接平滑遷移，客戶端切換網(wǎng)絡(luò)之后，如果是用TCP的話，會(huì)導(dǎo)致TCP的斷開(kāi)和重連，但在QUIC協(xié)議之下，可以仍使用原來(lái)的連接。比如說(shuō)客戶端從4g4G網(wǎng)絡(luò)切換到wifiWiFi網(wǎng)絡(luò)，可以實(shí)現(xiàn)不用重新連接的過(guò)程。 在具體的實(shí)踐上，我們?cè)诳蛻舳撕桶装逍帕罘?wù)之間接入了調(diào)度服務(wù)，這個(gè)服務(wù)是基于QUIC協(xié)議自研的調(diào)度服務(wù)。一方面，我們優(yōu)化了從客戶端到服務(wù)端的網(wǎng)絡(luò)傳輸協(xié)議，另一方面，接入的調(diào)度服務(wù)可以在全球進(jìn)行多地部署，實(shí)現(xiàn)客戶端的就近接入。從以上兩方面來(lái)解決用戶最后一公里的接入問(wèn)題，有效降低了白板信令的網(wǎng)絡(luò)傳輸延遲，提高了對(duì)弱網(wǎng)的抗性，從我們實(shí)際測(cè)試的效果來(lái)看，較之前有明顯的改善。 多端實(shí)時(shí)互動(dòng)同步 1. 痛點(diǎn)分析

接下來(lái)，我們來(lái)探討一下多端實(shí)時(shí)互動(dòng)同步的問(wèn)題以及解決方法。 什么是多端實(shí)時(shí)不同步呢？我們還是以教育場(chǎng)景老師和學(xué)生為例，老師和學(xué)生同時(shí)對(duì)一個(gè)課件翻頁(yè)或移動(dòng)處理，結(jié)果兩端呈現(xiàn)出來(lái)的結(jié)果不一致。通過(guò)對(duì)各種場(chǎng)景的分析，多端不一致的問(wèn)題主要可以歸納為以下三點(diǎn)：

多端操作沖突

多端同時(shí)操作同一個(gè)對(duì)象產(chǎn)生沖突，導(dǎo)致多端的不同步。比如說(shuō)a和b兩個(gè)人操作同一個(gè)對(duì)象，a把對(duì)象往左拖，b把對(duì)象往右拖，結(jié)果是a看到的對(duì)象在左邊，b看到的在右邊，兩者呈現(xiàn)不一致。這個(gè)問(wèn)題的根本原因主要在于沖突導(dǎo)致，這個(gè)問(wèn)題解決方案是：當(dāng)多端發(fā)起操作時(shí)服務(wù)端如何進(jìn)行沖突處理，客戶端該執(zhí)行什么樣的策略，確保各端執(zhí)行同樣的規(guī)則，從而實(shí)現(xiàn)多端的一致性。

操作亂序問(wèn)題

操作亂序主要是由網(wǎng)絡(luò)亂序和服務(wù)端的并發(fā)請(qǐng)求導(dǎo)致的多端不同步。

我們以上圖中的場(chǎng)景為例介紹亂序的問(wèn)題。左邊是操作端，右邊是觀看端，操作端把一個(gè)對(duì)象從a點(diǎn)快速移到b點(diǎn)，又快速移到c點(diǎn)，所以它的最后結(jié)果是在c點(diǎn)。而觀看端收到的結(jié)果卻是，這個(gè)對(duì)象被從a點(diǎn)移到c點(diǎn)又移到b點(diǎn)，最終結(jié)果是b點(diǎn)，導(dǎo)致兩者呈現(xiàn)不一致。該問(wèn)題的難點(diǎn)是如何解決由信令請(qǐng)求在網(wǎng)絡(luò)傳輸過(guò)程中亂序和并發(fā)請(qǐng)求導(dǎo)致的不同步問(wèn)題。

操作丟失

操作丟失一般是由于白板信令方?jīng)]有到達(dá)接收端導(dǎo)致的多端不同步。比如說(shuō)老師在互動(dòng)白板上畫(huà)了個(gè)矩形，結(jié)果課堂里有部分同學(xué)收到了矩形，有部分同學(xué)沒(méi)有收到，從而導(dǎo)致所有人的結(jié)果不一致。該問(wèn)題的原因一般是接收端因?yàn)榫W(wǎng)絡(luò)原因沒(méi)有收到該操作指令，導(dǎo)致操作端和接收端結(jié)果不一致。 2. 解決方案 （1）多端操作同步

針對(duì)以上痛點(diǎn)我們分別對(duì)其進(jìn)行了優(yōu)化，其實(shí)在線協(xié)作文檔里面臨的最大問(wèn)題就是多端同步問(wèn)題，這方面比較成熟的方案是用OT算法?；?dòng)白板在協(xié)作性上其實(shí)和在線文檔較為類似，因此，我們?cè)诨?dòng)白板上借鑒了該思路，采用了中心化的思想來(lái)做多端同步。 它的思路是這樣的，OT中心負(fù)責(zé)對(duì)客戶端的操作請(qǐng)求，根據(jù)客戶端版本、操作對(duì)象、操作類型等信息，進(jìn)行操作請(qǐng)求的沖突判定、合并操作、轉(zhuǎn)換生成統(tǒng)一操作，通知客戶端，客戶端只需要根據(jù)服務(wù)端的通知進(jìn)行相應(yīng)的處理即可。 由于客戶端只需要執(zhí)行服務(wù)端的操作，那么整個(gè)的沖突判定還有合并處理全由服務(wù)端來(lái)處理，這樣就比較容易達(dá)到多端同步，這是一個(gè)中心化的思想。 互動(dòng)白板里其實(shí)比較難的點(diǎn)應(yīng)該是文本編輯，這里可以做的很簡(jiǎn)單，也可以做的很復(fù)雜，如果做的很復(fù)雜的話，其實(shí)有點(diǎn)類似于在線協(xié)作文檔，如果有對(duì)這方面感興趣的同學(xué)，可以去網(wǎng)上搜一些相關(guān)的OT開(kāi)源算法進(jìn)行了解，我們不在這里對(duì)這個(gè)點(diǎn)進(jìn)行闡述。這就是多端操作同步的思路。 （2）亂序操作

關(guān)于操作亂序，大家可以看到完整的單向互動(dòng)流程是像上圖這樣的，我們可以把整個(gè)過(guò)程分成clientA到server和server到clientB兩個(gè)階段，來(lái)分別看看這兩個(gè)階段因此亂序的原因是什么。 clientA到server階段： 客戶端對(duì)服務(wù)端發(fā)起并發(fā)的http請(qǐng)求的時(shí)候，多個(gè)請(qǐng)求有可能走不同的網(wǎng)絡(luò)鏈路，這個(gè)時(shí)候，有一個(gè)鏈路的網(wǎng)絡(luò)有問(wèn)題就可能導(dǎo)致請(qǐng)求后發(fā)先至，也就是服務(wù)端收到的請(qǐng)求是亂序的。比較簡(jiǎn)單粗暴的解決方案就是客戶端執(zhí)行串行發(fā)送，每一個(gè)請(qǐng)求都等服務(wù)端回包完成之后再執(zhí)行下一個(gè)請(qǐng)求。根據(jù)我們的實(shí)踐，這種方法可以很好的解決客戶端到server的亂序問(wèn)題。 server到clientB： 因?yàn)榉?wù)端推送到客戶端一般采用的是TCP長(zhǎng)連接，所以這里的亂序問(wèn)題一般不是由網(wǎng)絡(luò)傳輸導(dǎo)致的，更多的是由于服務(wù)器的設(shè)計(jì)方案導(dǎo)致。比如說(shuō)在服務(wù)端沒(méi)有做串行的設(shè)計(jì)而是選擇并發(fā)的請(qǐng)求，就有可能從服務(wù)端發(fā)出去的請(qǐng)求是亂序的。那么較為簡(jiǎn)單的解決思路就是把服務(wù)端做成串行發(fā)送的模式。但是，根據(jù)我們的經(jīng)驗(yàn)，出于對(duì)服務(wù)端性能的考慮，我們并沒(méi)有采用這個(gè)方案。我們采用的方案是把這個(gè)工作交給客戶端來(lái)做，在客戶端進(jìn)行一個(gè)亂序重排，這樣可以有效的分擔(dān)服務(wù)端的壓力，對(duì)服務(wù)端的并發(fā)和吞吐性具有更好的效果。 （3）操作丟失

操作丟失的問(wèn)題可以看一下上圖的例子，操作端發(fā)送了兩個(gè)操作都到達(dá)了白板信令服務(wù)，白板信令服務(wù)也按順序發(fā)了，先發(fā)了操作1接受端收到了，但當(dāng)發(fā)操作2時(shí)，接收端網(wǎng)絡(luò)掉線了，導(dǎo)致接收端沒(méi)有收到該指令。那么在這種情況下，接收端怎么去把這個(gè)丟失的請(qǐng)求同步回來(lái)呢？ 我們的解決思路主要是兩種，第一，接收端需要對(duì)網(wǎng)絡(luò)狀態(tài)進(jìn)行監(jiān)控，當(dāng)察覺(jué)到網(wǎng)絡(luò)異常時(shí)，在斷網(wǎng)重連后能夠主動(dòng)去發(fā)起同步。第二，在接受端和服務(wù)端維持一個(gè)心跳同步協(xié)議，這樣就可以確保無(wú)論什么時(shí)候，即使稍微慢點(diǎn)也能把丟失的操作同步回來(lái)。我們通過(guò)以上兩種方案，基本可以完全解決操作丟失的問(wèn)題。 我們通過(guò)以上三點(diǎn)，對(duì)多端操作同步進(jìn)行優(yōu)化，從而達(dá)到一個(gè)較佳的效果，但多端操作的沖突里面，最復(fù)雜的應(yīng)該是OT中心的轉(zhuǎn)換，因?yàn)檫@里面操作比較多，所以需要去做不同的策略，同時(shí)也需要去探索尋找更好的解決方案。 總結(jié)一下以上的內(nèi)容主要是介紹即構(gòu)互動(dòng)白板的產(chǎn)品能力，闡述了整體的技術(shù)框架，針對(duì)白板音視頻同步和多端實(shí)時(shí)同步兩個(gè)技術(shù)難點(diǎn)分享了我們的相關(guān)探索和實(shí)踐。大家如果覺(jué)得我們的方案有什么不合理的地方也可以告知我們，或者有更優(yōu)的方案也歡迎提出來(lái)幫助我們進(jìn)行改進(jìn)。