一文帶你搞清楚藍(lán)牙 UUID      ...... 矜辰所致

前言

在使用藍(lán)牙的過程中，UUID 作為通用唯一識別碼，是必須要清楚的，按理來說它其實(shí)只是屬于一個(gè)簡單的概念，但是由于藍(lán)牙協(xié)議的層次分明，對于初學(xué)者來說很容易看得迷糊，理不清楚。所以本文就帶大家詳細(xì)認(rèn)清藍(lán)牙中的 UUID 。

我是矜辰所致，全網(wǎng)同名，盡量用心寫好每一系列文章，不浮夸，不將就，認(rèn)真對待學(xué)知識的我們，矜辰所致，金石為開！

一、 理論基礎(chǔ)

簡單過一遍理論基礎(chǔ)，UUID（通用唯一識別碼，Universally Unique Identifier） ，相當(dāng)于藍(lán)牙通信中的 “身份證”，通過標(biāo)準(zhǔn)化和自定義兩種形式，確保藍(lán)牙設(shè)備間能準(zhǔn)確識別、通信和交互。

藍(lán)牙協(xié)議通過 UUID 實(shí)現(xiàn)設(shè)備間的標(biāo)準(zhǔn)化通信，使用藍(lán)牙對外提供服務(wù)的設(shè)備，需要有對應(yīng)的服務(wù)功能，服務(wù)是藍(lán)牙設(shè)備中功能劃分的單元，每個(gè)服務(wù)都對應(yīng)著一種特定的功能或數(shù)據(jù)傳輸需求。

例如，當(dāng)一個(gè)藍(lán)牙設(shè)備（如智能手環(huán)）向外界廣播服務(wù)時(shí)，會(huì)攜帶對應(yīng)的 UUID，其他設(shè)備（如手機(jī)）通過識別這些 UUID，就能知道該設(shè)備提供哪些功能（如心率監(jiān)測、數(shù)據(jù)傳輸?shù)龋?，并建立針對性的連接。

藍(lán)牙 UUID 用于唯一標(biāo)識藍(lán)牙服務(wù)（Service）、特征（Characteristic）和描述符（Descriptor）等
核心組件，在藍(lán)牙官方文檔中有圖：

對于藍(lán)牙這個(gè) 服務(wù)，特征值，描述符知識理論基礎(chǔ)大家可以自行網(wǎng)上翻閱資料，

在我以前的博文 [ESP32-C3 學(xué)習(xí)測試 藍(lán)牙 篇（三、認(rèn)識藍(lán)牙 GATT 協(xié)議）]也有過這方面的說明。

我們的手機(jī)連接上藍(lán)牙設(shè)備，也可以看到 UUID ：

二、UUID 格式

藍(lán)牙 UUID 的標(biāo)準(zhǔn)格式為 128 位，通常表示為 32 個(gè)十六進(jìn)制字符，以 8-4-4-4-12 的格式分組，共 36 個(gè)字符（包括 4 個(gè)連字符）：

格式：8-4-4-4-12
示例：0000180D-0000-1000-8000-00805F9B34FB

2.1 標(biāo)準(zhǔn) UUID（SIG 定義）

由藍(lán)牙技術(shù)聯(lián)盟（Bluetooth SIG）定義，用于常見服務(wù)。

標(biāo)準(zhǔn)的UUID為：0000xxxx-0000-1000-8000-00805F9B34FB

為了節(jié)省帶寬，標(biāo)準(zhǔn) UUID 通常使用 16 位或 32 位短格式，實(shí)際通信時(shí)自動(dòng)擴(kuò)展為 128 位。每一個(gè)藍(lán)牙技術(shù)聯(lián)盟定義的屬性有一個(gè)唯一的16位 UUID，以代替上面的基本UUID的‘x’部分。

若 16 bit UUID為xxxx，那么 128 bit UUID 為 0000xxxx-0000-1000-8000-00805F9B34FB
若 32 bit UUID為xxxxxxxx，那么 128 bit UUID 為xxxxxxxx-0000-1000-8000-00805F9B34FB

