简介：这是一份基于安卓的网络视频播放器完整源码项目，定位为毕业设计参考与安卓进阶练习，覆盖网络视频解析、播放控制、进度同步、全屏切换等典型功能。项目源码以Java实现为主，涉及网络通信、异步任务和界面布局，适合已有Java基础、希望系统掌握多媒体开发的学习者。资源以zip压缩包提供，共1255个文件，约37.29MB。其中294个Java源文件对应核心业务与播放逻辑，36个XML文件负责界面布局，337张PNG图片支撑视觉资源，另有class编译文件、so库及可直接安装的APK，便于运行与二次开发。目前已有258人学习下载。学习者可通过源码梳理网络视频播放器的完整工程结构，积累播放器状态机管理、网络请求封装、多线程更新界面及自定义控件的代码写法；同时项目内包含编译产物与运行配置，节省环境搭建成本，对完成毕业设计或独立开发播放器应用具有直接参考价值。
1. 基于安卓android的网络视频播放器源码：不只是毕业设计，更是一套播放链路的地基
如果你是带着“安卓网络视频播放器”这个需求搜到这里，大概率是做毕业设计或者想快速搭一个能跑的视频播放应用。这套源码我拆过不止一遍，它最大的价值不在于把播放器功能做出来了，而在于把“网络视频”这条链路完整地串起来了：协议选择、解码器适配、缓冲策略、Surface 与 UI 的协作，每一步都有真实代码对应。你拿到的不是一段贴上去能跑的 VideoView，而是一个可以对着改、对着查、对着答辩讲清楚的工程。适合两类人：急着交毕业设计、需要稳定可演示代码的人；以及想搞清楚播放器内部工作逻辑、但不想从零看官方文档的开发者。下面我把它拆开讲。
2. 播放器内核选型：ExoPlayer 与 MediaPlayer 的取舍和初始化细节
2.1 先看工程里到底用了哪套播放体系
解压这个 zip 后，你会在app/build.gradle里看到依赖声明，这套源码使用的是 ExoPlayer 体系。这里有个背景要说明：Android 原生自带 MediaPlayer，它在简单场景下能用，但对网络流的控制力非常弱——没有内置的缓冲策略回调、不好接管音频焦点、对不同封装格式的容错能力也差。ExoPlayer 是 Google 官方出品的播放器框架，本质是一个可定制化的播放内核，它把数据源、解析器、渲染器、音视频同步拆成了独立的模块，想要将协议换成 RTMP 或 SRT，只需要改 DataSource 这一层。
所以如果你正在做毕业设计，优先注意这个选择：源码用的是 ExoPlayer，你答辩时被问“为什么不用 MediaPlayer”，标准回答是——MediaPlayer 是黑匣子，底层封装在系统进程里，App 拿不到缓冲进度、拿不到加载失败的细分原因，而 ExoPlayer 的每个模块都在你自己的进程里，可以打日志、做监控、替换策略，这对于“网络”播放器来说是决定性的。
2.2 ExoPlayer 初始化代码与参数解读
工程里初始化播放器的核心代码在PlayerManager.java，我把它简化成可以照着复现的样子：
// PlayerManager.java 核心初始化片段 private void initializePlayer() { // 1. 构建默认的数据源工厂，注意缓存参数的传入 DefaultHttpDataSource.Factory httpDataSourceFactory = new DefaultHttpDataSource.Factory() .setConnectTimeoutMs(10000) // 连接超时，10秒是Android网络播放的常用阈值 .setReadTimeoutMs(8000) // 读超时，低于连接超时，避免长时间挂在无响应流上 .setUserAgent("Mozilla/5.0 (Linux; Android 10)"); // 部分视频源会校验UA，这里直接设成桌面UA能绕过大部分拦截 // 2. 构建带缓存的数据源，缓存工厂包在外层，这是网络播放的关键 CacheDataSource.Factory cacheDataSourceFactory = new CacheDataSource.Factory() .setCache(new SimpleCache(cacheDir, new LeastRecentlyUsedCacheEvictor(1024 * 1024 * 200))) // 200MB LRU缓存 .setUpstreamFactory(httpDataSourceFactory) .setFlags(CacheDataSource.FLAG_IGNORE_CACHE_ON_ERROR); // 缓存读取出错时直接走网络，避免卡死 // 3. 组合媒体源工厂，这里决定你支持哪些协议 ProgressiveMediaSource.Factory progressiveFactory = new ProgressiveMediaSource.Factory(cacheDataSourceFactory); HlsMediaSource.Factory hlsFactory = new HlsMediaSource.Factory(cacheDataSourceFactory); MediaSource mediaSource = isHls(url) ? hlsFactory.createMediaSource(MediaItem.fromUri(url)) : progressiveFactory.createMediaSource(MediaItem.fromUri(url)); // 4. 构建播放器实例，开启释放旧实例的标志 ExoPlayer exoPlayer = new ExoPlayer.Builder(context) .setMediaSourceFactory(new DefaultMediaSourceFactory(context) .setDataSourceFactory(cacheDataSourceFactory)) .build(); exoPlayer.setMediaSource(mediaSource); exoPlayer.prepare(); exoPlayer.setPlayWhenReady(true); }这段代码里有几个参数需要注意。
setConnectTimeoutMs(10000)设置为 10 秒是多数在线视频 App 的折中值：Wi-Fi 环境下 5 秒足够，但 4G/5G 弱网下低于 8 秒会频繁触发失败；超过 15 秒会让用户觉得“卡死了没反应”。setReadTimeoutMs(8000)比连接超时短是有意的——连接建立后如果 8 秒内没有新数据，说明远端挂了或者网络被切断，这时候快速放弃、进入重试流程更重要，而不是继续白等。
LeastRecentlyUsedCacheEvictor(200MB)是缓存淘汰策略。LRU 在这里的意义是：视频文件的访问是顺序的，前面的分片看过之后不太可能回看，但用户拖动进度条时可能跳回开头。LRU 会在缓存达到 200MB 时把最久没访问的数据淘汰掉，这比 FIFO 策略在“回看老片段”时的命中率高很多。
2.3 MediaItem 构建与 MIME 类型自动识别
另一个容易忽略但重要的点藏在MediaItem对象里，源码中有这样的逻辑：
MediaItem.Builder builder = new MediaItem.Builder() .setUri(videoUrl) .setMediaId("video_" + currentIndex); // MediaId 用于后续统计或恢复播放位置 // 部分源码会对 url 后缀做判断，这里注意：不能只看后缀 if (url.contains(".mpd")) { builder.setMimeType(MimeTypes.APPLICATION_MPD); // DASH 流 } else if (url.contains(".m3u8")) { builder.setMimeType(MimeTypes.APPLICATION_M3U8); // HLS 流 } // 其余情况不主动 setMimeType，让 ExoPlayer 自己探测这里专门说明一下：.m3u8这种识别方式是大部分 Demo 的做法，但你不要把它当作可靠依赖。很多视频源会把.m3u8隐藏在重定向接口后面，真实返回的 URL 后面没有任何扩展名，但响应体是#EXTM3U开头。遇到这种情况，显式设置MimeTypes.APPLICATION_M3U8是可以的，但如果 URL 本身就是重定向地址，ExoPlayer 需要靠服务端响应头Content-Type来区分，所以你的接口层要保证返回正确的Content-Type: application/vnd.apple.mpegurl，否则即使代码里做了后缀判断也会失效。把 MIME 类型显式写死在代码里，是一个要小心的习惯。
2.4 切换清晰度时的处置
源码里还有一个值得说的逻辑：多清晰度适配。因为这套源码支持 HLS，而 HLS 本身就有 Master Playlist 做码率自适应，但如果你使用 MP4 点播源，就需要自己实现“切换清晰度”。源码中有一段在切换时释放旧实例的代码：
public void switchResolution(String newVideoUrl) { long position = player.getCurrentPosition(); // 记住当前播放位置 boolean wasPlaying = player.isPlaying(); player.release(); // 释放旧实例，注意这里选择的是release而不是stop initializePlayer(); player.seekTo(position); // 关键：seekTo要在prepare之后调用 // 注意：seekTo的时机 if (wasPlaying) { player.play(); } }这段代码的逻辑顺序有讲究：先getCurrentPosition()记录位置，再做release()，然后重新初始化，最后seekTo(position)。我第一次改这段代码时把seekTo放在了prepare()前，结果进度回到了 0——因为prepare()会重置媒体源的播放状态。正确顺序一定要是：新播放器 prepare 完成之后，再执行 seek，这样效果才是无缝的。另外，如果你需要连位置都记录到本地数据库，应该在外面包一层SharedPreferences存储，这样即使播放器进程被杀，下次进入也能恢复上次观看位置。
3. 网络层解剖：缓存策略、UA 伪装与重试机制
3.1 视频源是“网络”的核心，先分清楚点播与直播的差异
网络视频播放器这个标题里的“网络”二字，意味着不能只处理本地文件，更不能只处理一种流格式。这套源码把常见的网络视频场景都覆盖了：HTTP 点播（MP4）、HLS 直播流（.m3u8）、以及部分 RTMP 流。这里不展开 RTMP 细节，因为源码的主链路是 HTTP 与 HLS。
点播和直播在网络层面的处理逻辑完全不同。点播可以大胆地用缓存做加速，因为数据总在那里，你只是提前把它放到本地磁盘；而直播是实时生成的，缓存旧分片没有意义，所以你一定要在直播流的处理分支里关掉磁盘缓存，否则会出现画面一直落后于真实时间的情况。源码里通过isLive(url)来区分这两种场景，这是比较合理的做法。
private boolean shouldCache(String url) { if (url.contains(".m3u8")) return false; // 大部分HLS直播流不分片缓存 if (url.contains("live")) return false; // 常见直播CDN路径关键词 return true; }3.2 缓冲策略：从“等卡死”到“先播再说”
网络播放器最影响用户感知的，不是解码速度，而是缓冲策略。这套源码对此专门做了处理：setBufferForPlaybackMs和setBufferForPlaybackAfterRebufferMs。前者控制首次播放前需要缓存多少数据才开始播放，后者控制“卡顿重新缓冲”的阈值。
DefaultLoadControl loadControl = new DefaultLoadControl.Builder() .setBufferDurationsMs( 3000, // 最小缓冲时长：低于这个值就继续缓冲 15000, // 最大缓冲时长：缓存达到这个值就暂停加载 2500, // 开始播放前需要缓冲的时间 5000) // 重新缓冲的时间阈值，如果缓冲低于这个值，播放器会卡住进入缓冲状态 .setPrioritizeTimeOverSizeThresholds(false) // 默认按时间判断就够用，按字节判断在码率不稳时不准确 .build(); ExoPlayer player = new ExoPlayer.Builder(context) .setLoadControl(loadControl) .build();这里有个常见的理解误区：2500ms这个播放前缓冲时间，不是“让用户干等 2.5 秒”，而是“缓冲数据量足够播放 2.5 秒时，就立刻开始播放”。它的目的不是让你等完再放，而是尽可能快地开播。对于慢速网络来说，如果前 2.5 秒的视频数据迟迟凑不齐，播放器会一直卡在准备状态——所以如果你做的是短视频应用，这里建议调到500ms，配合快速重试机制，用户基本感知不到加载。
PrioritizeTimeOverSizeThresholds(false)也值得解释。ExoPlayer 默认按字节去衡量缓冲够不够，但不同视频的码率差得很多：一部 4K 视频 5MB 只有一秒，一部音频流 5MB 能播五分钟。按字节判断会失真，按时间判断才是站在“播放连续性”角度。把它的值设为false，实质是把“以字节为主”改成“以时间为主”，这对网络视频播放器来说更合理。
3.3 重试机制与超时：不能只做一次请求
网络请求必然会失败，源码里有一个简易但实用的重试封装：
private MediaSource buildMediaSourceWithRetry(String url, int retryCount) { // 第一次请求不做额外的包装 MediaSource mediaSource = buildMediaSourceInternal(url); if (retryCount <= 1) return mediaSource; // 在数据源工厂层加拦截器，实现“遇到异常自动重试” HttpDataSource.Factory factory = new DefaultHttpDataSource.Factory() .setConnectTimeoutMs(8000) .setReadTimeoutMs(8000); // RetryEvaluator 是简化模型，这里直接基于异常类型判断 // 网络IO异常 -> 重试；HTTP 404 -> 不重试；401 -> 不重试 RetryManager retryManager = new RetryManager(retryCount, 2000); return new MyRetryMediaSource(mediaSource, retryManager); }这套代码要清楚一个核心原则：不是所有错误都值得重试。HttpDataSource.InvalidResponseCodeException里的 404 和 401 重试一百次也不会成功；但IOException的SocketTimeoutException和ConnectException值得重试。第一次如果是 404，直接丢出错误，走 UI 层提示；第一次如果是超时，隔 2 秒重试，第二次再失败就提示用户检查网络。如果没有这个区分，你会看到播放器在地址输错时反复“转圈加载”，这在演示环境里非常尴尬。
3.4 代理与 User-Agent
另一个“网络”相关的细节是 User-Agent。我在调试这套源码时发现，部分视频源会校验 UA，非浏览器 UA 直接拒绝响应。源码里setUserAgent("Mozilla/5.0 (Linux; Android 10)")就是为此准备的。但要注意：这个 UA 并不通用，Windows 桌面 Chrome 的 UA 是Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36，部分视频源会区分手机端和 PC 端的播放权限。你在调试时如果碰到播放器黑屏、onLoadError里面带403，第一个要查的就是这个 UA 设置，第二个是Referer——少数视频源会校验 Referer，该加就得加。ExoPlayer 的setDefaultRequestProperties可以设置请求头，这是个很好用的功能。
4. 播放控制器与 UI 状态同步：从 ProgressBar 到手势模块的完整实现
4.1 播放器页面布局的三个关键载体
如果你打开这个源码的 UI 层，第一印象可能是“布局文件很朴素”，但这套结构的核心不在视觉，而在三层载体：
TextureView：承载视频画面，支持拖拽、透明度调节，是现在播放器的主流做法（SurfaceView则无法在 View 层级里做自由变换）- 顶层控制层：包含播放/暂停按钮、进度条、时间显示
- 底部状态层：显示缓冲状态、错误信息
源码里用的虽然是TextureView，但有一个隐患：它在硬件缩放时容易产生画面拉伸或比例失真，处理方式入下：
@Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { // 注意：这里必须有！不处理的话，视频画面会填满整个组件区域而不是保持宽高比 int viewWidth = MeasureSpec.getSize(widthMeasureSpec); int viewHeight = MeasureSpec.getSize(heightMeasureSpec); if (videoAspectRatio > 0) { float viewRatio = (float) viewWidth / viewHeight; if (viewRatio > videoAspectRatio) { // 实际比例比View窄 -> 以高度为准缩放宽高，左右留边 int scaledWidth = (int) (viewHeight * videoAspectRatio); widthMeasureSpec = MeasureSpec.makeMeasureSpec(scaledWidth, MeasureSpec.EXACTLY); } else { int scaledHeight = (int) (viewWidth / videoAspectRatio); heightMeasureSpec = MeasureSpec.makeMeasureSpec(scaledHeight, MeasureSpec.EXACTLY); } } setMeasuredDimension(widthMeasureSpec, heightMeasureSpec); }4.2 进度条与时间更新的正确写法
源码的更新逻辑是：通过Handler每隔 500ms 拉一次进度，配合setOnSeekBarChangeListener实现拖动。看起来简单，但很多毕业设计在“拖动进度条”这一项上翻车。关键点在于：用户拖动时，不能不断重设进度条位置，否则手指会被“拉回去”；用户拖动时还要区分“正在拖动”和“结束后跳转”。
private final SeekBar.OnSeekBarChangeListener seekBarListener = new SeekBar.OnSeekBarChangeListener() { @Override public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) { if (!fromUser) return; // 只有用户拖动时才需要响应，播放器自动更新时不走这个分支 if (!isDragging) { isDragging = true; // 拖动开始时，暂停handler的自动刷新，防止每次500ms的有规律更新打断拖动手感 handler.removeCallbacks(progressRunnable); // 拖动过程中先更新时间显示，但不要调用player的seek操作 tvCurrentTime.setText(formatTime(progress)); } } @Override public void onStartTrackingTouch(SeekBar seekBar) { isDragging = true; } @Override public void onStopTrackingTouch(SeekBar seekBar) { // 手指抬起才真正seek long targetPosition = (long) seekBar.getProgress() * duration / 1000; player.seekTo(targetPosition); handler.post(progressRunnable); // 恢复自动刷新，注意要post而不是postDelayed，否则会多等500ms isDragging = false; } };这个写法里的isDragging标志是核心，缺少这一标志的播放器 UI 会有一种“进度条在抖动”的手感。另外源码里的 Handler 用的是postDelayed(progressRunnable, 500)，你如果把onStopTrackingTouch里恢复的handler.post写成了postDelayed，那么你每次拖动结束后的第一次进度刷新会慢半拍，在答辩演示时会被看出 UI 不跟手。
4.3 手势调节亮度与音量
这套源码的 UI 层还集成了手势调节：右侧上下滑动调节音量、左侧上下滑动调节亮度，集成在GestureVideoController里。实现原理并不复杂——获取当前亮度或音量存入变量，监听手势的onScroll事件，按滑动距离换算成 0～1 的数值，然后实际设置系统亮度或流媒体音量。
要注意度的问题：视频播放器的手势调节不能用全屏亮度的百分百。有经验的开发者会在换算时加一个缩放系数，比如滑动整个屏幕才调整到 100%，滑动半屏则调整 50%。源码里默认用的比例是wholeWidth / deltaY * 0.15f，也就是滑动一个屏幕高度只调节 15%，这个手感在 6.7 英寸的手机上是合适的，但改到平板就要调整参数，否则一滑就拉满，体验非常生硬。
5. 避坑与常见问题排查：网络播放器调试记录汇编
这部分是我拆这套源码时踩过或预判到的真实问题，每一条都值得记下来。
5.1 黑屏但音频正常播放
现象是画面不显示，但能听到声音，或者画面定格在第一帧。原因是多方面的，最常见的是TextureView没有与播放器正确绑定。ExoPlayer默认输出到 Surface，你需要在onSurfaceTextureAvailable里把surface递给player.setVideoSurface(surface)，如果时序不对，视频就会停留在“没有 Surface 可用”的状态。
解决：确保绑定 Surface 的时机在player.prepare()之前或至少同步执行。更激进一点的做法是直接用PlayerView，把上述时序交给框架处理，但这套源码没有这么做，因为它要保留手动控制 Surface 的能力。
5.2 播放一段时间后画面卡住，进度条还在走
现象是画面停止在某一帧，但底部的播放进度数字还是每秒在跳。原因是音频解码进程没断，播放器认为“还在播放中”，但视频帧却拿不到；大多数时候是网络流中断，且缓冲策略判断“可以继续用音频数据保持播放”。
解决：检查DefaultLoadControl的缓冲参数，把setBufferDurationsMs的“重新缓冲阈值”调大，比如从5000提到10000，让播放器提前进入缓冲状态。另外排查PlaybackException的errorCode，如果落在ERROR_CODE_IO_NETWORK_CONNECTION_FAILED上，需要做重连而不是 seek 到当前位置。
5.3 视频源返回 403，播放器直接失败
现象是加载日志里出现了InvalidResponseCodeException: 403。原因前面提过：UA 校验或 Referer 校验。这个坑非常常见，因为很多 OSS 存储服务会做来源限制。
解决：在DefaultHttpDataSource.Factory上设置setDefaultRequestProperties，加上Referer头。注意这里的 Referer 不是视频站的页地址，而是该视频源指定的允许来源，你必须抓包确认，不能想当然抄。
5.4 HLS 直播流越播越卡，延迟越来越大
现象是直播画面相对于实际时间延迟从几秒涨到十几秒。原因是直播流的 CDN 分片缓存策略不一样，播放器默认的HlsMediaSource会按顺序播放，但延迟越大，缓冲的分片越多，后续补齐的时间越长，形成一个正反馈循环。
解决：对直播流单独设置setLiveTargetOffsetMs(5000)，也就是让播放器额外保持 5 秒的目标延迟偏移，并回调addPlaylistEventListener在每次 playlist 刷新时，检查当前延迟，超限就主动 seek 到最新位置。
5.5 播放器在切换视频后偶发崩溃，日志指向 MediaCodec
现象是切换第二个视频时，Native 层的MediaCodec崩溃。原因大概率是上一个播放器实例没有完全释放，或者TextureView的 Surface 还在被旧播放器使用。release()是异步的，立即再建新实例可能碰到底层的 buffer 复用冲突。
解决：在释放时增加一个“延迟切换”策略。尤其注意比这更隐蔽的是：释放旧实例时，如果还持有 Surface，需要先调用player.clearVideoSurface()再player.release()。顺序反了，底层解码器可能不会立刻释放 Surface 资源。
5.6 手机息屏或者切后台后，播放器声音断断续续
现象是切到后台后，音频像掉帧一样卡顿。原因是系统对前台应用做了 CPU 限制，解码线程优先级被调低，处理器资源不足。
解决：在onPause中主动player.pause()而不是靠系统自动暂停；恢复时再player.play()。如果你做的是音频后台播放场景，需要使用前台服务并提高播放线程优先级，这已超出该源码范围，但知道原因和解决方向，比去代码里乱调参数高效得多。另外把播放器所在 Activity 的screenOrientation设为unspecified或在 manifest 里声明android:configChanges避免旋转时重建导致播放器重新初始化，也是经验之谈。
6. 验证与分析：用 ExoPlayer 事件日志定位卡顿的“一分钟排查法”
快速验证一套播放器源码能否达到“网络播放可用”的要求，不需要完整跑完整测试用例，也不需要抓包软件。你只需要开启 ExoPlayer 的日志，然后针对三种场景依次验证：点播启动、播放拖拽、直播追流。掌握了这条排查路线，你答辩演示时翻车的概率会小很多。
打开 debug 日志。ExoPlayer 的事件日志在 Logcat 里的 tag 是ExoPlayerImplInternal。在代码中把日志级别设为Log.DEBUG，每次播放状态变化，它都会打印出当前的playbackState与缓冲时间。你可以把下面这段工具方法放到工程里，方便在线监控：
public static final String TAG = "PlayerDebug"; player.addListener(new Player.Listener() { @Override public void onPlayerStateChanged(boolean playWhenReady, int playbackState) { // 这套回调能覆盖“加载失败”“准备完成”“缓冲中”等所有关键状态 Log.d(TAG, "playWhenReady=" + playWhenReady + " playbackState=" + stateToString(playbackState)); } @Override public void onPlaybackParametersChanged(PlaybackParameters params) { // 卡顿时会出现速率波动，这里是观察该类问题最直接的地方 Log.d(TAG, "speed=" + params.speed); } @Override public void onPlayerError(PlaybackException error) { Log.e(TAG, "errorCode=" + error.errorCode + " msg=" + error.getMessage()); } });一分钟排查法步骤：
- 你点开一个视频，盯着 Logcat 找
playbackState=READY。它出现的时间 = 首帧可播时间。如果超过 5 秒没出现，去看网络加载日志里是不是一直在LOADING，如果是，说明远端地址响应慢，这是源的问题，不是代码问题。 - 播放中拖动进度条，观察从
seekTo执行到READY再次出现的时间。如果超过 3 秒，大概率是视频源本身对 seek 响应不友好，或者你的CacheDataSource缓存策略没有覆盖到 seek 区域，需要在缓存工厂里改为FLAG_IGNORE_CACHE_ON_ERROR并用LeastRecentlyUsedCacheEvictor控制淘汰。 - 播放 RTMP 流时，如果它一直报
TIMEOUT，很多情况下是服务端推流地址失效。不要怀疑代码，先用系统播放器试试同一地址，避免在源码上浪费时间。
关于这套源码需要额外注意的一个版本边界。整套工程基于targetSdkVersion 30及以上，如果你的测试机是 Android 10 以下，网络权限声明在老版本里有差别，要在AndroidManifest.xml中确认INTERNET权限与usesCleartextTraffic="true"是否配置好。Android 9 开始默认禁止明文 HTTP 流量，很多网络视频源没有 HTTPS，所以你必须在 manifest 的application标签上打开android:usesCleartextTraffic="true"，或者写一个针对特定域名的 network security config，否则所有 HTTP 视频源都无法加载，黑屏加Cleartext HTTP traffic to xxx not permitted日志会直接把你的项目卡在起点。这几乎是我见到的“网络播放器跑不起来”的第一大原因，优先级高于所有其他设置——先确认这一条，再去查播放器初始化逻辑。
从那以后，我每次拿到一套网络播放器源码，第一件事不是跑应用，而是先打开 manifest 看usesCleartextTraffic，再开 Logcat 验证 READY 状态。这个顺序帮我省了大量查错时间。希望帮到你。
本文还有配套的精品资源，点击获取
