陌生人视频匹配App源码解析：Java服务端与WebRTC信令实战

简介：一份基于Java的陌生人交友App视频匹配社交聊天软件设计源码，面向具备一定Java基础、希望入门移动端社交类项目的开发者，覆盖陌生人匹配、视频通话、聊天消息等典型功能模块的实现思路。资源共含253个文件，以61个Java源文件、33个Vue前端文件、31个JavaScript脚本为主体，配合46张PNG界面切图、20个TTF字体、SCSS样式以及SQL与XML配置文件等，压缩包整体约35.41MB，目录结构清晰，便于按后端逻辑、前端页面、静态资源分层学习。内容预览中可见主页与视频演示动图，能辅助理解功能效果；完整源码包含数据存储、接口调用、页面交互等常见环节，适合二次开发，也可作为课程设计或毕业设计的参考项目。目前已有770人浏览学习，适合需要快速搭建陌生人社交App原型或研究音视频匹配交互的Java学习者深入研读。

1. 陌生人交友App里的视频匹配，为什么值得单独拿一套Java源码来研究

陌生人交友App最容易做砸的功能就是视频匹配。按钮点下去，到对面画面出现，中间隔着匹配调度、信令交换、NAT穿透、编解码协商四层，每一层都可能让用户卡在“连接中”。我见过不少团队把IM聊天做得很好，一上视频就翻车，原因不是不会调摄像头，而是没把“匹配”当成一个并发服务来设计。这套基于Java的陌生人交友App源码，对应的是一个包含服务端和Android客户端的完整工程：Java负责匹配调度、会话管理、消息存转发，客户端负责采集渲染，两端用WebSocket交换信令，用WebRTC承载音视频。对正在做社交聊天软件或想进泛娱乐方向的人说，这是一份能把理论变成真机通话的最小样本。适合先跑起来，再逐段改造成商业项目。

2. 先看清整套源码的地图：Java服务端与Android端各自负责哪一半

拿到任何一份源码，第一件事不是找启动类，而是先看目录和模块边界。陌生人视频匹配App表面是聊天软件，本质是带实时音视频能力的即时通讯系统。常见做法是把工程拆成两个仓库：Java服务端负责状态与调度，Android客户端负责体验与采集。服务端体感最重的部分不是REST接口，而是匹配队列、信令网关和会话状态机；客户端体感最重的部分不是界面，而是PeerConnection的生命周期管理。先看懂这个分工，后面所有排错都能落到“这是哪一侧的问题”。

2.1 服务端选型背后的三个硬指标：并发匹配、状态一致性、低延迟信令

为什么陌生人交友的服务端要选Spring Boot + Netty + Redis的组合，而不是一台普通Web服务器包打天下？因为视频匹配有三个普通聊天没有的压力点。

第一是并发匹配。用户都在晚上八九点涌入，匹配接口的QPS会短时拉高。匹配不能像订外卖那样排队慢慢来，用户在等匹配时每多一秒就多点一次退出。这就要求“取人”和“配对”在毫秒级完成，而Redis的list和hash天然适合做这件事，Java里用StringRedisTemplate就能在几行代码内完成一次原子出队。

第二是状态一致性。匹配这个动作不是“你发起请求、返回一个对方用户”就结束了。两个人如果能被配到一起，服务端必须保证同一个人同一时刻只出现在一个匹配流程里，否则就会出现“一个人同时被两三个人匹配到”的玄学问题。这个约束靠MySQL行锁做会很慢，放在Redis的Lua脚本里做才是常规解。

第三是低延迟信令。视频接通要看SDP与ICE交换的往返速度。HTTP轮询的延迟在三五百毫秒以上，而且服务端没法主动推送给客户端。WebSocket长连接能把信令延迟压到几十毫秒，Netty或者Spring WebSocket都能承担这个角色。不少团队把Spring Boot当HTTP容器，再把WebSocket单独拆给Netty，一套Java体系里两个进程，职责分开，升级互不影响。

