【圖文版】AIOT 小智 AI 聊天機器人 ESP32 項目源碼圖解

前言

小智 AI 聊天機器人是最近一個很火的開源項目，它借助LLM大模型以及TTS等AI的能力，通過自然語言來與其對話實現交互。它可以回答任何問題、播放音樂、背誦古詩，頗有未來AI機器人的雛形。

因為最近工作上的需要對其進行了研究，因此有了本篇文章。本文不會過多的講解源碼，而是通過圖解各個架構和數據流的方式，帶大家搞懂它的工作原理。我相信只要搞懂了工作原理，再來看源碼就會簡單很多，廢話不多說，馬上進入正題。

源碼： https://github.com/78/xiaozhi-esp32 ，本文章基于源碼 v1.7.6 版本。

系統架構

本小節展示小智 AI 各種架構圖，包括：

整體系統架構分層圖：展示系統從用戶交互到物理硬件的完整分層結構
核心組件關系圖：展示系統核心組件之間的依賴關系和職責分工
硬件抽象層繼承體系：展示硬件抽象層的面向對象設計和繼承關系
服務層架構詳圖：詳細展示四個核心服務的內部架構和數據流
并發架構與任務管理：展示FreeRTOS下的任務管理和并發控制機制
配置管理架構：展示從配置源到運行時的完整配置管理流程

整體系統架構分層圖

展示系統從用戶交互到物理硬件的完整分層結構

整體系統架構分層圖.png

👤 用戶交互層

位置: 最頂層，直接面向用戶
作用: 處理用戶的輸入輸出操作
組件:
- 語音輸入：接收用戶的語音指令
- 觸摸交互：處理屏幕觸摸操作
- 視覺反饋：通過顯示屏向用戶展示信息
- 音頻輸出：播放AI回復和系統提示音

🧠 應用層

位置: 核心控制層
作用: 系統的大腦，統一調度和管理
組件:
- Application主控制器：單例模式，負責整個系統的生命周期管理
- 狀態管理器：管理9個不同的設備狀態轉換
- 事件系統：基于FreeRTOS事件組，處理系統內各種事件
- 任務調度器：管理后臺任務的執行

?? 服務層

位置: 業務邏輯層，分為四個子模塊
作用: 提供具體的功能服務
音頻服務:
- 音頻處理器：支持AFE噪聲抑制和直通模式
- 喚醒詞檢測：ESP-SR或ESP Wake Word兩種方案
- OPUS編解碼器：實現音頻的壓縮和解壓
- 音頻隊列：管理音頻數據的緩沖
網絡服務:
- 協議管理器：支持WebSocket和MQTT兩種協議
- 網絡棧：WiFi和4G網絡自動切換
- 會話管理：維護連接狀態和會話信息
MCP服務:
- MCP服務器：實現JSON-RPC 2.0協議
- 工具注冊表：管理設備能力發現
- 屬性驗證器：確保參數類型和范圍正確
傳統IoT服務:
- Thing管理器：兼容舊版IoT協議
- 設備控制：處理狀態同步

🏗? 硬件抽象層

位置: 連接服務層和驅動層的橋梁
作用: 屏蔽硬件差異，提供統一接口
開發板繼承體系:
- Board基類：定義通用接口
- WifiBoard：WiFi網絡開發板
- Ml307Board：4G網絡開發板
- DualNetworkBoard：雙網絡開發板
硬件抽象接口:
- 音頻編解碼接口：統一音頻硬件操作
- 顯示接口：支持LCD和OLED顯示
- LED接口：控制各種LED設備
- 攝像頭接口：視覺輸入支持
- 電源接口：電池和充電管理

🔌 驅動層

位置: 直接操作硬件的最底層軟件
作用: 提供硬件設備的具體驅動實現
音頻編解碼器: ES8311、ES8374、ES8388等不同芯片驅動
顯示驅動: LCD、OLED、觸摸屏驅動
網絡驅動: WiFi、4G、以太網驅動
外設驅動: I2C、SPI、GPIO、UART、ADC等總線和接口驅動

? 物理硬件層

位置: 最底層，實際的物理硬件
作用: 提供計算和輸入輸出能力
ESP32芯片系列: 支持ESP32、ESP32-S3、ESP32-C3、ESP32-C6、ESP32-P4
物理組件: 麥克風、揚聲器、顯示屏、觸摸面板、攝像頭、LED、傳感器、電源管理

🌍 外部系統

