最近在做一些實驗性質的東西，記得去年短暫玩過 2023 年底上市的第二代 Ray-Ban Meta 智能眼鏡，雖然它主要還是依舊智慧型手機作為算力中心，但我們對它所使用的串流技術很感興趣，因為聽說他們是用藍芽做串流。剛開始我聽到的一些聲音，像是：『他們不知道用了什麼黑科技』這類沒有建設性、不應該從 RD 嘴裡說出來的話時，始終不以為然。
坦白講，每次只要聽到有人說『黑科技』這三個字我都覺得倒胃口，一件理論上可以做到的事，外行人的認知被信息差，加上也沒實作能力去驗證，就什麼都變成黑科技了（有多黑？比巴西黑鮑魚還黑嗎？笑鼠）。反重力技術說不定也非啥黑科技，只是政府不讓你普通老百姓了解罷了。 Ray-ban Meta 的黑科技，講白了就是人家拉個近200人團隊在搞那支眼鏡，然後把軟體、硬體規格點滿，再加上極致優化後的成果唄！
因為知道 Ray-Ban Meta 智能眼鏡有塞入一個強大的 WiFi 晶片在裡面，一開始我猜測會不會有可能是透過 WiFi P2P 或 WiFi SoftAP 的方式去做串流，而去年初我也快速做了一個WiFi P2P架構的 prototype 來驗證，確實傳輸效率非常快，幾百MB的大檔幾乎可以秒級傳完，從眼鏡端將媒體串流到手機端更是不用說的順暢，還記得當時我們的媒體流還是以未經編碼的方式傳透過Socket來傳輸的（這表示所需的頻寬會更大）。
後來因為 iOS 平台不支持 WiFi P2P，所以我們又改用 WiFi SoftAP 的架構來實作，然後這次是採用H264在眼鏡端對影像做編碼，並以RTSP協議來傳輸媒體流。在將熱點強制設為5G頻段的情況下，其串流傳輸效率跟WiFi P2P幾乎相差無異，且眼鏡端功耗聽說更小。題外話，小米的智能眼鏡聽說也是靠 WiFi 在做串流，前陣子有把玩過，不過畢竟是大陸產品，我摸幾下就不想玩了，怕隱私被洩漏一空（笑鼠）。
但是後來聽路人甲轉述說，Ray-Ban Meta 的眼鏡在做直播時，以及最新的 Ray-Ban Display 眼鏡，在透過 WeChat 做視訊聊天時，串流確實是走藍芽通道。不過不論功耗再小，開啟 WiFi 來傳輸這件事本身的功耗就比藍芽大上許多，這也是產品落地最無法被接受的事，因為智能眼鏡那小到摳憐的電池，如果 WiFi 熱點一直開著，電量很快就會被榨乾了。即使透過 BLE 命令來控制眼鏡端 WiFi 熱點，採用按需啟動的方式，在執行媒體串流時，功耗依舊是相當大的！
所以前段時間農曆過年前後，我一直在思考藍芽串流架構的可行性。基於屌絲 SW RD 不信邪的心態，前陣子在家裡花了大約三個小時和 AI Agent 討論、分析、拆解問題、動手開幹，三個小時後，搞出了一個最小限度可動，但其效果僅容自嗨的藍芽串流架構。如果是外行人 Vibe Coder 或者是打嘴砲等級的 SW RD 看到效果，大概會直接認為沒戲唱就放棄了，但我再次秉持不信邪的心態，決定跟它死磕下去。而這也一直都是我解決問題的態度，因為我曾經聽過一句話，沒有背景跟靠山的人，最大的武器就是培養讓自己擁有令人恐懼的執行力。
接著後續幾天，我利用幾個晚上的時間，持續和 AI Agent 討論分析->實作->驗證->優化，一週過去後，我在完全沒變動現有硬體架構的條件下，只靠軟體技術優化，就搞出了一個雖不算完美，但可以在720p解析度、15 FPS、500K Bitrate的條件下，透過藍芽通道做雙向媒體串流，且達到表現尚且不俗的效果！坦白講，這效果已經超出我的預期。
不過我預期中的完美效果，應該是跟我們去年花了好幾個月實作、優化，搞出來的那套 RTSP＋WiFi SoftAP 的串流架構那般近乎完全流暢無延遲、清晰且豪無花屏的效果相近才是。不過想歸想，無奈藍芽通道的物理頻寬跟 WiFi 通道頻寬相比，本質上就是輕量級幹重量級，有如街頭89硬剛拳王泰森，不用比直接下課了！
所以即使720P的條件下可以做到近乎完美，如果硬體沒有什麼升級，那麼上到1080P也是直接沒戲唱了（也實際試過了，效果就是會卡頓），畢竟物理限制就在那邊！即使從 HEVC 編碼升級到壓縮率更高的 AV1 編碼，720P也許能有更流暢的效果，但是1080P終究可能還是沒戲唱，再說還有4K、8K呢？
以下是透過純藍芽串流架構，在市售智慧型手機和夜市買來的安卓平台智能眼鏡上面，實現雙向媒體串流，並透過 Zoom SDK來進行視訊會議的 Demo 效果影片。
在嵌入式系統開發的領域中，智慧眼鏡始終處於電池續航、散熱效率與無線頻寬這「技術三角」的極限拉鋸戰中。要在極度受限的硬體空間內實現即時影音串流，傳統基於 Wi-Fi (RTSP) 的方案雖具備頻寬優勢，卻因高功耗與長達 5 至 15 秒的連線握手時間（DHCP + RTSP Handshake），難以滿足穿戴式裝置「即開即用」的直覺體驗。
借鑒 Ray-Ban Meta 的技術轉向，業界正致力於將串流負載從 Wi-Fi 轉移至藍牙通道。然而，要在物理理論上限僅約 2-3 Mbps 的藍牙頻寬下，穩定輸送 720p 高清畫面，絕非簡單的協議更換。這是一場涉及傳輸層重構、記憶體零拷貝策略與壅塞控制演算法的深度優化革命。
核心技術堆疊：建構高效能傳輸基石
為了突破藍牙傳輸的「天花板」，我們必須捨棄通用的序列埠模擬（RFCOMM），轉向更底層、更高效的技術組合：
- 傳輸層：Bluetooth 5.3 + L2CAP CoC (Logical Link Control and Adaptation Protocol Connection-oriented Channels)。要求 Android 10 (API 29) 以上支援，跳過冗餘的多工層，直接操作 HCI 層以降低開銷。在 iOS 平台上，自 iOS 11 開始，在 CoreBluetooth 框架中正式提供了對 L2CAP 面向連接通道的支持。
- 視訊編碼：HEVC (H.265) 硬體編碼。在 720p@15fps 的「黃金平衡點」下，較 H.264 節省約 40%-50% 的位元率佔用，是將 HD 畫面塞進藍牙管道的唯一途徑。
- 音訊編碼：Opus 編碼 (24kbps)。專為低延遲語音設計，僅佔用整體位元率的 3-5%，卻能提供優於 AAC 的音質。
傳輸介質與架構深度對比
特性 | 傳統 Wi-Fi RTSP 架構 | 重構後 L2CAP/HEVC 架構 | 建築師視角與影響 |
|---|
傳輸協議 | Wi-Fi SoftAP + RTSP/UDP | Bluetooth 5.3 + L2CAP CoC | 功耗降低 4-10 倍，省去 Wi-Fi 廣播開銷 |
連線延遲 | 5 ~ 15 秒 | < 2 秒 | 基於既有 BLE 連線，實現「即時啟動」 |
視訊編碼 | H.264 (AVC) | HEVC (H.265) | 相同品質下頻寬需求減半 |
有效吞吐量 | 4 ~ 8 Mbps | 200-300+ KB/s (1.6 - 2.4 Mbps) | L2CAP 成功將有效頻寬壓榨至物理極限 |
典型延遲 | 200ms ~ 500ms | 300ms ~ 500ms | 經優化後，藍牙延遲已能對標 Wi-Fi |
底層革命：為什麼選擇 L2CAP CoC 而非傳統 RFCOMM？
在傳統藍牙開發中，SPP (Serial Port Profile) 建立在 RFCOMM 之上，而 RFCOMM 是為了模擬序列埠而設計。在現代高清串流面前，RFCOMM 已成為嚴重的技術瓶頸：
- MTU 碎片的代價：RFCOMM 的 MTU（最大傳輸單元）被硬性限制在約 990 Bytes。以一幀約 60KB 的 HEVC IDR（關鍵幀）為例，RFCOMM 必須將其拆分為超過 60 個小包。這不僅增加了封包標頭開銷，更引發了頻繁的系統呼叫（System Call）與 CPU 上下文切換。
- L2CAP CoC 的物理優勢：L2CAP CoC 允許協商巨大的 MTU（最高可達 64KB）。同樣的 60KB IDR 幀，在 L2CAP 下僅需 1~2 個大包 即可完成。
工程數據分析： 透過 L2CAP 重構，我們將系統呼叫次數降低了 10 至 30 倍，並繞過了 RFCOMM 多工層的狀態機處理。這不僅將吞吐量從 1.5 Mbps 提升至 2-3 Mbps，更大幅減輕了處理器負擔，為穿戴式設備爭取到寶貴的散熱空間。
結語：從技術重構看未來擴展
透過 L2CAP CoC 的底層重構與全鏈路的動態優化，我們成功在藍牙這個「窄頻通道」上完成了一次高清影音串流的極限壓榨。實測數據顯示，單幀傳輸延遲降低了 2-4 倍，且因系統呼叫次數大幅減少，顯著降低了眼鏡端的 CPU 負載與發熱量。
然而，工程師必須保持理性。面對未來 4K 或 8K 的串流需求，2-3 Mbps 的藍牙頻寬已達物理天花板。屆時，技術路線勢必回歸 Wi-Fi Direct 或採用極低幀率的「快照模式」。但本次 L2CAP 重構所建立的零拷貝與 anti-bufferbloat 經驗，已為穿戴式裝置在功耗與效能間的平衡，樹立了堅實的架構基準。
