相機(jī)：三條路線與PTZ控制避坑指南)
1. 先聊清楚uniapp 接云臺(tái)相機(jī)這件事到底難在哪我做安防類項(xiàng)目有幾年了最近半年被問得最多的一個(gè)問題就是uniapp 能不能接云臺(tái)相機(jī)云臺(tái)插件到底好不好用。這個(gè)問題表面上是問插件實(shí)際上是問一整套取流、控制、跨端適配的技術(shù)路線能不能成立。我前后在三個(gè)項(xiàng)目里試過不同做法一個(gè)園區(qū)值班室的中控屏、一個(gè)連鎖門店的巡店應(yīng)用、還有一個(gè)設(shè)備巡檢的移動(dòng)作業(yè)端規(guī)模都不大但把該踩的坑基本都踩了一遍。先給結(jié)論uniapp 跨平臺(tái)監(jiān)控方案是可行的但它的可行有明確邊界。你能用一套代碼同時(shí)出 H5、安卓 App、iOS App甚至小程序這個(gè)誘惑太大尤其是團(tuán)隊(duì)只有一兩個(gè)前端的時(shí)候。可視頻監(jiān)控這個(gè)場(chǎng)景天生重原生——解碼、渲染、硬件加速、低延遲傳輸每一環(huán)都貼著操作系統(tǒng)底層走而 uniapp 的強(qiáng)項(xiàng)是視圖層和業(yè)務(wù)層的跨端復(fù)用兩者中間隔著一層原生橋接摩擦就發(fā)生在這一層。下文我把標(biāo)題里說的云臺(tái)插件統(tǒng)一理解為某安防廠商下文簡(jiǎn)稱 A 廠商提供的、封裝了設(shè)備登錄、實(shí)時(shí)預(yù)覽、云臺(tái)控制PTZ、錄像回放、抓圖等能力的 SDK 插件形態(tài)產(chǎn)品。它可能是一個(gè) uni 原生插件也可能是一個(gè) H5 播放頁還可能只是一套 HTTP 接口加標(biāo)準(zhǔn)流地址。形態(tài)不同優(yōu)劣差別巨大這也是很多人測(cè)評(píng)結(jié)果互相矛盾的原因——大家測(cè)的壓根不是同一個(gè)東西。這篇文章適合三類人看正在做技術(shù)選型的項(xiàng)目負(fù)責(zé)人、準(zhǔn)備動(dòng)手接入的前端或移動(dòng)端開發(fā)、以及被一套代碼多端跑打動(dòng)但還沒踩過坑的產(chǎn)品同學(xué)。我會(huì)把三條主流路線的架構(gòu)、云臺(tái)指令的細(xì)節(jié)、跨端差異、實(shí)測(cè)數(shù)據(jù)和排錯(cuò)經(jīng)驗(yàn)全部攤開講參數(shù)和計(jì)算過程都給出來能直接抄的部分我會(huì)寫得足夠具體。2. 三條技術(shù)路線的架構(gòu)拆解與優(yōu)劣勢(shì)對(duì)照2.1 路線一web-view 內(nèi)嵌廠商 H5 監(jiān)控頁改動(dòng)最小的偷懶方案這是上手最快的一條路。A 廠商通常會(huì)提供一個(gè)免插件的網(wǎng)頁版預(yù)覽頁地址里帶上設(shè)備序列號(hào)、通道號(hào)、token 之類的參數(shù)你只要在 uniapp 里放一個(gè)web-view組件把地址塞進(jìn)去畫面就出來了云臺(tái)控制按鈕廠商也已經(jīng)畫好了。我在門店巡店那個(gè)項(xiàng)目里第一版就是這么干的從拿到地址到跑通兩個(gè)小時(shí)。它的優(yōu)勢(shì)非常直接零原生開發(fā)、零協(xié)議理解、零解碼邏輯。廠商網(wǎng)頁內(nèi)部已經(jīng)把取流、解碼、云臺(tái)指令封裝好了你不需要知道背后用的是 WebSocket 推流還是 HTTP-FLV也不需要關(guān)心 H.264 還是 H.265。對(duì)于只要求能看、能轉(zhuǎn)、能回放的輕量場(chǎng)景這條路性價(jià)比最高。但坑也很密集。第一是通信問題網(wǎng)頁和 uniapp 之間只能靠postMessage或者 URL 傳參雙向通信在 App 端勉強(qiáng)能用小程序端受限于業(yè)務(wù)域名校驗(yàn)?zāi)茏龅降氖虑楦?。第二是UI 不可控廠商頁面永遠(yuǎn)帶著自己的 logo、自己的按鈕布局你想把它嵌進(jìn)自己的設(shè)計(jì)體系里幾乎不可能只能整頁鋪滿。第三是拿不到視頻幀截圖、AI 識(shí)別、本地錄像這些需求直接判死刑。第四是登錄態(tài)和 token 管理A 廠商的 H5 地址一般有效期很短頁面切后臺(tái)再回來經(jīng)常要重新鑒權(quán)用戶看到的就是一片黑屏加一個(gè)轉(zhuǎn)圈。我印象最深的一次是客戶要求點(diǎn)擊畫面任意位置云臺(tái)自動(dòng)把那個(gè)點(diǎn)移到畫面中心也就是常說的 3D 定位。廠商 H5 頁面本身支持但它是內(nèi)部邏輯我們無法從外部觸發(fā)最后只能改成讓用戶自己按方向鍵。這就是路線一的本質(zhì)你借用了別人的能力也接受了別人的邊界。2.2 路線二原生插件直連 SDK延遲最低但維護(hù)成本最高第二條路是把 A 廠商的移動(dòng)端 SDK 封裝成 uni 原生插件。安卓側(cè)通常是幾個(gè).aar加一堆.so動(dòng)態(tài)庫iOS 側(cè)是.framework然后按 uniapp 原生插件的規(guī)范暴露方法給 JS 調(diào)用比如login、startRealPlay、ptzControl、stopRealPlay、startPlayback。這條路是性能天花板。SDK 直連設(shè)備或者直連廠商的流媒體服務(wù)走的是私有協(xié)議延遲能壓到 200 到 500 毫秒云臺(tái)指令也是走專用通道按下按鈕到畫面轉(zhuǎn)動(dòng)體感幾乎是實(shí)時(shí)的。功能也最全預(yù)置位、巡航、抓圖存本地、雙向?qū)χv、本地錄像、碼流切換主碼流/子碼流全都有。代價(jià)是雙端各寫一遍。安卓和 iOS 的 SDK 接口長得完全不一樣安卓里叫PTZControliOS 里可能是ptzControlWithCommand參數(shù)順序也不同你得寫兩套橋接代碼。包體積也會(huì)明顯變大我做過的一個(gè)版本加上.so之后安裝包從 18MB 漲到了 62MB雖然可以做 ABI 拆分只保留arm64-v8a但還是要多出二十多兆。更麻煩的是版本耦合。uni 原生插件要跟 HBuilderX 的版本、基座版本對(duì)齊云打包的自定義基座一旦和插件不匹配就是白屏或者方法找不到。我遇到過一次升級(jí)了 IDE 之后插件里某個(gè)回調(diào)不再觸發(fā)排查了半天才發(fā)現(xiàn)是基座緩存沒清。另外這條路完全放棄了 H5 和小程序如果你老板一開始說我們要多端最后發(fā)現(xiàn)只有 App 能用返工成本很高。注意封裝 A 廠商 SDK 時(shí)要特別留意.so的架構(gòu)裁剪只保留arm64-v8a能省一半體積但部分老舊的安卓一體機(jī)是 32 位系統(tǒng)砍掉armeabi-v7a之后會(huì)直接崩在UnsatisfiedLinkError。上線前一定要確認(rèn)目標(biāo)機(jī)型的 CPU 架構(gòu)。2.3 路線三自建流媒體網(wǎng)關(guān)加通用播放器折中但最費(fèi)運(yùn)維第三條路是我現(xiàn)在最推薦的中間方案服務(wù)端把設(shè)備的 RTSP 流拉過來轉(zhuǎn)成 WebRTC 或 HTTP-FLV前端用統(tǒng)一的播放器組件播。設(shè)備側(cè)只需要開放 RTSP 地址和賬號(hào)密碼剩下的交給網(wǎng)關(guān)。H5 和 App 用flv.js或者 WebRTC 播放器小程序用live-player組件播 RTMP 或 FLV。這條路的最大好處是前端徹底統(tǒng)一。同一套播放器封裝邏輯通過條件編譯在三個(gè)端上跑業(yè)務(wù)代碼復(fù)用率能到 90% 以上。云臺(tái)控制走的是廠商的 HTTP 接口跟播放器解耦前端只要發(fā)一個(gè)請(qǐng)求就行不需要任何原生能力。代價(jià)轉(zhuǎn)移到了服務(wù)端。你要維護(hù)一個(gè)流媒體服務(wù)要算帶寬要處理設(shè)備斷線重連要管會(huì)話和鑒權(quán)。以 1080p 主碼流 4Mbps 為例如果網(wǎng)關(guān)不做轉(zhuǎn)碼只做轉(zhuǎn)封裝一臺(tái) 4 核 8G 的服務(wù)器扛二三十路拉流問題不大但一旦要做 H.265 轉(zhuǎn) H.264因?yàn)闉g覽器對(duì) H.265 支持很差CPU 立刻成為瓶頸一路轉(zhuǎn)碼大概要吃掉一個(gè)核心的 30% 到 50%。這個(gè)成本很多人在選型階段根本沒算進(jìn)去。延遲上WebRTC 能做到 300 到 800 毫秒HTTP-FLV 大概 1 到 3 秒HLS 就別考慮了動(dòng)輒 5 秒以上云臺(tái)轉(zhuǎn)一下要等半天才看到畫面體驗(yàn)極差。2.4 三條路線橫向?qū)Ρ冗x型時(shí)到底看哪幾個(gè)指標(biāo)光講感受不夠我把關(guān)鍵維度整理成表格你對(duì)著自己的項(xiàng)目勾一下就知道該走哪條。對(duì)比維度路線一 web-view路線二 原生插件路線三 自建網(wǎng)關(guān)首幀延遲1 到 3 秒200 到 500 毫秒WebRTC 300 到 800 毫秒FLV 1 到 3 秒云臺(tái)控制體感一般有 0.5 秒左右滯后幾乎實(shí)時(shí)較好取決于接口響應(yīng)端覆蓋App、H5僅 AppApp、H5、小程序包體積增量幾乎為 020 到 40MB2 到 5MBUI 可控性極低高高截圖/錄像/AI不支持完整支持需網(wǎng)關(guān)側(cè)配合服務(wù)端成本無無有按路數(shù)和帶寬增長前端開發(fā)量極低高雙端各寫中長期維護(hù)難度受廠商頁面變更影響受 SDK 與 IDE 版本影響受運(yùn)維能力影響我的經(jīng)驗(yàn)是如果三個(gè)月內(nèi)要交付且只需要 App選路線一如果對(duì)延遲和控制精度有硬要求、長期迭代選路線二如果有小程序端訴求、或者未來要接多家廠商設(shè)備選路線三。最怕的是需求沒說清楚就先動(dòng)手做完發(fā)現(xiàn)方向不對(duì)那才是真的浪費(fèi)。3. 云臺(tái)控制才是真正的地雷區(qū)指令下發(fā)的細(xì)節(jié)與兜底3.1 控制通道和媒體通道必須解耦別把云臺(tái)指令塞進(jìn)播放鏈路新手最容易犯的錯(cuò)是把云臺(tái)控制和視頻播放當(dāng)成一件事。比如用 web-view 內(nèi)嵌播放頁就想著云臺(tái)按鈕也用它自帶的吧或者用原生插件云臺(tái)指令只能通過播放器的實(shí)例發(fā)。這兩種做法都會(huì)讓你在后期極其被動(dòng)——播放器崩了云臺(tái)就轉(zhuǎn)不了播放器換了云臺(tái)邏輯要重寫。正確的做法是把兩者徹底分開。視頻走視頻的通道云臺(tái)走云臺(tái)的通道兩者只在業(yè)務(wù)層做狀態(tài)同步。云臺(tái)通道的最優(yōu)解是廠商的 HTTP 接口形如POST /api/ptz/control參數(shù)里帶設(shè)備序列號(hào)、通道號(hào)、動(dòng)作命令、速度、持續(xù)時(shí)間。這條通道你可以用uni.request發(fā)三個(gè)端完全一致不依賴任何原生能力也不受播放器狀態(tài)影響。分離之后有個(gè)好處你可以做指令隊(duì)列和狀態(tài)機(jī)。比如用戶按住向左前端每秒發(fā) 5 次指令不是必須但某些廠商協(xié)議要求持續(xù)心跳松開時(shí)發(fā)一次停止。如果網(wǎng)絡(luò)抖動(dòng)導(dǎo)致某次停止指令丟了隊(duì)列里會(huì)有重試。而如果用播放器自帶的控制方法你根本不知道指令有沒有發(fā)出去。還有一點(diǎn)云臺(tái)指令的響應(yīng)要跟 UI 反饋配合。按下按鈕后按鈕變高亮收到接口返回成功之后再取消高亮如果 3 秒內(nèi)沒返回顯示控制超時(shí)請(qǐng)重試。這種細(xì)節(jié)看著小但在值班室場(chǎng)景里特別重要——值班員按了半天沒反應(yīng)會(huì)以為系統(tǒng)壞了反復(fù)狂點(diǎn)最后云臺(tái)轉(zhuǎn)過頭。3.2 方向、速度、時(shí)長三要素一次完整的指令封裝應(yīng)該長什么樣不同廠商的云臺(tái)指令字段長得不一樣但本質(zhì)都是三要素方向、速度、持續(xù)時(shí)間。方向一般有八個(gè)上、下、左、右、左上、左下、右上、右下加上變倍放大縮小、聚焦遠(yuǎn)/近、光圈大/小、預(yù)置位調(diào)用。速度是個(gè)整數(shù)檔位常見的是 1 到 8 檔或者 1 到 7 檔數(shù)字越大轉(zhuǎn)得越快。速度檔位和實(shí)際角速度的關(guān)系廠商手冊(cè)里通常會(huì)寫1 檔約等于最大轉(zhuǎn)速的 1/8。假設(shè)某球機(jī)的水平最大轉(zhuǎn)速是 200 度每秒那 4 檔就是 100 度每秒轉(zhuǎn)動(dòng) 90 度大概需要 0.9 秒。這個(gè)換算在調(diào)試時(shí)非常有用你可以據(jù)此判斷按一下按鈕轉(zhuǎn) 90 度大概要按多久也能據(jù)此設(shè)定前端的默認(rèn)速度。// 以某廠商 HTTP 接口為例封裝一個(gè)通用的云臺(tái)控制方法 const PTZ_SPEED_MAX 8 /** * param {Object} opts * param {String} opts.deviceId 設(shè)備序列號(hào) * param {Number} opts.channel 通道號(hào)通道 1 表示第一路 * param {Number} opts.command 1上 2下 3左 4右 5左上 6左下 7右上 8右下 9放大 10縮小 11停止 * param {Number} opts.speed 1-8 檔默認(rèn) 4 檔 * param {Number} opts.duration 持續(xù)毫秒數(shù)0 表示一直轉(zhuǎn)到收到停止指令 */ export async function ptzControl({ deviceId, channel 1, command, speed 4, duration 0 }) { // 速度檔位歸一化避免前端傳 0 或者 9 這種越界值 const safeSpeed Math.min(Math.max(Number(speed) || 4, 1), PTZ_SPEED_MAX) const res await uni.request({ url: ${BASE_URL}/api/ptz/control, method: POST, timeout: 5000, header: { Content-Type: application/json, Authorization: Bearer ${getToken()} }, data: { deviceId, channel, command, speed: safeSpeed, duration } }) if (res.data.code ! 0) throw new Error(res.data.msg || 云臺(tái)指令下發(fā)失敗) return res.data }配套還需要一個(gè)停止的兜底邏輯后面一節(jié)細(xì)說。這里先強(qiáng)調(diào)一個(gè)細(xì)節(jié)不要在前端做速度的百分比換算。有些同學(xué)喜歡把滑動(dòng)條做成 0 到 100然后除以 12.5 轉(zhuǎn)成檔位結(jié)果就是滑到 50 這個(gè)位置時(shí)四舍五入到 4 檔但用戶以為速度是一半。直接在 UI 上暴露 1 到 8 這八個(gè)檔位或者用慢/中/快三檔映射到 2/4/6比百分比直觀得多也少一類溝通成本。3.3 停止指令丟失的四種典型場(chǎng)景以及我用的三層兜底這是我在項(xiàng)目里踩得最狠的一個(gè)坑。云臺(tái)開始轉(zhuǎn)和停止轉(zhuǎn)是兩條獨(dú)立指令一旦只發(fā)了開始沒發(fā)停止云臺(tái)就會(huì)一路轉(zhuǎn)到機(jī)械限位撞上去發(fā)出咔咔的聲音長時(shí)間這樣對(duì)電機(jī)是實(shí)打?qū)嵉膿p傷。我遇到過的觸發(fā)場(chǎng)景有四個(gè)場(chǎng)景一手指滑出按鈕范圍。用戶按住向左手指往外一滑touchend在按鈕上沒觸發(fā)touchcancel如果沒監(jiān)聽停止指令就丟了。場(chǎng)景二頁面切后臺(tái)。用戶按住按鈕的時(shí)候來了個(gè)電話應(yīng)用進(jìn)后臺(tái)JS 線程被掛起回來的時(shí)候按鈕已經(jīng)不在按下狀態(tài)了。場(chǎng)景三路由跳轉(zhuǎn)。按住按鈕的同時(shí)點(diǎn)了返回頁面卸載未發(fā)出的指令沒了。場(chǎng)景四網(wǎng)絡(luò)抖動(dòng)。停止指令發(fā)出去了但接口超時(shí)前端拋異常走了錯(cuò)誤分支沒有重試。我的解決方案是三層兜底實(shí)測(cè)下來再?zèng)]出過問題第一層事件層面全覆蓋。除了touchstart和touchend必須同時(shí)監(jiān)聽touchcancel并且在document級(jí)別App 端用plus的全局事件監(jiān)聽指針抬起保證手指離開屏幕的任何方式都能觸發(fā)停止。第二層定時(shí)器兜底。每次下發(fā)開始轉(zhuǎn)動(dòng)時(shí)同時(shí)啟動(dòng)一個(gè)定時(shí)器時(shí)長等于預(yù)期的最大轉(zhuǎn)動(dòng)時(shí)間比如 5 秒超時(shí)后強(qiáng)制發(fā)一次停止指令并彈一個(gè)輕提示云臺(tái)轉(zhuǎn)動(dòng)超時(shí)已自動(dòng)停止。第三層狀態(tài)回讀校驗(yàn)。停止指令發(fā)出后延遲 500 毫秒調(diào)一次廠商的查詢?cè)婆_(tái)狀態(tài)接口如果返回的狀態(tài)仍是在轉(zhuǎn)動(dòng)再補(bǔ)發(fā)一次停止最多重試兩次。let ptzTimer null let isMoving false async function startMove(command) { if (isMoving) await stopMove() // 防止上一條指令還沒停就發(fā)新指令 isMoving true await ptzControl({ deviceId, command, speed, duration: 0 }) clearTimeout(ptzTimer) ptzTimer setTimeout(() { stopMove(超時(shí)自動(dòng)停止) }, 5000) } async function stopMove(reason ) { if (!isMoving) return clearTimeout(ptzTimer) isMoving false const cmd 11 try { await ptzControl({ deviceId, command: cmd }) } catch (e) { // 失敗重試一次 try { await ptzControl({ deviceId, command: cmd }) } catch (e2) {} } setTimeout(async () { try { const status await queryPtzStatus(deviceId) if (status.moving) await ptzControl({ deviceId, command: cmd }) } catch (e) {} }, 500) } // 頁面卸載時(shí)也要停 onUnload(() { stopMove(頁面卸載) }) onHide(() { stopMove(應(yīng)用進(jìn)入后臺(tái)) })提示isMoving這個(gè)狀態(tài)鎖一定要加。用戶連點(diǎn)方向鍵的時(shí)候沒有鎖的話會(huì)并發(fā)發(fā)出十幾條指令設(shè)備端處理不過來表現(xiàn)就是畫面卡一下然后猛地轉(zhuǎn)一大截非常嚇人。4. 跨端適配的差異清單三個(gè)端根本不是一回事4.1 小程序端live-player 的能力邊界要先摸清很多人默認(rèn)uniapp 一套代碼多端跑以為小程序端也能跑原生插件這是錯(cuò)的。小程序不支持原生插件只支持live-player組件而這個(gè)組件對(duì)協(xié)議有限制——一般支持 RTMP 和 FLV不支持 RTSP也不能播放 HLS 的直播流點(diǎn)播可以。所以如果你的設(shè)備只能出 RTSP小程序端就必須要有一個(gè)轉(zhuǎn)封裝的網(wǎng)關(guān)繞不開。live-player還有幾個(gè)特點(diǎn)要提前知道它是原生組件層級(jí)永遠(yuǎn)在最上面普通的view蓋不住它只能用cover-view和cover-image。要做云臺(tái)控制按鈕浮在畫面上就得用cover-view寫而cover-view支持的樣式非常有限圓角、陰影、漸變基本都不生效。我做過一版最后干脆把控制區(qū)放在畫面下方不做懸浮反而更清爽。另外live-player的清晰度和碼流切換需要在初始化時(shí)通過mode參數(shù)指定運(yùn)行中切換要銷毀重建組件會(huì)有明顯黑屏。如果業(yè)務(wù)需要頻繁切主/子碼流建議直接固定用子碼流720p、1Mbps 左右畫質(zhì)夠看延遲和流量都友好。關(guān)于小程序的準(zhǔn)入live-player屬于實(shí)時(shí)音視頻類組件對(duì)小程序主體的服務(wù)類目有要求不是隨便注冊(cè)一個(gè)號(hào)就能用。上線前一定先確認(rèn)自己賬號(hào)是否具備條件這個(gè)環(huán)節(jié)卡住的話前端做得再好也發(fā)不出去。這一點(diǎn)在項(xiàng)目排期的時(shí)候就要問清楚別等到提審才發(fā)現(xiàn)。4.2 App 端nvue 與 vue 的組件層級(jí)問題App 端如果走原生插件畫面通常是一個(gè)原生view它和 uniapp 的 vue 頁面不在一個(gè)渲染層里。在 vue 頁面里這個(gè)原生 view 會(huì)蓋住所有普通元素跟小程序的原生組件一個(gè)毛病。解決辦法是用nvue頁面weex 渲染它的層級(jí)控制更接近原生可以把原生 view 嵌進(jìn)去。但 nvue 的坑也不少。它不支持大部分 CSS 選擇器只支持 flex 布局position: fixed的行為跟普通 vue 不一樣列表必須用list組件而不是scroll-view。我的做法是把監(jiān)控畫面單獨(dú)做成一個(gè) nvue 頁面控制面板、設(shè)備列表這些用普通 vue 頁面通過uni.navigateTo跳轉(zhuǎn)兩邊只傳設(shè)備 ID 和通道號(hào)。這樣既繞開了層級(jí)問題又不用把整個(gè)應(yīng)用改寫成 nvue。還有一個(gè)容易忽略的點(diǎn)App 端的硬解碼。低端安卓機(jī)軟解 1080p 會(huì)直接卡成幻燈片一定要在插件里開啟硬解。安卓的硬解兼容性是出了名的差不同芯片平臺(tái)高通、聯(lián)發(fā)科、紫光展銳表現(xiàn)差異很大有些機(jī)型開硬解會(huì)花屏。我的經(jīng)驗(yàn)是做一個(gè)開關(guān)默認(rèn)開硬解同時(shí)在設(shè)置里留一個(gè)兼容模式給用戶手動(dòng)關(guān)掉遇到花屏讓他自己切比你在代碼里到處加機(jī)型白名單靠譜。4.3 H5 端解碼能力和跨域是兩個(gè)繞不過去的門檻瀏覽器端的問題主要是兩個(gè)。一是編碼格式H.265 在 Chrome 上的支持非常差基本要靠 WebAssembly 軟解1080p 軟解 CPU 直接拉滿風(fēng)扇狂轉(zhuǎn)。所以面向 H5 的方案一定要在網(wǎng)關(guān)側(cè)把 H.265 轉(zhuǎn)成 H.264或者干脆把設(shè)備的子碼流編碼格式設(shè)成 H.264。二是跨域和鑒權(quán)。flv.js播 HTTP-FLV 需要服務(wù)端允許跨域Access-Control-Allow-Origin要配好。如果流地址帶 tokentoken 過期后播放器不會(huì)自動(dòng)重新拉流表現(xiàn)就是畫面卡住不動(dòng)也不報(bào)錯(cuò)。我一般會(huì)監(jiān)聽播放器的error和statistics_info事件超過 5 秒沒有新數(shù)據(jù)就主動(dòng)銷毀重建同時(shí)刷新 token。H5 還有一個(gè)隱形問題瀏覽器的自動(dòng)播放策略。帶聲音的流必須用戶交互之后才能播所以監(jiān)控頁面的初始狀態(tài)最好是靜音畫面出來后給一個(gè)開啟聲音的按鈕。不然用戶進(jìn)去看到一片黑其實(shí)是播放被攔了控制臺(tái)里一行提示非技術(shù)的同事根本找不到原因。5. 實(shí)測(cè)數(shù)據(jù)延遲怎么量、并發(fā)怎么算、內(nèi)存怎么控5.1 延遲的逐段拆解與測(cè)量方法先說測(cè)量方法這個(gè)很實(shí)用用兩臺(tái)手機(jī)一臺(tái)打開高精度秒表網(wǎng)頁另一臺(tái)顯示監(jiān)控畫面把兩臺(tái)手機(jī)放在一起用第三臺(tái)手機(jī)的高速攝像120 幀或 240 幀拍下來看秒表數(shù)字和畫面里秒表數(shù)字差多少幀。這個(gè)土辦法比任何工具都準(zhǔn)我在項(xiàng)目驗(yàn)收時(shí)經(jīng)常用客戶一看就服。延遲的構(gòu)成可以拆成四段設(shè)備采集編碼 80 到 150 毫秒、網(wǎng)絡(luò)傳輸 30 到 200 毫秒取決于是否走公網(wǎng)、服務(wù)端轉(zhuǎn)封裝緩沖 100 毫秒到 3 秒這里是最大的變量、前端解碼渲染 50 到 150 毫秒。優(yōu)化的重點(diǎn)全在第三段。如果走 HTTP-FLV播放器默認(rèn)會(huì)緩存一個(gè) GOP 的數(shù)據(jù)才開始播GOP 設(shè)成 4 秒的話光等待就是 2 秒起。解決辦法是讓設(shè)備把 I 幀間隔調(diào)到 1 秒甚至 0.5 秒同時(shí)關(guān)閉 B 幀播放器側(cè)把enableStashBuffer設(shè)為false、stashInitialSize調(diào)小。我實(shí)測(cè)過這樣一套組合拳能把 FLV 的延遲從 3 秒壓到 1.2 秒左右。如果對(duì)延遲有硬要求比如需要跟著云臺(tái)轉(zhuǎn)動(dòng)實(shí)時(shí)看畫面變化延遲超過 1 秒會(huì)非常難受那就只能上 WebRTC。它沒有 GOP 緩沖的概念靠 NACK 和 PLI 做丟包重傳和關(guān)鍵幀請(qǐng)求做到 500 毫秒以內(nèi)不稀奇。代價(jià)是服務(wù)端的復(fù)雜度和 CPU 開銷上去了得權(quán)衡。傳輸方式實(shí)測(cè)首幀延遲云臺(tái)跟隨體感服務(wù)端開銷適用場(chǎng)景HLS5 到 10 秒完全不能用低只看回放不做控制HTTP-FLV1.2 到 3 秒勉強(qiáng)可用中一般預(yù)覽、值班監(jiān)看WebRTC0.3 到 0.8 秒流暢高需要精準(zhǔn)控制的場(chǎng)景原生 SDK 直連0.2 到 0.5 秒流暢無App 專屬追求極致體驗(yàn)5.2 多路并發(fā)、內(nèi)存與帶寬的賬要提前算做監(jiān)控方案必算兩筆賬帶寬和內(nèi)存。帶寬方面假設(shè)一路 1080p 主碼流 4Mbps一個(gè) 4 宮格頁面就是 16Mbps。如果有 10 個(gè)用戶同時(shí)看 4 宮格網(wǎng)關(guān)的出口帶寬就是 160Mbps換算成下載速度是 20MB/s。這個(gè)數(shù)字很多人在方案評(píng)審時(shí)才意識(shí)到然后回頭要求前端降碼流。我的建議是默認(rèn)走子碼流720p 大概 1 到 1.5Mbps4 宮格 6Mbps10 個(gè)用戶 60Mbps一臺(tái)常規(guī)云服務(wù)器就能扛住需要看細(xì)節(jié)時(shí)再單畫面切主碼流。存儲(chǔ)方面如果要做本地或服務(wù)端錄像按 4Mbps 算一天一路就是4Mbps × 86400 秒 ÷ 8 43.2GB。存 30 天就是 1.3TB 一路十路就是 13TB。這個(gè)賬一定要在需求階段就算給客戶看否則他覺得錄個(gè)像能有多大。內(nèi)存方面安卓機(jī)上每一路 1080p 解碼大概占 80 到 150MB 內(nèi)存4 宮格就是 400 到 600MB加上應(yīng)用本身低端機(jī)3GB 內(nèi)存很容易被系統(tǒng)殺掉。所以我把并發(fā)路數(shù)硬性限制在 4 路超過就提示最多同時(shí)預(yù)覽 4 路并且做分頁加載——用戶滑到第二頁時(shí)才初始化新的播放實(shí)例滑走的立刻銷毀。實(shí)測(cè)下來這樣一來內(nèi)存峰值能降 40% 左右長時(shí)間運(yùn)行8 小時(shí)以上也不會(huì)出現(xiàn)明顯的內(nèi)存增長。還有一個(gè)細(xì)節(jié)頁面切后臺(tái)要主動(dòng)停流。很多應(yīng)用切到后臺(tái)還在拉流解碼手機(jī)燙得厲害電量掉得飛快。onHide里調(diào)stopPlayonShow里重新startPlay兩行代碼的事用戶口碑差別很大。6. 排錯(cuò)速查這些坑我基本都踩過一遍6.1 畫面類問題黑屏、花屏、卡頓的排查順序黑屏是最常見的報(bào)障但原因可能有七八種按下面的順序查能省很多時(shí)間。第一步看播放器有沒有觸發(fā)播放成功回調(diào)。沒有觸發(fā)就是取流地址或鑒權(quán)的問題先用 VLC 之類的通用播放器驗(yàn)證地址本身通不通排除設(shè)備側(cè)故障。第二步看控制臺(tái)有沒有跨域報(bào)錯(cuò)。有就是服務(wù)端 CORS 沒配或者用了 HTTPS 頁面去拉 HTTP 的流混合內(nèi)容被瀏覽器攔截這是 H5 端最高頻的原因。第三步看編碼格式。花屏大概率是 H.265 用軟解或者硬解兼容性問題切成 H.264 試試如果是綠屏加馬賽克一般是碼流不完整或者網(wǎng)絡(luò)丟包嚴(yán)重。第四步看內(nèi)存?？D但不報(bào)錯(cuò)用開發(fā)者工具看一眼內(nèi)存曲線如果持續(xù)上漲就是播放實(shí)例沒有銷毀切頁面時(shí)stopPlay沒調(diào)。6.2 控制類問題指令發(fā)出去了但云臺(tái)不動(dòng)云臺(tái)不動(dòng)的情況我的排查順序是先確認(rèn)接口返回碼很多廠商接口返回 200 但 body 里的 code 是錯(cuò)誤碼前端只看 HTTP 狀態(tài)就誤判成功了再確認(rèn)通道號(hào)多通道設(shè)備比如 NVR 下掛多個(gè)攝像機(jī)通道號(hào)從 1 開始還是從 0 開始不同廠商不一樣填錯(cuò)了指令發(fā)給了不存在的通道最后確認(rèn)設(shè)備是否被其他客戶端占用某些設(shè)備同時(shí)只允許一個(gè)控制端值班室的大屏占著控制權(quán)你這邊發(fā)指令就沒反應(yīng)。還有一種情況是能轉(zhuǎn)但轉(zhuǎn)得很慢或者很快。這就是速度檔位的問題檢查一下前端傳的是 1 到 8 還是 0 到 100映射錯(cuò)了就會(huì)出這種效果。我有一次就是因?yàn)閮商状a里一套傳檔位一套傳百分比聯(lián)調(diào)了半天。6.3 打包與兼容類問題插件在真機(jī)上失效原生插件最常見的報(bào)錯(cuò)是方法未定義八成是自定義基座沒打。標(biāo)準(zhǔn)基座里沒有你的插件必須打自定義基座才能調(diào)試這個(gè)新人幾乎必踩。其次是**.so架構(gòu)缺失**報(bào)UnsatisfiedLinkError檢查build.gradle里的abiFilters和目標(biāo)機(jī) CPU 架構(gòu)是否匹配現(xiàn)在主流是arm64-v8a但工控機(jī)、一體機(jī)不少還是 32 位。第三是iOS 的隱私權(quán)限描述。訪問麥克風(fēng)對(duì)講、相冊(cè)截圖保存都需要在Info.plist里配描述文案缺了會(huì)在調(diào)用瞬間閃退日志里還不一定有明確提示。最后是插件版本與 IDE 版本不匹配表現(xiàn)是編譯通過但運(yùn)行時(shí)找不到方法。解決辦法是清基座緩存、重新打自定義基座別在這上面浪費(fèi)時(shí)間猜。現(xiàn)象最可能原因快速驗(yàn)證方式處理方式畫面全黑無報(bào)錯(cuò)token 過期或跨域用通用播放器驗(yàn)證流地址刷新 token、配置 CORS畫面花屏H.265 硬解兼容性切 H.264 或關(guān)硬解加兼容模式開關(guān)云臺(tái)無響應(yīng)通道號(hào)錯(cuò)誤或設(shè)備被占用看接口 body 的 code校正通道號(hào)、釋放控制權(quán)云臺(tái)轉(zhuǎn)不停停止指令丟失抓包看是否有停止請(qǐng)求加三層兜底邏輯插件方法未定義未打自定義基座看控制臺(tái)報(bào)錯(cuò)棧重打自定義基座運(yùn)行一段時(shí)間卡死播放實(shí)例未銷毀觀察內(nèi)存曲線頁面切換時(shí) stopPlay7. 選型建議與落地節(jié)奏別一上來就啃硬骨頭7.1 按團(tuán)隊(duì)規(guī)模和訴求對(duì)號(hào)入座如果團(tuán)隊(duì)只有一兩個(gè)前端且只做 App、交付周期緊直接走路線一用廠商的 H5 頁面把流程跑通先把業(yè)務(wù)價(jià)值交付出去后面再優(yōu)化。如果對(duì)云臺(tái)精度、截圖、AI 識(shí)別有硬需求且團(tuán)隊(duì)有安卓或 iOS 的封裝能力走路線二性能是最優(yōu)的。如果要多端覆蓋、要接多家廠商設(shè)備、團(tuán)隊(duì)有服務(wù)端運(yùn)維能力走路線三前期投入大但天花板最高。還有一個(gè)混合策略我經(jīng)常用App 端走原生插件H5 和小程序端走網(wǎng)關(guān)加 FLV。同一個(gè)業(yè)務(wù)頁面通過條件編譯區(qū)分播放組件上層的設(shè)備列表、云臺(tái)控制面板、報(bào)警信息這些邏輯完全復(fù)用。這樣既保證了主場(chǎng)景的體驗(yàn)又覆蓋了次要場(chǎng)景代價(jià)只是多維護(hù)一個(gè)網(wǎng)關(guān)。7.2 我給一個(gè)三個(gè)月的落地節(jié)奏第一個(gè)月做驗(yàn)證不要寫業(yè)務(wù)代碼。拿一臺(tái)真實(shí)設(shè)備把三條路線各跑一個(gè)最小 demo重點(diǎn)測(cè)三件事延遲用秒表法量、云臺(tái)控制體感、目標(biāo)機(jī)型的兼容性。這一步做完路線基本就定了而且后面的返工風(fēng)險(xiǎn)能降一大半。第二個(gè)月做骨架。把播放組件、云臺(tái)控制器、設(shè)備管理三個(gè)模塊拆開播放組件對(duì)外只暴露play、stop、snapshot三個(gè)方法云臺(tái)控制器對(duì)外只暴露move、stop、gotoPreset。用接口約束住后面換實(shí)現(xiàn)只改一個(gè)文件。第三個(gè)月做適配和打磨。集中處理各端差異、內(nèi)存優(yōu)化、異常兜底然后拉真實(shí)用戶值班員、巡檢員試用一周。他們對(duì)卡不卡、轉(zhuǎn)得準(zhǔn)不準(zhǔn)的感知比任何測(cè)試用例都準(zhǔn)往往能挖出你在實(shí)驗(yàn)室里發(fā)現(xiàn)不了的問題。最后分享一個(gè)我自己踩出來的小體會(huì)云臺(tái)控制這件事寧可讓用戶多點(diǎn)兩下也不要讓它轉(zhuǎn)得太猛。我給所有項(xiàng)目的默認(rèn)速度都設(shè)成 4 檔中速并且在設(shè)置里提供精細(xì)模式2 檔。用戶第一次用會(huì)嫌慢但用一周之后沒人愿意調(diào)回去——轉(zhuǎn)太快根本對(duì)不準(zhǔn)尤其是要看清車牌或者人臉的時(shí)候?qū)幙陕病＿@個(gè)參數(shù)看著不起眼卻是使用體驗(yàn)里最容易被忽略、也最容易調(diào)好的一環(huán)。 uniapp接入云臺(tái)相機(jī)：三條路線與PTZ控制避坑指南
1. 先聊清楚uniapp 接云臺(tái)相機(jī)這件事到底難在哪我做安防類項(xiàng)目有幾年了最近半年被問得最多的一個(gè)問題就是uniapp 能不能接云臺(tái)相機(jī)云臺(tái)插件到底好不好用。這個(gè)問題表面上是問插件實(shí)際上是問一整套取流、控制、跨端適配的技術(shù)路線能不能成立。我前后在三個(gè)項(xiàng)目里試過不同做法一個(gè)園區(qū)值班室的中控屏、一個(gè)連鎖門店的巡店應(yīng)用、還有一個(gè)設(shè)備巡檢的移動(dòng)作業(yè)端規(guī)模都不大但把該踩的坑基本都踩了一遍。先給結(jié)論uniapp 跨平臺(tái)監(jiān)控方案是可行的但它的可行有明確邊界。你能用一套代碼同時(shí)出 H5、安卓 App、iOS App甚至小程序這個(gè)誘惑太大尤其是團(tuán)隊(duì)只有一兩個(gè)前端的時(shí)候。可視頻監(jiān)控這個(gè)場(chǎng)景天生重原生——解碼、渲染、硬件加速、低延遲傳輸每一環(huán)都貼著操作系統(tǒng)底層走而 uniapp 的強(qiáng)項(xiàng)是視圖層和業(yè)務(wù)層的跨端復(fù)用兩者中間隔著一層原生橋接摩擦就發(fā)生在這一層。下文我把標(biāo)題里說的云臺(tái)插件統(tǒng)一理解為某安防廠商下文簡(jiǎn)稱 A 廠商提供的、封裝了設(shè)備登錄、實(shí)時(shí)預(yù)覽、云臺(tái)控制PTZ、錄像回放、抓圖等能力的 SDK 插件形態(tài)產(chǎn)品。它可能是一個(gè) uni 原生插件也可能是一個(gè) H5 播放頁還可能只是一套 HTTP 接口加標(biāo)準(zhǔn)流地址。形態(tài)不同優(yōu)劣差別巨大這也是很多人測(cè)評(píng)結(jié)果互相矛盾的原因——大家測(cè)的壓根不是同一個(gè)東西。這篇文章適合三類人看正在做技術(shù)選型的項(xiàng)目負(fù)責(zé)人、準(zhǔn)備動(dòng)手接入的前端或移動(dòng)端開發(fā)、以及被一套代碼多端跑打動(dòng)但還沒踩過坑的產(chǎn)品同學(xué)。我會(huì)把三條主流路線的架構(gòu)、云臺(tái)指令的細(xì)節(jié)、跨端差異、實(shí)測(cè)數(shù)據(jù)和排錯(cuò)經(jīng)驗(yàn)全部攤開講參數(shù)和計(jì)算過程都給出來能直接抄的部分我會(huì)寫得足夠具體。2. 三條技術(shù)路線的架構(gòu)拆解與優(yōu)劣勢(shì)對(duì)照2.1 路線一web-view 內(nèi)嵌廠商 H5 監(jiān)控頁改動(dòng)最小的偷懶方案這是上手最快的一條路。A 廠商通常會(huì)提供一個(gè)免插件的網(wǎng)頁版預(yù)覽頁地址里帶上設(shè)備序列號(hào)、通道號(hào)、token 之類的參數(shù)你只要在 uniapp 里放一個(gè)web-view組件把地址塞進(jìn)去畫面就出來了云臺(tái)控制按鈕廠商也已經(jīng)畫好了。我在門店巡店那個(gè)項(xiàng)目里第一版就是這么干的從拿到地址到跑通兩個(gè)小時(shí)。它的優(yōu)勢(shì)非常直接零原生開發(fā)、零協(xié)議理解、零解碼邏輯。廠商網(wǎng)頁內(nèi)部已經(jīng)把取流、解碼、云臺(tái)指令封裝好了你不需要知道背后用的是 WebSocket 推流還是 HTTP-FLV也不需要關(guān)心 H.264 還是 H.265。對(duì)于只要求能看、能轉(zhuǎn)、能回放的輕量場(chǎng)景這條路性價(jià)比最高。但坑也很密集。第一是通信問題網(wǎng)頁和 uniapp 之間只能靠postMessage或者 URL 傳參雙向通信在 App 端勉強(qiáng)能用小程序端受限于業(yè)務(wù)域名校驗(yàn)?zāi)茏龅降氖虑楦?。第二是UI 不可控廠商頁面永遠(yuǎn)帶著自己的 logo、自己的按鈕布局你想把它嵌進(jìn)自己的設(shè)計(jì)體系里幾乎不可能只能整頁鋪滿。第三是拿不到視頻幀截圖、AI 識(shí)別、本地錄像這些需求直接判死刑。第四是登錄態(tài)和 token 管理A 廠商的 H5 地址一般有效期很短頁面切后臺(tái)再回來經(jīng)常要重新鑒權(quán)用戶看到的就是一片黑屏加一個(gè)轉(zhuǎn)圈。我印象最深的一次是客戶要求點(diǎn)擊畫面任意位置云臺(tái)自動(dòng)把那個(gè)點(diǎn)移到畫面中心也就是常說的 3D 定位。廠商 H5 頁面本身支持但它是內(nèi)部邏輯我們無法從外部觸發(fā)最后只能改成讓用戶自己按方向鍵。這就是路線一的本質(zhì)你借用了別人的能力也接受了別人的邊界。2.2 路線二原生插件直連 SDK延遲最低但維護(hù)成本最高第二條路是把 A 廠商的移動(dòng)端 SDK 封裝成 uni 原生插件。安卓側(cè)通常是幾個(gè).aar加一堆.so動(dòng)態(tài)庫iOS 側(cè)是.framework然后按 uniapp 原生插件的規(guī)范暴露方法給 JS 調(diào)用比如login、startRealPlay、ptzControl、stopRealPlay、startPlayback。這條路是性能天花板。SDK 直連設(shè)備或者直連廠商的流媒體服務(wù)走的是私有協(xié)議延遲能壓到 200 到 500 毫秒云臺(tái)指令也是走專用通道按下按鈕到畫面轉(zhuǎn)動(dòng)體感幾乎是實(shí)時(shí)的。功能也最全預(yù)置位、巡航、抓圖存本地、雙向?qū)χv、本地錄像、碼流切換主碼流/子碼流全都有。代價(jià)是雙端各寫一遍。安卓和 iOS 的 SDK 接口長得完全不一樣安卓里叫PTZControliOS 里可能是ptzControlWithCommand參數(shù)順序也不同你得寫兩套橋接代碼。包體積也會(huì)明顯變大我做過的一個(gè)版本加上.so之后安裝包從 18MB 漲到了 62MB雖然可以做 ABI 拆分只保留arm64-v8a但還是要多出二十多兆。更麻煩的是版本耦合。uni 原生插件要跟 HBuilderX 的版本、基座版本對(duì)齊云打包的自定義基座一旦和插件不匹配就是白屏或者方法找不到。我遇到過一次升級(jí)了 IDE 之后插件里某個(gè)回調(diào)不再觸發(fā)排查了半天才發(fā)現(xiàn)是基座緩存沒清。另外這條路完全放棄了 H5 和小程序如果你老板一開始說我們要多端最后發(fā)現(xiàn)只有 App 能用返工成本很高。注意封裝 A 廠商 SDK 時(shí)要特別留意.so的架構(gòu)裁剪只保留arm64-v8a能省一半體積但部分老舊的安卓一體機(jī)是 32 位系統(tǒng)砍掉armeabi-v7a之后會(huì)直接崩在UnsatisfiedLinkError。上線前一定要確認(rèn)目標(biāo)機(jī)型的 CPU 架構(gòu)。2.3 路線三自建流媒體網(wǎng)關(guān)加通用播放器折中但最費(fèi)運(yùn)維第三條路是我現(xiàn)在最推薦的中間方案服務(wù)端把設(shè)備的 RTSP 流拉過來轉(zhuǎn)成 WebRTC 或 HTTP-FLV前端用統(tǒng)一的播放器組件播。設(shè)備側(cè)只需要開放 RTSP 地址和賬號(hào)密碼剩下的交給網(wǎng)關(guān)。H5 和 App 用flv.js或者 WebRTC 播放器小程序用live-player組件播 RTMP 或 FLV。這條路的最大好處是前端徹底統(tǒng)一。同一套播放器封裝邏輯通過條件編譯在三個(gè)端上跑業(yè)務(wù)代碼復(fù)用率能到 90% 以上。云臺(tái)控制走的是廠商的 HTTP 接口跟播放器解耦前端只要發(fā)一個(gè)請(qǐng)求就行不需要任何原生能力。代價(jià)轉(zhuǎn)移到了服務(wù)端。你要維護(hù)一個(gè)流媒體服務(wù)要算帶寬要處理設(shè)備斷線重連要管會(huì)話和鑒權(quán)。以 1080p 主碼流 4Mbps 為例如果網(wǎng)關(guān)不做轉(zhuǎn)碼只做轉(zhuǎn)封裝一臺(tái) 4 核 8G 的服務(wù)器扛二三十路拉流問題不大但一旦要做 H.265 轉(zhuǎn) H.264因?yàn)闉g覽器對(duì) H.265 支持很差CPU 立刻成為瓶頸一路轉(zhuǎn)碼大概要吃掉一個(gè)核心的 30% 到 50%。這個(gè)成本很多人在選型階段根本沒算進(jìn)去。延遲上WebRTC 能做到 300 到 800 毫秒HTTP-FLV 大概 1 到 3 秒HLS 就別考慮了動(dòng)輒 5 秒以上云臺(tái)轉(zhuǎn)一下要等半天才看到畫面體驗(yàn)極差。2.4 三條路線橫向?qū)Ρ冗x型時(shí)到底看哪幾個(gè)指標(biāo)光講感受不夠我把關(guān)鍵維度整理成表格你對(duì)著自己的項(xiàng)目勾一下就知道該走哪條。對(duì)比維度路線一 web-view路線二 原生插件路線三 自建網(wǎng)關(guān)首幀延遲1 到 3 秒200 到 500 毫秒WebRTC 300 到 800 毫秒FLV 1 到 3 秒云臺(tái)控制體感一般有 0.5 秒左右滯后幾乎實(shí)時(shí)較好取決于接口響應(yīng)端覆蓋App、H5僅 AppApp、H5、小程序包體積增量幾乎為 020 到 40MB2 到 5MBUI 可控性極低高高截圖/錄像/AI不支持完整支持需網(wǎng)關(guān)側(cè)配合服務(wù)端成本無無有按路數(shù)和帶寬增長前端開發(fā)量極低高雙端各寫中長期維護(hù)難度受廠商頁面變更影響受 SDK 與 IDE 版本影響受運(yùn)維能力影響我的經(jīng)驗(yàn)是如果三個(gè)月內(nèi)要交付且只需要 App選路線一如果對(duì)延遲和控制精度有硬要求、長期迭代選路線二如果有小程序端訴求、或者未來要接多家廠商設(shè)備選路線三。最怕的是需求沒說清楚就先動(dòng)手做完發(fā)現(xiàn)方向不對(duì)那才是真的浪費(fèi)。3. 云臺(tái)控制才是真正的地雷區(qū)指令下發(fā)的細(xì)節(jié)與兜底3.1 控制通道和媒體通道必須解耦別把云臺(tái)指令塞進(jìn)播放鏈路新手最容易犯的錯(cuò)是把云臺(tái)控制和視頻播放當(dāng)成一件事。比如用 web-view 內(nèi)嵌播放頁就想著云臺(tái)按鈕也用它自帶的吧或者用原生插件云臺(tái)指令只能通過播放器的實(shí)例發(fā)。這兩種做法都會(huì)讓你在后期極其被動(dòng)——播放器崩了云臺(tái)就轉(zhuǎn)不了播放器換了云臺(tái)邏輯要重寫。正確的做法是把兩者徹底分開。視頻走視頻的通道云臺(tái)走云臺(tái)的通道兩者只在業(yè)務(wù)層做狀態(tài)同步。云臺(tái)通道的最優(yōu)解是廠商的 HTTP 接口形如POST /api/ptz/control參數(shù)里帶設(shè)備序列號(hào)、通道號(hào)、動(dòng)作命令、速度、持續(xù)時(shí)間。這條通道你可以用uni.request發(fā)三個(gè)端完全一致不依賴任何原生能力也不受播放器狀態(tài)影響。分離之后有個(gè)好處你可以做指令隊(duì)列和狀態(tài)機(jī)。比如用戶按住向左前端每秒發(fā) 5 次指令不是必須但某些廠商協(xié)議要求持續(xù)心跳松開時(shí)發(fā)一次停止。如果網(wǎng)絡(luò)抖動(dòng)導(dǎo)致某次停止指令丟了隊(duì)列里會(huì)有重試。而如果用播放器自帶的控制方法你根本不知道指令有沒有發(fā)出去。還有一點(diǎn)云臺(tái)指令的響應(yīng)要跟 UI 反饋配合。按下按鈕后按鈕變高亮收到接口返回成功之后再取消高亮如果 3 秒內(nèi)沒返回顯示控制超時(shí)請(qǐng)重試。這種細(xì)節(jié)看著小但在值班室場(chǎng)景里特別重要——值班員按了半天沒反應(yīng)會(huì)以為系統(tǒng)壞了反復(fù)狂點(diǎn)最后云臺(tái)轉(zhuǎn)過頭。3.2 方向、速度、時(shí)長三要素一次完整的指令封裝應(yīng)該長什么樣不同廠商的云臺(tái)指令字段長得不一樣但本質(zhì)都是三要素方向、速度、持續(xù)時(shí)間。方向一般有八個(gè)上、下、左、右、左上、左下、右上、右下加上變倍放大縮小、聚焦遠(yuǎn)/近、光圈大/小、預(yù)置位調(diào)用。速度是個(gè)整數(shù)檔位常見的是 1 到 8 檔或者 1 到 7 檔數(shù)字越大轉(zhuǎn)得越快。速度檔位和實(shí)際角速度的關(guān)系廠商手冊(cè)里通常會(huì)寫1 檔約等于最大轉(zhuǎn)速的 1/8。假設(shè)某球機(jī)的水平最大轉(zhuǎn)速是 200 度每秒那 4 檔就是 100 度每秒轉(zhuǎn)動(dòng) 90 度大概需要 0.9 秒。這個(gè)換算在調(diào)試時(shí)非常有用你可以據(jù)此判斷按一下按鈕轉(zhuǎn) 90 度大概要按多久也能據(jù)此設(shè)定前端的默認(rèn)速度。// 以某廠商 HTTP 接口為例封裝一個(gè)通用的云臺(tái)控制方法 const PTZ_SPEED_MAX 8 /** * param {Object} opts * param {String} opts.deviceId 設(shè)備序列號(hào) * param {Number} opts.channel 通道號(hào)通道 1 表示第一路 * param {Number} opts.command 1上 2下 3左 4右 5左上 6左下 7右上 8右下 9放大 10縮小 11停止 * param {Number} opts.speed 1-8 檔默認(rèn) 4 檔 * param {Number} opts.duration 持續(xù)毫秒數(shù)0 表示一直轉(zhuǎn)到收到停止指令 */ export async function ptzControl({ deviceId, channel 1, command, speed 4, duration 0 }) { // 速度檔位歸一化避免前端傳 0 或者 9 這種越界值 const safeSpeed Math.min(Math.max(Number(speed) || 4, 1), PTZ_SPEED_MAX) const res await uni.request({ url: ${BASE_URL}/api/ptz/control, method: POST, timeout: 5000, header: { Content-Type: application/json, Authorization: Bearer ${getToken()} }, data: { deviceId, channel, command, speed: safeSpeed, duration } }) if (res.data.code ! 0) throw new Error(res.data.msg || 云臺(tái)指令下發(fā)失敗) return res.data }配套還需要一個(gè)停止的兜底邏輯后面一節(jié)細(xì)說。這里先強(qiáng)調(diào)一個(gè)細(xì)節(jié)不要在前端做速度的百分比換算。有些同學(xué)喜歡把滑動(dòng)條做成 0 到 100然后除以 12.5 轉(zhuǎn)成檔位結(jié)果就是滑到 50 這個(gè)位置時(shí)四舍五入到 4 檔但用戶以為速度是一半。直接在 UI 上暴露 1 到 8 這八個(gè)檔位或者用慢/中/快三檔映射到 2/4/6比百分比直觀得多也少一類溝通成本。3.3 停止指令丟失的四種典型場(chǎng)景以及我用的三層兜底這是我在項(xiàng)目里踩得最狠的一個(gè)坑。云臺(tái)開始轉(zhuǎn)和停止轉(zhuǎn)是兩條獨(dú)立指令一旦只發(fā)了開始沒發(fā)停止云臺(tái)就會(huì)一路轉(zhuǎn)到機(jī)械限位撞上去發(fā)出咔咔的聲音長時(shí)間這樣對(duì)電機(jī)是實(shí)打?qū)嵉膿p傷。我遇到過的觸發(fā)場(chǎng)景有四個(gè)場(chǎng)景一手指滑出按鈕范圍。用戶按住向左手指往外一滑touchend在按鈕上沒觸發(fā)touchcancel如果沒監(jiān)聽停止指令就丟了。場(chǎng)景二頁面切后臺(tái)。用戶按住按鈕的時(shí)候來了個(gè)電話應(yīng)用進(jìn)后臺(tái)JS 線程被掛起回來的時(shí)候按鈕已經(jīng)不在按下狀態(tài)了。場(chǎng)景三路由跳轉(zhuǎn)。按住按鈕的同時(shí)點(diǎn)了返回頁面卸載未發(fā)出的指令沒了。場(chǎng)景四網(wǎng)絡(luò)抖動(dòng)。停止指令發(fā)出去了但接口超時(shí)前端拋異常走了錯(cuò)誤分支沒有重試。我的解決方案是三層兜底實(shí)測(cè)下來再?zèng)]出過問題第一層事件層面全覆蓋。除了touchstart和touchend必須同時(shí)監(jiān)聽touchcancel并且在document級(jí)別App 端用plus的全局事件監(jiān)聽指針抬起保證手指離開屏幕的任何方式都能觸發(fā)停止。第二層定時(shí)器兜底。每次下發(fā)開始轉(zhuǎn)動(dòng)時(shí)同時(shí)啟動(dòng)一個(gè)定時(shí)器時(shí)長等于預(yù)期的最大轉(zhuǎn)動(dòng)時(shí)間比如 5 秒超時(shí)后強(qiáng)制發(fā)一次停止指令并彈一個(gè)輕提示云臺(tái)轉(zhuǎn)動(dòng)超時(shí)已自動(dòng)停止。第三層狀態(tài)回讀校驗(yàn)。停止指令發(fā)出后延遲 500 毫秒調(diào)一次廠商的查詢?cè)婆_(tái)狀態(tài)接口如果返回的狀態(tài)仍是在轉(zhuǎn)動(dòng)再補(bǔ)發(fā)一次停止最多重試兩次。let ptzTimer null let isMoving false async function startMove(command) { if (isMoving) await stopMove() // 防止上一條指令還沒停就發(fā)新指令 isMoving true await ptzControl({ deviceId, command, speed, duration: 0 }) clearTimeout(ptzTimer) ptzTimer setTimeout(() { stopMove(超時(shí)自動(dòng)停止) }, 5000) } async function stopMove(reason ) { if (!isMoving) return clearTimeout(ptzTimer) isMoving false const cmd 11 try { await ptzControl({ deviceId, command: cmd }) } catch (e) { // 失敗重試一次 try { await ptzControl({ deviceId, command: cmd }) } catch (e2) {} } setTimeout(async () { try { const status await queryPtzStatus(deviceId) if (status.moving) await ptzControl({ deviceId, command: cmd }) } catch (e) {} }, 500) } // 頁面卸載時(shí)也要停 onUnload(() { stopMove(頁面卸載) }) onHide(() { stopMove(應(yīng)用進(jìn)入后臺(tái)) })提示isMoving這個(gè)狀態(tài)鎖一定要加。用戶連點(diǎn)方向鍵的時(shí)候沒有鎖的話會(huì)并發(fā)發(fā)出十幾條指令設(shè)備端處理不過來表現(xiàn)就是畫面卡一下然后猛地轉(zhuǎn)一大截非常嚇人。4. 跨端適配的差異清單三個(gè)端根本不是一回事4.1 小程序端live-player 的能力邊界要先摸清很多人默認(rèn)uniapp 一套代碼多端跑以為小程序端也能跑原生插件這是錯(cuò)的。小程序不支持原生插件只支持live-player組件而這個(gè)組件對(duì)協(xié)議有限制——一般支持 RTMP 和 FLV不支持 RTSP也不能播放 HLS 的直播流點(diǎn)播可以。所以如果你的設(shè)備只能出 RTSP小程序端就必須要有一個(gè)轉(zhuǎn)封裝的網(wǎng)關(guān)繞不開。live-player還有幾個(gè)特點(diǎn)要提前知道它是原生組件層級(jí)永遠(yuǎn)在最上面普通的view蓋不住它只能用cover-view和cover-image。要做云臺(tái)控制按鈕浮在畫面上就得用cover-view寫而cover-view支持的樣式非常有限圓角、陰影、漸變基本都不生效。我做過一版最后干脆把控制區(qū)放在畫面下方不做懸浮反而更清爽。另外live-player的清晰度和碼流切換需要在初始化時(shí)通過mode參數(shù)指定運(yùn)行中切換要銷毀重建組件會(huì)有明顯黑屏。如果業(yè)務(wù)需要頻繁切主/子碼流建議直接固定用子碼流720p、1Mbps 左右畫質(zhì)夠看延遲和流量都友好。關(guān)于小程序的準(zhǔn)入live-player屬于實(shí)時(shí)音視頻類組件對(duì)小程序主體的服務(wù)類目有要求不是隨便注冊(cè)一個(gè)號(hào)就能用。上線前一定先確認(rèn)自己賬號(hào)是否具備條件這個(gè)環(huán)節(jié)卡住的話前端做得再好也發(fā)不出去。這一點(diǎn)在項(xiàng)目排期的時(shí)候就要問清楚別等到提審才發(fā)現(xiàn)。4.2 App 端nvue 與 vue 的組件層級(jí)問題App 端如果走原生插件畫面通常是一個(gè)原生view它和 uniapp 的 vue 頁面不在一個(gè)渲染層里。在 vue 頁面里這個(gè)原生 view 會(huì)蓋住所有普通元素跟小程序的原生組件一個(gè)毛病。解決辦法是用nvue頁面weex 渲染它的層級(jí)控制更接近原生可以把原生 view 嵌進(jìn)去。但 nvue 的坑也不少。它不支持大部分 CSS 選擇器只支持 flex 布局position: fixed的行為跟普通 vue 不一樣列表必須用list組件而不是scroll-view。我的做法是把監(jiān)控畫面單獨(dú)做成一個(gè) nvue 頁面控制面板、設(shè)備列表這些用普通 vue 頁面通過uni.navigateTo跳轉(zhuǎn)兩邊只傳設(shè)備 ID 和通道號(hào)。這樣既繞開了層級(jí)問題又不用把整個(gè)應(yīng)用改寫成 nvue。還有一個(gè)容易忽略的點(diǎn)App 端的硬解碼。低端安卓機(jī)軟解 1080p 會(huì)直接卡成幻燈片一定要在插件里開啟硬解。安卓的硬解兼容性是出了名的差不同芯片平臺(tái)高通、聯(lián)發(fā)科、紫光展銳表現(xiàn)差異很大有些機(jī)型開硬解會(huì)花屏。我的經(jīng)驗(yàn)是做一個(gè)開關(guān)默認(rèn)開硬解同時(shí)在設(shè)置里留一個(gè)兼容模式給用戶手動(dòng)關(guān)掉遇到花屏讓他自己切比你在代碼里到處加機(jī)型白名單靠譜。4.3 H5 端解碼能力和跨域是兩個(gè)繞不過去的門檻瀏覽器端的問題主要是兩個(gè)。一是編碼格式H.265 在 Chrome 上的支持非常差基本要靠 WebAssembly 軟解1080p 軟解 CPU 直接拉滿風(fēng)扇狂轉(zhuǎn)。所以面向 H5 的方案一定要在網(wǎng)關(guān)側(cè)把 H.265 轉(zhuǎn)成 H.264或者干脆把設(shè)備的子碼流編碼格式設(shè)成 H.264。二是跨域和鑒權(quán)。flv.js播 HTTP-FLV 需要服務(wù)端允許跨域Access-Control-Allow-Origin要配好。如果流地址帶 tokentoken 過期后播放器不會(huì)自動(dòng)重新拉流表現(xiàn)就是畫面卡住不動(dòng)也不報(bào)錯(cuò)。我一般會(huì)監(jiān)聽播放器的error和statistics_info事件超過 5 秒沒有新數(shù)據(jù)就主動(dòng)銷毀重建同時(shí)刷新 token。H5 還有一個(gè)隱形問題瀏覽器的自動(dòng)播放策略。帶聲音的流必須用戶交互之后才能播所以監(jiān)控頁面的初始狀態(tài)最好是靜音畫面出來后給一個(gè)開啟聲音的按鈕。不然用戶進(jìn)去看到一片黑其實(shí)是播放被攔了控制臺(tái)里一行提示非技術(shù)的同事根本找不到原因。5. 實(shí)測(cè)數(shù)據(jù)延遲怎么量、并發(fā)怎么算、內(nèi)存怎么控5.1 延遲的逐段拆解與測(cè)量方法先說測(cè)量方法這個(gè)很實(shí)用用兩臺(tái)手機(jī)一臺(tái)打開高精度秒表網(wǎng)頁另一臺(tái)顯示監(jiān)控畫面把兩臺(tái)手機(jī)放在一起用第三臺(tái)手機(jī)的高速攝像120 幀或 240 幀拍下來看秒表數(shù)字和畫面里秒表數(shù)字差多少幀。這個(gè)土辦法比任何工具都準(zhǔn)我在項(xiàng)目驗(yàn)收時(shí)經(jīng)常用客戶一看就服。延遲的構(gòu)成可以拆成四段設(shè)備采集編碼 80 到 150 毫秒、網(wǎng)絡(luò)傳輸 30 到 200 毫秒取決于是否走公網(wǎng)、服務(wù)端轉(zhuǎn)封裝緩沖 100 毫秒到 3 秒這里是最大的變量、前端解碼渲染 50 到 150 毫秒。優(yōu)化的重點(diǎn)全在第三段。如果走 HTTP-FLV播放器默認(rèn)會(huì)緩存一個(gè) GOP 的數(shù)據(jù)才開始播GOP 設(shè)成 4 秒的話光等待就是 2 秒起。解決辦法是讓設(shè)備把 I 幀間隔調(diào)到 1 秒甚至 0.5 秒同時(shí)關(guān)閉 B 幀播放器側(cè)把enableStashBuffer設(shè)為false、stashInitialSize調(diào)小。我實(shí)測(cè)過這樣一套組合拳能把 FLV 的延遲從 3 秒壓到 1.2 秒左右。如果對(duì)延遲有硬要求比如需要跟著云臺(tái)轉(zhuǎn)動(dòng)實(shí)時(shí)看畫面變化延遲超過 1 秒會(huì)非常難受那就只能上 WebRTC。它沒有 GOP 緩沖的概念靠 NACK 和 PLI 做丟包重傳和關(guān)鍵幀請(qǐng)求做到 500 毫秒以內(nèi)不稀奇。代價(jià)是服務(wù)端的復(fù)雜度和 CPU 開銷上去了得權(quán)衡。傳輸方式實(shí)測(cè)首幀延遲云臺(tái)跟隨體感服務(wù)端開銷適用場(chǎng)景HLS5 到 10 秒完全不能用低只看回放不做控制HTTP-FLV1.2 到 3 秒勉強(qiáng)可用中一般預(yù)覽、值班監(jiān)看WebRTC0.3 到 0.8 秒流暢高需要精準(zhǔn)控制的場(chǎng)景原生 SDK 直連0.2 到 0.5 秒流暢無App 專屬追求極致體驗(yàn)5.2 多路并發(fā)、內(nèi)存與帶寬的賬要提前算做監(jiān)控方案必算兩筆賬帶寬和內(nèi)存。帶寬方面假設(shè)一路 1080p 主碼流 4Mbps一個(gè) 4 宮格頁面就是 16Mbps。如果有 10 個(gè)用戶同時(shí)看 4 宮格網(wǎng)關(guān)的出口帶寬就是 160Mbps換算成下載速度是 20MB/s。這個(gè)數(shù)字很多人在方案評(píng)審時(shí)才意識(shí)到然后回頭要求前端降碼流。我的建議是默認(rèn)走子碼流720p 大概 1 到 1.5Mbps4 宮格 6Mbps10 個(gè)用戶 60Mbps一臺(tái)常規(guī)云服務(wù)器就能扛住需要看細(xì)節(jié)時(shí)再單畫面切主碼流。存儲(chǔ)方面如果要做本地或服務(wù)端錄像按 4Mbps 算一天一路就是4Mbps × 86400 秒 ÷ 8 43.2GB。存 30 天就是 1.3TB 一路十路就是 13TB。這個(gè)賬一定要在需求階段就算給客戶看否則他覺得錄個(gè)像能有多大。內(nèi)存方面安卓機(jī)上每一路 1080p 解碼大概占 80 到 150MB 內(nèi)存4 宮格就是 400 到 600MB加上應(yīng)用本身低端機(jī)3GB 內(nèi)存很容易被系統(tǒng)殺掉。所以我把并發(fā)路數(shù)硬性限制在 4 路超過就提示最多同時(shí)預(yù)覽 4 路并且做分頁加載——用戶滑到第二頁時(shí)才初始化新的播放實(shí)例滑走的立刻銷毀。實(shí)測(cè)下來這樣一來內(nèi)存峰值能降 40% 左右長時(shí)間運(yùn)行8 小時(shí)以上也不會(huì)出現(xiàn)明顯的內(nèi)存增長。還有一個(gè)細(xì)節(jié)頁面切后臺(tái)要主動(dòng)停流。很多應(yīng)用切到后臺(tái)還在拉流解碼手機(jī)燙得厲害電量掉得飛快。onHide里調(diào)stopPlayonShow里重新startPlay兩行代碼的事用戶口碑差別很大。6. 排錯(cuò)速查這些坑我基本都踩過一遍6.1 畫面類問題黑屏、花屏、卡頓的排查順序黑屏是最常見的報(bào)障但原因可能有七八種按下面的順序查能省很多時(shí)間。第一步看播放器有沒有觸發(fā)播放成功回調(diào)。沒有觸發(fā)就是取流地址或鑒權(quán)的問題先用 VLC 之類的通用播放器驗(yàn)證地址本身通不通排除設(shè)備側(cè)故障。第二步看控制臺(tái)有沒有跨域報(bào)錯(cuò)。有就是服務(wù)端 CORS 沒配或者用了 HTTPS 頁面去拉 HTTP 的流混合內(nèi)容被瀏覽器攔截這是 H5 端最高頻的原因。第三步看編碼格式。花屏大概率是 H.265 用軟解或者硬解兼容性問題切成 H.264 試試如果是綠屏加馬賽克一般是碼流不完整或者網(wǎng)絡(luò)丟包嚴(yán)重。第四步看內(nèi)存?？D但不報(bào)錯(cuò)用開發(fā)者工具看一眼內(nèi)存曲線如果持續(xù)上漲就是播放實(shí)例沒有銷毀切頁面時(shí)stopPlay沒調(diào)。6.2 控制類問題指令發(fā)出去了但云臺(tái)不動(dòng)云臺(tái)不動(dòng)的情況我的排查順序是先確認(rèn)接口返回碼很多廠商接口返回 200 但 body 里的 code 是錯(cuò)誤碼前端只看 HTTP 狀態(tài)就誤判成功了再確認(rèn)通道號(hào)多通道設(shè)備比如 NVR 下掛多個(gè)攝像機(jī)通道號(hào)從 1 開始還是從 0 開始不同廠商不一樣填錯(cuò)了指令發(fā)給了不存在的通道最后確認(rèn)設(shè)備是否被其他客戶端占用某些設(shè)備同時(shí)只允許一個(gè)控制端值班室的大屏占著控制權(quán)你這邊發(fā)指令就沒反應(yīng)。還有一種情況是能轉(zhuǎn)但轉(zhuǎn)得很慢或者很快。這就是速度檔位的問題檢查一下前端傳的是 1 到 8 還是 0 到 100映射錯(cuò)了就會(huì)出這種效果。我有一次就是因?yàn)閮商状a里一套傳檔位一套傳百分比聯(lián)調(diào)了半天。6.3 打包與兼容類問題插件在真機(jī)上失效原生插件最常見的報(bào)錯(cuò)是方法未定義八成是自定義基座沒打。標(biāo)準(zhǔn)基座里沒有你的插件必須打自定義基座才能調(diào)試這個(gè)新人幾乎必踩。其次是**.so架構(gòu)缺失**報(bào)UnsatisfiedLinkError檢查build.gradle里的abiFilters和目標(biāo)機(jī) CPU 架構(gòu)是否匹配現(xiàn)在主流是arm64-v8a但工控機(jī)、一體機(jī)不少還是 32 位。第三是iOS 的隱私權(quán)限描述。訪問麥克風(fēng)對(duì)講、相冊(cè)截圖保存都需要在Info.plist里配描述文案缺了會(huì)在調(diào)用瞬間閃退日志里還不一定有明確提示。最后是插件版本與 IDE 版本不匹配表現(xiàn)是編譯通過但運(yùn)行時(shí)找不到方法。解決辦法是清基座緩存、重新打自定義基座別在這上面浪費(fèi)時(shí)間猜。現(xiàn)象最可能原因快速驗(yàn)證方式處理方式畫面全黑無報(bào)錯(cuò)token 過期或跨域用通用播放器驗(yàn)證流地址刷新 token、配置 CORS畫面花屏H.265 硬解兼容性切 H.264 或關(guān)硬解加兼容模式開關(guān)云臺(tái)無響應(yīng)通道號(hào)錯(cuò)誤或設(shè)備被占用看接口 body 的 code校正通道號(hào)、釋放控制權(quán)云臺(tái)轉(zhuǎn)不停停止指令丟失抓包看是否有停止請(qǐng)求加三層兜底邏輯插件方法未定義未打自定義基座看控制臺(tái)報(bào)錯(cuò)棧重打自定義基座運(yùn)行一段時(shí)間卡死播放實(shí)例未銷毀觀察內(nèi)存曲線頁面切換時(shí) stopPlay7. 選型建議與落地節(jié)奏別一上來就啃硬骨頭7.1 按團(tuán)隊(duì)規(guī)模和訴求對(duì)號(hào)入座如果團(tuán)隊(duì)只有一兩個(gè)前端且只做 App、交付周期緊直接走路線一用廠商的 H5 頁面把流程跑通先把業(yè)務(wù)價(jià)值交付出去后面再優(yōu)化。如果對(duì)云臺(tái)精度、截圖、AI 識(shí)別有硬需求且團(tuán)隊(duì)有安卓或 iOS 的封裝能力走路線二性能是最優(yōu)的。如果要多端覆蓋、要接多家廠商設(shè)備、團(tuán)隊(duì)有服務(wù)端運(yùn)維能力走路線三前期投入大但天花板最高。還有一個(gè)混合策略我經(jīng)常用App 端走原生插件H5 和小程序端走網(wǎng)關(guān)加 FLV。同一個(gè)業(yè)務(wù)頁面通過條件編譯區(qū)分播放組件上層的設(shè)備列表、云臺(tái)控制面板、報(bào)警信息這些邏輯完全復(fù)用。這樣既保證了主場(chǎng)景的體驗(yàn)又覆蓋了次要場(chǎng)景代價(jià)只是多維護(hù)一個(gè)網(wǎng)關(guān)。7.2 我給一個(gè)三個(gè)月的落地節(jié)奏第一個(gè)月做驗(yàn)證不要寫業(yè)務(wù)代碼。拿一臺(tái)真實(shí)設(shè)備把三條路線各跑一個(gè)最小 demo重點(diǎn)測(cè)三件事延遲用秒表法量、云臺(tái)控制體感、目標(biāo)機(jī)型的兼容性。這一步做完路線基本就定了而且后面的返工風(fēng)險(xiǎn)能降一大半。第二個(gè)月做骨架。把播放組件、云臺(tái)控制器、設(shè)備管理三個(gè)模塊拆開播放組件對(duì)外只暴露play、stop、snapshot三個(gè)方法云臺(tái)控制器對(duì)外只暴露move、stop、gotoPreset。用接口約束住后面換實(shí)現(xiàn)只改一個(gè)文件。第三個(gè)月做適配和打磨。集中處理各端差異、內(nèi)存優(yōu)化、異常兜底然后拉真實(shí)用戶值班員、巡檢員試用一周。他們對(duì)卡不卡、轉(zhuǎn)得準(zhǔn)不準(zhǔn)的感知比任何測(cè)試用例都準(zhǔn)往往能挖出你在實(shí)驗(yàn)室里發(fā)現(xiàn)不了的問題。最后分享一個(gè)我自己踩出來的小體會(huì)云臺(tái)控制這件事寧可讓用戶多點(diǎn)兩下也不要讓它轉(zhuǎn)得太猛。我給所有項(xiàng)目的默認(rèn)速度都設(shè)成 4 檔中速并且在設(shè)置里提供精細(xì)模式2 檔。用戶第一次用會(huì)嫌慢但用一周之后沒人愿意調(diào)回去——轉(zhuǎn)太快根本對(duì)不準(zhǔn)尤其是要看清車牌或者人臉的時(shí)候?qū)幙陕病＿@個(gè)參數(shù)看著不起眼卻是使用體驗(yàn)里最容易被忽略、也最容易調(diào)好的一環(huán)。