【AVRCP】规范精讲[39]：文件夹列表截断，MTU限制下的批量数据传输

用过蓝牙音乐车机的朋友，大概率遇到过一个奇怪的问题：手机里明明有几百首歌，车机上却只显示前几十首，翻页也加载不出后面的内容。很多人以为是手机蓝牙没给权限，其实背后藏着AVRCP协议里一个非常关键的细节------GetFolderItems命令的 MTU 截断机制。

---

目录

一、场景与核心问题：为什么列表会被截断？

二、核心流程：MTU限制下的截断传输全链路

三、关键协议知识点

四、代码示例：控制器分批请求逻辑

五、开发避坑指南

六、测验

---

AVRCP的Browsing通道虽然支持浏览手机里的歌单、文件夹，但单次传输的数据量会被控制器的最大接收MTU限制住。如果一次请求100首歌的信息，目标设备根本没法把所有数据塞进一个响应包，就只能分多次截断传输。这个流程如果处理不好，就会出现列表加载不全、卡顿、甚至断连的问题。

本文就来拆解这个场景，讲清楚MTU如何限制数据传输、截断流程怎么跑、开发里最容易踩的坑有哪些，把协议里的这个高频考点彻底讲透。

---

一、场景与核心问题：为什么列表会被截断？

在蓝牙音频设备的文件浏览场景里，控制器（CT，比如车机、耳机）会通过Browsing通道向目标设备（TG，比如手机、播放器）发送GetFolderItems命令，请求文件夹或歌单里的文件列表。但控制器的接收缓冲区（MTU）是有限的，比如常见的2048字节。

每一条歌曲信息都包含显示名称、艺术家名等字段，都要占用固定的字节数。如果一次请求的歌曲数量太多，所有数据加起来超过了MTU的上限，目标设备就没法一次性把所有数据塞进一个AVCTP响应包，只能截断传输。

就像快递运输，一个包裹只能装2048字节的货物，你要寄100件商品，每件都占几十字节，就得分好几次打包，分批寄给对方。这个分批打包的过程，就是AVRCP里的GetFolderItems截断机制。

二、核心流程：MTU限制下的截断传输全链路

下面以控制器MTU=2048字节、歌单有60首歌曲为例，完整拆解截断传输的流程：

1. 前置条件：通道建立与 MTU 协商

控制器和目标设备首先完成两个关键通道的建立：

• 基础AVRCP控制通道建立，实现播放控制、音量调节等基础功能

• AVRCP Browsing通道建立，这是文件浏览的专用通道，用于传输文件夹列表、歌曲信息等大数据

控制器会向目标设备宣告自己的最大接收MTU（本例中为2048字节），目标设备会根据这个值计算单次响应最多能装下多少条完整的歌曲信息。

2. 第一次请求：批量请求与第一次截断

控制器发送GetFolderItems命令，请求歌单中索引0到99的歌曲，同时指定需要携带艺术家名属性。

GetFolderItems_Cmd(SearchResultList, 0, 99, 1, ArtistName)

目标设备收到请求后，开始计算单条歌曲信息的大小：

• 显示名称长度：40字节

• 艺术家名长度：40字节

• 其他固定字段（索引、类型、属性ID等）：约20字节

单条歌曲信息总大小约100字节，2048字节的MTU一次最多只能装下25条完整的歌曲信息。

于是目标设备返回第一次响应：GetFolderItemsRsp(Items 0-24)，只包含前25条歌曲信息。

3. 第二次请求：续传剩余数据

控制器收到第一次响应后，知道还有更多数据没传输完成，于是发送第二次GetFolderItems命令，请求索引25到99的歌曲：

GetFolderItems_Cmd(SearchResultList, 25, 100, 1, ArtistName)

目标设备再次计算，2048字节的MTU依然只能装下25条，于是返回第二次响应：GetFolderItemsRsp(Items 25-49)。

4. 循环续传：直到所有数据传输完成

控制器继续发送请求，目标设备分批返回响应，直到歌单里的60首歌曲全部传输完成。整个过程中，控制器需要维护当前已接收的最大索引，确保每次请求的起始索引是上一次结束的位置，避免重复请求或遗漏数据。

三、关键协议知识点

1. MTU 与AVCTP Browsing通道

AVCTP Browsing通道的MTU决定了单次响应的最大数据量，目标设备必须严格按照控制器宣告的MTU大小拆分数据，否则会导致响应包被丢弃或控制器缓冲区溢出。

协议中明确说明：

