绿豆APP源码7.0：苹果CMS原生JAVA影视APP动态域名插件实战指南-开发者社区

简介：修正版绿豆APP源码7.0是一套基于苹果CMS原生JAVA的影视点播源码，集成木白动态域名插件，适合希望快速搭建自有影视APP的开发者与运营者。功能与萝卜APP基本一致，覆盖投屏、画中画、倍速、弹幕、下载、试看、三级分销、积分任务、激励广告与开屏广告等模块；广告位既可对接信天翁平台，也支持自定义上传，后台内置三个播放器，并支持切片、官方解析与线路并发，整体运营配置灵活。资源共2000个文件，主要包含728个xml布局/配置、523个java核心逻辑、281个json数据、225个html内置页面以及js、css等辅助资源，压缩包约925.81MB，目录结构完整，可在Android Studio中直接导入打包。目前已有446人学习下载。源码百分百可运行且无需授权，但安装配置需要一定技术基础，更适合具备Android开发经验、能独立解决环境问题的进阶用户。

1. 绿豆APP源码7.0到底修了什么：先搞清楚这套影视APP的骨架

拿到这套绿豆APP源码7.0木白动态域名插件版苹果CMS原生JAVA影视源码，很多人第一反应是直接塞进Android Studio编译，结果十有八九卡在接口对接和编译环境上。先说结论：这套东西的本质是一个原生Java写的安卓影视客户端，通过苹果CMS自带的VOD接口拉取影片数据，再叠加一个动态域名切换插件，解决接口域名失效后APP变“死壳”的问题。所谓7.0修正版，修的不是UI多好看，而是原版里播放器崩溃、播放地址解析错位、部分机型黑屏这些能直接劝退用户的硬伤。

这套源码适合两类人：一类是自己已经搭好苹果CMS内容站、不想再依赖第三方套壳工具、想出一个真正属于自己包名的原生APP；另一类是研究动态域名切换机制的开发同学，想知道APP怎么在后台域名失效时自动换到备用地址。内容版权和授权问题不在源码讨论范围内，需要你自己搞定，这套东西只解决工程落地。下面按我的实操顺序来，先把本地编译跑通，再谈插件、对接和排坑。

2. 从源码到能跑的APP：环境准备与本地编译的完整动作

本地能不能跑起来，决定了后面所有工作值不值得继续。遇到过太多人问我：为什么照着源码改了半天，一编译全是红错？多数情况不是源码问题，是工具链版本没对上。这套源码是原生Java项目，不是Flutter也不是RN，所以环境坑相对固定，按下面几步走基本能一次过。

2.1 环境版本怎么选：JDK、IDE与SDK的匹配关系

先别急着装最新版Android Studio。老源码对最新工具链经常水土不服，最常见的就是Android Gradle Plugin版本和Gradle版本不匹配，导致同步直接失败。我一般先看项目里的gradle-wrapper.properties，里面锁定了这个项目预期使用的Gradle版本，再反向决定JDK和IDE：

cat gradle/wrapper/gradle-wrapper.properties

重点看distributionUrl里的版本号，比如gradle-6.7.1-all.zip。Gradle 6.x 对JDK 8和JDK 11都支持，但如果你本地装的是JDK 17，部分老版本AGP会直接报Unsupported class file major version。这个参数的意思是：项目启动构建时用哪个Gradle版本去编译，它不是装的软件，而是由wrapper自动下载到本地。如果你网络不稳，它会一直卡在下载阶段，所以这里也可以顺便确认下distributionUrl的下载源是否被内网拦截。

接下来的环境选择，我建议按这个表兜底：

组件	建议配置	说明
JDK	1.8 或 11	优先用JDK 8，兼容性最稳
Android Studio	4.2 及以上即可	新版也能开，但别让它乱升级AGP
SDK Platform	29 或 30	和项目compileSdkVersion对齐
Build Tools	29.0.3 左右	版本向下兼容，别装太新

