简介：这是一款名为ONE兔2.0的社区交友婚恋视频即时通讯双端APP完整源码，面向移动应用开发者、产品经理及有意入行的新手，提供可直接编译运行的iOS与Android项目基础。源码包共2000个文件，以747个HTML页面、584个JavaScript脚本、347个Java后端代码为主，辅以CSS样式、JSON配置、SQL数据库脚本等，涵盖前端界面、业务逻辑、服务端接口与数据表结构；其中HTML与CSS构成多端页面骨架，Java与JS分别负责服务端接口和交互逻辑，SQL、JSON则便于初始化数据库与联调，压缩包整体87.08MB。已有131人学习下载，说明其具备一定参考价值。开发者可基于现有模块快速搭建功能完整的交友婚恋应用，也可通过研读源码掌握社区动态、智能匹配、实时视频通讯等核心实现思路，并针对UI、算法或业务流程进行二次定制，是学习原生移动开发与全栈实践的实用素材。

1. ONE兔2.0：一套源码同时覆盖交友、婚恋与视频通话，拆之前先想清楚这三件事

拿到这套“原生社区交友婚恋视频即时通讯双端APP源码 ONE兔2.0版”，第一反应别急着看 CSS 和 UI 图，先想清楚一个问题：这套源码里最值钱的不是视频通话那一层，而是社区动态流与婚恋匹配的耦合逻辑。多数同类产品把社区、匹配、IM 拆成三个独立模块凑在一起，而 ONE兔 2.0 的特点是匹配结果会反向影响社区信息流的排序，这层业务联动关系才是二次开发时最值得保留和扩展的地方。源码按 iOS 与 Android 双端组织，社区、婚恋匹配、视频即时通讯三大能力都落在原生层，适合两类人：一类是准备快速搭建社交产品原型、需要可编译可演示代码的团队；另一类是刚入门移动端、想研究原生社交应用完整工程结构的新手。拆包之前建议先确认三件事：音视频 SDK 的授权方式、用户体系是否依赖服务端部署、以及源码里是否包含支付与审核相关配置，这三件事直接决定你拿到手后是先跑通界面还是先补服务端。

2. 双端代码组织：ONE兔 2.0 的 iOS/Android 目录结构与原生通信边界

2.1 从工程依赖判断它是不是“真原生”：查 Podfile 和 build.gradle

拿到压缩包先别解压完就双击打开，我一般先看工程配置文件。iOS 侧查 Podfile 或 Cartfile ，Android 侧查 app/build.gradle ，这两份文件能直接暴露项目的技术栈底细。如果依赖列表里大量出现 Flutter、React Native、uni-app 相关库，说明所谓的“原生”只是壳；如果依赖集中在 AFNetworking、SDWebImage、Glide、OkHttp、EventBus 这类典型原生库，基本可以确认是纯原生工程。ONE兔 2.0 的源码里 iOS 侧常见的是以 Objective-C 为主、Swift 混编的工程结构，Android 侧则是 Java/Kotlin 混用，音视频部分依赖模块化 SDK。

用命令快速看目录结构是个高效做法，可以跳过 IDE 加载直接确认模块边界：

unzip ONE兔2.0.zip -d onetu-src
cd onetu-src
find . -maxdepth 2 -type d | head -50
find . -name "Podfile" -o -name "build.gradle" | head -10

这条命令把压缩包解开后，第一层目录通常是 iOS 、 Android 、 Server （如果作者附带服务端）三个顶层模块。 find 限定两层深度能看到主要业务模块，比如 IM 、 Live 、 Community 、 Match 这类目录名。如果顶层就有 Pods 或 .gradle 缓存目录，说明依赖已经拉取过；如果没有，编译前要先执行 pod install 或 Gradle Sync，否则工程打不开。参数说明： -maxdepth 2 控制查找深度，避免输出几十层第三方库目录干扰判断； head -50 截取前 50 行，防止终端刷屏。

2.2 双端通信层的公共抽象：IM 信令和业务请求都走统一 JSON 信封

原生双端最怕的是两端各写一套协议，调试时字段对不上。ONE兔 2.0 的做法是在双端各维护一个 MessagePacket 封装类，所有业务消息统一走同样的 JSON 信封，业务字段全部放在 data 里。这种设计的好处是服务端只认一种协议格式，推送、IM、视频呼叫都能复用同一套解析链路。

{
  "ver": "2.0",
  "cmd": 1001,
  "seq": 893245617,
  "ts": 1719296000000,
  "data": {
    "from": "uid_1024",
    "to": "uid_2048",
    "msg_type": "text",
    "content": "你好，看了你的动态，想认识一下"
  }
}

