最近我又把一个点播模块从系统播放器换成了 ijkplayer，起因倒不是什么玄乎的性能问题，就是单纯遇到了几路不常见的封装格式，系统 MediaPlayer 和 ExoPlayer 处理起来都不省心，而 ijkplayer 直接基于 FFmpeg，格式兼容性天然占优。很多团队在选型播放器时都会纠结“到底该自己封装还是直接用开源方案”，我的结论是：ijkplayer 可以拿来就用，但前提是你得把它的编译产物、初始化参数、生命周期处理和边角坑都摸清楚，否则集成完只是“能出声”，离“稳定可靠”还差很远。
说实话，ijkplayer 的配置使用在官方仓库里写得很简略，真正跑起来卡住的点全是文档之外的东西。这篇我就把我从拿到源码到上线的完整过程捋一遍，包括怎么取编译产物、怎么加依赖、怎么理解那一堆 setOption、怎么处理生命周期和断流重连，最后附上我踩过的几个典型坑。内容偏向安卓实操，适合刚接手播放器集成、或者想从官方 Demo 升级到自研业务的开发者参考。
1. ijkplayer 的实际定位：弹幕视频社区为什么需要自研播放器
1.1 一个播放器 SDK 要承载的任务
视频播放器听起来是个“系统自带能力”，真做过的人才知道坑有多深。系统 MediaPlayer 只保证你播个 MP4、播个基础 HLS，一旦遇到 RTMP 直播流、特殊编码的 AVI、带 odd 像素格式的视频，轻则绿屏，重则直接 failed。ExoPlayer 虽然解码架构优秀，但它对 FFmpeg 封装格式的覆盖要靠扩展库，集成成本并不低。
ijkplayer 的定位就是“用 FFmpeg 做解码后端，用安卓原生渲染做输出”的播放器内核。它在安卓端把 FFmpeg 的 demuxer、decoder 通过 NDK 编译成 so 库，再对外暴露一套 Java API，也就是IjkMediaPlayer。这套 API 的命名和调用时序刻意贴近系统 MediaPlayer，所以从系统播放器迁移过来的成本很低：setDataSource、prepareAsync、start、pause、seekTo、release，基本思维模型一致。
这套架构的好处很明显：FFmpeg 支持的容器格式和编码格式，ijkplayer 几乎都能继承过来。某一路视频在系统播放器里黑屏，换成 ijkplayer 很可能就正常了。对做聚合类视频产品的团队来说，这种“格式兜底”能力非常关键。
1.2 “拿来主义”的边界在哪里
很多人以为 ijkplayer 是个“开箱即用”的 SDK，这个理解要修正。它本质是播放内核 + 一套薄封装，UI 部分比如手势拖动、亮度调节、倍速面板，官方 Demo 里有，但不算产品级组件。官方的IjkVideoView封装了 SurfaceView/TextureView、媒体控制器和外设事件，可它带了不少历史包袱，比如 Wi-Fi 下网络类型判断、自定义 media controller 样式，这些在正式项目里通常要重写。
所以我的建议是：仓库的ijkplayer-example目录只当参考，真正集成时核心依赖ijkplayer-java和对应 ABI 的 so 模块，然后自己实现播放器页面。你保留自由度的同时，又拿到了 FFmpeg 级别的解码能力。ijkplayer 项目本身更新节奏不算快，但 FFmpeg 内核决定了它不会轻易“过时”，这是它到今天仍值得用的根本原因。
2. 获取产物两条路线：预编译 so 还是源码编包
2.1 直接依赖官方 release 包的取舍
ijkplayer 官方发布里带了各个 ABI 的 so 和对应 Java 层模块，最快的方式是直接在 Gradle 里加依赖。历史版本坐标形如：
implementation 'tv.danmaku.ijk.media:ijkplayer-java:0.8.8' implementation 'tv.danmaku.ijk.media:ijkplayer-armv7a:0.8.8' implementation 'tv.danmaku.ijk.media:ijkplayer-arm64:0.8.8' implementation 'tv.danmaku.ijk.media:ijkplayer-x86:0.8.8'这套坐标是早期发布到公共仓库的，现在因为仓库服务停摆，新项目直接拉取可能失败。我的做法是先下载官方 release 压缩包，把ijkplayer-java、ijkplayer-armv7a、ijkplayer-arm64、ijkplayer-x86这几个模块的 AAR 抠出来，放到工程libs目录，再统一依赖。等你的包体积累到你开始在意 so 大小的时候，再按需裁剪。
注意，ABI 不是“全都加一遍”就完事。只保留 armv7a 和 arm64 通常够用，x86 留给你自己的模拟器调试，如果体积敏感，直接不打包 x86 也可以。不同 ABI 的 so 与 Java 层分离，这个设计意味着你要是加错 ABI 模块，运行时才会报dlopen failed，排起来很绕，后面我会专门说。
2.2 源码编译要准备的环境和流程
如果官方包满足不了业务，比如你想裁剪协议、去掉不用的 demuxer、或者集成更高版本的 FFmpeg，那就得走源码编译这条路。编译 ijkplayer 需要：
- 一台 Linux 或 macOS 主机，Windows 上编译 NDK 项目体验很差。
- 指定版本的 NDK，官方 README 里建议了对应的 NDK 版本。新版本 NDK 也能碰运气编过，但老项目在较新 NDK 下会遇到语法不兼容问题，所以没特殊理由别用最新 NDK。
- 编译脚本依赖 GNU Make、curl、git 这类基础工具。
整体流程分成三步：拉源码、拉 FFmpeg、编 FFmpeg 和 ijkplayer。精简版大致是：
git clone https://github.com/.../ijkplayer.git ijkplayer cd ijkplayer ./init-android.sh ./compile-ffmpeg.sh clean ./compile-ffmpeg.sh all ./compile-ijk.sh allinit-android.sh会拉取对应版本的 FFmpeg 源码并打补丁，所以要先保证网络通畅，以及 GitHub 访问没问题。编译脚本支持armv7a、arm64、x86、x86_64这些目标，全量编下来时间不短，建议先跑单个架构验证。
2.3 编译裁剪：module-lite 与自定义 module
ijkplayer 的模块化很有意思：源码仓库里预置了module.sh、module-lite.sh、module-default.sh等配置脚本。这些脚本控制着 FFmpeg 编译时到底开启哪些协议、哪些解码器、哪些封装格式。
默认module.sh开启的内容多，出来的 so 也大。只做点播业务的话，用module-lite.sh通常就够，它保留了常用协议和 H.264/H.265、AAC/MP3 等主流编解码。如果你需要rtmp协议，可以在module-lite.sh基础上追加：
export COMMON_FF_CFG_FLAGS="$COMMON_FF_CFG_FLAGS --enable-protocol=rtmp"把这个追加写在module.sh里的指定位置，或者建一个自己的模块脚本再source进去。裁剪的收益很直观，我见过一个只保留 H.264/HTTP/HLS 的包，so 体积能比默认全量小 30% 以上，对于渠道分包严格的 App，这很值。
3. 跑通第一个播放画面：Gradle 配置与基础调用
3.1 模块依赖怎么加才不冗余
假设你手头已经有一份 AAR 或者直接引用了源码模块，最精简的依赖应该是ijkplayer-java加一个当前设备 ABI 对应的 so 模块。千万别把armv7a、arm64、x86同时打进正式包，那不是功能完整，那是包体浪费。
如果你在 Android Studio 里以源码模块方式集成，工程结构看起来会是这样：
dependencies { implementation project(':ijkplayer-java') implementation project(':ijkplayer-armv7a') // debug 时再引用 x86 模块 debugImplementation project(':ijkplayer-x86') }这里debugImplementation是仁慈的：调试期模拟器有 x86 可用，发布包自动排除。这种 ABI 分离设计还有一个隐藏好处，你可以针对不同渠道配置不同的 so 模块，比如低端机渠道只发 armv7a，包体更小。
3.2 从创建播放器到显示第一帧的完整代码
IJKMediaPlayer 的基础用法和 MediaPlayer 很像，但有几处必须设置。先看一段最基础的接入：
public class PlayerActivity extends AppCompatActivity implements SurfaceHolder.Callback { private IjkMediaPlayer mediaPlayer; private SurfaceView surfaceView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_player); surfaceView = findViewById(R.id.surface_view); surfaceView.getHolder().addCallback(this); IjkMediaPlayer.loadLibrariesOnce(null); IjkMediaPlayer.nativeProfileBegin(); mediaPlayer = new IjkMediaPlayer(); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_FORMAT, "safe", 0); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_FORMAT, "protocol_whitelist", "rtmp,rtsp,tcp,udp,http,https,file,crypto"); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_FORMAT, "rtsp_transport", "tcp"); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec", 1); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_PLAYER, "start-on-prepared", 1); } @Override public void surfaceCreated(SurfaceHolder holder) { if (mediaPlayer != null) { mediaPlayer.setDisplay(holder); mediaPlayer.setDataSource("https://example.com/demo.m3u8"); mediaPlayer.prepareAsync(); } } // surfaceChanged / surfaceDestroyed 略 }注意setDisplay要在prepareAsync之前调用，否则可能出现“音频在播、画面黑屏”的状态。loadLibrariesOnce(null)会在首次创建播放器前把 so 加载好，一般来说放在 Application 里做一次即可。
protocol_whitelist是我非常推荐设置的一项。默认白名单覆盖了常见协议，但手动写清单能避免某些危险协议被意外拉起，也方便排查“为什么某路流打不开”——直接看白名单就知道是不是被过滤了。rtsp_transport=tcp针对 RTSP 流，走 UDP 在弱网下丢包容易花屏，改成 TCP 延迟略高但稳定得多。
3.3 生命周期管理：onPause/onResume 不是组件自己搞定的
也是新手最容易翻车的点：播放器实例的生命周期不会跟着 Activity 自动走。你没在onPause里暂停，来电时可能外放声音；没在onDestroy里释放，下一次进页面就会E/MediaPlayer: should have subtitle controller这类诡异日志，甚至直接 ANR。
基本规范：
@Override protected void onPause() { super.onPause(); if (mediaPlayer != null && mediaPlayer.isPlaying()) { mediaPlayer.pause(); } } @Override protected void onDestroy() { super.onDestroy(); if (mediaPlayer != null) { mediaPlayer.stop(); mediaPlayer.release(); mediaPlayer = null; } }release()之后把引用置空，避免后续回调访问到空对象。如果播放器在后台还要继续出声，就得配合前台 Service 保住进程优先级，同时把音频焦点处理好，这部分我放到后面专门聊。
4. 协议、解码与渲染配置：那些 setOption 到底在干什么
4.1 软硬解切换与 MediaCodec 的取舍
mediacodec这个选项控制是否优先硬解。设 1 表示开启 MediaCodec 硬解，底层会优先把视频流转给系统硬件解码器。硬解功耗低、性能高，缺点是对某些非法编码的视频兼容性差，会直接黑屏或绿屏。软解通过 FFmpeg 自己的解码器，CPU 占用高，但兼容面更广。实际工程里我常用两套组合：
// 硬解优先 mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec", 1); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec-auto-rotate", 1); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec-handle-resolution-change", 1);// 软解兜底 mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec", 0); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_PLAYER, "framedrop", 1);framedrop用于视频解码跟不上时自动丢帧，避免音频正常但画面越来越卡。直播场景建议开启，点播追求画质的话可以关掉。opensles决定音频输出是否走 OpenSL ES，设为 0 有时能规避部分设备的爆音问题，没有统一答案，遇到再说。
4.2 为 RTMP/HLS 定制协议参数
ijkplayer 的协议能力来自 FFmpeg，所以 FFmpeg 支持的协议级参数大部分都能通过setOption覆盖。做直播拉流时，我一般先处理连接超时：
mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_FORMAT, "rw_timeout", "10000000"); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_FORMAT, "timeout", "10000000");rw_timeout单位是微秒，10000000就是 10 秒。超过这个时间读不到数据，播放器会抛超时错误。弱网环境下这个值不能设太短，否则稍微卡顿一下就被当成断流，也不能太长，否则用户等半天没反馈。
HLS 点播还有一个常见诉求是“快速起播”。FFmpeg 默认会 probe 一段数据来探测格式，可能导致首屏延迟偏高，可以尝试收紧探测范围：
mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_FORMAT, "analyzeduration", "5000000"); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_FORMAT, "probesize", "1024000");这两项不是越小越好，调太小会导致格式识别失败。建议在你的测试机上对比几个值，找到一个“首屏可接受 + 格式识别稳定”的区间。这种参数就是典型的“文档不会替你做决定”的配置。
4.3 SurfaceView 与 TextureView 的选择依据
ijkplayer 渲染视频画面依赖 Surface，你可以把它绑定到SurfaceView，也可以绑定到TextureView。它们各有代价：
| 对比项 | SurfaceView | TextureView |
|---|---|---|
| 性能 | 高，系统层合成 | 低一点，需要额外纹理上传 |
| 动画支持 | 差，旋转缩放可能黑边 | 好，可随意加动画 |
| 截图能力 | 需要额外实现 | 可直接 getBitmap |
| 与播放器生命周期耦合 | 需要自己处理 Surface 重建 | 相对省心 |
直播和普通点播我首选SurfaceView，性能更稳。如果播放器页面外面套了个复杂的转场动画，或者产品要求播放区域做圆角、模糊、缩放这些效果，就换TextureView。注意TextureView必须在它 available 之后才能setSurface，顺序错了画面不会出来，只会有声音。
5. 播放器这层皮：监听、缓冲状态与常见误用
5.1 状态机与客户端事件回调
ijkplayer 的事件回调分成两类：一类是 Java 层的OnPreparedListener、OnCompletionListener、OnErrorListener、OnInfoListener，另一类是 native 层通过setOnNativeInvokeListener暴露的 invoke 请求。初学阶段把前者用好就够。
OnInfoListener里最常处理的是缓冲事件：
mediaPlayer.setOnInfoListener((mp, what, extra) -> { switch (what) { case IjkMediaPlayer.MEDIA_INFO_BUFFERING_START: showLoading(); break; case IjkMediaPlayer.MEDIA_INFO_BUFFERING_END: hideLoading(); break; case IjkMediaPlayer.MEDIA_INFO_VIDEO_RENDERING_START: hideCover(); break; } return true; });这里的MEDIA_INFO_BUFFERING_START/END是相对可信的缓冲状态信号，但不绝对。有时已经开始缓冲了，回调还没到；有时网络抖动了一下，缓冲结束又立刻开始，loading 动画就会闪。所以我额外加了一层：进入缓冲时记录时间点，如果 1 秒内又收到结束回调，就不播 loading。这属于体验层的经验处理，不是播放器本身能解决的。
5.2 播放进度与 seek 的处理方式
seekTo的精度是很多点播业务关心的。ijkplayer 对 MP4 这类有索引的格式 seek 通常很准，对 HLS 则会受切片时长影响，seek 后落在关键帧附近会有小幅偏差。这是封装格式本身的限制，不用强求毫秒级精确。
业务侧要做的是“先暂停、再 seek、再恢复”的模式，否则边播边 seek 可能引起画面跳变。代码上的规范是：
boolean isSeeking = false; mediaPlayer.setOnSeekCompleteListener(mp -> { isSeeking = false; mediaPlayer.start(); }); public void seekToPosition(long positionMs) { isSeeking = true; mediaPlayer.pause(); mediaPlayer.seekTo(positionMs); }进度条拖动时不要把每次onProgressChanged都直接发一个seekTo，那样播放器会收到一串请求，底层状态很容易错乱。正确做法是拖拽结束的onStopTrackingTouch再 seek，拖动过程中只更新 UI 时间显示。
5.3 网络异常、断流重连的实战处理
播放器onError会给出错误码，ijkplayer 常见的有10000（通用错误）、-10001（打开失败）、-10003（无效参数）。真正连不上的场景，我建议先区分：
- 播放器内部错误：表现为 prepare 失败或打开流失败，需要重试或提示。
- 播放中网络中断：表现为
MEDIA_INFO_BUFFERING_START长时间不结束，最终触达超时错误。
直播断流重连是业务里比较头疼的部分。我这里提供一个相对稳的流程：进入onError后先释放旧播放器实例，创建新IjkMediaPlayer，重新setDataSource，中间增加退避逻辑——第一次等 1 秒重试，第二次等 2 秒，最多等 5 秒，避免服务端还没恢复时客户端进入疯狂重试循环。
int retryCount = 0; private void reconnect() { releasePlayer(); long delay = Math.min(5000, 1000L * (retryCount + 1)); retryCount++; handler.postDelayed(this::initPlayer, delay); }手机上频繁切换 Wi-Fi 和移动网络时，建议在ConnectivityManager回调里检测NET_CAPABILITY_INTERNET的重新建立，再触发重连，而不是只靠播放器错误兜底。
6. 管理域细节：音频焦点、外接设备与后台续播
6.1 插拔耳机为什么会导致“没声音也没暂停”
很多开发者只写了播放器，没接耳机事件，于是出现一个典型现象：带着耳机听音频，拔出耳机后声音突然从外放炸出来，或者画面在播但声音没了。这不是 ijkplayer 的锅，是系统音频路由变化后，播放器没有主动响应。
解决方式是在播放器页面注册ACTION_AUDIO_BECOMING_NOISY广播：
private final BroadcastReceiver noisyReceiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { if (mediaPlayer != null && mediaPlayer.isPlaying()) { mediaPlayer.pause(); } } }; // 注册 registerReceiver(noisyReceiver, new IntentFilter(AudioManager.ACTION_AUDIO_BECOMING_NOISY)); // onDestroy 反注册这个广播只在音频线路从耳机切到外放时发出，是系统专门用来提醒“该暂停了”的机制。视频播放器如果不处理，轻则外放尴尬，重则被判为骚扰用户。
6.2 音频焦点申请与音视频同步的关系
音频焦点是安卓音频管理的核心规则。你的播放器在后台或与其他 App 同时播放时，必须申请AudioManager.AUDIOFOCUS_GAIN。不申请焦点，可能是“能出声但会被系统突然压低音量”，也可能在有电话时没被正常暂停，用户体验很分裂。
标准做法：
AudioManager audioManager = (AudioManager) getSystemService(Context.AUDIO_SERVICE); AudioFocusRequest focusRequest = new AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN) .setAudioAttributes(new AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) .setContentType(AudioAttributes.CONTENT_TYPE_MOVIE) .build()) .setOnAudioFocusChangeListener(this::onAudioFocusChange) .build(); audioManager.requestAudioFocus(focusRequest);焦点变化回调里，AUDIOFOCUS_LOSS表示你永久失去焦点，必须暂停播放；AUDIOFOCUS_LOSS_TRANSIENT表示临时失去，比如来电、导航，也要暂停，但恢复时可以考虑续播；AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK表示压低音量而不是暂停，适合纯音频但不太适合视频，视频场景我通常也直接暂停。
6.3 后台播放时的锁屏与通知栏方案
如果产品需求是“退出页面继续播放”，播放器实例就不能住在 Activity 里，否则 Activity 一销毁播放器就没了。常规做法是抽一个前台 Service 持有播放器实例，Activity 只负责 UI 和控制指令。Service 和 Activity 通过 Binder 通信，播放器的事件回调通过本地广播或者一个弱引用的 Listener 抛回 UI。
这个模式跑通后，锁屏播放还需要设置媒体锁屏信息，否则用户锁屏后虽然还能出声，但无法通过锁屏快捷控制暂停或切歌。现在系统推荐用MediaSessionService，但这个方案和 ijkplayer 的 Java API 之间没有现成的桥接层，你得自己把seekTo、pause、play映射到PlaybackState和MediaMetadata上。工作量不算小，我的建议是：产品没明确要求锁屏控制，就只做前台 Service + 通知栏媒体按钮，不要一上来就搭全套媒体会话，收益不高还容易引入新坑。
7. 踩坑清单和源码级排障思路
7.1 一个崩溃日志的排查顺序
集成 ijkplayer 后最常见的崩溃是UnsatisfiedLinkError或dlopen failed。遇到这类崩溃，第一步不是看 Java 代码，而是确认 so 到底有没有进包。
用 Android Studio 的 APK Analyzer 打开 APK，进lib/目录逐个看 ABI 文件夹，确认释放包里的ijkplayer.so、ffmpeg.so存在且架构匹配。如果只加了ijkplayer-armv7a，真机上没问题，但测试机如果是 64 位 ARM 处理器，系统可能选择加载 64 位 so 目录，找不到就崩。解决方案通常是 ABI 目录里放了什么，Java 层就只加载什么，或者干脆把 armv7a 和 arm64 都留上。
第二步是看 Logcat。ijkplayer 的 native 层日志 tag 通常是ffmpeg和IJKMediaPlayer，启动阶段会打印FFmpeg version、Configuration这些信息。如果这些日志根本没出现，说明 so 没加载成功；如果出现了，但紧接着报Protocol not found，那就是编译裁剪时把对应协议裁掉了，回到模块脚本里把协议加回去再编。
第三步是区分 Java 层错误和 native 层错误。Java 层onError会返回错误码，native 层会直接打印AVERROR相关的调试信息。业务上你只需要把错误码映射成用户提示：超时提示“网络不给力”，协议不支持提示“暂不支持该格式”，鉴权失败提示“链接已失效”。
7.2 自定义协议头与鉴权请求的常见误区
有些视频地址需要带上Referer或User-Agent才能访问，ijkplayer 通过 FFmpeg 协议层支持自定义 headers。常见的写法是：
mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_FORMAT, "user_agent", "MyPlayer/1.0"); mediaPlayer.setOption(IJKMediaPlayer.OPT_CATEGORY_FORMAT, "headers", "Referer: https://example.com/\r\n");这里有个细节：headers的值要符合 HTTP 头格式，每个字段之间用回车换行分隔。还有，如果服务端走的是临时鉴权 URL，比如带token参数且几分钟就过期，你必须在播放前把完整 URL 一次性设置进去，不能在播放中再改。原因不难理解，播放器已经进入内部状态机，临时换地址很可能导致流程错乱。
我试过在prepareAsync之后通过setDataSource换一个带新 token 的地址，结果表现是能播但会偶发黑屏，后来改成播放前拼接 URL + headers 同时下发，问题就消失了。所以遇到鉴权流的播放问题，优先检查是不是“鉴权参数更新时序”出了岔子。
7.3 我现在的接入规范
踩过几轮坑后，我把自己负责的播放器模块接入规范固定成下面几条：
- 播放器实例绑定页面或绑定 Service，不搞全局单例播放器，避免页面销毁后内存泄漏；
- 所有
setOption集中在创建播放器后的同一个方法里，方便排查某一路流行为异常时快速对比参数差异； - 网络拉流统一设置
rw_timeout，不让用户无限等待； - Surface 绑定顺序固定为“先绑定、再 prepare”，不做“先 prepare、再绑定”的冒险操作；
- 生命周期回调里只调用播放器的状态方法，不做耗时操作，
release()永远放在非主线程或者尽快执行，避免阻塞 UI； - 错误重试统一走后端配置的重试次数和退避策略，不写死；
- 每次升级 FFmpeg 或模块裁剪，都保留一套“全量参数”的对比环境，遇到兼容性问题时先确认是不是裁剪导致。
这套规范写下来并不复杂，但它让播放器从“能工作”变成了“可以稳定维护”。ijkplayer 配置使用的技术点其实就那么多，真正区分好与坏的，是你能不能在自己项目里把参数、生命周期和异常处理串成一条可预测的流程。后面再遇到新的播放格式兼容问题，我大概率还是会先拿起 ijkplayer 来试一把，它的 FFmpeg 底子摆在那里，处理特殊封装的路子确实顺手。