翻车最多的是有人装了JDK 17，然后AGP还是3.x，编译到一半报各种UnsupportedOperationException。解决很简单，在Android Studio的Project Structure里把JDK切到本机装好的JDK 8，或者直接改项目里的gradle.properties，加上一句指定Java环境的参数。

2.2 首次编译的完整操作：导入、换源、出Debug包

确认环境后，用Android Studio选择Open an existing project，选中源码根目录，等待Gradle同步。首次同步大概率会卡在依赖下载上，因为默认仓库是Google和Maven Central，国内访问很慢。这里我会先把仓库换成阿里云镜像，改项目根目录的build.gradle：

buildscript { repositories { maven { url 'https://maven.aliyun.com/repository/public' } maven { url 'https://maven.aliyun.com/repository/google' } maven { url 'https://maven.aliyun.com/repository/gradle-plugin' } google() mavenCentral() } }

这段配置的意思是把Gradle插件和依赖库的下载源优先指向国内镜像，maven.aliyun.com/repository/public对应的是central和jcenter的聚合，google对应Android官方依赖。改完之后重新同步，速度会快很多。注意：如果项目里用了某些只在特定私有仓库发布的依赖，镜像里找不到，保留原来的google()和mavenCentral()做兜底即可，别整个删掉。

同步通过后，直接出Debug包验证环境是否真的通了：

./gradlew assembleDebug

assembleDebug是Gradle构建Debug版本的任务，会依次执行资源合并、Java编译、打包和签名（Debug用的是默认调试签名）。如果这步报AAPT2 error或者resource linking failed，八成是SDK Platform版本和项目compileSdkVersion不一致。打开app/build.gradle，把compileSdkVersion改成你本地已下载的版本号，同步再编。首次出包大概五到十分钟，成功后输出目录在app/build/outputs/apk/debug/下，拿到一个可以直接安装的APK文件。到这里，至少证明源码本身没病。

2.3 替换CMS地址与包名：搜索、替换、验证一条龙

编译通过只是开始。源码里默认的接口地址和包名肯定是别人的，不换掉，装到手机上打开就是一片空白甚至闪退。我一般先做一次全局搜索，找硬编码的域名和包名：

grep -rn "http://" app/src/main/java/ | head -30

这条命令会把Java代码里所有写死的HTTP地址列出来，重点看配置类。常见的做法是源码里有一个ApiConfig或AppConfig类，集中管理接口地址，长这样：