这个信封格式里 ver 是协议版本号， cmd 是命令字， seq 是客户端生成的请求序列号，用于匹配响应和做去重， ts 是毫秒级时间戳。 data 是业务负载，不同类型消息可以替换 msg_type 和 content 。我建议二次开发时保留这套信封结构，不要因为某次需求改动就新增字段到外层，否则后续加视频通话信令、礼物消息、位置共享都要改解析层，影响面太大。双端各写一个 PacketParser ，Android 用 Gson 解析，iOS 用 MJExtension 或 Codable，模板代码可以直接抄这层。

2.3 服务端接口在源码里的落点：找到 API 客户端就能看清功能边界

双端源码里的接口调用都集中在各自的网络层目录，Android 一般在 data/api/ 或 network/ ，iOS 一般在 Network/ 或 APIManager/ 。找到这几个目录，所有功能对应的后端接口就浮出水面了。以 Android 侧为例，通常会看到类似这样的 Retrofit 接口定义：

interface OnetuApi {

    @POST("v2/community/feed/list")
    suspend fun feedList(
        @Query("page") page: Int,
        @Query("pageSize") pageSize: Int,
        @Query("scene") scene: String
    ): ApiResponse<FeedListData>

    @POST("v2/match/recommend")
    suspend fun recommend(
        @Body request: RecommendRequest
    ): ApiResponse<List<UserCard>>
}

feedList 用于拉取社区信息流， page 和 pageSize 分页， scene 是场景标识，不同 Tab 传入不同值； recommend 是匹配推荐接口，请求体里通常包含用户筛选条件。注意这个 scene 参数，ONE兔 2.0 的社区信息流分成关注、推荐、同城三个场景，服务端返回的数据结构完全不同，所以接口里用枚举字符串区分。你二次开发时如果要加“带话题的动态”，一般不是改接口，而是在 FeedListData 里埋 topic 字段，这比新增接口成本低，同时能复用已有的分页缓存逻辑。

3. 社区动态与婚恋匹配：ONE兔 2.0 的内容流和智能推荐，核心不在算法而在数据模型

3.1 社区内容流的两种实现：时间线拉取与关注分发

社区动态模块在功能上看起来是“发动态、看动态、点赞评论”，但实际工程实现要解决两个问题：数据怎么存、信息流怎么排序。ONE兔 2.0 的动态数据模型按用户维度组织，每一条动态归属一个用户，用户在首页看到的是自己关注列表加推荐池的混合流。源码里动态表结构大致长这样：

