为什么给鸿蒙做一个原生影视库

更新于 2026 年 8 月 31 日 · Vela Player 的设计取舍

取舍一：系统硬解优先，而不是全程软解

全程软解是很有诱惑力的一条路：自带一套解码器，什么格式都自己解，行为完全可预测，也不用管每台设备的芯片差异。不少跨平台播放器就是这么做的，工程上干净得多。

没选它的理由只有一条，但很硬：手机是电池设备。软解一部 4K HEVC 会把 CPU 长时间拉满，发热、掉电、降频接踵而至，一部两小时的电影未必看得完。而且画中画、后台播放这类系统能力也是跟着系统播放器走的。

所以实际做法是三档接力：系统 AVPlayer 永远首选（硬解、低功耗、画中画），覆盖 H.264 与 HEVC 8/10bit，AV1 按设备能力探测；系统解不了的自动切内置 libmpv 软解引擎接管，RMVB / RealVideo、OGM、WTV、DVR-MS、MXF、VC-1、MPEG-2 这些冷门格式都在这一档；再不行还有 FFmpeg 转码桥兜底。切换发生在起播那一刻，界面上还是同一个播放器，你不需要知道哪一档在工作。

代价是要维护三套播放实现并让它们的状态对齐——进度、音轨与字幕的选择、暂停恢复、音频焦点被别的应用抢走时怎么办，每一样都要在三条链路上各做一遍。远比只写一套麻烦，但省下的是用户的电量。硬解与软解的差别单独写在这一篇里。

取舍二：刮削按目录结构判定，而不是维护目录名黑名单

「哪些文件该入库、哪些是花絮」这件事，最常见的做法是列一张黑名单：Sample、Extras、Trailers、「花絮」，扫到就跳过。简单直接。

问题是这张名单永远追不上发布组。真实遇到过的附属目录名包括 Sample,Screens、Box Cover,Poster、Subtitle,info、External AC3，以及一个叫「奥斯卡获奖动画长片」的目录——最后这个尤其说明问题，它看起来完全像一个正经的作品目录，任何黑名单都不会把它列进去。

所以判据换成了结构与时长：子树里最长的片子，短于同一部作品正片的四分之一，就判为附属（时长拿不到时退回文件体积比）。这一条判据把上面那些花样名一次全认了出来，而且不需要维护任何名单。整体的分工是：目录结构决定「哪些文件该入库、谁是正片、哪几个互为版本」，文件名决定「叫什么、第几季第几集」。

结构判据自己也有坑，最要命的一个是同目录多个视频文件怎么解释。规则得分三种，缺一不可：变集号是分集，变技术参数是版本，变片名是不同的片。第三条最容易被省掉，而省掉的后果是静默丢片——「蜘蛛侠 8 部合集」目录下平铺的《平行宇宙》《英雄归来》《英雄远征》会被当成同一部片的三个版本合成一条，9 个文件只入库 4 条，界面上不会有任何报错。静默丢东西比报错更坏，因为你根本不会去找。

代价：几百个文件平铺在一个目录里的片库，结构里没有可用信息，负担全压回文件名上——仍然能扫，只是准确率取决于命名。纠错方法见电影刮削完全指南。

取舍三：网盘做端内直连，而不是让用户自己搭中转

接网盘最省力的做法是只支持 AList / OpenList：应用只需要说一种协议，接一次就通吃十几家网盘，后续每加一家新网盘都是 AList 那边的事。工程量差了一个量级。

没把它当作唯一方案，是因为门槛：要一台常开的服务器或 NAS，凭据存在那台机器上，而且夸克这类源的视频在 AList 侧走服务端代理，会吃中转机的带宽。对「只想在手机上看夸克里那几部片」的人，这个门槛高得离谱。

所以夸克、UC、天翼、移动云盘四家做了端内直连：登录在各家官方登录页完成，应用不接触你的账号密码，凭据交给鸿蒙系统级密钥库保管，手机直接连网盘，不经过任何第三方。同时 AList / OpenList 照样支持——两条路并存，不是二选一，已经有服务器的人不吃亏。

代价是每家各写一套，而且是持续的维护成本。各家的认证方式、错误码约定、字段转义、直链有效期全不一样，任何一家改一次接口都要跟着改。举个具体的：夸克的直链签名绑着 Cookie、Referer、User-Agent 三个请求头，且必须与取链那一刻逐字一致，所以直链根本不能缓存进数据库，每次播放前都要现取——这类细节每家一套，展开写在夸克进阶篇里。

取舍四：本地优先，没有服务端

另一条路很标准：做一个云端账号，片库、进度、设置全同步，顺便还能做推荐、看数据、发推送。绝大多数做大了的应用都走这条。

没走，理由是这些数据的性质：媒体库是你的私人片单，观看记录是你的私人作息。这两样一旦上了云，就变成一份需要被保管、可能被泄露、也可能被拿去做别的事情的数据。而这个应用不需要它们就能工作。

