2、移动端实时查看需求分析
好，咱们直接进入正题。移动端实时查看，听起来简单，做起来坑不少。我这些年经手过好几个远程监控项目，从工地到养殖场，从仓库到连锁门店，用户吐槽最多的点，其实就三个方向：延迟高、画质差、操作复杂。说白了，用户要的就是「打开手机就能看，看了不卡，卡了能回放，出事了能报警」。今天我就把这几个痛点掰开揉碎了讲清楚。
用户痛点分析
延迟高——用户最不能忍的「慢」
我记得有个做冷链仓储的客户，跟我抱怨说：「我打开App看冷库温度监控画面，等了三秒才出图，这要是货出了问题，黄花菜都凉了。」
为什么会这样？其实延迟主要卡在三个环节：
- 推流端编码延迟：摄像头采集到画面，需要编码成H.264或H.265，这个编码过程本身就有几十到几百毫秒的延迟。
- 网络传输延迟：从摄像头到服务器，再从服务器到手机，中间经过公网，丢包重传、路由跳转都会增加延迟。
- 播放端解码延迟：手机收到数据流，需要解码渲染，低端手机解码能力弱，延迟更明显。
核心指标：我一般要求端到端延迟控制在 1秒以内，超过2秒用户就会明显感觉「卡」。如果是云台控制类的场景，延迟必须低于500ms，否则用户转一下摄像头，画面半天才动，体验极差。
画质差——看不清等于白看
「我装了个200万像素的摄像头，结果在手机上看到的画面糊得像马赛克。」这话我听过不下十次。
画质差的原因，我总结下来主要有三点：
- 码率被压缩得太狠：为了省带宽，很多方案把码率压到512Kbps以下，画面细节全丢了。
- 分辨率适配没做好：手机屏幕小，但摄像头输出的是1080P甚至4K，直接缩放显示，锯齿感严重。
- 弱光环境下的噪点：晚上或者光线不足时，摄像头自动增益，画面全是噪点，码率再高也没用。
我的经验：我曾经在某个项目中，用户要求「能看清车牌」。我们测试发现，码率低于1.5Mbps时，车牌边缘就开始模糊。所以后来我们做了动态码率调整——白天光线好时用2Mbps，晚上用1Mbps，配合降噪算法，效果好了很多。
操作复杂——用户不想当工程师
你想想看，一个仓库管理员，他只想点一下「查看摄像头」，结果App里要选协议、配端口、输IP地址……这不是难为人吗？
我见过最夸张的一个案例：某品牌的监控App，要用户手动输入「RTSP地址」才能看画面。这哪是给普通人用的？
操作复杂主要体现在：
- 设备绑定流程繁琐：扫码、配对、输入密码、选择网络……步骤超过5步，用户流失率就飙升。
- 多设备管理混乱：家里装了4个摄像头，App里显示一堆列表，分不清哪个是哪个。
- 回放操作反人类：想找昨天下午3点的录像，要拖动进度条一点点找，没有时间轴标记。
核心功能需求
好，痛点说完了，咱们聊聊怎么解决。核心功能就三个：实时预览、回放、报警推送。一个都不能少。
实时预览
这是最基本的功能，但要做好不容易。我建议做到以下几点：
- 秒开播放：用户点击摄像头，画面要在1秒内显示出来。这需要做「预连接」和「首帧快速解码」。
- 多码流切换：WiFi环境下用高清流，4G/5G环境下用流畅流。我习惯在App里加一个「自动切换」开关，用户不用手动选。
- 手势操作：双指缩放、单指拖动、双击全屏，这些是标配。别忘了加一个「截图」按钮，用户看到异常画面能立刻保存。
回放
回放功能，说白了就是「时间旅行」。用户要能回到过去，看到当时发生了什么。
- 时间轴设计：我建议用「缩略图+时间刻度」的方式，用户拖动时能看到关键帧的缩略图，方便定位。
- 倍速播放：1倍、2倍、4倍、8倍，甚至16倍。用户看一整天的录像，不可能逐秒看。
- 事件标记：报警事件、移动侦测事件，要在时间轴上用不同颜色标记出来。用户点一下就能跳到对应位置。
注意：回放功能对存储和带宽要求很高。我曾经遇到一个项目，用户要求同时回放4路1080P录像，结果手机内存直接爆了。后来我们做了「分片加载」——只加载当前时间点前后5分钟的数据，滑动时再动态加载。
报警推送
报警推送是「救命」功能。用户不可能24小时盯着屏幕，但出了事必须第一时间知道。
- 多类型报警：移动侦测、区域入侵、声音异常、设备离线……每种报警都要能单独配置。
- 推送内容：不要只发一条「有报警」，要带上截图和文字描述。比如「门口有人经过，截图如下」。
- 防打扰机制：晚上11点到早上7点，用户可以设置「静默模式」，只记录不推送。或者只推送「重要报警」。
非功能需求
功能做完了，还得看跑不跑得稳。非功能需求，说白了就是「快、稳、安全」。
低延迟
前面说了，延迟要控制在1秒以内。具体怎么做？
- 使用WebRTC或RTMP：这两个协议在低延迟方面表现最好。WebRTC能做到200-500ms延迟，RTMP在1-2秒。
- 边缘节点加速：在离用户近的地方部署边缘服务器，减少网络跳转。我习惯用CDN或者自建边缘节点。
- GOP结构优化：把关键帧间隔（GOP）设为1-2秒，这样用户拖拽进度条时能快速找到关键帧。
高并发
一个监控平台，可能同时有几千甚至几万个用户在看。高并发怎么扛？
- 流媒体服务器集群：用Nginx-RTMP或SRS搭建集群，支持水平扩展。
- 负载均衡：用户请求进来，先经过负载均衡器，分发给空闲的服务器。
- 连接复用：同一个用户看多个摄像头，不要建立多个连接，用一条连接复用多个流。
避坑指南：我曾经在某个项目中，没有做连接复用，结果一个用户同时看4路摄像头，手机端建立了4个TCP连接，导致手机发热严重，电量掉得飞快。后来改成单连接多路复用，问题解决了。
安全性
监控画面涉及隐私，安全是底线。我建议至少做到以下几点：
- 传输加密：使用HTTPS和SRTP加密，防止中间人攻击。
- 身份认证：用户登录要用双因素认证（密码+短信验证码）。
- 设备鉴权：摄像头接入平台时，要有设备ID和密钥校验，防止非法设备接入。
- 数据存储加密：录像文件存储在云端时，要加密存储。即使数据库被拖走，也解不开。
知识体系结构图
下面这张图，是我自己梳理的「移动端实时查看方案」核心逻辑。你看一眼就能明白整个体系是怎么串起来的。
这张图把「痛点→功能→非功能」的链路画得很清楚。你设计时，一定要从用户痛点出发，倒推功能和性能指标。别一上来就堆技术，用户不关心你用的是什么协议，他只关心「打开能不能看，看了卡不卡」。