做了一个原生 macOS 视频客户端 OKVideoMac，今天第一次开源，分享一下 Native-first + Android Bridge 的实现

linyao2010

这段时间一直在做一个自己想用的 macOS 视频客户端，今天终于把第一个公开版本发出来了：

OKVideoMac 0.3.41 （ Build 64 ）

GitHub：

https://github.com/yaolin-dev/OKVideoMac

Latest Release：

https://github.com/yaolin-dev/OKVideoMac/releases/latest

普通用户直接下载：

OKVideoMac-0.3.41-macOS-arm64.dmg

目前主要面向 **Apple Silicon Mac / macOS 12+**，使用 SwiftUI 做原生 macOS 界面，播放器底层是 libmpv 。

先把最重要的一点放在前面：

OKVideoMac 不内置第三方视频源、账号、Cookie 、解析地址或 DRM Key 。

下面截图里的内容也全部是本地生成的 Demo Media ，不是真实影视站、电视台或 IPTV 内容。



为什么做这个

最开始其实就是一个很朴素的需求。

我平时接触过 TVBox 、FongMi 这一类生态，也用过一些桌面端播放器和影视壳，但一直想要一个真正按照 macOS 使用习惯做的客户端：

原生 macOS 界面，而不是 Web 套壳

启动和交互尽量轻快

点播、直播都走统一的播放器体验

搜索、详情、历史、收藏这些基本功能都要像一个正常 Mac 软件

尽量兼容已有的一些 Provider / Spider 生态

但又不希望整个 Mac App 被 Android Runtime 绑住

后来越做越深，最后形成了现在这个项目。

目前 UI 主要是 SwiftUI ，播放基于 libmpv ；点播和直播都尽量保持 Native-first 。

目前支持什么

目前公开版主要包括：

Native CMS JSON Provider

部分 CMS XML Response

部分 QuickJS Spider

部分 CatVod / CatPaw 风格 Node .js.md5 视频接口

M3U / TXT / JSON 直播源

XMLTV EPG

搜索、详情、历史、收藏

libmpv 点播 / 直播播放

部分 Java / Dex csp_ Provider 的可选 Android Bridge

这里我特意一直用“部分”“Selected”“Experimental”这样的表述。

因为我不想把项目宣传成：

“全面兼容 TVBox / FongMi / CatPaw”

实际兼容性还是取决于具体源格式、运行时、API 结构、解析方式和媒体行为。

如果对兼容范围感兴趣，仓库里有单独的 Compatibility 文档。



一个我自己比较喜欢的设计：Android Bridge

这个项目最后没有走“把 Android App 整个搬到 Mac 上”的路线。

普通能力全部直接跑在 macOS：

Native Provider

QuickJS

Node

Live

XMLTV

libmpv Playback

这些都 不需要 Android。

真正麻烦的是已有生态里的一部分 Java / Dex csp_ Spider 。

它们原本就是 Android Runtime 下的东西。

全部重新用 Swift 实现，兼容成本很高；但如果为了它们让整个软件依赖 Android ，又会失去做原生 Mac App 的意义。

所以最后做成了一个可选兼容层，大致是：

Swift Provider
→ Android Bridge
→ dedicated Android Emulator
→ ADB
→ bundled Bridge APK
→ DexClassLoader
→ Spider
→ JSON result
→ Swift

也就是说：

Android 在这里是一个 Compatibility Runtime ，而不是 OKVideoMac 的运行平台。

如果你不用 Java / Dex csp_ Provider ，Android 环境完全可以不装。

这个思路我觉得还挺有意思，也可能对其他“原生应用需要兼容另一个生态遗留组件”的场景有一些参考价值。

播放器是我花时间最多的地方之一

播放器底层使用 libmpv 。

除了最基本的播放之外，这段时间主要折腾了：

Seek

快速切换媒体

Live 切台

字幕 / 音轨

播放窗口生命周期

teardown

并发请求覆盖

render surface 生命周期

第一次播放时的时序问题

发布前最后还抓到一个挺典型的 race：

第一次进入 Live 时，本地 HLS 加载太快，loadfile 有机会早于 OpenGL render surface 真正 ready ，结果第一次打开频道可能黑屏；切一次频道以后 surface 已经存在，反而马上正常。

最后没有用：

sleep 300ms

这种方式硬等，而是改成了 event-driven readiness handshake：

create render context
→ real render probe
→ render surface ready
→ loadfile
→ file_loaded
→ first render swap

最终 Build 64 做了多轮 cold-launch / first-live regression ，再加上人工实际播放、重开、切台、VOD 和声音验证之后才发布。



直播

直播目前支持独立导入 M3U / TXT / JSON 。

为了发布前测试和截图，我还专门做了一套本地 Demo Environment：

自己生成画面

H.264 / AAC

本地 HLS

4 个 Demo Channel

不使用真实电视台或第三方 IPTV

这样既能真实测试播放器、切台和 HLS ，又不会为了演示软件去放第三方影视内容。





为什么现在就开源

这个版本肯定不能说已经“成熟到没有 Bug”。

但做到现在，我最大的感受是：

只靠我自己继续测试，边际收益已经越来越低了。

我的机器、网络、配置和使用习惯都太固定。

真正能把项目继续往前推的，反而是：

不同 Apple Silicon 机器

不同 macOS 版本

不同 Provider

不同直播源

不同字幕 / 编码 / 网络情况

完全不同的使用习惯

所以决定先公开。

目前第一个公开版本已经做了 Developer ID 签名和 Apple Notarization ，Release 里同时放了 DMG 、源码包、第三方源码、License 、SBOM 、Manifest 和 SHA-256 校验信息。

下载

GitHub：

https://github.com/yaolin-dev/OKVideoMac

Latest Release：

https://github.com/yaolin-dev/OKVideoMac/releases/latest

目前版本：

OKVideoMac 0.3.41 （ Build 64 ）

系统要求：

macOS 12+

Apple Silicon (arm64)

普通用户下载：

OKVideoMac-0.3.41-macOS-arm64.dmg

打开 DMG 后拖到 Applications 即可。

最后

这是我第一次把自己做的软件完整公开开源。

现在我最想要的其实不是“项目第一天有多少 Star”，而是：

有人愿意真的装一下，然后告诉我哪里不好用。

尤其欢迎反馈：

安装体验

macOS 不同版本兼容

Provider 兼容问题

点播 / Live / HLS

字幕 / 音轨

Crash

性能和内存

UI 交互

Android Bridge 环境配置

有问题可以直接在 GitHub 提 Issue：

https://github.com/yaolin-dev/OKVideoMac/issues

如果有人对 Native macOS + Optional Android Compatibility Runtime 这套架构感兴趣，也欢迎一起交流。

第一次公开项目，如果有哪里做得不规范，也欢迎直接指出。🙂