1. 先聊清楚uniapp 接云台相机这件事到底难在哪我做安防类项目有几年了最近半年被问得最多的一个问题就是uniapp 能不能接云台相机云台插件到底好不好用。这个问题表面上是问插件实际上是问一整套取流、控制、跨端适配的技术路线能不能成立。我前后在三个项目里试过不同做法一个园区值班室的中控屏、一个连锁门店的巡店应用、还有一个设备巡检的移动作业端规模都不大但把该踩的坑基本都踩了一遍。先给结论uniapp 跨平台监控方案是可行的但它的可行有明确边界。你能用一套代码同时出 H5、安卓 App、iOS App甚至小程序这个诱惑太大尤其是团队只有一两个前端的时候。可视频监控这个场景天生重原生——解码、渲染、硬件加速、低延迟传输每一环都贴着操作系统底层走而 uniapp 的强项是视图层和业务层的跨端复用两者中间隔着一层原生桥接摩擦就发生在这一层。下文我把标题里说的云台插件统一理解为某安防厂商下文简称 A 厂商提供的、封装了设备登录、实时预览、云台控制PTZ、录像回放、抓图等能力的 SDK 插件形态产品。它可能是一个 uni 原生插件也可能是一个 H5 播放页还可能只是一套 HTTP 接口加标准流地址。形态不同优劣差别巨大这也是很多人测评结果互相矛盾的原因——大家测的压根不是同一个东西。这篇文章适合三类人看正在做技术选型的项目负责人、准备动手接入的前端或移动端开发、以及被一套代码多端跑打动但还没踩过坑的产品同学。我会把三条主流路线的架构、云台指令的细节、跨端差异、实测数据和排错经验全部摊开讲参数和计算过程都给出来能直接抄的部分我会写得足够具体。2. 三条技术路线的架构拆解与优劣势对照2.1 路线一web-view 内嵌厂商 H5 监控页改动最小的偷懒方案这是上手最快的一条路。A 厂商通常会提供一个免插件的网页版预览页地址里带上设备序列号、通道号、token 之类的参数你只要在 uniapp 里放一个web-view组件把地址塞进去画面就出来了云台控制按钮厂商也已经画好了。我在门店巡店那个项目里第一版就是这么干的从拿到地址到跑通两个小时。它的优势非常直接零原生开发、零协议理解、零解码逻辑。厂商网页内部已经把取流、解码、云台指令封装好了你不需要知道背后用的是 WebSocket 推流还是 HTTP-FLV也不需要关心 H.264 还是 H.265。对于只要求能看、能转、能回放的轻量场景这条路性价比最高。但坑也很密集。第一是通信问题网页和 uniapp 之间只能靠postMessage或者 URL 传参双向通信在 App 端勉强能用小程序端受限于业务域名校验能做到的事情更少。第二是UI 不可控厂商页面永远带着自己的 logo、自己的按钮布局你想把它嵌进自己的设计体系里几乎不可能只能整页铺满。第三是拿不到视频帧截图、AI 识别、本地录像这些需求直接判死刑。第四是登录态和 token 管理A 厂商的 H5 地址一般有效期很短页面切后台再回来经常要重新鉴权用户看到的就是一片黑屏加一个转圈。我印象最深的一次是客户要求点击画面任意位置云台自动把那个点移到画面中心也就是常说的 3D 定位。厂商 H5 页面本身支持但它是内部逻辑我们无法从外部触发最后只能改成让用户自己按方向键。这就是路线一的本质你借用了别人的能力也接受了别人的边界。2.2 路线二原生插件直连 SDK延迟最低但维护成本最高第二条路是把 A 厂商的移动端 SDK 封装成 uni 原生插件。安卓侧通常是几个.aar加一堆.so动态库iOS 侧是.framework然后按 uniapp 原生插件的规范暴露方法给 JS 调用比如login、startRealPlay、ptzControl、stopRealPlay、startPlayback。这条路是性能天花板。SDK 直连设备或者直连厂商的流媒体服务走的是私有协议延迟能压到 200 到 500 毫秒云台指令也是走专用通道按下按钮到画面转动体感几乎是实时的。功能也最全预置位、巡航、抓图存本地、双向对讲、本地录像、码流切换主码流/子码流全都有。代价是双端各写一遍。安卓和 iOS 的 SDK 接口长得完全不一样安卓里叫PTZControliOS 里可能是ptzControlWithCommand参数顺序也不同你得写两套桥接代码。包体积也会明显变大我做过的一个版本加上.so之后安装包从 18MB 涨到了 62MB虽然可以做 ABI 拆分只保留arm64-v8a但还是要多出二十多兆。更麻烦的是版本耦合。uni 原生插件要跟 HBuilderX 的版本、基座版本对齐云打包的自定义基座一旦和插件不匹配就是白屏或者方法找不到。我遇到过一次升级了 IDE 之后插件里某个回调不再触发排查了半天才发现是基座缓存没清。另外这条路完全放弃了 H5 和小程序如果你老板一开始说我们要多端最后发现只有 App 能用返工成本很高。注意封装 A 厂商 SDK 时要特别留意.so的架构裁剪只保留arm64-v8a能省一半体积但部分老旧的安卓一体机是 32 位系统砍掉armeabi-v7a之后会直接崩在UnsatisfiedLinkError。上线前一定要确认目标机型的 CPU 架构。2.3 路线三自建流媒体网关加通用播放器折中但最费运维第三条路是我现在最推荐的中间方案服务端把设备的 RTSP 流拉过来转成 WebRTC 或 HTTP-FLV前端用统一的播放器组件播。设备侧只需要开放 RTSP 地址和账号密码剩下的交给网关。H5 和 App 用flv.js或者 WebRTC 播放器小程序用live-player组件播 RTMP 或 FLV。这条路的最大好处是前端彻底统一。同一套播放器封装逻辑通过条件编译在三个端上跑业务代码复用率能到 90% 以上。云台控制走的是厂商的 HTTP 接口跟播放器解耦前端只要发一个请求就行不需要任何原生能力。代价转移到了服务端。你要维护一个流媒体服务要算带宽要处理设备断线重连要管会话和鉴权。以 1080p 主码流 4Mbps 为例如果网关不做转码只做转封装一台 4 核 8G 的服务器扛二三十路拉流问题不大但一旦要做 H.265 转 H.264因为浏览器对 H.265 支持很差CPU 立刻成为瓶颈一路转码大概要吃掉一个核心的 30% 到 50%。这个成本很多人在选型阶段根本没算进去。延迟上WebRTC 能做到 300 到 800 毫秒HTTP-FLV 大概 1 到 3 秒HLS 就别考虑了动辄 5 秒以上云台转一下要等半天才看到画面体验极差。2.4 三条路线横向对比选型时到底看哪几个指标光讲感受不够我把关键维度整理成表格你对着自己的项目勾一下就知道该走哪条。对比维度路线一 web-view路线二 原生插件路线三 自建网关首帧延迟1 到 3 秒200 到 500 毫秒WebRTC 300 到 800 毫秒FLV 1 到 3 秒云台控制体感一般有 0.5 秒左右滞后几乎实时较好取决于接口响应端覆盖App、H5仅 AppApp、H5、小程序包体积增量几乎为 020 到 40MB2 到 5MBUI 可控性极低高高截图/录像/AI不支持完整支持需网关侧配合服务端成本无无有按路数和带宽增长前端开发量极低高双端各写中长期维护难度受厂商页面变更影响受 SDK 与 IDE 版本影响受运维能力影响我的经验是如果三个月内要交付且只需要 App选路线一如果对延迟和控制精度有硬要求、长期迭代选路线二如果有小程序端诉求、或者未来要接多家厂商设备选路线三。最怕的是需求没说清楚就先动手做完发现方向不对那才是真的浪费。3. 云台控制才是真正的地雷区指令下发的细节与兜底3.1 控制通道和媒体通道必须解耦别把云台指令塞进播放链路新手最容易犯的错是把云台控制和视频播放当成一件事。比如用 web-view 内嵌播放页就想着云台按钮也用它自带的吧或者用原生插件云台指令只能通过播放器的实例发。这两种做法都会让你在后期极其被动——播放器崩了云台就转不了播放器换了云台逻辑要重写。正确的做法是把两者彻底分开。视频走视频的通道云台走云台的通道两者只在业务层做状态同步。云台通道的最优解是厂商的 HTTP 接口形如POST /api/ptz/control参数里带设备序列号、通道号、动作命令、速度、持续时间。这条通道你可以用uni.request发三个端完全一致不依赖任何原生能力也不受播放器状态影响。分离之后有个好处你可以做指令队列和状态机。比如用户按住向左前端每秒发 5 次指令不是必须但某些厂商协议要求持续心跳松开时发一次停止。如果网络抖动导致某次停止指令丢了队列里会有重试。而如果用播放器自带的控制方法你根本不知道指令有没有发出去。还有一点云台指令的响应要跟 UI 反馈配合。按下按钮后按钮变高亮收到接口返回成功之后再取消高亮如果 3 秒内没返回显示控制超时请重试。这种细节看着小但在值班室场景里特别重要——值班员按了半天没反应会以为系统坏了反复狂点最后云台转过头。3.2 方向、速度、时长三要素一次完整的指令封装应该长什么样不同厂商的云台指令字段长得不一样但本质都是三要素方向、速度、持续时间。方向一般有八个上、下、左、右、左上、左下、右上、右下加上变倍放大缩小、聚焦远/近、光圈大/小、预置位调用。速度是个整数档位常见的是 1 到 8 档或者 1 到 7 档数字越大转得越快。速度档位和实际角速度的关系厂商手册里通常会写1 档约等于最大转速的 1/8。假设某球机的水平最大转速是 200 度每秒那 4 档就是 100 度每秒转动 90 度大概需要 0.9 秒。这个换算在调试时非常有用你可以据此判断按一下按钮转 90 度大概要按多久也能据此设定前端的默认速度。// 以某厂商 HTTP 接口为例封装一个通用的云台控制方法 const PTZ_SPEED_MAX 8 /** * param {Object} opts * param {String} opts.deviceId 设备序列号 * param {Number} opts.channel 通道号通道 1 表示第一路 * param {Number} opts.command 1上 2下 3左 4右 5左上 6左下 7右上 8右下 9放大 10缩小 11停止 * param {Number} opts.speed 1-8 档默认 4 档 * param {Number} opts.duration 持续毫秒数0 表示一直转到收到停止指令 */ 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 || 云台指令下发失败) return res.data }配套还需要一个停止的兜底逻辑后面一节细说。这里先强调一个细节不要在前端做速度的百分比换算。有些同学喜欢把滑动条做成 0 到 100然后除以 12.5 转成档位结果就是滑到 50 这个位置时四舍五入到 4 档但用户以为速度是一半。直接在 UI 上暴露 1 到 8 这八个档位或者用慢/中/快三档映射到 2/4/6比百分比直观得多也少一类沟通成本。3.3 停止指令丢失的四种典型场景以及我用的三层兜底这是我在项目里踩得最狠的一个坑。云台开始转和停止转是两条独立指令一旦只发了开始没发停止云台就会一路转到机械限位撞上去发出咔咔的声音长时间这样对电机是实打实的损伤。我遇到过的触发场景有四个场景一手指滑出按钮范围。用户按住向左手指往外一滑touchend在按钮上没触发touchcancel如果没监听停止指令就丢了。场景二页面切后台。用户按住按钮的时候来了个电话应用进后台JS 线程被挂起回来的时候按钮已经不在按下状态了。场景三路由跳转。按住按钮的同时点了返回页面卸载未发出的指令没了。场景四网络抖动。停止指令发出去了但接口超时前端抛异常走了错误分支没有重试。我的解决方案是三层兜底实测下来再没出过问题第一层事件层面全覆盖。除了touchstart和touchend必须同时监听touchcancel并且在document级别App 端用plus的全局事件监听指针抬起保证手指离开屏幕的任何方式都能触发停止。第二层定时器兜底。每次下发开始转动时同时启动一个定时器时长等于预期的最大转动时间比如 5 秒超时后强制发一次停止指令并弹一个轻提示云台转动超时已自动停止。第三层状态回读校验。停止指令发出后延迟 500 毫秒调一次厂商的查询云台状态接口如果返回的状态仍是在转动再补发一次停止最多重试两次。let ptzTimer null let isMoving false async function startMove(command) { if (isMoving) await stopMove() // 防止上一条指令还没停就发新指令 isMoving true await ptzControl({ deviceId, command, speed, duration: 0 }) clearTimeout(ptzTimer) ptzTimer setTimeout(() { stopMove(超时自动停止) }, 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) } // 页面卸载时也要停 onUnload(() { stopMove(页面卸载) }) onHide(() { stopMove(应用进入后台) })提示isMoving这个状态锁一定要加。用户连点方向键的时候没有锁的话会并发发出十几条指令设备端处理不过来表现就是画面卡一下然后猛地转一大截非常吓人。4. 跨端适配的差异清单三个端根本不是一回事4.1 小程序端live-player 的能力边界要先摸清很多人默认uniapp 一套代码多端跑以为小程序端也能跑原生插件这是错的。小程序不支持原生插件只支持live-player组件而这个组件对协议有限制——一般支持 RTMP 和 FLV不支持 RTSP也不能播放 HLS 的直播流点播可以。所以如果你的设备只能出 RTSP小程序端就必须要有一个转封装的网关绕不开。live-player还有几个特点要提前知道它是原生组件层级永远在最上面普通的view盖不住它只能用cover-view和cover-image。要做云台控制按钮浮在画面上就得用cover-view写而cover-view支持的样式非常有限圆角、阴影、渐变基本都不生效。我做过一版最后干脆把控制区放在画面下方不做悬浮反而更清爽。另外live-player的清晰度和码流切换需要在初始化时通过mode参数指定运行中切换要销毁重建组件会有明显黑屏。如果业务需要频繁切主/子码流建议直接固定用子码流720p、1Mbps 左右画质够看延迟和流量都友好。关于小程序的准入live-player属于实时音视频类组件对小程序主体的服务类目有要求不是随便注册一个号就能用。上线前一定先确认自己账号是否具备条件这个环节卡住的话前端做得再好也发不出去。这一点在项目排期的时候就要问清楚别等到提审才发现。4.2 App 端nvue 与 vue 的组件层级问题App 端如果走原生插件画面通常是一个原生view它和 uniapp 的 vue 页面不在一个渲染层里。在 vue 页面里这个原生 view 会盖住所有普通元素跟小程序的原生组件一个毛病。解决办法是用nvue页面weex 渲染它的层级控制更接近原生可以把原生 view 嵌进去。但 nvue 的坑也不少。它不支持大部分 CSS 选择器只支持 flex 布局position: fixed的行为跟普通 vue 不一样列表必须用list组件而不是scroll-view。我的做法是把监控画面单独做成一个 nvue 页面控制面板、设备列表这些用普通 vue 页面通过uni.navigateTo跳转两边只传设备 ID 和通道号。这样既绕开了层级问题又不用把整个应用改写成 nvue。还有一个容易忽略的点App 端的硬解码。低端安卓机软解 1080p 会直接卡成幻灯片一定要在插件里开启硬解。安卓的硬解兼容性是出了名的差不同芯片平台高通、联发科、紫光展锐表现差异很大有些机型开硬解会花屏。我的经验是做一个开关默认开硬解同时在设置里留一个兼容模式给用户手动关掉遇到花屏让他自己切比你在代码里到处加机型白名单靠谱。4.3 H5 端解码能力和跨域是两个绕不过去的门槛浏览器端的问题主要是两个。一是编码格式H.265 在 Chrome 上的支持非常差基本要靠 WebAssembly 软解1080p 软解 CPU 直接拉满风扇狂转。所以面向 H5 的方案一定要在网关侧把 H.265 转成 H.264或者干脆把设备的子码流编码格式设成 H.264。二是跨域和鉴权。flv.js播 HTTP-FLV 需要服务端允许跨域Access-Control-Allow-Origin要配好。如果流地址带 tokentoken 过期后播放器不会自动重新拉流表现就是画面卡住不动也不报错。我一般会监听播放器的error和statistics_info事件超过 5 秒没有新数据就主动销毁重建同时刷新 token。H5 还有一个隐形问题浏览器的自动播放策略。带声音的流必须用户交互之后才能播所以监控页面的初始状态最好是静音画面出来后给一个开启声音的按钮。不然用户进去看到一片黑其实是播放被拦了控制台里一行提示非技术的同事根本找不到原因。5. 实测数据延迟怎么量、并发怎么算、内存怎么控5.1 延迟的逐段拆解与测量方法先说测量方法这个很实用用两台手机一台打开高精度秒表网页另一台显示监控画面把两台手机放在一起用第三台手机的高速摄像120 帧或 240 帧拍下来看秒表数字和画面里秒表数字差多少帧。这个土办法比任何工具都准我在项目验收时经常用客户一看就服。延迟的构成可以拆成四段设备采集编码 80 到 150 毫秒、网络传输 30 到 200 毫秒取决于是否走公网、服务端转封装缓冲 100 毫秒到 3 秒这里是最大的变量、前端解码渲染 50 到 150 毫秒。优化的重点全在第三段。如果走 HTTP-FLV播放器默认会缓存一个 GOP 的数据才开始播GOP 设成 4 秒的话光等待就是 2 秒起。解决办法是让设备把 I 帧间隔调到 1 秒甚至 0.5 秒同时关闭 B 帧播放器侧把enableStashBuffer设为false、stashInitialSize调小。我实测过这样一套组合拳能把 FLV 的延迟从 3 秒压到 1.2 秒左右。如果对延迟有硬要求比如需要跟着云台转动实时看画面变化延迟超过 1 秒会非常难受那就只能上 WebRTC。它没有 GOP 缓冲的概念靠 NACK 和 PLI 做丢包重传和关键帧请求做到 500 毫秒以内不稀奇。代价是服务端的复杂度和 CPU 开销上去了得权衡。传输方式实测首帧延迟云台跟随体感服务端开销适用场景HLS5 到 10 秒完全不能用低只看回放不做控制HTTP-FLV1.2 到 3 秒勉强可用中一般预览、值班监看WebRTC0.3 到 0.8 秒流畅高需要精准控制的场景原生 SDK 直连0.2 到 0.5 秒流畅无App 专属追求极致体验5.2 多路并发、内存与带宽的账要提前算做监控方案必算两笔账带宽和内存。带宽方面假设一路 1080p 主码流 4Mbps一个 4 宫格页面就是 16Mbps。如果有 10 个用户同时看 4 宫格网关的出口带宽就是 160Mbps换算成下载速度是 20MB/s。这个数字很多人在方案评审时才意识到然后回头要求前端降码流。我的建议是默认走子码流720p 大概 1 到 1.5Mbps4 宫格 6Mbps10 个用户 60Mbps一台常规云服务器就能扛住需要看细节时再单画面切主码流。存储方面如果要做本地或服务端录像按 4Mbps 算一天一路就是4Mbps × 86400 秒 ÷ 8 43.2GB。存 30 天就是 1.3TB 一路十路就是 13TB。这个账一定要在需求阶段就算给客户看否则他觉得录个像能有多大。内存方面安卓机上每一路 1080p 解码大概占 80 到 150MB 内存4 宫格就是 400 到 600MB加上应用本身低端机3GB 内存很容易被系统杀掉。所以我把并发路数硬性限制在 4 路超过就提示最多同时预览 4 路并且做分页加载——用户滑到第二页时才初始化新的播放实例滑走的立刻销毁。实测下来这样一来内存峰值能降 40% 左右长时间运行8 小时以上也不会出现明显的内存增长。还有一个细节页面切后台要主动停流。很多应用切到后台还在拉流解码手机烫得厉害电量掉得飞快。onHide里调stopPlayonShow里重新startPlay两行代码的事用户口碑差别很大。6. 排错速查这些坑我基本都踩过一遍6.1 画面类问题黑屏、花屏、卡顿的排查顺序黑屏是最常见的报障但原因可能有七八种按下面的顺序查能省很多时间。第一步看播放器有没有触发播放成功回调。没有触发就是取流地址或鉴权的问题先用 VLC 之类的通用播放器验证地址本身通不通排除设备侧故障。第二步看控制台有没有跨域报错。有就是服务端 CORS 没配或者用了 HTTPS 页面去拉 HTTP 的流混合内容被浏览器拦截这是 H5 端最高频的原因。第三步看编码格式。花屏大概率是 H.265 用软解或者硬解兼容性问题切成 H.264 试试如果是绿屏加马赛克一般是码流不完整或者网络丢包严重。第四步看内存。卡顿但不报错用开发者工具看一眼内存曲线如果持续上涨就是播放实例没有销毁切页面时stopPlay没调。6.2 控制类问题指令发出去了但云台不动云台不动的情况我的排查顺序是先确认接口返回码很多厂商接口返回 200 但 body 里的 code 是错误码前端只看 HTTP 状态就误判成功了再确认通道号多通道设备比如 NVR 下挂多个摄像机通道号从 1 开始还是从 0 开始不同厂商不一样填错了指令发给了不存在的通道最后确认设备是否被其他客户端占用某些设备同时只允许一个控制端值班室的大屏占着控制权你这边发指令就没反应。还有一种情况是能转但转得很慢或者很快。这就是速度档位的问题检查一下前端传的是 1 到 8 还是 0 到 100映射错了就会出这种效果。我有一次就是因为两套代码里一套传档位一套传百分比联调了半天。6.3 打包与兼容类问题插件在真机上失效原生插件最常见的报错是方法未定义八成是自定义基座没打。标准基座里没有你的插件必须打自定义基座才能调试这个新人几乎必踩。其次是**.so架构缺失**报UnsatisfiedLinkError检查build.gradle里的abiFilters和目标机 CPU 架构是否匹配现在主流是arm64-v8a但工控机、一体机不少还是 32 位。第三是iOS 的隐私权限描述。访问麦克风对讲、相册截图保存都需要在Info.plist里配描述文案缺了会在调用瞬间闪退日志里还不一定有明确提示。最后是插件版本与 IDE 版本不匹配表现是编译通过但运行时找不到方法。解决办法是清基座缓存、重新打自定义基座别在这上面浪费时间猜。现象最可能原因快速验证方式处理方式画面全黑无报错token 过期或跨域用通用播放器验证流地址刷新 token、配置 CORS画面花屏H.265 硬解兼容性切 H.264 或关硬解加兼容模式开关云台无响应通道号错误或设备被占用看接口 body 的 code校正通道号、释放控制权云台转不停停止指令丢失抓包看是否有停止请求加三层兜底逻辑插件方法未定义未打自定义基座看控制台报错栈重打自定义基座运行一段时间卡死播放实例未销毁观察内存曲线页面切换时 stopPlay7. 选型建议与落地节奏别一上来就啃硬骨头7.1 按团队规模和诉求对号入座如果团队只有一两个前端且只做 App、交付周期紧直接走路线一用厂商的 H5 页面把流程跑通先把业务价值交付出去后面再优化。如果对云台精度、截图、AI 识别有硬需求且团队有安卓或 iOS 的封装能力走路线二性能是最优的。如果要多端覆盖、要接多家厂商设备、团队有服务端运维能力走路线三前期投入大但天花板最高。还有一个混合策略我经常用App 端走原生插件H5 和小程序端走网关加 FLV。同一个业务页面通过条件编译区分播放组件上层的设备列表、云台控制面板、报警信息这些逻辑完全复用。这样既保证了主场景的体验又覆盖了次要场景代价只是多维护一个网关。7.2 我给一个三个月的落地节奏第一个月做验证不要写业务代码。拿一台真实设备把三条路线各跑一个最小 demo重点测三件事延迟用秒表法量、云台控制体感、目标机型的兼容性。这一步做完路线基本就定了而且后面的返工风险能降一大半。第二个月做骨架。把播放组件、云台控制器、设备管理三个模块拆开播放组件对外只暴露play、stop、snapshot三个方法云台控制器对外只暴露move、stop、gotoPreset。用接口约束住后面换实现只改一个文件。第三个月做适配和打磨。集中处理各端差异、内存优化、异常兜底然后拉真实用户值班员、巡检员试用一周。他们对卡不卡、转得准不准的感知比任何测试用例都准往往能挖出你在实验室里发现不了的问题。最后分享一个我自己踩出来的小体会云台控制这件事宁可让用户多点两下也不要让它转得太猛。我给所有项目的默认速度都设成 4 档中速并且在设置里提供精细模式2 档。用户第一次用会嫌慢但用一周之后没人愿意调回去——转太快根本对不准尤其是要看清车牌或者人脸的时候宁可慢慢挪。这个参数看着不起眼却是使用体验里最容易被忽略、也最容易调好的一环。