位置: 系統外部的云服務和應用
作用: 提供AI能力和設備管理
AI云服務: 語音識別和對話生成
MCP客戶端: 設備控制應用
OTA服務器: 固件更新服務
配置服務器: 設備激活和配置

📦 開發板實例層

位置: 具體的硬件產品實現
作用: 將抽象架構映射到具體硬件
支持70+開發板: M5Stack Core S3、ESP32-S3-BOX、LILYGO T-Circle-S3等

連接關系分析

用戶交互流: 用戶 → 輸入 → Application → 輸出 → 用戶
服務調用流: Application → 各服務層 → 硬件抽象層 → 驅動層 → 物理硬件
外部通信流: 網絡服務 ? 外部系統（虛線表示可選連接）

核心組件關系圖

展示系統核心組件之間的依賴關系和職責分工

🎯 核心單例組件（紅色邊框）

Application: 系統主控制器，協調所有其他組件
McpServer: 設備控制服務，提供MCP協議支持
ThingManager: IoT設備管理，處理傳統IoT協議
Board: 硬件抽象基類，代表具體的開發板實例

?? 服務組件（綠色邊框）

AudioProcessor: 音頻處理服務，包含AFE和直通模式
WakeWord: 喚醒詞檢測服務，支持多種檢測算法
Protocol: 網絡協議服務，支持WebSocket和MQTT
Display: 顯示管理服務，控制屏幕輸出
AudioCodec: 音頻編解碼服務，處理音頻硬件

🔧 工具組件（紫色邊框）

BackgroundTask: 后臺任務管理，處理異步操作
OTA: 固件升級服務，支持遠程更新
Settings: 配置管理服務，處理系統配置
SystemInfo: 系統信息服務，提供設備信息

依賴關系分析

Application作為中心: 直接依賴大多數核心服務
服務依賴硬件: 所有服務組件最終依賴Board硬件抽象
工具支持應用: 工具組件為Application提供輔助功能
分層依賴: 遵循分層架構，上層依賴下層

硬件抽象層繼承體系

展示硬件抽象層的面向對象設計和繼承關系

Board基類（抽象類）

作用: 定義所有開發板的通用接口
核心方法:
- GetBoardType(): 返回開發板類型標識
- GetAudioCodec(): 獲取音頻編解碼器實例
- GetDisplay(): 獲取顯示器實例
- GetLed(): 獲取LED控制實例
- CreateHttp/WebSocket/Mqtt(): 創建網絡協議實例
- StartNetwork(): 啟動網絡功能
- SetPowerSaveMode(): 電源管理
保護成員: uuid_字符串，每個設備的唯一標識

WifiBoard類

繼承: Board基類
特化: 專門處理WiFi網絡的開發板
新增功能:
- ResetWifiConfiguration(): 重置WiFi配置
- EnterWifiConfigMode(): 進入WiFi配置模式
重寫方法: 網絡相關方法針對WiFi優化

Ml307Board類

繼承: Board基類
特化: 專門處理4G網絡的開發板
新增功能:
- InitializeMl307(): 初始化ML307 4G模塊
重寫方法: 網絡相關方法針對4G優化

DualNetworkBoard類

繼承: 同時繼承WifiBoard和Ml307Board（多重繼承）
特化: 支持WiFi和4G雙網絡的開發板
新增功能:
- SwitchToWifi(): 切換到WiFi網絡
- SwitchToCellular(): 切換到4G網絡
- GetActiveNetwork(): 獲取當前活躍網絡類型

具體開發板實現

ESP32S3Box: WiFi開發板，帶TouchScreen LCD
M5StackCoreS3: WiFi開發板，帶圓形LED燈帶
LilygoTCircleS3: WiFi開發板，圓形顯示屏
SensecapWatcher: WiFi開發板，帶攝像頭功能

設計模式分析

模板方法模式: 基類定義算法框架，子類實現具體步驟
工廠方法模式: 通過create_board()函數創建具體實例
策略模式: 不同網絡類型使用不同的實現策略

服務層架構詳圖

詳細展示四個核心服務的內部架構和數據流

🎵 音頻服務架構

數據流: 音頻輸入 → 音頻處理 → 喚醒詞檢測 → OPUS編碼 → 隊列系統
處理器選擇:
- AfeAudioProcessor: 帶噪聲抑制和回聲消除
- NoAudioProcessor: 直通模式，不做處理
喚醒詞方案:
- AfeWakeWord: 基于ESP-SR的喚醒檢測
- EspWakeWord: 基于ESP Wake Word的檢測
- NoWakeWord: 無喚醒功能的模式
編碼標準: OPUS格式，60ms幀時長
隊列管理: 生產者-消費者模式的音頻緩沖