比如下圖中，第一個(gè)服務(wù)就是標(biāo)準(zhǔn) UUID：

2.2 自定義 UUID

用于私有服務(wù)或廠商特定功能，需開發(fā)者自行生成，通常使用 UUID 隨機(jī)生成器生成 128 位 UUID，確保全球唯一性。

比如下圖中的最后一個(gè) Service ，使用的就是自定義的 128 位 UUID ：

一般應(yīng)用來說，多見 16bit 或者128 bit UUID ，本文后面的討論也皆在討論這兩種情況。

三、UUID 分類

那我們上面知道，服務(wù)有 UUID ，特征有 UUID ，描述符有 UUID，而且有時(shí)候服務(wù)UUID 和 特征值 UUID 會(huì)一樣？這怎么區(qū)分開呢？

上面這個(gè)問題就是新手容易搞迷糊的地方，首先他們確實(shí)是共用 16-bit 或者 128 bit 編號的，而且確實(shí)存在Service 和 Characteristic UUID 一樣的情況，但是?。?！Service 和 Characteristic UUID 一樣的情況只有在使用自定義的 128-bit UUID 的情況下才會(huì)發(fā)生??！16-bit 區(qū)間被 SIG 固定了用途。

上面說到 16-bit 區(qū)間被 SIG 固定了用途，我們平時(shí)藍(lán)牙連接設(shè)備后，幾乎大部分設(shè)備都能見到 16-bit UUID 為 0x1800 、0x1801 什么的，如下圖：

其實(shí)這些都是藍(lán)牙聯(lián)盟規(guī)定好固定的：

• 0x180x 開頭 → 只能當(dāng) Service UUID
• 0x2Axx 開頭 → 只能當(dāng) Characteristic UUID
• 0x29xx 開頭 → 只能當(dāng) Descriptor UUID

只要記住這種規(guī)定，以后看到 UUID 就不會(huì)犯迷糊了，下面把常見的一些列出來，當(dāng)做記錄，也方便自己以后查閱。

3.1 0x180x 開頭UUID（Service UUID）

0x180x 區(qū)間只能當(dāng) Service UUID ， 但是不是說 Service UUID 只能用 0x180x 這里要搞清楚，因?yàn)槲覀兛梢宰远x，也可以使用一些預(yù)留區(qū)域的值。

我們用表格記錄一下：

通用類

基本上做 BLE 從機(jī)，都得加上 0x1800 / 0x1801 / 0x180A / 0x180F 四件套。

傳感器與健康（手環(huán)、手表、醫(yī)療）

做傳感器需要用到 0x180D / 0x1809 / 0x1810 / 0x1843 / 0x183E / 0x181B 等上面這些。

HID & 音頻 & OTA

做 BLE 鍵鼠/遙控 0x1812 必用。

手機(jī)/PC 常用后臺(tái)服務(wù)

3.2 0x2Axx 開頭UUID（Characteristic UUID）

0x2Axx (0x2A00 – 0x2AFF) 區(qū)間只能當(dāng) Characteristic UUID ， 同上面一樣，反過來并不是必須用這個(gè)區(qū)間來做 Characteristic UUID。

通用與設(shè)備信息

傳感器與運(yùn)動(dòng)類（手環(huán)/手表/溫度計(jì)）

電池與電源

HID 與 DFU（鍵鼠、OTA）

安全與配對

3.2.1 鍵盤鼠標(biāo) UUID 說明

記錄到這里，還想說明一個(gè)問題，我們發(fā)現(xiàn)有的 UUID 在 Service 里面之專門給某個(gè)東西的，在 Characteristic 里面也有專門給這個(gè)東西的，比如鍵盤鼠標(biāo)，比如傳感器，為什么 SIG 要在服務(wù)和特征里面“重復(fù)”用 UUID 標(biāo)定？這里專門分一小節(jié)說明一下。

Service 的 0x1812 是 “功能集合” 名稱 。
告訴客戶端“本設(shè)備提供 HID 功能，下面可以放鍵盤、鼠標(biāo)、消費(fèi)級遙控器甚至電池報(bào)告。

