用过车载蓝牙听歌的朋友，可能遇到过这种情况：点击一首歌曲，车机上只显示了歌名和歌手，专辑封面、流派、时长等信息全是空的，或者直接显示"信息缺失"。很多人以为是手机没传全数据，其实这背后藏着AVRCP里一个极易被忽略的细节------GetItemAttributes命令的 MTU 截断机制。
目录
和上一篇讲的文件夹列表批量截断不同，这次是单条歌曲的多属性请求被MTU限制住了。比如你一次性请求10个属性，但控制器的接收缓冲区只能装下6个，目标设备只能返回前6个，剩下的就只能标记为不可用。如果没处理好这个流程，就会出现歌曲信息残缺、界面显示异常，甚至车机直接卡死的问题。
本文把这个场景拆透，讲清楚MTU如何限制单条属性的传输、截断规则怎么跑、开发里最容易踩的坑有哪些，把这个高频考点彻底讲明白。
一、场景与核心问题：为什么歌曲属性会不全？
在蓝牙音频的文件浏览场景里，控制器（CT，比如车机、耳机）会向目标设备（TG，比如手机、播放器）发送GetItemAttributes命令，请求某一首歌曲的详细信息，比如歌名、艺术家、专辑、流派、时长、封面ID等。
但控制器的接收缓冲区（MTU）是有限的，比如本例中的335字节。每一个属性都包含ID、长度和具体数据，都要占用固定的字节数。如果一次性请求的属性太多，或者属性数据太长，总数据量超过了MTU上限，目标设备就没法把所有属性塞进一个响应包，只能截断返回部分属性。
就像你去餐厅点了10道菜，但餐厅一次只能出6道，剩下的菜只能下次再做，或者直接告诉你"暂时无法提供"。AVRCP里的GetItemAttributes截断，就是这个道理。
二、核心流程：MTU限制下的属性截断全链路
下面以控制器MTU=335字节、单条属性平均大小50字节、请求10个属性为例，完整拆解截断传输的流程：
1. 前置条件：通道建立与 MTU 协商
控制器和目标设备首先完成两个关键通道的建立：
基础AVRCP控制通道建立，实现播放控制、音量调节等基础功能
AVRCP Browsing通道建立，这是文件浏览的专用通道，用于传输歌曲属性、文件夹列表等大数据
控制器会向目标设备宣告自己的最大接收MTU（本例中为335字节），目标设备会根据这个值计算单次响应最多能装下多少个完整的属性。
2. 控制器发起多属性请求
控制器发送GetItemAttributes命令，指定目标歌曲的UID和10个要请求的属性ID，比如歌名、艺术家、专辑、流派、时长、封面ID等。
cpp
GetItemAttributes_Cmd(UID, List of 10 Attributes)目标设备收到请求后，开始计算每个属性的大小：每个属性包含4字节的属性ID、2字节的长度字段和实际数据，本例中每个属性平均占用50字节。
3. 目标设备按 MTU 截断响应
目标设备计算总数据量：10个属性 × 50字节 = 500字节，超过了控制器335字节的MTU限制。于是目标设备按照协议规则，尽量多装完整的属性，不拆分任何一个属性。
335字节 ÷ 50字节/个 = 6个属性，目标设备只能把前6个完整的属性塞进响应包，返回给控制器：
cpp
GetItemAttributesRsp(6 Attributes)剩下的4个属性因为无法完整放入响应包，目标设备不会包含在响应里。
4. 控制器处理缺失属性
控制器收到响应后，解析出前6个属性，对于请求列表里但响应中没有的4个属性，控制器必须按照协议要求，标记为不可用，而不是显示乱码或崩溃。
三、关键协议知识点
1. 核心规则：属性不可拆分，必须完整传输
AVRCP协议里明确写了：
The target device shall send as many complete attributes as possible in the response, without splitting any single attribute across multiple responses.
简单来说，单个属性是不可拆分的原子单元，要么完整出现在响应里，要么完全不出现，绝对不能把一个属性拆成两半塞进不同的响应包。这也是为什么本例中335字节只能装下6个属性，而不是装下6个完整的和1个截断的。
2. GetItemAttributes命令的关键参数
-
ItemUID：要请求属性的歌曲或文件的唯一ID，用于定位目标文件 -
AttributeList：控制器指定的要请求的属性ID列表，比如0x01（歌名）、0x02（艺术家）、0x03（专辑）等，最多可请求所有标准属性 -
响应中只会包含能完整放入MTU的属性，且顺序和请求列表一致，控制器必须按请求顺序解析
3. 控制器的强制处理逻辑
协议规定，控制器对于请求列表中未出现在响应里的属性，必须视为该属性不可用，不能尝试解析不完整的数据，也不能重复发送请求。如果控制器强行解析不存在的属性，会导致缓冲区溢出或崩溃。
四、代码示例：控制器属性请求与解析逻辑
cpp
// 控制器端GetItemAttributes请求与解析伪代码
#define CT_MAX_MTU 335
#define ATTRIBUTE_SIZE 50 // 单条属性平均大小
// 要请求的属性ID列表（10个属性）
uint8_t attribute_list[] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A};
uint8_t received_attributes[10] = {0}; // 标记哪些属性已收到
void avrcp_send_item_attributes_request(uint32_t item_uid) {
// 发送GetItemAttributes命令，请求10个属性
send_get_item_attributes_cmd(item_uid, attribute_list, 10);
}
void avrcp_handle_item_attributes_response(uint8_t *rsp_data, uint8_t received_count) {
// 重置接收标记
memset(received_attributes, 0, sizeof(received_attributes));
// 解析响应中的属性（顺序和请求列表一致）
for (int i = 0; i < received_count; i++) {
uint8_t attr_id = rsp_data[i * ATTRIBUTE_SIZE];
received_attributes[attr_id - 0x01] = 1; // 标记该属性已收到
// 解析属性数据并更新界面
parse_and_update_ui(attr_id, rsp_data + i * ATTRIBUTE_SIZE + 6);
}
// 处理未收到的属性，标记为不可用
for (int i = 0; i < 10; i++) {
if (!received_attributes[i]) {
mark_attribute_not_available(attribute_list[i]);
}
}
}五、开发避坑指南
-
控制器不要一次性请求过多属性：新手开发时，为了省事会一次性请求所有10+个属性，结果因为MTU限制只能收到部分，导致界面显示残缺。建议根据界面实际需要，按需请求属性，比如车机界面只显示歌名和歌手，就只请求这两个属性。
-
目标设备必须按请求顺序填充属性：响应里的属性顺序必须和请求列表一致，控制器是按顺序解析的，如果乱序返回，会导致解析错位，属性对应错误。
-
控制器必须正确处理"不可用"属性：很多开发会忽略这一点，收到响应后直接按请求列表解析，结果越界访问缓冲区，导致车机或耳机崩溃。
-
注意属性数据长度对传输的影响：如果歌曲名、艺术家名很长，单条属性的实际大小会超过平均值，导致能装下的属性数量减少，开发时要按最坏情况（最大属性长度）计算，而不是平均长度。
六、测验
**题目：**AVRCP中GetItemAttributes命令为什么会出现属性不全的情况？简述流程与核心规则（车载蓝牙协议开发-长安汽车2023）
答案
核心原因是控制器的MTU限制，目标设备无法一次性装下所有请求的属性。流程为：
-
控制器宣告Browsing通道MTU，目标设备按MTU计算最多能装下的完整属性数量
-
控制器发送多属性请求，目标设备返回前N个能完整放入响应的属性
-
控制器将未出现在响应中的属性标记为不可用，核心规则是单个属性不可拆分，必须完整传输
**题目：**控制器收到GetItemAttributes截断响应后，为什么不能重复发送请求获取剩余属性？
答案
AVRCP协议中，GetItemAttributes命令不支持分多次请求同一首歌曲的属性，目标设备也无法知道后续请求是为了获取上一次截断的剩余属性。重复请求只会再次触发同样的截断逻辑，无法获取剩余属性，正确做法是按需减少请求的属性数量，或按MTU适配请求列表。
**题目：**目标设备在处理GetItemAttributes请求时，如何计算单次响应能装下的属性数量？（TWS耳机协议开发-小米2024）
答案
目标设备的计算逻辑为：
-
从控制器宣告的MTU中减去响应包的固定头部大小
-
按请求列表的顺序，依次计算每个属性的实际大小（ID+长度+数据）
-
累加属性大小，直到再加上下一个属性会超过剩余MTU为止，前面的所有属性都放入响应包，后面的属性不包含在响应中