CREATE TABLE `feed_post` (
  `post_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) unsigned NOT NULL COMMENT '发布者ID',
  `content` text COMMENT '文本内容',
  `image_list` text COMMENT '图片URL列表，逗号分隔',
  `video_url` varchar(512) DEFAULT '' COMMENT '视频地址',
  `location_code` varchar(32) DEFAULT '' COMMENT '同城场景定位编码',
  `topic_id` bigint(20) DEFAULT '0' COMMENT '话题ID，0为无话题',
  `like_count` int(11) DEFAULT '0',
  `comment_count` int(11) DEFAULT '0',
  `status` tinyint(4) DEFAULT '1' COMMENT '1正常 0删除',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`post_id`),
  KEY `idx_user_time` (`user_id`, `create_time`),
  KEY `idx_topic_time` (`topic_id`, `create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

表里 user_id 加 create_time 的联合索引支撑“我关注的人的时间线”， topic_id 加 create_time 支撑话题流， location_code 用于同城筛选。注意这里的 image_list 用逗号分隔存储多张图，是社区产品常见的折中方案；如果你要支持图片排序和裁剪参数，建议改成 JSON 数组格式存入，前端解析更可控。 like_count 和 comment_count 是冗余计数字段，每次点赞评论时用事务更新，避免查询时做 count 聚合拖慢列表页。

3.2 婚恋匹配打分：从排除硬性条件到多因子加权计算

ONE兔 2.0 的婚恋匹配不是简单“符合条件就推荐”，而是把候选用户过一遍硬性条件过滤，再对剩余用户做多因子加权打分排序。硬性条件包括性别取向、年龄区间、距离范围、是否在线等，这部分用 SQL 直接过滤：

SELECT u.user_id, u.nickname, u.age, u.city_code, u.height,
       u.education, u.income_level, u.avatar_url
FROM user_profile u
WHERE u.gender = #{targetGender}
  AND u.age BETWEEN #{minAge} AND #{maxAge}
  AND u.status = 1
  AND u.user_id NOT IN (
    SELECT black_uid FROM user_blacklist WHERE uid = #{currentUserId}
  )
  AND u.user_id NOT IN (
    SELECT liker_id FROM user_like_record WHERE liked_id = #{currentUserId} AND status = 0
  )
ORDER BY RAND()
LIMIT 200;

这段 SQL 先把异性、年龄区间、正常状态、黑名单和已拒绝过我的用户排除掉， ORDER BY RAND() 是粗筛，取 200 个候选进入内存层打分。实际项目里 RAND() 在大表上会很慢，更稳的做法是 LIMIT 一个大的偏移量后交给推荐服务去做均匀采样。拿到候选列表后再按匹配度打分，权重大致是年龄差 30%、身高差 10%、教育程度 10%、收入水平 10%、兴趣标签重合度 25%、活跃度 15%，具体权重在服务端配置中心可调。打分模型的核心在于兴趣标签重合度——用户选择兴趣标签时会被限制在 20 个以内，重合一个加 5 分，重合超过 6 个进入“高匹配池”，信息流里会优先展示对方的动态。

3.3 常见二次开发点：用户标签体系和筛选条件扩展

这套源码里用户标签字段是硬编码的字符串枚举，比如 hobby 字段存的是逗号分隔的 “movie,music,sports”。扩展时我建议改成标签 ID 数组并独立建表，同时增加一个 tag_weight 字段，让不同标签在匹配打分时权重不同。筛选条件同样存在硬编码问题， user_profile 表里的 income_level 、 education 是固定枚举，如果你要接入婚姻状况、是否接受异地恋这些新维度，不要继续往主表堆列，建一张 user_extend 扩展表，用 key-value 方式存储，查询时动态拼接过滤条件。这种设计改动小，而且不影响老版本 App 的接口兼容。

4. 视频即时通讯：ONE兔 2.0 的信令流程、音视频链路与双端 Debug 手段

4.1 选型判断：源码里的信令封装层，暴露了音视频方案的真实结构

视频通话模块是这套源码里最容易让二次开发者误判的部分。很多人拿到源码翻到音视频相关目录，看到一堆 RTCEngine 、 CallSession 类，以为是自研 WebRTC，其实大多数情况下是接入了第三方音视频 SDK 后再包了一层统一信令。判断方式很简单：看目录里有没有集成厂商的特征文件名，声网会有 AgoraRtcEngine ，腾讯云会有 TRTCCloud ，即构会有 ZegoExpressEngine ，七牛会有 QNRTC 。ONE兔 2.0 源码里的音视频链路是模块化设计，底层 SDK 可以替换，信令层完全由源码控制。

选型时我一般按团队情况做取舍，核心对比维度如下：

对比维度	自研 WebRTC	第三方音视频 SDK
搭建周期	2 个月以上，需要维护 STUN/TURN	1 周内可跑通
月成本	服务器带宽和 TURN 流量费用	按分钟计费，峰值有折扣
弱网表现	需要大量调优经验	厂商已内置弱网策略
自定义能力	全链路可控	受限于厂商能力边界
源码耦合度	信令、媒体全自控	只控信令，媒体层黑盒

如果产品只是 MVP 验证阶段，建议保留 ONE兔 2.0 原有的信令框架，底层 SDK 换成自己账号的厂商 SDK，这样成本最低。如果要做海外市场或者深度定制美颜、虚拟形象，自研 WebRTC 才有必要。注意无论哪种方案，信令层必须保留呼叫、振铃、接听、拒绝、挂断、超时、网络切换这一整套状态机，否则用户体验断崖式下跌。

4.2 信令消息流：从呼叫到挂断的完整状态流转

ONE兔 2.0 的呼叫信令走的是长连接通道，通常封装在 IM 模块内部，和普通聊天消息用同一条链路。呼叫过程中信令消息按序流转，状态机定义如下：

IDLE -> CALLING -> RINGING -> ACCEPTED -> TALKING
  |         |          |          |
  |         +-> CANCEL+          +-> REJECT
  |                    |              |
  +--------------------+--------------+-> IDLE
  |                    |
  +--------------------+-> NO_RESPONSE (30s timeout)

状态说明：主叫方发起邀请，信令 call_invite 从 CALLING 进入 RINGING 表示被叫方设备已收到；被叫点击接听后发送 call_accept ，双方进入 TALKING ；任一方挂断发送 call_hangup 回到 IDLE ；30 秒无响应则服务端推送 call_timeout 。源码里要重点看两个边界处理，一是 CALLING 状态下主叫主动取消时要发 call_cancel ，防止被叫端一直响铃；二是通话过程中如果收到 network_switch 信令，客户端要自动重连音视频通道而不是直接挂断。

调通信令后可以用一个简单的自动化脚本验证消息序列，方便定位是哪一端丢消息：

const net = require('net');

const client = net.createConnection({ port: 5222, host: '127.0.0.1' }, () => {
  const invite = JSON.stringify({
    ver: '2.0', cmd: 2001, seq: Date.now(),
    data: { from: 'uid_test1', to: 'uid_test2', type: 'video_call' }
  });
  client.write(invite + '\n');
});

client.on('data', chunk => {
  const msg = JSON.parse(chunk.toString().trim());
  console.log(`cmd=${msg.cmd} seq=${msg.seq} ts=${msg.ts}`);
  if (msg.cmd === 2005) client.end();
});

这段 Node 脚本模拟主叫端发起视频呼叫并打印服务端返回的信令命令字， cmd=2001 是呼叫邀请， cmd=2005 是服务端确认回执。你在本地调试时可以把 PORT 指向自己部署的信令服务，通过观察命令字序号判断信令是否按预期顺序到达。如果收到 cmd=4001 之类的错误码，通常是被叫端不在线或者权限校验失败，去服务端日志里查用户在线状态即可。

4.3 双端联调时的抓包与日志定位

视频通话出问题时，最怕双端互相甩锅。我的习惯是先用抓包确认信令层有没有到达，再看媒体链路，最后才看业务逻辑。Android 侧直接抓日志：

adb logcat -s OnetuRTC DEBUG | grep -E "call_state|rtc_stats|signal"

这条命令过滤 OnetuRTC 模块的日志，查看 call_state 的状态跳转、 rtc_stats 的码率分辨率变化、 signal 信令收发记录。iOS 侧在 Xcode 的 Console 里直接搜索 OnetuRTC 关键词，效果一样。如果信令正常但画面出不来，用 tcpdump 看媒体端口：

tcpdump -i any -n port 20000-30000 -w rtc_media.pcap

视频媒体流一般走 UDP，抓 20000-30000 端口段的包，抓完用 Wireshark 打开看 RTP 包是否正常到达。如果发现大量重传包，说明上行带宽不足，需要调低编码码率而不是改信令超时。这个排查思路比盲目翻源码高效得多，尤其在双端同时出问题时能快速切分责任边界。

5. 二次开发落地：ONE兔 2.0 从源码到可上线 App 要补的最后一步

5.1 替换签名、包名与推送配置

拿到源码后最容易忽略的是包名和签名。Android 侧如果直接编译安装，会和你本机其他应用冲突，而且推送服务、第三方登录都会因为包名不匹配而失效。替换时要同步改四处： build.gradle 里的 applicationId 、 AndroidManifest.xml 里的 package 属性、 MainActivity 的包路径、以及第三方 SDK 后台配置的包名。iOS 侧要改 Bundle Identifier ，同时去 Apple Developer 后台重新生成推送证书，否则 APNs 推送直接报错。这块没有捷径，漏一处就是运行期莫名其妙的崩溃或回调失败。

5.2 音视频弱网参数调优与验证

音视频模块的默认参数是给演示环境用的，码率、帧率、分辨率都偏保守。上线前我一般做一轮弱网调优，核心参数在 RTCConfig.java 或 RTCConfig.m 里：

RTCConfig config = new RTCConfig();
config.setVideoProfile(480, 848, 15);          // 分辨率宽高 + 帧率
config.setMinBitrate(200);                     // 最小码率 kbps
config.setMaxBitrate(1200);                    // 最大码率 kbps
config.setAudioSampleRate(48000);
config.setAudioChannelCount(1);
config.setWeakNetworkStrategy(WeakNetworkStrategy.BALANCED);

这段配置里 minBitrate 和 maxBitrate 是最关键的两个参数。带宽充足时用 maxBitrate 保证画质，网络变差时逐步降到 minBitrate ，低于这个值就触发“网络不佳”提示。 BALANCED 策略适合社交类产品，在画质和流畅度之间取中间值；如果是婚恋场景需要看对方表情细节，可以切到 CLEAR_PRIORITY 。改完参数后不要只看局域网效果，用 macOS 自带的 Network Link Conditioner 或 Android 的弱网模拟工具限速测试，重点观察 300ms 延迟加 5% 丢包时通话是否断线。验证标准是：3 分钟通话内画面卡顿不超过 3 次，且卡顿后能在 2 秒内恢复。满足这个标准，音视频模块的二次开发才算真正收尾。

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