音视频系统开发

项目背景

这是一套影音内容的多端产品矩阵，共 13 个仓库，覆盖 2022 至 2026 年。终端形态包括 iOS 音频端（Swift）、iOS 端（Objective-C）、安卓端、H5 与运营端（Vue，存在多个并行版本），以及 Flutter 跨端应用（Dart），后端接口服务用 Java 编写。多个产品线接入同一套内容接口。这些仓库不是同一时间起步的，产品线之间有先后，也各自受过当时技术选型的影响。

客户当时的状态

影音内容类产品的麻烦通常不在某一个端，而在于端多之后的一致性。用户今天在手机上听到第 20 分钟，明天换设备打开，如果进度接不上，体验就断了。内容侧同理：运营在后台调整了推荐位与播放列表，如果各端各自缓存、各自解释数据，同一份内容在不同端看到的结果就会不一样。另外，历史上积累下来的多个前端版本并行存在，改动分散在几套代码里，维护成本被放大，也没有人能一口说清影响范围。还有一个现实约束：内容运营的节奏比研发快，运营做一次调整如果要各端都改代码，排期就永远排不完。

我们的做法与取舍

第一个取舍是把内容接口收敛成一套。各端只做展示差异，不做内容规则。代价是接口层设计要求更高、联调更频繁，收益是新增一个端不必重写内容逻辑。

第二个取舍是把收听进度与播放列表放到服务端维护。这比各端本地存储复杂，也需要处理冲突，但用户换设备之后体验才是连续的——这一点不值得为了省事而让步。

第三个取舍是接受多版本前端并存，先收敛接口而不是立即合并代码。合并会带来大量回归风险，短期内保留并行、用统一接口约束各版本，是更稳妥的路径。

系统怎么承载这条链路

服务层承载内容数据、收听进度与播放列表状态；iOS 音频端、iOS 端、安卓端、H5 与 Flutter 跨端各自接入同一套接口；运营端负责推荐位与播放列表编排，内容调整通过接口一次性下发，而不是逐端配置。

交付状态与边界

代码处于持续维护状态，最近一次提交在 2026 年（具体月份未披露）。需要说清楚的是边界：内容版权与授权由内容方按协议提供，平台不承担版权审核责任；音视频源文件的存储与分发以既有或签约方案为准；第三方渠道的账号与结算规则按其平台规则执行，系统不改写这些规则。各仓库活跃度并不一致，我们按实际情况说明。