🌐 網絡服務架構

協議支持: WebSocket（實時雙向通信）和MQTT（IoT消息傳輸）
二進制協議: BinaryProtocol2/3版本支持
網絡棧: 自動WiFi/4G切換能力
傳輸層: TCP/WebSocket over WiFi, ML307模塊 over 4G

?? MCP服務架構

核心: McpServer單例服務
工具管理:
- 通用工具集: 音量、LED、GPIO、電機控制
- 自定義工具: 開發板特定功能
屬性系統: 類型驗證和范圍檢查
協議處理: JSON-RPC 2.0請求解析和響應生成
執行引擎: 回調函數調用和硬件控制

📱 顯示服務架構

顯示類型:
- LcdDisplay: TFT/IPS彩色屏幕
- OledDisplay: OLED單色/彩色屏幕
- EsplogDisplay: 串口日志顯示（調試用）
渲染引擎: LVGL圖形庫
字體系統: 多語言字體支持
主題系統: 暗色/亮色模式切換
資源管理: 圖片和音頻資源加載

服務間協作

音頻網絡協作: 音頻隊列向網絡服務提供編碼數據
MCP網絡協作: JSON-RPC處理器通過網絡服務通信
MCP顯示協作: 硬件控制可以更新顯示內容

并發架構與任務管理

展示FreeRTOS下的任務管理和并發控制機制

? FreeRTOS內核

任務調度器: 優先級搶占式調度，確保高優先級任務及時執行
內存管理器: 堆棧管理，防止棧溢出
事件組: 任務間事件同步機制
隊列: 任務間數據傳遞通道
定時器: 周期性任務觸發機制

🔄 應用任務分配

主任務: Application::Start()，優先級高，系統控制中心
音頻任務: OPUS編解碼，優先級實時，保證音頻流暢
網絡任務: 協議處理，優先級中，處理網絡通信
顯示任務: LVGL渲染，優先級中，界面更新
后臺任務: BackgroundTask，優先級低，處理非緊急任務
喚醒詞任務: 實時檢測，優先級高，快速響應用戶
MCP任務: 工具執行，優先級中，設備控制

📚 任務棧分配

內存分配原則: 根據任務需求分配合適大小的棧空間
音頻任務棧: 8KB，需要音頻緩沖區
網絡任務棧: 6KB，協議處理緩沖
顯示任務棧: 4KB，GUI渲染緩沖
后臺任務棧: 28KB，最大的棧空間用于復雜操作
其他任務: 3-4KB，滿足基本功能需求

🔄 同步機制

應用事件組:
- SCHEDULE_EVENT: 調度事件
- SEND_AUDIO_EVENT: 音頻發送事件
- CHECK_VERSION_EVENT: 版本檢查事件
互斥鎖保護:
- 音頻互斥鎖: 保護編解碼器訪問
- 顯示互斥鎖: LVGL線程安全
- MCP互斥鎖: 工具執行保護
信號量同步: 網絡連接狀態同步

并發控制策略

優先級分配: 實時任務(音頻、喚醒詞) > 控制任務(主任務) > 功能任務(網絡、顯示、MCP) > 后臺任務
資源保護: 關鍵資源使用互斥鎖保護
事件驅動: 通過事件組實現松耦合的任務協作

配置管理架構

展示從配置源到運行時的完整配置管理流程

?? 配置源

用戶配置: 通過menuconfig選擇70+開發板類型和功能選項
SDK默認配置: 針對不同ESP32芯片的優化配置
開發板配置: 每個開發板的硬件參數和引腳定義
組件配置: 外部依賴庫的版本和配置要求

🔄 配置處理

Kconfig解析器: 處理menuconfig的用戶選擇
開發板選擇器: 根據選擇激活對應的開發板配置
依賴解析器: 檢查組件版本兼容性
配置驗證器: 檢測配置沖突和不一致

🏗? 編譯時配置

CMake配置: 確定構建目標和編譯選項
編譯器標志: 設置優化級別和特殊編譯選項
鏈接選項: 確定內存布局和分區方案
分區表: 定義Flash存儲的分區結構

? 運行時配置

Settings管理器: 持久化用戶設置和系統配置
設備激活: 從云端獲取設備特定配置
WiFi憑據: 網絡連接配置
用戶偏好: 語言、音量等個性化設置