Characteristic 0x2A22 / 0x2A32 / 0x2A33是 “數(shù)據(jù)槽” 名稱 。
告訴客戶端 “ 這個(gè)槽放的是 Boot 鍵盤輸入報(bào)告，長度 8 字節(jié)，格式固定 ”。

名字里帶“Keyboard/Mouse”只是告訴你“這條管道按 Boot 協(xié)議走固定格式”；
.
UUID 數(shù)字本身不帶格式，格式由 Report Map Descriptor（UUID 0x2A4E）里那張 80~200 字節(jié)的“小字節(jié)碼”定義。
.
真正決定“是鍵盤還是鼠標(biāo)”的是 Report Map 描述符，不是 UUID 名字；
那里才寫“Usage Page = Generic Desktop，Usage = Keyboard，Report Size = 8，Report Count = 6”。
這個(gè)在后期學(xué)習(xí)鍵盤鼠標(biāo)報(bào)表的時(shí)候會(huì)遇到。

如果是鍵盤，手機(jī)端展開 0x1812 Human Interface Device 服務(wù)后：

→ Service 的 0x1812 只出現(xiàn)在最頂層，
→ 下面的 0x2A4D / 0x2A22 分配在這個(gè) 0x1812 的 Service 下面的不同 Characteristic 上，

手機(jī)端查看層次如下圖所示：

還是要再次說明，真正告訴手機(jī)“這是鍵盤”的是 Report Map 里的描述符，不是 UUID。因?yàn)檫@里我們主要討論 UUID ，就不展開討論。

3.3 0x29xx 開頭UUID（Descriptor UUID）

0x29xx 開頭只能當(dāng) Descriptor UUID ，而且描述符 UUID 并不多。截至 Bluetooth v5.4，0x2900 ~ 0x290D 是當(dāng)前已發(fā)布的標(biāo)準(zhǔn)描述符 UUID 。

下面的比上面的記錄多了變量名，是根據(jù)WCH CH585 示例工程中的定義來列舉的：

至于新增加的 0x2908 后面的描述符，大家可自行網(wǎng)上查找。

我們這里看一個(gè)示例架構(gòu)，幫助大家理解一下上面的分類：

3.4 0xFFxx開頭 UUID（Vendor Specific）

0xFF00 ~ 0xFFFF 區(qū)間為SIG 的公共預(yù)留池（Vendor-Specific 區(qū)間） 任何廠商都可以臨時(shí)借用。

這個(gè)區(qū)間 SIG 作為公共預(yù)留區(qū)間，一般用作示例測試參考，屬于臨時(shí)方案，想要作為產(chǎn)品，要么去 SIG 申請正式分配，要么直接用 128-bit 自建 UUID。

額外說明。使用 16bit UUID 那么久必須保證同一份規(guī)范表里 Service、Characteristic 不能重復(fù)。這是官方文檔規(guī)定好的。

CH585 例程把 0xFFE0 當(dāng) Service，再把 0xFFE1-0xFFE5 當(dāng) Characteristic，作為示例演示使用，如下圖：

當(dāng)然，除了 0xFF00 ~ 0xFFFF 區(qū)間，如果想用其他數(shù)值，比如0xCCC0、0xAAA1 這種，他們并不在 SIG 已經(jīng)劃出用途的 “ 固定區(qū)間 ”里，能不能用？會(huì)怎么樣？

首先，單協(xié)議角度看，拿 0xCCC0 / 0xAAA1 當(dāng) Service 或 Characteristic 用，沒什么問題，芯片例程、調(diào)試 Demo 里這么干只要自己知道自己的設(shè)定，也能夠調(diào)試解析。

但是僅限于例程，產(chǎn)品不建議，它們?nèi)允?SIG 的公共編號池資源，只是目前還沒輪到給 0xCCC0 分配名字而已，指不定哪天 SIG 把 0xCCC0 分配成“某官方服務(wù)”，你就得跟著改，否則后續(xù)過認(rèn)證、做 BQB 測試就會(huì)出問題。

做產(chǎn)品最規(guī)范的途徑只有兩條：

