大家好，之前开源了一个自己做的 macOS 视频客户端 OKVideoMac。
第一版出来的时候，其实基本功能已经能用了：
- TVBox / CatVod 一类配置
- CatPawOpen / MiraPlay 一类 Node 源
- 直播
- 搜索
- 详情
- 收藏 / 历史
- libmpv 播放
但自己连续当主力软件用了一个月以后，越来越觉得：
“能跑”和“真正好用”之间，还有很长一段距离。
所以过去这一个月，我基本没有继续堆新功能，而是把大量时间花在重新整理 UI 、交互、播放链路、源兼容和底层生命周期上。
现在正式发布 OKVideoMac 0.4.0 （ Build 94 ）。
先简单介绍一下项目
OKVideoMac 是一个用 Swift / SwiftUI 开发的原生 macOS 视频与直播客户端。
播放器使用 libmpv。
它不是 Android App 移植，也不是把 TVBox 界面直接搬到 Mac 上。
我的目标一直是：
保留 TVBox / CatVod / CatPawOpen 这类生态比较开放的“壳与源分离”能力，但把客户端真正按照 macOS 软件重新做一遍。
目前支持的主要路径包括：
- Native CMS JSON
- 部分 CMS XML
- QuickJS Spider
- CatVod / FongMi 风格 JS
- CatPaw 风格 Node
.js.md5
- 部分 Java / Dex
csp_ Spider
- M3U / TXT / JSON 直播
- XMLTV EPG
其中绝大部分路径都不需要 Android 。
只有部分传统 Java / Dex csp_ Spider ，会通过可选的 Android Bridge 兼容。
并不是声称“所有 TVBox 源全部兼容”，实际兼容性还是取决于源格式、运行时、接口实现和具体 Spider 。
0.4.0 我主要重新做了什么？
1. UI 基本重新设计了一遍
这是这一版最直观的变化。
首页、分类、搜索、详情、收藏、历史、设置等页面都重新统一了一遍。
包括：
- Sidebar
- Toolbar / Titlebar
- 筛选器
- 选中状态
- 弹窗
- 滚动区域
- 字体层级
- 间距
- 深色模式
- 窗口尺寸变化
都尽量回归 macOS 自己的交互方式。
第一版多少还有一点“把电视端软件搬到电脑上”的感觉。
这一版我越来越明确一个原则：
既然它运行在 Mac 上，那它首先应该是一个 Mac App ，其次才是一个影视客户端。
所以现在很多地方都改成了 SwiftUI / AppKit 更自然的交互，而不是照着 Android TV 的思路做。
2. 播放器还是 libmpv ，但底层改了很多
播放器核心没有换，依然是 libmpv 。
但这一轮真正花时间的，其实不是“能不能播放”，而是大量播放器生命周期问题。
比如：
- 首帧什么时候真正 ready
- 播放器打开 / 退出的资源释放
- 连续切集
- 快速拖动进度条
- 播放到结尾
- 用户主动快进到结尾
- 自动下一集
- 直播连续换台
- 播放失败后的清理
- 窗口关闭后的 teardown
- mpv 与 Swift 状态同步
这些东西单独看都不算什么大功能，但叠起来以后，非常影响一个播放器到底“顺不顺手”。
我这一轮最大的感受也是：
做出一个能播放视频的 Demo 不难，难的是把播放器真正打磨到你每天愿意用。
3. TVBox 和 CatPawOpen 两条兼容链路重新梳理
这个项目现在其实有两套比较不同的源运行逻辑。
一类是传统的：
TVBox / CatVod / FongMi
包括 CMS 、QuickJS 、Java / Dex csp_ Spider 等。
另一类是：
CatPawOpen / MiraPlay 风格的 Node 视频接口
这一轮我花了很多时间去研究这两类项目原本的行为，然后尽量避免在 Mac 端“拍脑袋兼容”。
比如：
- 首页到底什么时候重新请求
- 分类切换是否应该缓存
- detail 请求如何调度
- Node runtime 是否重复初始化
- Spider 生命周期
- 搜索并发
- 超时隔离
- 播放地址解析
- 网盘类源的处理
- Action / Dialog 回调
- Java Spider 与原生运行时之间如何隔离
现在整体架构比第一版清楚很多。
4. Android 现在只是兼容层，不是软件运行基础
这个也解释一下。
有些传统 TVBox Java Spider 本质上就是 Android / Dex 生态，如果完全不提供 Android 兼容层，就没办法做到比较完整的兼容。
所以项目里有一个可选的 Android Bridge 。
但现在它的定位非常明确：
Native 优先，Android fallback 。
也就是说：
普通 CMS 、QuickJS 、Node .js.md5、直播、XMLTV 、正常播放都不需要 Android 。
只有确实遇到 Java / Dex csp_ Spider 时才会启动这个兼容环境。
这一点我后面还会继续优化。
长期方向肯定是：
能原生处理的全部原生处理，Android 只留给无法替代的兼容场景。
5. 这次反而砍掉了一些“想做的功能”
比如 TMDB 详情增强，我原本准备放进 0.4.0 。
后来做着做着决定先停下来。
一方面是国内网络环境下 TMDB API 的可用性问题，另一方面我觉得这一版继续加功能，意义已经不大了。
所以最后选择：
先把现有东西做好，再增加下一层能力。
TMDB 、详情信息增强之类的东西，准备留到后面的版本。
项目不提供什么
这个还是需要明确说明一下。
OKVideoMac 本身：
不内置任何第三方影视源、账号、Cookie 、解析服务或者 DRM Key 。
项目提供的是客户端、Provider 运行能力和播放器。
请只使用自己有权访问的配置和内容。
目前版本
OKVideoMac 0.4.0 （ Build 94 ）
系统要求：
- Apple Silicon Mac
- macOS 12.0+
- arm64
正式 DMG 已完成：
- Developer ID 签名
- Apple Notarization
- Staple
Release 里除了 DMG ，也提供了对应源码、第三方源码和许可证归档、SBOM 、Notices 、Manifest 、SHA256SUMS 等发布材料。
GitHub：
https://github.com/yaolin-dev/OKVideoMac
0.4.0 Release：
https://github.com/yaolin-dev/OKVideoMac/releases/tag/v0.4.0
项目采用 GPL-3.0 开源。
最后
这个项目最开始其实就是因为一直没找到一个自己真正喜欢的 macOS 客户端，所以决定自己写。
做第一版的时候觉得：
“功能跑通应该就差不多了。”
真正连续用了一个月以后才发现，大量工作其实发生在功能跑通之后。
状态管理、播放器生命周期、缓存、并发、异常路径、源兼容、窗口行为、UI 一致性……
这些东西很难截图展示，但可能才是一个软件从 Demo 变成日常工具真正需要花时间的地方。
0.4.0 对我来说更像是 OKVideoMac 第一个真正成型的版本。
项目还比较年轻，肯定还有不少问题。
如果有 Apple Silicon Mac ，欢迎试一下。
尤其如果你也在做 SwiftUI 、libmpv 、播放器、TVBox / CatVod / CatPaw 相关的东西，也很欢迎交流实现思路。
Bug 或兼容性问题可以直接提 Issue 。
另外也很好奇 V2EX 上有没有人在做类似的：
“把原本偏 Android / TV 的开放源生态，重新做成原生桌面应用”
这类项目。
感觉这里面其实还有很多挺有意思的问题可以继续折腾。
ZiLong 09-06 00:541楼