配置流程分析

編譯前: 用戶選擇 → 配置處理 → 編譯配置
編譯時: 根據配置生成目標固件
運行時: 加載持久化配置和云端配置
配置層次: 編譯時配置 < 默認運行時配置 < 用戶自定義配置

數據流程圖

數據流程圖可以幫我們梳理整理數據流的走向，理解整個系統是如何運作的。

接下來從如下層面介紹數據流：

整體系統架構數據流：展示從用戶輸入到系統響應的完整數據傳輸路徑
音頻數據流詳細流程：按時間順序展示音頻處理的完整生命周期
網絡協議棧數據流：展示網絡數據從應用層到物理層的完整傳輸路徑
MCP協議數據流：詳細展示設備控制協議的完整工作流程
設備狀態機流轉圖：展示設備在不同工作模式下的狀態轉換邏輯
內存管理數據流：展示ESP32有限內存下的高效內存管理策略

整體系統架構數據流

展示從用戶輸入到系統響應的完整數據傳輸路徑

🎤 音頻采集路徑

起點: 用戶語音 → 麥克風物理采集
硬件轉換: 麥克風 → 音頻編解碼器（ES8311/ES8374/ES8388）
數據格式: 模擬音頻信號 → PCM數字音頻數據（24kHz/16bit）
處理層級: 音頻編解碼器 → 音頻處理器（AFE噪聲抑制/直通模式）

🗣? 喚醒詞檢測路徑

檢測輸入: 降噪后的音頻數據
檢測引擎: ESP-SR 或 ESP Wake Word 算法
觸發機制: 檢測到"你好，小智"關鍵詞 → 生成喚醒事件
狀態切換: 喚醒事件 → Application主控制器 → 設備狀態轉換

📦 音頻編碼傳輸路徑

編碼流程: 錄音數據 → OPUS編碼器 → 60ms幀時長的數據包
緩沖管理: OPUS數據包 → 音頻隊列（MAX_AUDIO_PACKETS_IN_QUEUE 限制）
協議封裝: 音頻隊列 → 協議層（WebSocket/MQTT）
網絡傳輸: 二進制協議格式 → 網絡棧（WiFi/4G）→ AI服務器

🤖 AI處理響應路徑

服務器處理: AI服務器接收音頻 → 語音識別 → 對話生成
雙路返回:
- 音頻響應: OPUS音頻流 → 網絡棧 → 協議層 → OPUS解碼器 → 音頻編解碼器 → 揚聲器
- 控制消息: JSON消息 → 協議層 → Application → 顯示屏更新/MCP設備控制

🔄 狀態管理路徑

狀態控制: Application → 設備狀態機（9個狀態）
事件驅動: 設備狀態 → FreeRTOS事件組 → 后臺任務調度
任務分配: 事件組 → 后臺任務（4096*7棧空間）

?? MCP設備控制路徑

工具發現: MCP服務器 → 工具發現（JSON-RPC 2.0）
屬性驗證: 設備能力 → 屬性驗證器（類型檢查&范圍限制）
設備操作: 驗證通過 → 設備控制（音量/LED/GPIO/電機）

關鍵設計特點

雙向數據流: 音頻上行和下行采用相同的編解碼標準（OPUS）
多協議支持: WebSocket作為主協議，MQTT作為備用協議
狀態驅動: 所有數據流都受設備狀態機控制
事件解耦: 通過FreeRTOS事件組實現組件間松耦合

音頻數據流詳細流程

按時間順序展示音頻處理的完整生命周期

階段一: 音頻采集階段

T1: 用戶開始說話，產生聲波信號
T2: 麥克風采集聲波并轉換為電信號
T3: 音頻編解碼器將模擬信號轉換為PCM數字信號（24kHz/16bit采樣率）
T4: 音頻處理器對原始音頻流進行降噪處理
T5: 喚醒詞檢測器分析降噪后音頻，識別"你好，小智"關鍵詞
T6: 檢測成功后向Application發送喚醒事件

階段二: 錄音與傳輸階段

T7: Application接收喚醒事件，狀態切換為kListening（監聽模式）
T8: Application指示音頻處理器開始正式錄音
T9: 音頻處理器將PCM音頻塊傳遞給OPUS編碼器
T10: OPUS編碼器將音頻壓縮為60ms幀長的數據包
T11: 壓縮后的數據包放入音頻隊列進行緩沖管理
T12: 協議層從隊列取出數據，封裝為AudioStreamPacket
T13: 通過二進制協議（BinaryProtocol2/3）向AI服務器傳輸

