简介：原生Java高仿短视频APP双端源码是一份完整的移动端短视频项目，面向Java/Android开发者及音视频技术学习者，适合用来理解App从界面到媒体处理再到服务端交互的完整实现。资源包含Android端Java代码、iOS端Objective-C代码，以及基于ThinkPHP和MySQL的服务器端逻辑。压缩包采用7z格式，共1127个文件、63.2MB。主要文件类型包括png图片素材、xml布局与工程配置、java源码，以及so动态库、jar依赖库等，覆盖UI资源、Android构建文件与底层编解码库，可在Android Studio中直接导入阅读。目前已有776人学习下载。源码中的关键学习点包括：用Activity/Fragment构建可复用界面、结合MediaCodec和FFmpeg处理音视频、借助OpenGL ES渲染视频帧；后端部分则能学习PHP接口开发与URL伪静态配置，对想深入双端短视频开发的人有较高参考价值。
1. 原生Java高仿短视频APP双端源码：先搞懂这条 java 音视频链路再动手
第一次拿到这份原生Java高仿短视频APP双端源码时，我先做的是解压后用 Android Studio 直接打开 Gralde 工程，结果还没编译就看到一串找不到 aar 的报错。后来把文件清单翻了一遍才明白，这套源码的价值不在“一键能跑”，而在于它把 java 音视频处理和完整移动端业务串在一起：Android 端负责拍摄、硬编、播放，iOS 端用 OC 和 AVFoundation 做采集编辑，服务端用 PHP 推接口、MySQL 存视频元数据。对想搞懂短视频 App 从录制到 Feed 流播放整个闭环的人来说，这是一个能拆着读、能挑模块落地到项目里的现成参考。新手可以从后端的伪静态和 API 开始顺藤摸瓜，熟手则可以直接提取音视频封装层复用。
2. 工程目录拆解：Android、iOS、PHP三个子工程怎么协同
2.1 顶层目录与三端职责划分
这套源码的顶层目录不是单一 App 工程，而是把移动端和服务端分成三个相对独立的代码仓库式目录，这是我拆源码时第一个要确认的。一份高仿短视频 App 前端至少有两个端，后端又是另一套技术栈，如果全部揉在一个目录里，编译和排查问题都会很痛苦。
比较典型的组织方式是这样的目录：
| 目录 | 职责 | 主要技术 |
|---|---|---|
| android/ | 短视频主界面、拍摄、播放、上传 | Java，Android SDK，RecyclerView |
| ios/ | 短视频采集、编辑、播放 | Objective-C，AVFoundation |
| server/ | 用户、视频、评论、点赞接口 | PHP 5.6，ThinkPHP，MySQL |
| docs/ | 接口文档、部署说明 | Markdown/SQL |
这份源码里 Android 工程的核心包名路径通常按功能划分，而不是按层划分。比如video.core放解码器封装和硬编硬解逻辑，video.ui放拍摄页和播放页，network放 API 请求封装。消息队列这类权重不高的功能会直接放一个包自己管，不像企业级项目按 domain/application/infrastructure 分层那么严格。对于学习和二次开发来说，按功能分包的定位更快。
iOS 端则遵循 MVC 架构，控制器层是XXXViewController，视图层是FeedView、RecordView这类自定义 UIView。和 Android 端不同，iOS 端的音视频逻辑大量依赖系统框架，代码量虽然不如 Android 多，但 AVFoundation 的会话配置直接决定了录制是否黑屏、是否有声音，这部分不能只看不跑。
服务端在server/Application下按 ThinkPHP 的模块方式组织，Home 模块处理前端页面，Api 模块处理移动端 JSON 请求。伪静态配置放在根目录的.htaccess或者 Nginx 配置里。
2.2 Android 模块：aar 依赖与 Gradle 构建配置
Android 工程里经常能看到libs目录下躺着几个 aar 文件，输入清单里的uGC_SDK_4.4.3774.aar和ti-sdk.aar就属于这类。aar 是 Android Library 的打包格式，里面不仅有 Java 类，还包含资源、so 和 AndroidManifest，比 jar 更完整。
我一般会把本地 aar 依赖单独放到app/libs下，用文件依赖方式引入。Gradle 配置长这样：
android { defaultConfig { ndk { // 只保留这两类 ABI，减少包体积，避免 x86 模拟器兼容问题 abiFilters "armeabi-v7a", "arm64-v8a" } } } dependencies { // 音视频 UGC SDK，包含推流、录制、编辑的 native 实现 implementation files('libs/uGC_SDK_4.4.3774.aar') // 业务封装 SDK，里面包装了认证、上传任务等逻辑 implementation files('libs/ti-sdk.aar') // 下拉刷新和图片加载这一类基础库 implementation 'androidx.appcompat:appcompat:1.2.0' implementation 'com.github.bumptech.glide:glide:4.11.0' }这段配置里有几个值得注意的点。abiFilters如果你不加，Gradle 会把所有 ABI 的 so 都打包进去，APK 体积多出几十 MB，而且在某些模拟器上运行 64 位包反而更容易出问题。这里的uGC_SDK_4.4.3774.aar对应的是输入中那份 4.4.3774 版本，老版本 SDK 对 Android 11 的分区存储适配不完整，如果你要跑在新手机上，可能还需要对文件路径做一次适配。ti-sdk.aar属于业务层封装，里面如果也引用了 OkHttp 或者 JSON 库，和主工程的版本一旦冲突，编译时会出现 duplicate class 报错，解决方式通常是依赖替换，先定位重复类是哪个库引入的，然后在对应依赖上用exclude排除。
2.3 iOS 模块：Objective-C 代码与 FFmpeg 库怎么放
iOS 端不像 Android 那样当着用户面秀 aar，第三方库经常以源码或 framework 形式存在。输入描述里提到 FFmpeg，我在拆这套源码时发现ios/ThirdParty目录下确实有编译好的 FFmpeg 静态库。这个库不是用来做全部解码的，而主要承担 Android 和 iOS 后端统一下发的视频转码、GIF 生成、音频抽取这些“系统框架做不过来”的活。
iOS 目录结构大致是这样：
| 路径 | 作用 |
|---|---|
| Classes/Controllers | 首页、拍摄、编辑、我的页面控制器 |
| Classes/Views | 视频列表 cell、录制按钮、滤镜滑杆 |
| Classes/Utils | AVFoundation 采集封装、FFmpeg 命令工具 |
| Frameworks | 第三方 framework 和静态库 |
| Resources | 启动图、滤镜资源、配置 plist |
这里要特别注意 iOS 的硬编硬解：AVFoundation 的 AVAssetWriter 用于录制输出，AVPlayer 用于播放，这套源码在录制预设里用的AVCaptureSessionPreset1280x720，帧率 30。如果你要改成 1080P，不仅采集端要动，编码 bit rate 也要跟着调整，不然生成的文件会非常大。
2.4 那些 .bin 文件到底是谁的
很多人打开源码压缩包，看到fileSnapshots.bin、localClassSetAnalysis.bin、fileHashes.bin这一串文件会以为是核心源码，其实这些是 Gradle 在增量构建时生成的缓存快照，英文单词拼起来就是文件快照、类集合分析、任务产物索引。它们记录的是一台机器上某个时刻的构建状态，拷贝到另一台电脑上不仅没用，有时还会因为路径不匹配导致 Gradle 认为缓存失效、重新编译。
正确的做法是：解压源码后直接把build目录和这些 bin 文件删掉，只保留源码、Gradle 配置和本地依赖库。我记得第一次没删，AS 的 Gradle 一直提示 cache is corrupted，我把.gradle和build目录清了才正常。所以后续每次拿到这类带编译缓存的源码包，我都会先执行一遍清理再打开工程。
3. 音视频处理核心：MediaCodec 硬解、OpenGL ES 渲染与 AVFoundation 采集
3.1 播放链路：MediaPlayer 还是 MediaCodec？
短视频 Feed 流的播放器和普通播放器最大的区别是：列表要顺滑、首帧要快、不能因为视频格式不同就卡住解码。这套源码在播放场景里同时用了 MediaPlayer 和 MediaCodec。MediaPlayer 封装度高，直接给一个 URL 和 Surface 就能播，适合视频列表里大多数 H.264 格式的视频；MediaCodec 负责处理那些需要做帧级处理的业务，比如滤镜、抽帧、加水印。
如果你在源码里看到MediaPlayer，它的用法通常是这样：
MediaPlayer player = new MediaPlayer(); player.setDataSource(videoUrl); player.setSurface(holder.getSurface()); player.setOnPreparedListener(mp -> { // 把首帧显示出来，避免黑屏等待 mp.start(); }); player.prepareAsync();这里的prepareAsync不能改成prepare，短视频列表页如果所有视频都在主线程同步准备，页面直接卡到用户划不走。setSurface的时机也很关键，必须在 SurfaceHolder 创建完成之后再传，否则播放器拿不到可用的画面输出窗口，表现就是有声音没图像。
MediaCodec 则复杂些，它就像一座黑匣子，输入原始压缩数据，输出原始解码帧。在源码里，MediaCodec 主要用于对视频做抽帧。
3.2 用 MediaCodec 解码视频帧的 Java 实现
下面这段是源码里解码视频帧拿 ByteBuffer 的简化逻辑：
MediaFormat format = MediaFormat.createVideoFormat("video/avc", width, height); format.setInteger(MediaFormat.KEY_COLOR_FORMAT, MediaCodecInfo.CodecCapabilities.COLOR_FormatYUV420SemiPlanar); MediaCodec decoder = MediaCodec.createDecoderByType("video/avc"); decoder.configure(format, surface, null, 0); decoder.start(); MediaCodec.BufferInfo info = new MediaCodec.BufferInfo(); while (!isFinished) { int inIndex = decoder.dequeueInputBuffer(10000); if (inIndex >= 0) { ByteBuffer inputBuffer = decoder.getInputBuffer(inIndex); // 从 MediaExtractor 中读取下一帧压缩数据 int sampleSize = extractor.readSampleData(inputBuffer, 0); if (sampleSize < 0) { decoder.queueInputBuffer(inIndex, 0, 0, 0, MediaCodec.BUFFER_FLAG_END_OF_STREAM); break; } decoder.queueInputBuffer(inIndex, 0, sampleSize, extractor.getSampleTime(), 0); extractor.advance(); } int outIndex = decoder.dequeueOutputBuffer(info, 10000); if (outIndex >= 0) { decoder.releaseOutputBuffer(outIndex, true); } } decoder.stop(); decoder.release();这段代码最要紧的是COLOR_FormatYUV420SemiPlanar，它对应的是 NV12 内存排布，很多设备硬解默认输出 NV12。如果你后续要喂给 OpenGL ES 做纹理渲染，必须知道这个颜色格式，否则纹理画出来颜色会偏绿或者花屏。decoder.releaseOutputBuffer(outIndex, true)的第二个参数传 true 表示把解码帧直接渲染到 surface。如果只想拿数据不想上屏，改成 false 并通过getOutputImage获取缓冲。
参数上，dequeueInputBuffer(10000)超时设的是毫秒，不要设 0，否则在极端帧率波动下会漏帧。外部读取源用 MediaExtractor 的readSampleData，传入的 ByteBuffer 大小需要预先分配，建议按视频宽高的 1.5 倍分配合适内存。
3.3 OpenGL ES 离屏渲染与滤镜
短视频美化离不开滤镜，这套源码里滤镜不是逐像素转 ByteBuffer 算的，而是通过 OpenGL ES 将解码得到的视频帧转成纹理，再在 Fragment Shader 里做 RGB 调整。这样能保证实时预览的流畅度，是成熟 App 常规做法。
一个简单的黑白滤镜着色器长这样：
precision mediump float; uniform sampler2D inputTexture; varying vec2 texCoord; void main() { vec4 color = texture2D(inputTexture, texCoord); float gray = dot(color.rgb, vec3(0.299, 0.587, 0.114)); gl_FragColor = vec4(vec3(gray), color.a); }OpenGL ES 渲染视频帧其实是把 SurfaceTexture 作为外部纹理，updateTexImage拿到最新帧，然后绑定GL_TEXTURE_EXTERNAL_OES。源码里如果你看到OES相关代码，不要改掉纹理 target，改成GL_TEXTURE_2D后大多数设备上内容会变成黑色。滤镜效果可以用强度值动态调，例如把gray和原色color.rgb做插值，实现从原图到黑白渐变。
3.4 iOS 侧 AVFoundation 采集与 FFmpeg 转码
iOS 端的采集链路完全依赖 AVFoundation。源码里录制页会用一个AVCaptureSession，配置 input 和 output 后把采集画面显示到AVCaptureVideoPreviewLayer上。录制时用AVCaptureMovieFileOutput写出视频，代码如下：
AVCaptureSession *session = [[AVCaptureSession alloc] init]; session.sessionPreset = AVCaptureSessionPreset1280x720; AVCaptureDevice *device = [AVCaptureDevice defaultDeviceWithMediaType:AVMediaTypeVideo]; AVCaptureDeviceInput *input = [AVCaptureDeviceInput deviceInputWithDevice:device error:nil]; [session addInput:input]; AVCaptureMovieFileOutput *output = [[AVCaptureMovieFileOutput alloc] init]; [session addOutput:output]; [session startRunning]; [output startRecordingToOutputFileURL:fileURL recordingDelegate:self];这里要注意sessionPreset不能直接设成AVCaptureSessionPresetHigh就完事，不同 preset 对焦段、帧率、编码质量的影响很玄学，拍短视频建议固定 720P 或 1080P，避免设备自动切换分辨率导致录制中断。startRecordingToOutputFileURL需要传一个文件 URL，而且是file://开头，写成路径字符串会直接 crash。
FFmpeg 在这套源码里的戏份主要是对本地视频转码，适配不同分辨率，比如把一个 4K 视频压成 720P：
// 注意：这是 OC 里拼接 FFmpeg 命令行参数的过程 NSArray *cmd = @[ @"ffmpeg", @"-i", inputPath, @"-vf", @"scale=1280:720", @"-b:v", @"2500k", @"-c:v", @"libx264", @"-y", outputPath ];这个命令里-b:v 2500k是视频码率，720P 短视频一般建议 2000k 到 3000k，太低了画面会有大量块状噪声，太高了上传慢。-c:v libx264指定 H.264 编码，短视频基本都用这个，兼容性最好。
4. 服务端联调：ThinkPHP 伪静态、MySQL 表结构与 API 请求签名
4.1 PHP 5.6 + MySQL 5.5 环境搭建要点
这套源码的服务端技术栈是 PHP 5.6 配 MySQL 5.5，都是老版本。你如果要跑在今天的环境里，PHP 7.4 以上大概率会出现mysql_connect函数不存在的问题，因为老代码常直接用mysql_*系列函数，而 PHP 7 已经删掉这些函数了。常见的做法是装一个 PHP 5.6 的集成环境，专门给这套源码用，例如 Windows 上可以建一个独立的 PHP 5.6 + Nginx 或 Apache 站点。
PHP 5.6 上跑 ThinkPHP 还要确认两个配置项：
; php.ini 中必须开启这两项 extension=php_pdo_mysql.dll extension=php_mysql.dll如果pdo_mysql没开，ThinkPHP 连数据库直接报could not find driver。另外 MySQL 5.5 的默认排序规则建议用utf8_general_ci，不要用utf8mb4_unicode_ci，老版本对 utf8mb4 支持不够好，遇到生僻字会变成问号。
4.2 ThinkPHP 伪静态配置：Apache 与 Nginx 两套写法
伪静态的目的就是把index.php/Home/Index/index这类 URL 变成/home.html类似的地址。源码里移动端实际请求的是 API 模块，所以伪静态规则也会把index.php/Api/重写掉。Apache 环境下的规则通常在根目录.htaccess：
<IfModule mod_rewrite.c> Options +FollowSymlinks -Multiviews RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php?s=$1 [QSA,PT,L] </IfModule>如果你用的是 Nginx，要在 server 配置里写：
location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?s=$1 last; } }伪静态 404 的排查重点在于：PHP 5.6 的 Apache 是否加载了mod_rewrite，以及AllowOverride None会不会拦截.htaccess。Nginx 则要确认if (!-e $request_filename)这句没有拼错，写成if (!-e $request_uri)就会把带参数的文件名也重写一遍，导致无限的循环转发。
4.3 MySQL 核心表设计
短视频 App 的后端表不会太多，但每张表都直接影响 App 功能。以这套源码为例，我看到的表设计思路如下：
| 表名 | 字段示例 | 作用 |
|---|---|---|
| user | id, nickname, avatar, signature | 用户信息 |
| video | id, user_id, video_url, cover_url, width, height, duration | 视频元数据 |
| comment | id, video_id, user_id, content | 评论 |
| video_like | id, video_id, user_id, create_time | 点赞记录 |
video表里至少要有width和height，客户端拿到视频地址后需要用这两个字段决定封面比例。有些代码直接测视频真实分辨率再裁，但那会造成列表布局跳动，所以服务端在视频上传成功后就要算好分辨率返回给 App。点赞表要唯一索引(video_id, user_id)，防止同一用户反复点击造成重复数据，这是后端最常见的坑。
4.4 移动端怎么调接口
移动端请求服务端时，源码里用的是 JSON 格式，HTTP 方法以 POST 为主。一个典型的登录接口请求长这样：
OkHttpClient client = new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .build(); JSONObject body = new JSONObject(); body.put("phone", "13800138000"); body.put("code", "123456"); body.put("sign", buildSign(body.toString())); Request request = new Request.Builder() .url("https://api.example.com/Api/User/login") .post(RequestBody.create(body.toString(), MEDIA_TYPE_JSON)) .build(); try (Response response = client.newCall(request).execute()) { JSONObject json = new JSONObject(response.body().string()); if (json.getInt("code") == 0) { // 保存 token 到 SharedPreferences } }这里的buildSign在源码里一般是把请求参数按 key 排序，拼上密钥后做 MD5。签名参数建议放在 JSON body 里，不要放 URL query，否则日志里容易把签名带出去。响应结构统一是{code, msg, data}，code 为 0 表示成功。如果后端返回 404，先去看伪静态规则，而不是查代码。
5. 避坑指南：黑屏、卡顿、SDK 冲突与伪静态 404
5.1 首帧黑屏
现象：视频列表滑动时，播放器有声音但画面黑屏，要等 2 到 3 秒才出第一帧。
原因：setSurface在 Surface 未就绪时传空，MediaPlayer 内部没有有效输出窗口，只能等待 Surface 回调。
解决：在SurfaceHolder.Callback的surfaceCreated之后再执行setSurface，不要直接在onCreate里调用。我一般会用一个标志位记录 Surface 是否可用，等数据源准备好后统一处理。这样首帧时间能压到 200ms 以内。
5.2 播放卡顿掉帧
现象：在低端机上播放 1080P 视频，画面一卡一卡，但单独用系统播放器正常。
原因：MediaPlayer 默认硬解，但某些厂商对高分辨率 H.264 的硬解能力不足，解码速度跟不上 30fps 的渲染节奏。
解决：把视频转码到 720P，或者降低播放器的setVideoScalingMode。如果链路是自己写的 MediaCodec 解码，那还要检查dequeueOutputBuffer的超时时间，10ms 以下会频繁空转。最直接的判定方法是打印每帧的presentationTimeUs，看相邻帧间隔是否稳定在 33ms 附近，如果跳变明显就说明解码端出问题了。
5.3 aar 与 support 库冲突
现象：编译时报More than one file was found with OS independent path META-INF/xxx或 duplicate class。
原因：uGC_SDK_4.4.3774.aar和ti-sdk.aar内部打包了support-annotations、json 库等公共类，主工程也依赖相同库，Gradle 不知道用哪份。
解决：在packagingOptions里排除 META-INF 文件，并对重复的模块打上 exclude：
android { packagingOptions { exclude 'META-INF/DEPENDENCIES.txt' exclude 'META-INF/INDEX.LIST' } } dependencies { implementation('com.squareup.okhttp3:okhttp:3.14.9') { exclude group: 'org.json', module: 'json' } }我当时遇到的是ti-sdk.aar里旧 OkHttp 与主工程的新版冲突，最后把 aar 里重复的类单独抽出来重新分包才算救回来。建议拿到 aar 后先解压看一眼libs目录，提前知道里面有什么再做依赖。
5.4 伪静态规则生效后 404
现象：Apache 环境访问接口返回 404，直接访问index.php/Api/User/login又能通。
原因：.htaccess的 RewriteRule 没生效，或者AllowOverride没开启，导致服务器不读取该文件。
解决：先确认 Apache 配置中站点根目录是AllowOverride All。同时在.htaccess第一行加RewriteBase /，防止子目录部署时重写路径错位。Nginx 场景则要重启服务，并检查rewrite是否写在location /而不是location ~\.php$块里，后者会拦截到 PHP 文件时不进行重写，导致路由被当成真实路径。
5.5 UGC SDK 被混淆后录制失败
现象：开启混淆后打正式包，拍摄页初始化就闪退，或者录制按钮点击没反应，debug 包正常。
原因：SDK 里的 native 方法、Activity、Service 没有被 keep，混淆把类名和方法名改了，native 层按原符号找不到入口。
解决：在 proguard 规则里把 SDK 相关包全量 keep：
-keep class com.ugc.sdk.** { *; } -dontwarn com.ugc.sdk.**也不要只 keep 类名而忽略方法名，写{ *; }是稳妥的。另外如果 SDK 通过反射调用V4AppContext这类内部类，也要 keep。血泪经验是：after 打正式包，先在混淆配置里搜 SDK 的包名，再对照 SDK 的说明文档把文档建议的 keep 规则全部贴进去，不要省。
6. 端到端验证：用模拟 Feed 把录制到播放跑通
源码到手后，最怕的是每个模块单独看着都对，连起来根本走不通。我会用一条最简链路做端到端验证：录制一段视频，上传服务端，然后在列表页播放它。整个过程用命令行脚本就能辅助完成。
先检查服务端是否正常启动，注册一个测试账号并登录拿 token：
curl -s -X POST http://你的服务器地址/index.php/Api/User/register \ -H "Content-Type: application/json" \ -d '{"phone":"13800000001","code":"123456"}'响应里会包含token字段。接着把电脑里准备好的一段 MP4 推到模拟器或手机上，然后模拟 App 上传行为：
adb push test.mp4 /sdcard/DCIM/test.mp4 adb shell am start -n com.example.shortvideo/.ui.publish.PublishActivity \ --es video_path "file:///sdcard/DCIM/test.mp4"进入发布页后手动确认上传和封面生成是否正常。发布成功后，去列表页看新视频是否出现在第一个位置，点击播放能否在 1 秒内出现首帧。如果黑屏，暂停播放并拉日志：
adb logcat -s MediaPlayer:V MediaCodec:V看有没有Error (1,-)或input buffer not available之类的记录。排查的关键是用真机，模拟器虽然能跑界面，但硬解码和 OpenGL ES 的渲染路径和真机差异很大，很多黑屏、花屏问题在模拟器上复现不出来。
验证通过后，我会把这条脚本存成一个verify.sh放到工程根目录。从那以后每次改完音视频模块或者换机器跑这套源码，我都强制走一遍注册、上传、播放的闭环，确认至少这三点没问题才继续往下改：第一接口能通，第二视频能传，第三列表能播。希望这些操作细节能在你拆这份源码时少走几步弯路，帮到你。
本文还有配套的精品资源，点击获取