所以实际形态是：媒体库与观看记录存在本机 SQLite；源密码交给鸿蒙系统级密钥库，不落明文；不接任何第三方统计、广告或推送 SDK，没有自建行为上报，应用没有服务端。离开设备的只有两类请求——发往你自己配置的服务器或网盘的访问请求，以及为匹配海报而发往元数据接口的查询词（通常就是片名和年份），刮削结果缓存在本机。

代价必须写清楚：没有账号，就没有云端同步。换一台新设备，媒体库是空的——要重新加源、重新扫一遍，因为那份库只存在原来那台设备上。这是真实的功能缺失，不是「我们认为你不需要」。

观看进度是个例外，但也只是局部的例外：在你自己的、登录同一华为账号又处在同一局域网的鸿蒙设备之间，进度可以自动合并，走的是系统的近场分布式能力，不经过云端。前提是那台设备上也已经把同一部片扫进了自己的媒体库——它匹配的是本机库里的条目。条件不满足时就是各看各的，所以这一条我们只说它「可能帮到你」，不当成承诺。

有一部分是补上的：跨设备接续走鸿蒙自己的分布式能力，手机上看到一半，在平板或鸿蒙 PC 上接着放，进度、当前音轨与字幕、字幕延迟一起带过去，不经过任何云端。但要说清区别——接续是「此刻把这一场播放传过去」，和上面那条进度合并是两件事：两者都不会替你同步媒体库。想要「多台设备长期看到同一份库、同一份进度」，目前更实际的办法是把片库跑在 Emby / Jellyfin / Plex 上，库和进度都归服务端管。

取舍五：智慧屏单独排版，而不是把手机布局放大

把手机布局按比例放大，是适配大屏最省事的做法，很多应用就是这么上电视的。

它不行的原因是方向不对：手机是竖屏的「上图下文」纵向流，横到 16:9 的大屏上会散架。详情页第一版就是这么散的——同一屏里出现了四条不同的左边界：海报一条、标题一条、按钮一条、简介一条；简介横跨大半个屏幕，一行读不完，右侧却空着一大片；剧照只占上半屏，底下压着一条硬边，海报还骑在那条骑缝上。

所以电视上的详情页是独立的一套：剧照铺满首屏，左到右的渐变托住文字，信息全部收进左半屏并对齐同一条基线，简介限三行。列表型页面（设置、文件）则限宽居中——铺满时「字幕」和它右端的取值隔着大半个屏幕，三米外根本对不上。海报墙反而不限宽，网格本来就该铺满，二维扫视没有长行的问题。

判断标准可以概括成一句：同一屏里出现两条以上左边界，或者一行文字横跨半屏以上，就该为电视单独排。

还有一批只在电视上成立的细节，每条都是被真机逼出来的：横滚行的「全部」入口挪到行末当最后一张卡（留在标题行右侧的话，从导航栏按一下方向键往下第一个撞上的就是它，海报一张都碰不到）；首页向下滚动时顶栏收起（1280×720 的界面基准上，顶栏加页面大标题一度吃掉首屏近三成高）；以及因为电视没有触摸屏，加源要先用「扫描局域网」自动填地址、网盘用手机扫码登录。这些写在智慧屏那一篇里。

代价是两套布局各自维护，同一个功能改一次要检查两处。

坦白：现在还做不到的

上面五条讲的是选了什么。这一节讲还差什么，按重要程度排：

• HDR 送显没做。当前版本 HDR 与杜比视界片源能播，但以 SDR 呈现。这一项在验证中，成熟后随版本更新说明，这里不提前承诺。这是清单上最靠前的一条。
• 媒体库不能跨设备同步，也没有云端备份。换设备要重新加源、重新扫描。观看进度在同账号同局域网的设备之间能自动合并，媒体库不行。这是取舍四的直接代价，短期内不会变——真要解决，得先想明白怎么在不设账号的前提下做到。
• 剧集偶尔会裂成两张卡片。分组认的是刮削回来的条目 id 而不是剧名，当一部剧里有些集刮到了 id、有些没刮到时就会裂开。对整部剧重新刮削通常能合回去，但「通常」不等于解决。
• 没有插件体系，也不读 .nfo。元数据是重新刮的，从 Kodi 那类方案迁过来的人要重扫一遍。
• 一个刚起步的应用，追不平十几年的打磨。这句没什么好绕的。能承诺的只有一条原则：官网与商店页只写已实现的能力，没写的就是还没有。

常见问题

为什么不做成跨平台的？

上面五条取舍里，有四条的答案都依赖具体平台：硬解要贴着系统播放器走，跨设备接续是鸿蒙的分布式能力，密钥库是系统级的，智慧屏的走焦模型是这套 UI 框架特有的。做成跨平台意味着这几样全都要退回到最小公约数——那就退回成一个「能打开文件的播放器」了。

应用会看到我的片单吗？

看不到。没有服务端，也没有任何统计 SDK，媒体库与观看记录都在本机。想核对的话，隐私说明在隐私政策页。

首个版本免费，后面会怎么收？

首个版本免费。后续计划把远程媒体源、媒体库刮削这类能力做成 Pro 订阅，届时会明确写清哪些功能属于哪一档，已有功能不会转成收费。