階段三: 響應與播放階段

T14: AI服務器處理音頻，返回OPUS音頻流和JSON控制消息
T15: 協議層分離音頻數據和控制消息
T16: 音頻數據傳遞給OPUS解碼器，控制消息傳遞給Application
T17: OPUS解碼器將壓縮音頻解碼為PCM數據
T18: PCM數據傳遞給音頻編解碼器轉換為模擬信號
T19: Application狀態切換為kSpeaking（播放模式）
T20: 揚聲器播放AI響應語音給用戶

時序特點分析

異步處理: 喚醒檢測和錄音處理可以并行進行
狀態同步: 每個關鍵階段都有對應的設備狀態
緩沖管理: 隊列機制確保音頻流的連續性
雙工通信: 支持錄音和播放同時進行

網絡協議棧數據流

展示網絡數據從應用層到物理層的完整傳輸路徑

🎵 應用數據層

音頻數據: OPUS格式，60ms幀時長，適合實時傳輸
JSON消息: 控制指令和狀態信息，使用文本格式便于調試
MCP消息: JSON-RPC 2.0格式，用于設備控制和能力發現

📦 協議處理層

二進制協議: BinaryProtocol2/3版本，提供高效的數據封裝
協議路由器: 智能選擇最適合的傳輸協議
WebSocket協議:
- 主要協議選擇
- 實時雙向通信能力
- 低延遲特性適合語音交互
MQTT協議:
- 備用協議選擇
- IoT標準協議，適合設備管理
- 支持主題訂閱和發布模式

🔌 傳輸層

TCP Socket: 提供可靠的端到端傳輸
連接管理: 處理連接建立、維護和斷開
流控制: 防止網絡擁塞和數據丟失

📡 網絡接口層

網絡接口路由: 智能選擇可用的網絡接口
WiFi協議棧:
- 802.11 b/g/n標準支持
- 適合室內高帶寬場景
4G蜂窩網絡:
- ML307模塊支持
- 適合移動和偏遠地區
雙網絡切換:
- 自動故障轉移機制
- 無縫網絡切換能力

📡 物理層

WiFi天線: 2.4GHz頻段，支持多種天線類型
4G天線: 支持多頻段LTE網絡
信號傳輸: 電磁波信號在空中傳播

🌍 服務器端

互聯網路由: 通過運營商網絡到達服務器
負載均衡器: 分發請求到多個服務器實例
AI服務器集群: 處理語音識別和對話生成

網絡特性分析

多協議冗余: WebSocket主用，MQTT備用，確保連接可靠性
自適應選擇: 根據網絡質量自動選擇最優傳輸路徑
故障轉移: 雙網絡支持，WiFi故障時自動切換到4G
負載均衡: 服務器端支持橫向擴展和負載分發

MCP協議數據流

詳細展示設備控制協議的完整工作流程

🎛? 設備能力注冊階段

能力定義: 設備端定義可控制的硬件能力（音量、LED、GPIO、電機）
MCP服務器: 作為設備端的協議服務器，管理所有可用工具
工具注冊: 通過AddCommonTools()方法注冊標準設備控制工具

🔧 工具類型定義

音量控制工具:
- 屬性: level (0-100范圍的整數)
- 功能: 調節系統音量大小
LED控制工具:
- 屬性: color (顏色值), brightness (亮度值)
- 功能: 控制LED燈帶/矩陣的顏色和亮度
GPIO控制工具:
- 屬性: pin (引腳號), state (高低電平狀態)
- 功能: 控制通用輸入輸出引腳
電機控制工具:
- 屬性: angle (角度), speed (速度)
- 功能: 控制舵機或步進電機

? 屬性驗證系統

類型檢查: 驗證參數類型（Boolean/Integer/String）
范圍檢查: 檢查數值參數的min_value和max_value限制
默認值處理: 為可選參數提供合理的默認值
Property類: 統一的屬性管理數據結構

📋 JSON-RPC 2.0協議處理

協議標準: 遵循JSON-RPC 2.0規范，確保互操作性
工具發現:
- 請求類型: tools/list
- 響應內容: 返回所有可用工具及其屬性定義
工具執行:
- 請求類型: tools/call
- 請求內容: 工具名稱和參數
- 響應內容: 執行結果和狀態信息