关键要认识一个事实：视频匹配的瓶颈不在“视频”而在“匹配”。视频流走P2P或TURN直通，与业务服务器无关，业务服务器只调度不转流。所以把Redis和WebSocket做好，匹配成功率才会上去，码率调得再高也救不了匹配后连不上。

2.2 按模块拆源码：认证、匹配、会话、消息、审核五个子系统的边界

一份合格的陌生人交友App源码，业务模块一般围绕五条线来组织。拿到源码后，按这五条线去目录里找对应包，比从头到尾读代码快得多。

认证模块负责登录、注册、设备指纹与Token签发。陌生人交友的登录方式通常包含手机号和第三方授权两种，Token要短时效，刷新Token要长时效。源码里一般会有独立的auth包，里面是Interceptor过滤器链，别把登录逻辑散落在各个接口里。

匹配模块是核心，它负责“把两个人拉到一起”，产出一次匹配关系。匹配策略可能简单到“队列里有就弹出来配对”，也可能复杂到按性别、地域、标签加权。这个模块在源码里通常只依赖Redis，不直接落库，因为匹配行为本身不需要存，只有匹配成功或失败的结果才需要存档。

会话模块负责通话房间的生命周期。匹配成功之后，服务端创建一个带唯一roomId的房间，记录两个用户ID、状态、创建时间。源码里最常见的坑是这个模块和匹配模块耦合在一起，匹配完直接进入通话状态，导致挂断后状态不知道回退到哪一层。正确做法是匹配只负责“牵线”，房间单独管理。

消息模块负责聊天文本、礼物、系统通知，这是陌生人聊天软件里最像传统IM的部分。基于Java的实现常见套路是Spring Boot + MyBatis操作MySQL落库，再用WebSocket或MQ推动在线消息。注意消息与视频通话并发时的时序，最典型的就是边通话边发文本消息，两条通道对端到达顺序不一致。

审核模块是陌生人社交App里绝对不能省的一块。头像、昵称、房间内违规内容都要有上报和处置通道。源码里哪怕只是预留了举报接口，也说明作者有上线意识；如果完全没有，自己要补。

2.3 数据库表设计与Redis数据结构的最小雏形

把这五条线落到存储上，需要的最小数据集大概是四张表：用户表、匹配记录表、会话表、消息表。下面这段SQL直接改字段就能用（基于MySQL 8、utf8mb4）：

CREATE TABLE `user` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '用户ID', `nickname` VARCHAR(64) NOT NULL COMMENT '昵称', `gender` TINYINT NOT NULL DEFAULT 0 COMMENT '0未知 1男 2女', `avatar_url` VARCHAR(255) DEFAULT '' COMMENT '头像', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0离线 1在线 2匹配中 3通话中', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_gender_status` (`gender`,`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `match_record` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `user_id_a` BIGINT NOT NULL, `user_id_b` BIGINT NOT NULL, `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0未接通 1接通 2超时 3挂断', `room_id` VARCHAR(64) DEFAULT '' COMMENT '通话房间号', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_a` (`user_id_a`, `created_at`), KEY `idx_user_b` (`user_id_b`, `created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='匹配记录表'; CREATE TABLE `call_session` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `room_id` VARCHAR(64) NOT NULL, `user_id` BIGINT NOT NULL, `peer_user_id` BIGINT NOT NULL, `state` TINYINT NOT NULL DEFAULT 0 COMMENT '0初始化 1呼叫中 2通话中 3已结束', `started_at` DATETIME DEFAULT NULL, `ended_at` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_room_user` (`room_id`,`user_id`), KEY `idx_user_state` (`user_id`,`state`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='通话会话表'; CREATE TABLE `chat_message` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `room_id` VARCHAR(64) NOT NULL, `from_user` BIGINT NOT NULL, `to_user` BIGINT NOT NULL, `msg_type` TINYINT NOT NULL DEFAULT 0 COMMENT '0文本 1图片 2礼物 3系统', `content` TEXT, `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_room_time` (`room_id`,`created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='聊天消息表';