• 去 SIG 花錢申請正式分配（16/32-bit）；
• 直接用 128-bit 自建 UUID。

所以 0xCCC0、0xAAA1 這種臨時(shí)使用可以，本質(zhì)上和 0xFF00 ~ 0xFFFF 的公共預(yù)留區(qū)差不多，屬于 SIG 公共編號區(qū)，目前沒人使用，但是隨時(shí)可能有用。

還要記住，整個(gè) 16-bit 空間都由 Bluetooth SIG 的官方文檔 《16-bit UUID Numbers Document》統(tǒng)一管理， 所有的 16-bit 空間 ?。。?所有的 16-bit 空間 ?。?！

經(jīng)過上面的說明相信大家以后在看到藍(lán)牙設(shè)備的 UUID ，能夠清楚的識別是什么類型。

四、WCH 藍(lán)牙示例中 UUID 對應(yīng)體現(xiàn)

最后一小節(jié)我們來簡單看看一下在 WCH 藍(lán)牙芯片例程中與 UUID 相關(guān)的地方。

我們打開從機(jī)工程：

詳細(xì)的從機(jī)例程會(huì)有對應(yīng)的從機(jī)示例解析博文（博主還沒寫= =！ 等寫了以后放上鏈接，大家可以自己查看網(wǎng)上其他資料~）

我們要看的地方是static gattAttribute_t simpleProfileAttrTbl[] 這個(gè)數(shù)組，因?yàn)樗苯雍臀覀兪謾C(jī)連接上設(shè)備看到的框架圖對應(yīng)起來。

4.1 0x28XX 開頭UUID

在第一欄我們就能看到一個(gè)名為primaryServiceUUID 的東西，但是跳轉(zhuǎn)過去，我們是找不到這個(gè)定義的，因?yàn)樗且粋€(gè)指針，指向一個(gè) UUID 的地址，但是這個(gè)地址是一個(gè) Flash 的固定地址，就等于說，CH585 示例種這個(gè) UUID 數(shù)據(jù)是燒錄完后就會(huì)保存在固定地址的一個(gè)數(shù)據(jù)。

既然官方都定義為 UUID ，而且固定起來了，說明他肯定是標(biāo)準(zhǔn)的 UUID ，于是上網(wǎng)查了一下：

0x28xx 一共只有 4 個(gè)（SIG 已全部分配完畢），它們是 GATT 的“骨架”UUID，永遠(yuǎn)不參與用戶數(shù)據(jù)，只用來告訴客戶端我這條屬性是干什么的：這里是服務(wù)頭 / 特征頭 / 引用頭。

在示例代碼中的體現(xiàn)：

在有些地方會(huì)有如下定義：

/**
 * GATT Declarations
 */
#define GATT_PRIMARY_SERVICE_UUID       0x2800 // Primary Service
#define GATT_SECONDARY_SERVICE_UUID     0x2801 // Secondary Service
#define GATT_INCLUDE_UUID               0x2802 // Include
#define GATT_CHARACTER_UUID             0x2803 // Characteristic

不參與用戶數(shù)據(jù)，作為框架存在，所以我們在手機(jī)端是看不到這幾個(gè) UUID 的，但是我們在歷程中，定義的時(shí)候確實(shí)是需要用到，而且位置是固定的，用的時(shí)候照抄常量，我們只需要記?。?/p>

• 0x2800 只放在 服務(wù)第一行
• 0x2803 只放在 每條特征第一行

如下：

// 1. 主服務(wù)聲明 → UUID 用 0x2800
{
  {ATT_BT_UUID_SIZE, primaryServiceUUID},   // type = 0x2800
  GATT_PERMIT_READ,
  0,
  (uint8_t *)&devInfoService        // 值 = 0x180A
},

// 2. 每條特征必須先放 0x2803 聲明
{
  {ATT_BT_UUID_SIZE, characterUUID},        // type = 0x2803
  GATT_PERMIT_READ,
  0,
  &devInfoMfrNameProps                      // 屬性+句柄+真正UUID
},

4.2 示例對應(yīng)圖