public class ApiConfig { // 主接口域名，发布前替换为你自己的苹果CMS域名 public static String BASE_URL = "http://your-cms-domain.com/api.php/provide/vod/"; // 备用域名，配合动态域名插件使用 public static String BACKUP_URL = "http://backup-domain.com/api.php/provide/vod/"; }

这里的BASE_URL是APP请求影片列表和详情数据的根地址，BACKUP_URL是动态域名插件的兜底入口。改的时候不要只改一处，全局搜一下有没有第二处硬编码，有些版本会把地址写进布局或者Assets配置文件里，漏掉的话就会出现“改了半天没生效”的错觉。

包名替换比地址替换更隐蔽。直接全局替换代码里的包名路径，还要同步改app/build.gradle里的applicationId、AndroidManifest.xml里的package属性，以及asset里所有引用包名的地方。最常见的翻车点是FileProvider的authorities没改，导致安装后打开文件选择或版本更新时崩溃，因为它把authorities写死成了旧包名。

替换完之后验证一下有没有漏网的请求，登录服务器或者本机起一个抓包，然后命令行过滤APP产生的HTTP请求：

adb logcat -s OkHttp

这个命令会打印App中OkHttp相关的日志，如果看到请求地址还是旧域名，说明还有地方没替换干净。务必确认所有请求都指向你自己的域名之后，再进入下一步，否则后面动态域名插件接进来，会在错误的前提下做判断，排错会非常痛苦。

3. 动态域名插件是怎么让APP不“失联”的：原理与接入方式

动态域名插件是这套源码的亮点，也是它值钱的地方。很多影视APP倒在维护上：不是产品不行，而是某个域名挂了之后，老用户装着的APP再也连不上服务，只能等重新发版。木白动态域名插件解决的就是这个场景——域名失效、DNS解析异常或服务器更换时，APP能自己找到下一个可用的地址。

3.1 动态域名插件的执行流程：从启动到请求发出

插件的核心思路不复杂：不把域名写死成一个，而是维护一份域名列表，APP启动后逐个试探，选一个当前能通的域名作为请求入口。完整流程是：APP冷启动，先读本地缓存的域名列表；如果缓存不存在或过期，就请求一个固定的“引导接口”获取最新域名配置；拿到后对每个域名做连通性探测；把第一个能通的域名写回本地缓存，后续业务请求全部走这个域名；同时启动一个定时任务，每隔一段时间重新拉取配置，防止某个域名悄悄失效。

接入时，最常见也最稳的做法是用OkHttp的Interceptor拦截器，把每个请求的Host动态替换成当前可用域名。看这段代码：

public class DomainInterceptor implements Interceptor { @Override public Response intercept(Chain chain) throws IOException { Request original = chain.request(); String current = DomainManager.getInstance().getCurrentDomain(); if (!original.url().host().equals(Uri.parse(current).getHost())) { HttpUrl newUrl = original.url().newBuilder() .host(Uri.parse(current).getHost()) .scheme(Uri.parse(current).getScheme()) .build(); Request request = original.newBuilder().url(newUrl).build(); return chain.proceed(request); } return chain.proceed(original); } }

这段代码的逻辑是：每次请求出去之前，先拿到当前可用域名，然后比较原请求的Host是否一致。不一致就把Host和scheme都替换成新域名，再放行请求。注意这里我同时改了scheme，因为很多备用域名为了省事只配了HTTPS，如果原请求写死的是HTTP，不改scheme的话会被运营商的劫持页面拦一道。参数上，getCurrentDomain()返回的是完整地址，包含协议头，这是为了避免在拼接时丢scheme。

3.2 远程下发配置与数据结构：后台侧怎么配合

插件本身只是客户端一半，另一半在后台。你需要准备一个接口，返回APP可用的域名列表和策略配置。这个接口最好放在自己的服务器上，哪怕是个静态JSON都行。返回结构长这样：

{ "code": 1, "msg": "ok", "data": { "domains": [ "http://api-a.example.com", "http://api-b.example.com", "http://api-c.example.com" ], "strategy": "first_available", "refreshHours": 12 } }

各字段含义如下：domains是候选域名数组，APP会按照数组顺序逐个探测；strategy是选择策略，first_available表示选第一个能通的域名，random表示从可用域名里随机挑一个，适合多个域名做负载分摊；refreshHours是域名配置的刷新间隔，建议设在6到24小时之间，太短会频繁请求引导接口，加大服务器压力，太长则域名失效后恢复慢。

客户端拿到这段JSON后，用Gson解析再写进本地缓存：

public void refreshDomains(String json) { Gson gson = new Gson(); DomainConfig config = gson.fromJson(json, DomainConfig.class); SharedPreferences sp = context.getSharedPreferences("domain_cache", MODE_PRIVATE); sp.edit() .putString("domain_list", gson.toJson(config.domains)) .putLong("refresh_time", System.currentTimeMillis()) .putInt("refresh_hours", config.refreshHours) .apply(); }

这段代码做的事情是：把远程返回的域名列表和刷新周期存到SharedPreferences里，apply()是异步写入，不会卡主线程。读取缓存时注意判断时间戳，别每次启动都刷一遍，刷得太勤反而容易被服务端限流。苹果CMS本身不提供这个插件的后台接口，我一般是在CMS里加一个自定义接口程序，或者单独部署一个轻量接口，用来输出这段JSON。

3.3 接入后必调的3个参数：超时、重试与降级

动态域名插件接入后，有三个参数必须调，不调就等着翻车。

第一个是连通性探测超时时间。默认OkHttp的connectTimeout是10秒，探测域名时如果第一个域名服务器不响应，会卡满10秒才换下一个，用户看到的就是启动白屏。建议改成3秒，配合retryOnConnectionFailure(true)，整体探测一个域名的时间控制在3秒内。

OkHttpClient client = new OkHttpClient.Builder() .connectTimeout(3, TimeUnit.SECONDS) .readTimeout(5, TimeUnit.SECONDS) .writeTimeout(5, TimeUnit.SECONDS) .retryOnConnectionFailure(true) .addInterceptor(new DomainInterceptor()) .build();

connectTimeout是建立连接的超时，readTimeout是等待响应的超时，retryOnConnectionFailure表示连接失败后自动重试一次。对视频接口这种请求体比较大的场景，读超时给5秒比较合适，再长会导致极差网络下一直转圈。

第二个是探测请求的选择。很多人用HEAD请求做连通性检测，省流量，但部分服务器禁了HEAD，返回404，误判域名不可用。我建议直接用GET请求引导接口，比如请求http://api-a.example.com/api.php/provide/vod/?ac=videolist&pg=1，状态码200且返回JSON就算通。这样检测和真实业务请求保持一致，误判率最低。

第三个是全部域名失效时的降级文案。这是最容易被忽略的：域名全挂了，APP不能卡死在启动页。要给一个明确的提示页或者Toast，比如“内容服务正在升级，请稍后重试”。一方面用户能理解，另一方面留一个手动重试按钮，触发一次强制刷新域名配置。这一条直接决定用户体验的下限，值得专门写一段逻辑处理。

4. 苹果CMS后台与APP的对接细节：播放器、分类与解析适配

动态域名解决的是“连得上”的问题，接下来是“连得上之后能不能出数据”。这套源码对接的是苹果CMS的VOD接口，字段名、分类ID、播放地址格式，这三样只要错一个，APP表现就是列表空白或者点击播放没反应。而这恰恰是新手最容易自我怀疑的地方：代码没改坏，但就是不出数据。

4.1 苹果CMS的API开关与VOD请求链路

先确认苹果CMS后台的接口模式已经打开。在后台的“系统-网站参数-接口模式”里要选“标准接口模式”，否则外部请求会被拒掉。然后直接用浏览器或者命令行验证下最基础的数据接口：

curl "http://your-cms-domain.com/api.php/provide/vod/?ac=videolist&pg=1&t=1"

参数含义：ac=videolist表示请求视频列表，pg=1是页码，t=1是分类ID。如果后台没开启分类ID为1的分类，可以去掉t参数先看全量数据。返回的JSON大结构是这样的：

{ "code": 1, "msg": "数据列表", "page": 1, "pagecount": 10, "limit": "20", "total": 200, "list": [ { "vod_id": 1, "vod_name": "测试影片", "vod_pic": "http://example.com/poster.jpg", "vod_play_from": "wjm3u8", "vod_play_url": "第1集#http://example.com/1.m3u8$$$第2集#http://example.com/2.m3u8" } ] }

APP这边拿到的就是list数组里的这些字段。vod_id是影片唯一ID，详情页的请求靠它；vod_name是片名；vod_pic是海报地址，如果这个地址用的域名是HTTPS而你CMS又是自签证书，图片会加载不出来；vod_play_from是线路名，多个线路用逗号分隔；vod_play_url是播放地址集合，这是最需要小心处理的字段。改完地址后，先用这个curl确认返回200和正确的JSON格式，再上APP排查，否则很容易把CMS的问题误判成APP的问题。

4.2 分类ID、播放组与线路的映射关系

播放地址解析是影视类APP里最容易写错的地方。vod_play_url的分隔符有固定约定：用$$$区分不同线路，用#区分同一线路下的不同集数。看这段解析代码：

public void parsePlayUrl(String playFrom, String playUrl) { String[] lines = playUrl.split("\\$\\$\\$"); String[] froms = playFrom.split(","); for (int i = 0; i < lines.length; i++) { String line = lines[i]; String[] episodes = line.split("#"); String lineName = i < froms.length ? froms[i] : "线路" + (i + 1); // episodes[0] 是集数名，episodes[1] 是播放地址 Log.d("PlayParse", "线路:" + lineName + " 首集地址:" + episodes[1]); } }

这里的逻辑是先把整个播放地址串按$$$切成多条线路，再对每条线路按#切成单集。playFrom字段用逗号分隔线路名，它的顺序和$$$切割后的数组顺序是一一对应的，所以lineName取playFrom对应下标的名称。注意Java里split("\\$\\$\\$")必须转义三个美元符号，少写一个转移符，整个字符串就切不开。

分类ID的映射更隐蔽。APP首页每个Tab对应一个分类ID，这个ID不是写死在Java里的，就在APP的配置文件里：

{ "category": [ { "name": "电影", "id": 1 }, { "name": "电视剧", "id": 2 }, { "name": "综艺", "id": 3 } ] }

这里的name是APP首页显示的分类名，id是苹果CMS后台的分类ID。两边对不上，表现就是首页分类能显示，点进去列表空荡荡。遇到这种情况，先去后台看分类实际ID，再回APP配置里对齐。最典型的翻车案例：后台把“电影”分类ID改成了15，APP里还写着1，用户一点电影分类，请求的是t=1，后台返回空列表，前台表现为白屏加一直loading。

4.3 播放器与解码器的选型取舍

播放地址解析出来后，下一个坎是播放器。这套源码里通常内置了两套播放方案：原生播放器和WebView播放。原生播放器一般基于IJKPlayer或ExoPlayer封装，IVIEW和H5播放是WebView方案。音频视频解码兼容性上，IJKPlayer最稳但包体积大；ExoPlayer对HLS协议支持好、平滑切换清晰度强，但老机型对某些编码格式支持差；WebView方案上线最快，但直播流和加密地址支持不好。

我个人偏好是主播放页面用IJKPlayer，遇到特殊协议再降级到WebView。IJKPlayer里最需要调的是解码方式，有一段经典配置：

IjkMediaPlayer player = new IjkMediaPlayer(); player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec", 0); player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec-auto-rotate", 0); player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "opensles", 0); player.setOption(IjkMediaPlayer.OPT_CATEGORY_FORMAT, "dns_cache_clear", 1);

参数解释：mediacodec=0是关闭硬解走软解，软解兼容性最好，但耗电高；如果你的用户群体基本都是近两年的机型，可以改成1走硬解，流畅度会明显提升；opensles=0是关闭OpenSL ES音频输出，解决部分机型播放没声音或者声音卡顿的问题；dns_cache_clear=1是每次播放前清DNS缓存，防止播放地址域名切换后解析到旧IP。这组参数几乎可以应对80%的黑屏和无声问题，剩下20%是片源本身编码不规范，只能换播放器处理。

5. 打包上架前的必查清单与高频故障排查

本地能跑、数据能出、视频能放，接下来就是准备上线。这个阶段最容易返工的是包名签名和版本号问题，其次是各种版本改乱了之后冒出来的怪故障。我每次打包前都会按下面的清单走一遍，能省掉大量重复安装调试的时间。

5.1 签名、包名与版本号：上架前的身份三件套

签名文件决定你是不是这个应用的主人。很多源码自带一个debug签名，直接用那个装到手机上没问题，但一旦想覆盖安装升级或者上架到分发平台，就必须换成自己的正式签名。生成签名文件的命令：

keytool -genkey -v -keystore release.keystore -alias video_app -keyalg RSA -keysize 2048 -validity 36500

参数说明：-keystore release.keystore是生成的签名文件名；-alias video_app是别名，后面在Gradle里要用；-keyalg RSA -keysize 2048指定加密算法和密钥长度；-validity 36500表示有效天数，约100年，影视APP更新周期长，签名过期会导致无法覆盖安装，所以一次性把天数拉满。生成过程中会要求设置密钥库密码，这个密码务必记牢，丢了就等于丢了应用的更新权。

然后把签名配置写进Gradle：

android { signingConfigs { release { storeFile file("../keystore/release.keystore") storePassword "你的密码" keyAlias "video_app" keyPassword "你的密码" } } buildTypes { release { signingConfig signingConfigs.release minifyEnabled true proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro" } } }

minifyEnabled true表示开启代码混淆，可以减小包体，但开了混淆后必须配合正确的keep规则，否则运行时报错。这里特别强调混淆规则，是因为影视源码里大量用到Gson反射，把Bean类一混淆，Gson解析时就找不到字段了，表现就是打开APP列表空白但日志无异常。加在proguard-rules.pro里的规则：

-keep class com.yourpackage.bean.** { *; } -keepattributes Signature -keepattributes *Annotation*

这条规则的意思是：com.yourpackage.bean包下所有类的所有成员都保留，不混淆；Signature属性保留，这是Gson解析泛型List时必须的。写完后打一个release包，安装到真机，重点验证列表加载、详情页跳转、播放启动这三个最基础的链路。

5.2 高频故障排查：闪退、空白、黑屏三类典型问题

我按出现频率从高到低整理了三个问题，基本覆盖这套源码80%的线上翻车场景。

第一个是安装后打开即闪退，日志里报ClassNotFoundException。现象：APP图标一闪而过，Logcat里能找到“Could not find class xxx”。原因是混淆把某个动态反射的类干掉了，或者JDK编译版本不一致。解决：先关掉minifyEnabled打包验证，如果是混淆问题，把报错类的包名加到keep规则里；如果是JDK问题，切回JDK 8重新clean再build。

第二个是列表空白但顶部轮播图正常。现象：首页能滑，海报能加载，但下方推荐列表一直是空的。原因：请求返回的分页字段和APP解析的字段对不上，常见的是苹果CMS返回limit字段，而APP解析的是pagesize。解决：把接口返回的JSON原样打印到日志里，对比APP代码里对应的Bean属性名，改成一致再打包。这类问题最大的迷惑性在于它不是网络断了，而是字段名契约不一致。

第三个是播放黑屏但有声音。现象：点播放后音频正常，画面全黑，进度条在走。原因：播放器走了硬解但当前片源的编码格式机型不支持。解决：进播放器设置页切换成软解；或者参考前面4.3的代码，把mediacodec改成0强制软解。如果切换后正常，就说明是解码方式问题，可以在APP里加一个“播放不流畅？切换解码”的入口给用户自己切换。

还有一个问题是覆盖安装后域名配置没更新。现象：用户从旧版本覆盖升级，APP还在请求旧域名，很长时间后才切换。这是因为动态域名插件的本地缓存没清。解决：版本升级时把versionCode作为缓存key的一部分，或者升级后强制清一次域名缓存。这个逻辑要放在APP启动的初始化里，不用弹窗，静默完成就行。

6. 让这套源码更稳：动态域名失效时的兜底机制与验证方法

6.1 用接口自检页验证动态域名切换到底有没有生效

动态域名插件有没有起作用，不能靠“看起来正常”判断，要有一个能主动验证的入口。我习惯在“设置-关于”页面里加一个隐藏入口，连续点击版本号五次，打开接口自检页。页面里列出几项：当前使用的域名、备用域名列表、上次刷新时间、CMS接口返回码、最近一次播放地址探测结果。这样在线上出问题时，让用户打开自检页截个图，问题定位效率会高很多。

自检页的核心是一个异步探测任务，代码逻辑大致是：

new Thread(() -> { for (String domain : DomainManager.getInstance().getAllDomains()) { boolean alive = probeDomain(domain); Log.d("DomainCheck", domain + " -> " + alive); } }).start();

probeDomain用GET请求拉一次CMS列表接口，返回200且JSON里的code为1就算存活。这个探测结果直接决定当前域名是否需要切换。每次发版前，我会把主域名故意改成错误地址，装包后确认APP能自动切到备用域名，再改回正确地址重新打包。