在 Colossal 公司转向代理式电商之前，我们正在开发一款移动端节拍发现应用。该应用允许音乐制作人上传节拍，音乐人则可以滑动浏览个性化信息流，而机器学习（ML）推荐系统会根据实时会话信号（如跳过率、收听时长、重复段锁定和重播次数）对该信息流进行排序。该移动应用的核心交互模式包括：从头开始播放当前曲目。跳转到当前曲目中的上一段或下一段。锁定一段，然后在滑动浏览不同曲目时使该段处于活动状态。该交互模型将个性化信息流导航与严格的音频限制相结合。尽管存在移动设备延迟、网络抖动和带宽限制，但每次滑动或段跳转都必须立即触发与节拍同步且无失真的曲目或段切换。最终设计通过以下方式避免了预加载整个文件：为每个节拍单独存储一个编码后的 MP3 文件，生成紧凑的段描述符，仅获取优先级较高的字节范围，利用 MP3 预热上下文对段进行解码，并在原生音频控制循环内调度曲目或段切换。在这个项目中，我负责系统的端到端开发：后端音频分析与段元数据生成、二进制描述符格式、移动范围流式传输策略，以及在 iOS 和 Android 平台上与 React Native 集成的原生 C++ 播放引擎。图 1：利用段锁定进行节拍发现（图片由作者制作）（点击查看动图）设计约束为了使系统正常运行，必须同时满足以下所有限制条件：段切换必须即时、无缝且无瑕疵。段循环必须避免在循环边界处出现咔嗒声或间隙。曲目过渡必须按小节对齐，以保持节奏的连续性。即使用户每拍仅停留两到三秒，而且音源顺序实时变化，播放也必须保持无缝衔接。该实现方案必须能在信号较弱的 3G 移动网络连接下正常运行。难点并不在于其中的任何一项要求，而在于如何在移动网络有限的条件下，使编解码器处理、传输、缓冲、调度以及原生播放等环节可以协同工作，形成一个统一的系统。为何现有的方法未能达到预期的效果在构建自定义系统之前，我针对该产品的播放模型评估了三种基准方案。标准音频播放器起初，我研究了标准音频播放器库是否能支持所需的播放模型。虽然这类播放器库非常适合基本的线性播放，但并非针对与节拍同步的即时段跳转和曲目切换而设计。此外，它们也没有提供该用例所需的底层播放控制或定向预缓冲功能。React Native（RN）桥接架构带来了额外的限制。由于暂停当前播放器并启动下一个播放器仍然需通过 React Native（RN） 桥接，所以无法确保在需要的时刻可靠地完成曲目切换。我在测试中发现，这种曲目切换会带来大约 5 到 10 毫秒的延迟以及抖动。等到进度回调到达 JavaScript 层时，播放进度已经在向前推进，这样难以实现精确的时机控制。图 2：标准播放器流程中的延迟情况（图片由作者制作）（点击查看动图）HLS/DASH此外，我还评估了 HTTP 实时流媒体（HLS）和基于 HTTP 的动态自适应流媒体（DASH）。这两种广泛使用的流媒体协议均以一系列小数据段的形式传输媒体内容。这些协议针对顺序播放、自适应码率切换以及在各种网络条件下的高效流媒体传输进行了优化。然而，它们并非为该应用所需要的快速、非线性段跳转而设计。另一个挑战在于，MP3 解码依赖于前一帧的上下文信息。如果播放从物理分段边界开始且缺少该上下文，那么最初解码的采样数据就可能会出错，从而产生可听见的失真。虽然交叉淡入淡出可以掩盖其中的一些失真，但却无法恢复缺失的解码上下文。因此，那不符合我们期望的交互模型。另一个限制在于缓冲行为。用户可以随时跳转到不同的段，如果目标段尚未缓冲，则必须暂停播放然后等待加载并解码该段。这种暂停会在需要即时响应时引入延迟。图 3：HLS/DASH 与 MP3 帧解码对比（图片由作者制作）全文件下载我也曾经考虑过在播放前将每个音频文件完整地下载下来。然而，下载所需的带宽远远超出了目标的运行条件。每个节拍的平均大小约为 3 MB，而用户通常只会在一个节拍上停留两到三秒，然后滑动跳过。要在该时间窗口内完全下载下一个节拍，仅音频数据就需要大约 8 兆比特每秒的持续吞吐量。一旦将解码开销、网络波动以及与其他应用资源共享的带宽因素考虑在内，实际需求将接近每秒 14 兆比特。由于该应用需要在约每秒 500 千比特的带宽下稳定运行，即使是最乐观的估计也超出了可用带宽约 16 倍，所以全文件下载方案不可行。这一评估表明，要满足产品限制，必须采用定制的传输模型和原生播放引擎。架构概览从宏观层面来看，该系统包括六个阶段：上传、服务器端处理、描述符生成、存储、移动范围检索以及原生播放。图 4：架构概览（图片由作者制作）虚拟分段当制作人上传一个节拍时，后端工作进程会对其进行处理和分析。其中一项关键的设计决策是如何在移动端支持选择性加载。文件分段有两种方式：使用物理分段（类似 HLS 方式）时，每个曲目会被拆分为许多小对象，这会增加请求数量、元数据开销、缓存碎片，并增加分段边界处的处理复杂度。使用虚拟分段时，存储中仅保留一个 MP3 文件，存储每个分段的字节范围，并通过 HTTP Range 请求按需获取范围。我选择了虚拟分段，因为它能够精确地控制接下来要获取的字节，同时避免了管理大量物理分段文件所带来的存储和请求开销。图 5：虚拟分段可视化（图片由作者制作）为 v1 版本选择 MP3 和 CBR对于该处理流程，我评估了 MP3 和高级音频编码（AAC），并最终在 v1 版本中选择了 MP3，因为它在处理过程中进行帧级检查和数据块规划更为简单；解码器在各目标设备和库中的行为具有可预测性；而且，这让我能够在 v1 版本的交付时间表内更快地推进工作。此外，我在音频处理过程中强制采用了恒定比特率（CBR）。通过将大部分块的大小保持在相近的水平，便可以在播放器中创建一个简单的预分配缓冲区池。这不仅降低了内存分配的复杂度，也简化了运行时缓冲区的复用。关于块大小的权衡播放引擎设定了实际的下限，即每个音频片段大约两秒。虽然可以创建更小的片段，但在该实现中这样做没有意义，因为播放器无法处理小于这个大小的片段，而且进一步拆分只会增加请求数量。虽然较小的音频块能提高响应速度，但会增加请求开销；虽然较大的音频块能减轻请求压力，但在低带宽连接下，它们会消耗过多的带宽来传输用户可能会跳过的音频内容，从而延迟接下来真正需要加载的音频块。对于这种交互模式而言，大约 3.5 秒的音频块大小是最佳平衡点。MP3 边界处理MP3 的帧并不总是可以独立解码的。由于比特池行为的存在，一个块中的第一个有效采样可能依赖于先前帧中的数据。这种特殊性增加了单独解码一个块并将其拼接到播放缓冲区的难度，因为它必须重现连续解码整个文件时在该点所获得的 PCM 输出。为了在解码路径中保持这种连续性，我在块规划阶段为每个非初始块预先添加了 9 个重叠帧。随后，我利用该预热上下文进行了解码，并在将 PCM 写入播放缓冲区之前丢弃预热采样。如果跳过该重叠预热步骤，那么块的起始部分就会在实际设备上产生可听见的失真。这里的 9 帧是基于 MP3 解码器的预热行为确定的，并通过目标解码路径进行了验证。如果该系统支持多种编解码器实现，那么我会将这种情况看成是针对单个解码器的兼容性规则，而非一个适用于所有场景的通用常量。描述符格式由于移动客户端需要在网络连接较弱的情况下快速获取并解析块的元数据，所以我将描述符视为传输设计的一部分。首先，我使用 JSON 进行检查，并在随后添加了一种紧凑的二进制格式。这种格式经过优化，可以实现快速的移动端解析且开销比较小。每首曲目都有两个描述符：一个用于调试和检查的 JSON 版本；一个包含移动客户端所需块元数据的紧凑二进制描述符。每个块用以下结构进行描述：@dataclassclass ChunkData: start_frame: int frames: int start_byte: int bytes: int复制代码曲目位置是根据帧索引推算出来的：position_ms = (frame_index * samples_per_frame * 1000) / sample_rate复制代码通过这种映射关系，客户端可以将片段时间戳解析为正确的块索引。由于 v1 产品将曲目最长时长限制为 10 分钟，所以每个块记录都可以压缩至 12 个字节：start_frame: uint16frames: uint16start_byte: uint32bytes: uint32f.write(struct.pack("<I", version))f.write(struct.pack("<I", len(chunks))) # uint32 countfor chunk in chunks: f.write(struct.pack("<HHII", chunk.start_frame, chunk.frames, chunk.start_byte, chunk.bytes))复制代码我根据 v1 版本中明确定义的约束条件规划了每个字段的大小：曲目最大时长：10 分钟采样率：44100 Hz每帧 MP3 采样数：1152根据上述大小规划，每首曲目约有 23000 个 MP3 帧，因此，start_frame 使用 uint16 类型就足够了，而 uint32 则在满足目标文件约束的前提下，为字节偏移量和块有效载荷大小提供了充足的空间。我曾考虑过 Protobuf 和 MessagePack ，但最终还是选择了这种极简的自定义格式，因为记录结构是固定的，在 Python 和 C++ 中解析逻辑非常简单，不需要依赖额外的序列化，而且我可以精确控制字节布局和版本规则。如果模式变得更复杂，那么 Protobuf 可能会是更好的选择。原生播放引擎如前所述，现成的 React Native 播放器无法满足该应用所需的播放行为。因此，我基于 Superpowered ，用原生 C++ 实现了播放层。我将其打包为原生 Expo 模块（当时使用 Builder Bob 构建），并将控制关键逻辑保留在原生代码中。在播放过程中，对时序有严格要求的部分必须以原生方式运行，而且核心逻辑必须在 iOS 和 Android 之间保持共享。音频回调必须在严格的时限内执行。因此，即使是很小的延迟也会产生可听见的失真。将状态转换和缓冲区写入操作保留在共享的 C++ 代码中，既可以避免它们经过 React Native 桥接路径，也可以避免在播放控制过程中出现 JavaScript 运行时暂停。JS/TS 接口被刻意设计得非常精简：const play = () => …const pause = () => …const loadTrack = (track: TrackMetadata) => …const unloadTrack = (uid: string) => …const setCurrentTrack = (uid: string) => …const seekTo = (milliseconds: number) => …const loopTrackSection = (trackUid: string, sectionId: number) => ...复制代码这让音频播放起来很简单。难点在于，在时间同步、循环播放和网络波动的多重压力下，仍然能够准确地播放。与节拍对齐的切换和段循环为了防止切分导致节拍错位，并保证曲目过渡时的节奏准确性，该应用不允许用户跳转到播放流中的任意位置。为此，曲目和段的切换不会在用户输入后立即执行，而是被安排在原生控制循环中，待到下一个小节边界时才进行。同样，段循环也是与段边界精确对齐。只有当该段的至少第一个音块已经缓冲完成后，循环才会被激活。因此，播放器不会出现卡顿、音频断层或以静音状态开始播放的情况。图 6：与节拍对齐的切换（图片由作者制作）（点击查看动图）原生传输与描述符解析考虑到性能限制，原生层必须直接从共享的 C++ 代码中获取二进制描述符和音频字节范围。由于 React Native C++ 模块默认不提供完整的跨平台 HTTP 协议栈，所以必须显式实现传输层。方案有两种：针对每个平台分别实现原生网络协议栈（即分别针对 iOS 和 Android 进行实现），或者实现一个跨平台的 C++ HTTP 层。我的实现基于 libcurl ，确保在两个平台上使用一致的方式处理范围请求、重试和错误。虽然这需要更多的初始设置，但可以避免传输逻辑重复，并且降低了 iOS 和 Android 行为随时间推移而产生差异的风险。在解析方面，原生读取器必须与后端的网络传输格式保持一致：#pragma pack(push, 1)struct ChunkData { uint16_t startFrame; uint16_t frames; uint32_t startByte; uint32_t bytes;};#pragma pack(pop)复制代码二进制描述符将块结构体存储为紧凑打包的 12 字节条目。目标平台上的结构体布局已经与传输格式一致，但我还是显式指定了打包方式，为的是确保内存中的表示形式与序列化格式完全一致。运行时解码流水线在实现描述符解析后，我定义了曲目的 AudioInMemory 结构。为了避免后续的内存分配，我为每个块预分配了一个 PCM 缓冲区槽位。这样，工作线程就可以在数据到达时直接将其解码到相应的槽位中。运行时流程如下：通过 HTTP Range 下载压缩后的块字节数据。将这些字节复制到解码器的专属缓冲区中。在工作线程中基于该缓冲区初始化解码器。在 AudioInMemory 中查找预先分配好的 PCM 槽位。对于非起始块，需要跳过重叠采样点。直接将音频数据解码写入到目标 PCM 缓冲区中。这种方法既避免了在音频回调线程中进行内存分配，也避免了在该线程中进行解码，从而最大限度地减少了该线程的工作量，并降低了产生可听见失真的可能性。缓冲区大小当元数据在原生层就绪后，我会在任何解码工作启动前，利用每个块的采样点数预先计算出 PCM 缓冲区的大小。// 在解码器路径中，MP3_SAMPLES_PER_FRAME = 1152，OVERLAP_FRAMES = 9samplesInChunk = (chunk.frames - OVERLAP_FRAMES) * MP3_SAMPLES_PER_FRAME;chunkBufferSizeBytes = 4 * samplesInChunk + 16384;复制代码这额外的 16384 字节源于 Superpowered 针对该内存播放路径设定的缓冲区大小要求。解码与缓冲区填充原生层通过 HTTP Range 请求获取到一个块之后，经过压缩的字节会首先被复制到解码器专属的缓冲区中，然后由一个工作线程将其直接解码到目标 PCM 插槽中：auto compressedAudioBuffer = malloc(dataSize);memcpy(compressedAudioBuffer, data.data(), dataSize);auto decoder = std::make_unique<Decoder>();int openCode = decoder->openAudioFileInMemory(compressedAudioBuffer, dataSize);// 跳过非初始段的预热重叠部分decoder->setPositionPrecise(OVERLAP_SAMPLES);auto payloadPtr = findPayloadPointerWithIndexInAudioInMemory(trackInfo->audioInMemory, chunkIndex);int decodeCode = decoder->decodeAudio(static_cast<short*>(payloadPtr), chunkSampleCountWithoutOverlap);复制代码直接解码到目标 PCM 插槽中，可以避免在播放前进行第二次 PCM 复制。线程模型与实时约束我将运行时任务拆分为三类独立的工作线程：音频线程：负责音频回调，全程无阻塞、无重型内存分配操作网络/解码工作线程：执行范围获取与 MP3 解码任务控制逻辑线程：调度曲目与段切换、更新播放器状态、协调预加载优先级音频线程必须严格保障实时安全，网络请求、解码运算、内存分配、锁开销比较高的协调逻辑都不能在播放回调内执行，哪怕极微小的延迟，都会引发可被人耳感知的音频掉帧卡顿。对于简单的共享状态，我使用了原子操作并将临界区保持得较短，这样音频线程就不会被优先级较低的任务阻塞。一些运行时优化在实际使用中带来了显著的改善。首先，我保持了多个播放器的就绪状态，包括当前、上一首和下一首曲目。因此，切换曲目时不需要在切换的瞬间重新初始化播放器。我还针对每首曲目复用了下载器的连接，允许重复发送 HTTP 范围请求，从而避免了新建连接带来的开销。此外，我用一个小型可复用缓冲区池取代了重复的 PCM 缓冲区分配。由于音频流采用 CBR 编码，大多数数据块大小比较接近，所以缓冲区复用非常有效。最后，我将共享状态控制在最小范围，并严格限制锁的作用域，这有助于在高负载下仍然保持比较低的协调开销。基于优先级的预取算法预取器并没有试图一次性下载所有内容。相反，它会不断地对一小部分可能的下一个播放路径进行优先级排序，并将带宽优先分配给接下来最有可能会用到的数据块。首先，优先级取决于是否启用了“段锁定”功能，其次取决于曲目和段之间的顺序。当启用“段锁定”时，最高优先级是下一个节拍中的同一段，因为那很可能是下一个播放目标。当段锁定处于禁用状态时，最高优先级是下一个节拍的第一个段，因为那默认是下一曲目的入口点。接下来，预取器会优先处理相邻的曲目和段目标，例如上一曲目、下一段和上一段。在覆盖了更高优先级的播放路径后，其他数据块会根据实际情况进行加载。该决策循环是刻意设计成了确定性的：onPlaybackStateChanged(state): candidates = [] candidates += chunks_needed_to_continue_current_path(state) candidates += chunks_needed_for_scheduled_bar_transition(state) if state.section_lock_enabled: candidates += same_section_in_next_track(state) candidates += same_section_in_previous_track(state) Else: candidates += first_section_in_next_track(state) candidates += first_section_in_previous_track(state) candidates += neighboring_sections_in...