我們這里上一下從機(jī)示例中的個(gè)人做的分析框圖，這些會(huì)在我的從機(jī)服務(wù)分析文章中內(nèi)容有詳細(xì)說明，由于涉及到了 UUID，這里也放一遍加深印象。

首先是整體的框架圖：

還有服務(wù) UUID 和 特征 UUID 在程序中定義方式是不同的，如下圖:

這里還有一個(gè)簡單的框架示例程序，幫助大家加深印象：

// 1. 0x28xx 骨架 UUID
const uint8_t primaryServiceUUID[2]    = { 0x00, 0x28 };
const uint8_t characterUUID[2]         = { 0x03, 0x28 };

// 2. 0x180x 服務(wù) UUID
const uint8_t envServUUID[2]           = { 0x1A, 0x18 };   // 0x181A

// 3. 0x2Axx 特征 UUID
const uint8_t tempUUID[2]              = { 0x6E, 0x2A };
const uint8_t humiUUID[2]              = { 0x6F, 0x2A };
const uint8_t battUUID[2]              = { 0x19, 0x2A };

// 4. 0x29xx 描述符 UUID
const uint8_t descCCC[2]               = { 0x02, 0x29 };
const uint8_t descUser[2]              = { 0x01, 0x29 };
const uint8_t descFormat[2]            = { 0x03, 0x29 };

// 5. 屬性表 —— 與上面 0~9 行一一對應(yīng)
static gattAttribute_t envAttrTbl[] = {
  /*0*/ {{ATT_BT_UUID_SIZE, primaryServiceUUID}, GATT_PERMIT_READ, 0, (uint8_t *)&envService},
  /*1*/ {{ATT_BT_UUID_SIZE, characterUUID},    GATT_PERMIT_READ, 0, &tempProps},
  /*2*/ {{ATT_BT_UUID_SIZE, tempUUID},         GATT_PERMIT_READ, 0, (uint8_t *)&tempVal},
  /*3*/ {{ATT_BT_UUID_SIZE, descCCC},          GATT_PERMIT_READ|GATT_PERMIT_WRITE, 0, (uint8_t *)tempCCC},
  /*4*/ {{ATT_BT_UUID_SIZE, characterUUID},    GATT_PERMIT_READ, 0, &humiProps},
  /*5*/ {{ATT_BT_UUID_SIZE, humiUUID},         GATT_PERMIT_READ, 0, (uint8_t *)&humiVal},
  /*6*/ {{ATT_BT_UUID_SIZE, characterUUID},    GATT_PERMIT_READ, 0, &battProps},
  /*7*/ {{ATT_BT_UUID_SIZE, battUUID},         GATT_PERMIT_READ, 0, (uint8_t *)&battVal},
  /*8*/ {{ATT_BT_UUID_SIZE, descUser},         GATT_PERMIT_READ, 0, (uint8_t *)battUserDesc},
  /*9*/ {{ATT_BT_UUID_SIZE, descFormat},       GATT_PERMIT_READ, 0, (uint8_t *)battFormat}
};

結(jié)語

本文詳細(xì)的說明了一下 BLE 藍(lán)牙的 UUID，應(yīng)該算是特別全面了。

最后再總結(jié)一下：

• 0x280x 只當(dāng)“標(biāo)簽”，對用戶不可見
• 0x180x / 0x2Axx 是用戶數(shù)據(jù)分別對應(yīng)服務(wù)（0x180x）和特征（0x2Axx）
• 0x29xx 只是附加說明
• 其他沒有定義的區(qū)間，測試可以臨時(shí)用
• 所有的16-bit UUID 都由 SIG 的官方文檔 《16-bit UUID Numbers Document》統(tǒng)一管理
• 自定義的 128-bit UUID，服務(wù) UUID 可以和 特征 UUID 一樣，16-bit 的服務(wù)和特征值的 UUID 不能一樣
• 同一設(shè)備，不同特征 UUID 任何時(shí)候都不能一樣

好了，本文就到這里吧，謝謝大家！ <3 △ <3

審核編輯 黃宇