字段里建议留意三点。一是user表的status不能只依赖数据库，它只是给运营看的状态快照，运行时的实时状态要用Redis维护，数据库里的status靠异步任务回写。二是match_record只记录结果，不承担匹配过程，过程全在Redis。三是chat_message的room_id字段让文本消息和视频会话共用同一把关联键，后端排查问题时按room_id能把两条链路串起来。

Redis侧的数据结构是这套源码的另一半。匹配队列用list，左侧生产右侧消费，LPUSH match_queue:10001 5000123；在线状态用hash，HSET online_users 10001 "{ip,connId,ts}"；通话房间状态用hash，field是roomId。再维护一个zset online_users_ts存每个用户最后一次活跃时间，score就是时间戳，用来清扫僵尸会话。这四个结构足够撑起第一版，往后加需求时别急着换存储，优先加Redis里的key。

提示：这套工程跑起来之前，先把环境变量配好，JDK 17以上、Maven 3.8以上、MySQL 8、Redis 6都齐了再启动。卡在环境上的问题比代码多，这是很多人忽略的java基础功。

3. 把陌生人匹配做成状态机：Redis队列、WebSocket信令与通话生命周期代码

匹配模块最容易写坏的地方，是没把整个流程定义成状态机。我一般会在源码里先找四个状态：IDLE（空闲）、MATCHING（匹配中）、CALLING（呼叫中）、TALKING（通话中），外加一个终态CLOSED。任何一次点击，都只是驱动状态迁移的事件。下面这段Java服务端的实现思路，按匹配、信令、清理三段拆开讲。

3.1 匹配请求入队：用Redis的原子操作防止“一个人被匹配两次”

陌生人交友的匹配接口，并发高峰时可能同时进来上千个请求。常规的“先查队列，再分配对象”写法，在并发下会产生重复分配。所以入队和配对必须放在同一个原子操作里。