The target device shall send as many complete items as possible in each response, based on the controller's maximum receivable MTU size.

也就是说，目标设备要在不超过MTU的前提下，尽量多塞完整的条目，不能把一条歌曲信息拆成两半，否则控制器无法解析。

2. GetFolderItems命令的关键参数

• FolderUID：要浏览的文件夹或列表的唯一ID，本例中是SearchResultList（搜索结果列表）

• StartItem：请求的起始索引，用于分批续传，每次请求从上一次结束的位置开始

• EndItem：请求的结束索引，控制器可以根据自己的需求指定，但实际返回的条目数受MTU限制

• AttributeCount：要携带的属性数量，本例中为1（仅艺术家名），属性越多，单条数据占用的字节数越多，单次能传输的条目数就越少

3. 开发中的核心规则

• 目标设备必须保证响应包中的所有条目都是完整的，不能截断单条数据

• 控制器需要维护请求状态，每次收到响应后更新当前已接收的最大索引，作为下一次请求的起始点

• 控制器不能假设一次请求就能收到所有数据，必须处理多次续传的场景

• 目标设备的拆分逻辑必须和控制器的MTU匹配，否则会导致数据传输失败

四、代码示例：控制器分批请求逻辑

// 控制器端GetFolderItems分批请求伪代码
#define CT_MAX_MTU 2048
#define ITEM_SIZE 100  // 单条歌曲信息平均大小

uint16_t current_index = 0;  // 当前已接收的最大索引
uint16_t total_items = 60;   // 歌单总条目数

void avrcp_browsing_request_next() {
    if (current_index >= total_items) {
        printf("所有条目已传输完成\n");
        return;
    }

    // 计算单次最多能请求的条目数（MTU/单条大小）
    uint16_t max_per_req = CT_MAX_MTU / ITEM_SIZE;
    if (max_per_req > (total_items - current_index)) {
        max_per_req = total_items - current_index;
    }

    // 构造GetFolderItems命令，请求current_index到current_index + max_per_req的条目
    send_get_folder_items_cmd(
        SEARCH_RESULT_LIST, 
        current_index, 
        current_index + max_per_req - 1, 
        1, 
        ATTRIBUTE_ARTIST_NAME
    );
}

// 收到响应后的处理函数
void avrcp_browsing_handle_response(uint16_t received_end_index) {
    // 更新当前已接收的最大索引
    current_index = received_end_index + 1;
    // 请求下一批数据
    avrcp_browsing_request_next();
}

五、开发避坑指南

1. 不要假设单次请求能拿到所有数据：很多新手开发时，只发送一次请求，收到响应就以为列表加载完成，结果只拿到前几十条，后面的内容永远加载不出来。

2. 目标设备拆分逻辑要严谨：如果目标设备把单条数据拆成两半塞进响应包，控制器解析时会直接报错，导致列表加载失败。

3. 控制器要处理MTU变更场景：部分设备在连接过程中可能会调整MTU大小，控制器需要同步更新单次请求的最大条目数。

4. 注意属性数量对传输效率的影响：携带的属性越多，单条数据越大，单次能传输的条目数越少，列表加载速度越慢，开发时要平衡功能和性能。

六、测验

**题目：**AVRCP中GetFolderItems命令为什么会出现截断传输？简述流程（车载蓝牙开发-比亚迪2023）

答案

截断传输的核心原因是控制器的最大接收MTU限制，单次响应无法装下所有请求的条目。流程为：

1. 控制器宣告Browsing通道MTU，目标设备根据MTU计算单次响应最多能装下的完整条目数

2. 控制器发送批量请求，目标设备返回部分条目

3. 控制器根据已接收的最大索引，继续发送后续请求，直到所有条目传输完成

**题目：**目标设备在拆分GetFolderItems响应时，为什么不能把单条歌曲信息拆成两半？

答案

AVRCP协议要求响应包中的条目必须是完整的，控制器解析时以单条条目为单位处理。如果拆分单条数据，控制器无法识别条目边界，会导致解析失败、列表显示乱码或崩溃。

**题目：**控制器如何处理GetFolderItems的截断响应，确保列表数据完整？（TWS耳机协议开发-OPPO2024）

答案

控制器需要维护当前已接收的最大索引，每次收到响应后更新该索引，并作为下一次请求的起始索引，持续发送后续请求，直到收到所有条目。同时控制器要根据自身MTU和单条条目大小，合理规划单次请求的条目数，避免不必要的多次请求。

---