🌐 網絡傳輸層

協議承載: MCP消息通過WebSocket或MQTT協議傳輸
雙向通信: 支持客戶端向設備發送命令，設備向客戶端報告狀態
連接管理: 維護與AI服務器的穩定連接

🤖 服務器端處理

MCP客戶端: 服務器端的MCP協議實現
工具目錄: 緩存和管理所有已連接設備的能力
智能控制: AI決策引擎分析用戶意圖，選擇合適的設備操作

? 設備端執行

回調執行: 使用std::function<ReturnValue>實現工具調用
硬件操作: 直接控制物理設備（GPIO、PWM、I2C等）
結果返回: 將操作結果封裝為ReturnValue返回給服務器

MCP協議優勢

標準化: 基于JSON-RPC 2.0，確保協議的通用性和互操作性
類型安全: 完整的屬性驗證系統防止無效參數
可擴展: 工具注冊機制支持動態添加新的設備能力
智能化: 服務器端AI決策引擎實現智能設備控制

設備狀態機流轉圖

展示設備在不同工作模式下的狀態轉換邏輯

🔄 啟動相關狀態

Unknown: 系統剛啟動的未知狀態
Starting: 系統初始化階段
- 成功路徑: → Idle（網絡已配置）
- 配置路徑: → WifiConfiguring（需要WiFi配置）
- 失敗路徑: → FatalError（初始化失敗）

📶 網絡配置狀態

WifiConfiguring: WiFi配置模式
- 成功路徑: → Idle（配置成功）
- 失敗路徑: → FatalError（配置失敗）
Connecting: 網絡重連狀態
- 成功路徑: → Idle（重連成功）
- 失敗路徑: → FatalError（連接失敗）

🎙? 核心工作狀態

Idle: 主要工作狀態，等待用戶交互
- 觸發路徑:
  - → Listening（檢測到喚醒詞）
  - → Connecting（網絡中斷）
  - → Activating（需要設備激活）
  - → Upgrading（發現新版本）
  - → AudioTesting（音頻測試模式）
Listening: 錄音狀態，OPUS編碼傳輸
- 轉換路徑:
  - → Speaking（收到AI響應）
  - → Idle（錄音超時或手動停止）
  - → FatalError（音頻處理失敗）
Speaking: 播放狀態，OPUS解碼播放
- 轉換路徑:
  - → Idle（播放完成）
  - → Listening（被喚醒詞中斷）
  - → FatalError（播放失敗）

🔧 維護相關狀態

Activating: 設備激活狀態
- 成功路徑: → Idle（激活成功）
- 失敗路徑: → FatalError（激活失敗）
Upgrading: 固件升級狀態
- 成功路徑: → Starting（升級完成重啟）
- 失敗路徑: → FatalError（升級失敗）
AudioTesting: 音頻測試模式
- 成功路徑: → Idle（測試完成）
- 失敗路徑: → FatalError（測試失敗）

?? 錯誤處理狀態

FatalError: 致命錯誤狀態
- 恢復路徑:
  - → Starting（手動重啟）
  - → [*]（系統重啟）

狀態機特性分析

容錯性設計: 每個狀態都有對應的錯誤處理路徑
可恢復性: FatalError狀態支持手動和自動重啟恢復
中斷處理: Speaking狀態可以被喚醒詞中斷，實現對話打斷
狀態持久化: 關鍵狀態轉換會影響設備的持久化配置

內存管理數據流

展示ESP32有限內存下的高效內存管理策略

💾 系統內存總覽

總內存容量: 約300KB RAM（ESP32系列芯片）
分配策略: 靜態分配 + 動態分配混合模式
內存區域: 棧內存、堆內存、靜態內存三大區域

📚 棧內存分配

主任務棧: 默認棧大小，處理系統主要控制邏輯
后臺任務棧: 4096*7 = 28KB，最大的棧分配，處理復雜后臺操作
音頻任務棧: 專用于音頻處理，需要實時性保證
網絡任務棧: 專用于網絡協議處理和數據傳輸

🗄? 堆內存分配

音頻緩沖區:
- OPUS幀緩沖：60ms * MAX_PACKETS個數據包
- PCM緩沖區：錄音和播放的原始音頻數據
- AFE處理緩沖區：降噪算法所需的工作內存
網絡緩沖區: WebSocket和MQTT協議的數據緩沖
JSON緩沖區: cJSON對象的動態內存分配
顯示緩沖區: LVGL圖形庫的幀緩沖區