public Long matchAndPop(Long userId, String gender, String targetGender) { String listKey = "match_queue:" + targetGender; String lockKey = "match_lock:" + userId; // 用SETNX做用户级互斥，防止同一个用户重复发起匹配 if (!stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS)) { throw new RuntimeException("重复匹配请求"); } try { // 优先从对端队列里取一个人 String peerId = stringRedisTemplate.opsForList().leftPop(listKey); if (peerId != null) { return Long.valueOf(peerId); } // 队列为空，把自己塞进队列并返回null表示等待 stringRedisTemplate.opsForList().rightPush("match_queue:" + gender, userId.toString()); return null; } finally { stringRedisTemplate.delete(lockKey); } }

这段代码里有三个参数值得细说。锁的过期时间设10秒，正常情况下匹配动作几毫秒就结束，锁过期只为了防死锁；如果环境里网络抖动严重，可以调到15秒，但不能再长，否则用户想取消匹配都进不来。队列的leftPop和rightPush放在同一把锁里，配合单一Redis实例时能保证同一个用户不会同时出现在两条队列里。gender参数不能只依赖前端传，服务端要拿Token里的性别字段覆盖，这是陌生人交友最常见的接口伪造点。

只做入队离“能匹配上”还差一步。用户B入队后，服务端需要立即通知B“有新匹配对象”，这个通知不能靠B轮询，要靠WebSocket下行推送。匹配成功的事件，服务端只需要推一条消息，比如{"action":"matched","roomId":"r_10001","peer":{}}，B端收到后自动发起呼叫信令，这就进入下一节的状态。

3.2 信令交换：Java服务端转发SDP与ICE候选的WebSocket代码

视频能建立起来，靠的是信令把三个东西送来送去：发起方的SDP、应答方的SDP、双方的ICE候选。服务端在这里只做鉴权、转发和房间绑定，不解析音视频数据。用Spring WebSocket实现一段转发逻辑很直接：

@MessageMapping("/signal/{roomId}") public void onSignal(@DestinationVariable String roomId, @Payload SignalMessage msg, Principal principal) { // 校验发送者确实在roomId房间里 if (!sessionService.inRoom(principal.getName(), roomId)) { return; } // 按消息类型做不同转发：offer/answer透传给对端，ICE也是透传 String targetUser = msg.getTargetUserId(); if ("candidate".equals(msg.getType())) { // ICE候选频率高，直接转发，不落库 webSocketSessionService.pushToUser(targetUser, msg); } else { // offer/answer要串行处理，防止两个端同时改状态 synchronized (roomId.intern()) { callStateMachine.transit(roomId, principal.getName(), msg); webSocketSessionService.pushToUser(targetUser, msg); } } }

这里的几个设计点新手容易漏。第一个是inRoom校验，WebSocket长连接一旦建立，服务端要能判断这条连接的Principal和roomId的关系，否则被刷接口的成本远高于REST接口。第二个是offer/answer锁，视频协商时不要并发处理，按roomId加锁，避免双方同时发出offer导致状态错乱。第三个是candidate不过滤，它可以高频到达，如果对端已经挂断，直接丢弃，服务端不用保存。

Java服务端做这种信令网关，常见的坑是把消息粘包处理放在业务线程里。Netty的handler里应该先粘包拆包、后进业务方法；Spring WebSocket相对省心，协议解析已经做好了，业务层只需要处理消息对象，这也是我用Spring WebSocket做主信令通道的原因。

3.3 心跳超时与会话清理：让挂死的通话房间主动释放

视频匹配里有一种翻车非常隐蔽：用户A匹配成功，用户B在点接受的一瞬间把App划掉了。服务端还存着“呼叫中”状态，用户A等了几秒自动超时，但这个房间在内存和Redis里都留着，不清理就会泄漏。最终表现是服务端内存缓慢上涨，一天后不得不重启。

给心跳加一层不可靠检测就行。客户端每5秒上报一次PING，格式是{"action":"ping","roomId":"r_10001","ts":<时间戳>}。服务端在Redis里更新心跳：

ZADD room_heartbeat r_10001 <当前秒级时间戳>

后台调度任务每30秒扫描一次这个zset，把score小于当前时间减15秒的roomId清理掉，同时通知两端会话结束：

@Scheduled(fixedDelay = 30000) public void sweepExpiredRooms() { long cutoff = System.currentTimeMillis() / 1000 - 15; Set<Object> expired = stringRedisTemplate.opsForZSet() .rangeByScore("room_heartbeat", 0, cutoff); for (Object roomIdObj : expired) { String roomId = roomIdObj.toString(); // 通知会话双方 notifySessionEnd(roomId, "timeout"); // 清Redis与本地状态缓存 clearRoomContext(roomId); } }

这里的参数口径是血泪经验：心跳间隔5秒，超时阈值15秒，清扫周期30秒。阈值太短，用户切后台3秒就断；阈值太长，挂了半分钟用户都无感知。Android切后台时音频通道还在跑，但网络可能被系统挂起，心跳会断，所以通话中要在前台Service里保活，不是只靠心跳。

这套状态机的完整推导，其实也是Java服务端面试里常被追问的题：从匹配入队、信令转发到超时回收，考察的既是Redis使用，也是并发下状态迁移的严谨程度。

4. Android端跑通视频聊天：WebRTC接入、Camera切换与码率控制代码

服务端负责调度，但用户看到的一切都由客户端决定。Java的Android端接入WebRTC，通常选用官方的org.webrtc库，它已经封装好了采集、编解码和传输。真正要自己写的代码集中在PeerConnection初始化、对信令消息的处理和画面渲染绑定三处。这里再强调一遍：WebRTC库不做信令，所有信令仍要走服务端的WebSocket回传。

4.1 PeerConnection初始化：IceServer、编解码与采集参数

初始化PeerConnection是整个App最不能出错的地方。参数定错，后面所有优化都是白费。这里是一段可运行的初始化模板：

PeerConnection.RTCConfiguration rtcConfig = new PeerConnection.RTCConfiguration(iceServers); rtcConfig.tcpCandidatePolicy = PeerConnection.TcpCandidatePolicy.DISABLED; rtcConfig.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE; rtcConfig.continualGatheringPolicy = PeerConnection.ContinualGatheringPolicy.GATHER_CONTINUALLY; rtcConfig.iceCandidatePoolSize = 10; // 媒体约束：视频和音频都开启 MediaConstraints mediaConstraints = new MediaConstraints(); mediaConstraints.mandatory.add(new MediaConstraints.KeyValuePair("OfferToReceiveVideo", "true")); mediaConstraints.mandatory.add(new MediaConstraints.KeyValuePair("OfferToReceiveAudio", "true")); PeerConnection peerConnection = factory.createPeerConnection(rtcConfig, observer); // 采集参数：720P、30帧、默认前摄像头 CameraVideoCapturer capturer = createCameraCapturer(Camera2Enumerator.getInstance(context)); VideoSource videoSource = factory.createVideoSource(capturer); VideoTrack localVideoTrack = factory.createVideoTrack("local_video", videoSource); peerConnection.addTrack(localVideoTrack, mediaConstraints);

这里三个参数直接影响连接质量。第一，iceCandidatePoolSize设为10，意思是连通性检测阶段会预先收集10个候选，减少双方建立连接前的等待时间，代价是少量电量和流量。第二，GATHER_CONTINUALLY让候选收集在通话过程中持续进行，弱网切换Wi-Fi到4G时会重新收集，不加这个移动场景经常连不上。第三，摄像头优先用Camera2，Camera1在新机型的兼容性维护成本太高，旧机型才需要降级回Camera1。

要特别说明的是，PeerConnection的factory要全局复用，但PeerConnection实例要做到一个会话一个。每次匹配成功新建，挂断后close并置空。常见错误是把它存成全局静态对象，第二次匹配时拿到的还是上一次的列表流，画面上一直显示上一个陌生人的剩余画面。

4.2 配对后的信令处理和摄像头切换：重建Track比替换Track更可靠

客户端收到服务端下发的matched消息后，下一步就是创建Offer并把它发给对端。流程很固定：创建PeerConnection、创建Offer、setLocalDescription、信令发给服务端转发。这里不再重复标准三步，重点说摄像头切换这个高频功能，它在陌生人交友里比普通IM更常用，因为用户第一反应就是不开摄像头或者切后摄像头展示环境。

// 切换到后摄像头 private void switchCamera() { if (videoCapturer != null) { videoCapturer.switchCamera(switchDoneCallback); } // 部分机型必须在切换后重新协商，否则对端画面卡住 if (needRenegotiation) { peerConnection.createOffer(new SdpCallback() { @Override public void onCreateSuccess(SessionDescription sdp) { peerConnection.setLocalDescription(new SdpCallback() { @Override public void onCreateSuccess(SessionDescription sdp2) { sendSignal("offer", sdp2.description, targetUserId); } }, sdp); } }, mediaConstraints); } }

switchCamera本身只需要一行，真正让很多项目翻车的全是细节。needRenegotiation标志位必须判断：编码参数没变时，多数机型不需要重新协商；但小米、vivo部分机型固件在切换后不会发送关键帧，对端画面会卡在最后一帧，这种情况强制renegotiate可解。统一策略是“切完摄像头主动发一个offer”，虽然多一次协商往返，但兼容性最好，这点开销在陌生人通讯里可以接受。

对端收到offer后回调里也要做好一件事：setRemoteDescription成功后再setLocalDescription应答，顺序反了会拿到无效的answer。可以把这个顺序判断写到回调的状态机里，和服务端状态机一一对应。

4.3 真机验证视频通话质量的三个参数：帧率、码率与分辨率的下限阈值

很多源码在模拟器上跑得好好的，真机一测就糊。原因通常是固定了分辨率不管机型性能。第一版可以按下面的表给参数，然后根据线上反馈分批调：

这三组参数不要只写死在代码里，启动时做一次能力探测更靠谱：读CPU核数、总内存、屏幕分辨率，对应到档位。视频码率还要一个动态下限，弱网时自动降到300kbps，保证画面能动。很多人把这个下限设到0，网络一抖画面整个卡死，反而让用户误以为App挂了。

帧率也别一味追高。对端屏幕刷新率60Hz的时候，24fps已经流畅，30fps只是给硬件留余量。把码率省下来给分辨率，陌生人场景更能看清对方环境，这是从运营数据里得到的经验，不是拍脑袋。

5. 陌生人视频匹配App的踩坑与排查清单：从配对失败到花屏发烫

不管服务端还是客户端，视频匹配App的绝大多数问题都集中在连接建立和画质体验两个环节。这一章把我反复踩过的坑按现象、原因、解决的顺序整理成一个清单，每一条都能直接在真机上复现。

5.1 匹配成功但一直显示“连接中”：ICE穿透失败与TURN中继缺失

现象：双方都收到matched消息，也交换了offer和answer，但双方一直处于连接中，始终不进入通话。

原因：两边的网络都不允许P2P直连。最常见的场景是用户A在办公网（有防火墙），用户B在家庭宽带（上游运营商做了Symmetric NAT），STUN只能拿到公网映射，打洞就是打不通，这时必须有一台TURN中继可用。

解决：给WebRTC配置至少一组TURN。自建coturn是最快路径，部署后把地址、账号、密码填进iceServers。注意TURN端口要同时开放UDP和TCP两种，在链路质量敏感的地区，TCP中继的连接建立会稍慢，但成功率远高于UDP裸连。上线前用两台不同网络形态的真机做一次穿透矩阵测试，把“双方NAT都严格”这条路径跑通，再对外放量。

5.2 视频发绿或花屏：硬编解码兼容性被低估

现象：通话建立成功，但画面不是偏绿，就是花屏马赛克，有些机型彻底黑屏。

原因：WebRTC默认的H264硬编解码在不同芯片的profile支持程度不一致。老芯片对H264 High Profile支持不全，编码端用了高端profile，解码端只支持Baseline，协商失败后回退不彻底，画面直接异常。

解决：把约束加在Offer的Sdp里，强制使用profile-level-id=42e01f（H264 Constrained Baseline）。两个端都在初始化时加上这个约束，兼容性立刻好转。如果团队测试资源有限，还可以直接切到VP8编码，体积变大，但兼容性是WebRTC全家桶里最好的，代价是低端机软编发热。

5.3 用户连续匹配到同一个对象：匹配没做冷却期

现象：用户匹配三次，两次遇到同一个人，尤其热门时段高发。

原因：匹配队列里剩下的人少，出队逻辑又只认“队列非空就弹一个”，没有排重、没有冷却。陌生人交友场景里女用户数量本来就少，多次被同一个男用户匹配到，体验会很不好。

解决：Redis里维护两个结构：一个zset recent_peer:<userId>记录最近5天配过的对端用户，score是时间戳；另一个是zset cool_down:<userId>记录冷却到期时间。弹人前先用ZRANGEBYSCORE把冷却期内的人临时过滤掉，队列空了就把当前用户放回队尾等下一轮。冷却期一般设24小时，男女用户统一口径，别对某一性别开特权。

5.4 服务端Java堆内存一直上涨：WebSocket会话引用泄漏

现象：服务端跑两天，JVM堆占用从40%爬到90%，GC后也回不去，必须重启。

原因：最常见的真凶是WebSocketSession实例存在某个static的Map里，用户挂断或断线后没有从Map里移除。Java服务端不像C++那样崩在明处，这种泄漏是温水煮青蛙，看着还在服务，实际早就在慢性消耗。

解决：在连接关闭回调里，除了给用户改状态，还要执行sessionMap.remove(userId)。把所有连接会话的增、删、查收敛到一个ConnectionManager类里，统一加日志。上线后用jstat -gcutil <pid> 1000观察Full GC频率，如果每半小时都Full GC，说明还有别的资源没释放，排查顺序是会话Map、定时任务里的局部变量、MQ消费线程里的累积缓冲。

5.5 低端机通话十分钟就发烫掉帧：自动降级链路没做全

现象：入门级手机通话五分钟后背板发烫，取景框预览开始掉到个位数帧率，随后系统弹温度提示。

原因：一上来就锁定720P/24fps也不是都扛得住。原因有二：720P编码本来就在低端机CPU里占用很高，加上预览、美颜、信令解码同时在跑，功耗直接拉满。

解决：把4.3的参数表接上运行时降级。在通话中每30秒读一次温度（可读/sys/class/thermal/thermal_zone0/temp，也可以直接用功耗估算），超过阈值自动降分辨率到480P、帧率降到15fps，并把码率降到600kbps。降级动作要重新协商SDP，这属于对端能感知的正常调整，不用弹窗告知。做过这个链路之后，低端机差评率能明显下降。

6. 从“能跑”到“能上架”：视频匹配App的升级清单与验收步骤

前五章解决的是“能跑”，这一章说清楚“能上架”还差哪些东西。视频匹配放量之后，技术就不再是唯一的胜负手，内容安全、举报链路、压测口径和日志留存变成了上线的硬门槛。

6.1 第一批该补的功能：内容安全、举报与黑名单

视频匹配一旦放量，内容审核就不是可选项。房间内出现违规内容时，两个用户都能一键举报，服务端收到后要能立刻断流或拉黑。这一套机制要接入到状态机里：举报动作直接驱动会话进入CLOSED，并写入举报记录。黑名单用Redis的set维护，入队前先检查，拉黑之后双方永不匹配。在入口审核也可以做，头像昵称过一遍机审，至少保证能删能改。陌生人社交App在应用商店审核时，举报与处置通道的完整性会被重点看，没有这两条链路基本到不了上架环节。

6.2 压测怎么定指标：匹配成功率的两种算法

上线前先跑两轮压测。第一轮测匹配调度：用模拟客户端开线程同时打匹配接口，观察匹配成功率，口径是成功建立的房间数除以匹配请求数，第一目标定99%以上。第二轮测连接建立：真机或模拟端同时跑50路，把连接建立成功率看成关键指标，口径是进入RTC_CONNECTED状态的会话数除以成功建立的房间数，目标在95%以上。低于这个数别急着买量，先回头查TURN中继和ICE配置。

注意两轮压测不要同时做，先调度后连接，否则出问题分不清责任。压测机要模拟不同网络形态，不能全在同一个机房内网跑，否则等于没测。

6.3 一个让我少走弯路的习惯：把信令日志当证据链保存

我自己的习惯是信令通道每一进一出都写结构化日志，包含时间戳、roomId、消息类型、对端用户ID。看起来是小事，但线上问题九成靠它定位：匹配失败翻日志看是在哪一步没有收到answer；画质问题翻日志看是不是协商出的分辨率不对；用户投诉连续碰到同一个人，翻日志看两次匹配的roomId和用户ID就能确认冷却逻辑有没有生效。日志可以热删，但不要不记。

还要提醒的是，陌生人交友更依赖外部回流和用户拉新，App下载页在iOS端和Android端的唤起体验经常不一致，很多用户就卡在“下载-安装-回来”这一步流失掉。分发路径比想象中更影响匹配大盘，值得跟技术链路一样认真对待。

我从第一次做视频匹配项目到现在，最大的感受是：陌生人交友这类App的技术复杂度并不在界面上，而是在状态与连接这两条暗线上。每一次“匹配上了却连不上”的投诉，背后都对应一段没有定义清楚的生命周期；每一次画质问题，背后都是一次没谈拢的编码协商。先把状态机、心跳、穿透、降级这几个骨架理顺，比急着加美颜滤镜有意义得多。希望帮到你。

本文还有配套的精品资源，点击获取