最近在做一些實驗性質的東西，記得去年短暫玩過 2023 年底上市的第二代 Ray-Ban Meta 智能眼鏡，雖然它主要還是依賴智慧型手機作為算力中心，但我們對它所使用的串流技術很感興趣，因為聽說他們是用藍芽做串流。
去年曾經有同事隨口問我：「我們的眼鏡做到跟他們一樣你覺得有可能嗎？」，因為我知道我們的硬體規格跟人家的相比並非等號，加上當時有其他事情在搞，所以隨口開玩笑回說：“可是聽說 Meta 有200個人在搞那個眼鏡捏（雖然不知道他們負責搞應用的有幾人），啊我如果一個人可以幹贏他們200人，那我還在這幹嘛？？？（笑）”
也記得更久以前，當我們還在研究那個眼鏡時，常聽到像是：『他們不知道用了什麼黑科技』，這類沒有建設性、不應該從 RD 嘴裡說出來的話，而我也是不以為然。坦白講，以前只要聽到某嘴砲經理常把『黑科技』三個字掛在嘴上，當做無知的遮羞布，我就會感到倒胃口！同樣身為RD，我只覺得 Shame on you！（打嘴炮、作秀搶風頭、噁心帶風向、搞政治操作、把別人做事的成果搶去幫自己抬轎、有鍋直接推給下屬扛、散佈同事私生活謠言，還有職場霸凌，這些你他媽都頂級專業戶，除此之外你沒啥洨用了！）
一件理論上可以做到的事情，外行人的認知被信息差，不懂加上沒實作能力去驗證，就什麼都變成黑科技了（多黑？比巴西黑鮑魚還黑嗎？）。反重力技術說不定也非啥黑科技，只是政府不讓你普通老百姓了解罷了。 Ray-ban Meta 的黑科技，講白了就是人家拉個百人團隊在搞那支眼鏡，然後把軟體技能和硬體規格點滿，再加上極致優化後的成果罷了！
當時知道 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 Meta Display 智能眼鏡，在透過被他們收購的那個聊天 APP 做視訊聊天時，聽說串流確實也是走藍芽。因為開啟 WiFi 來持續做串流這件事，本身的功耗就很大，這也是產品落地最無法被接受的事，因為智能眼鏡那小到摳憐的電量，如果 WiFi 一直開著，電量很快就被榨乾了。即使透過 BLE 命令來控制眼鏡端 WiFi 熱點，採用按需啟動的方式，可以節省一些電量，但是在執行媒體串流時，功耗依舊是相當大的，而且掃描、連接 WiFi 這個過程，本身就需要數秒的時間，這個延遲對使用者體驗並不佳。
所以前段時間農曆過年前後，我一直在思考藍芽串流架構的可行性。基於 SW RD 不信邪先做再說的心態，前陣子在家裡花了大約三個小時和 AI Agent 討論、分析、拆解問題、動手開幹，三個小時後，搞出了一個最小限度可動，但其效果僅容自嗨的藍芽串流架構。
如果是外行人 Vibe Coder 或者是打嘴砲等級的 RD 看到效果，大概會認為沒戲唱就直接放棄了吧！但我在學生時期，是可以整晚寫代碼不睡覺，只為實現一些功能，然後在睡夢中浮現solution，醒來後真的把問題解掉的那種入戲程度（當年可沒有什麼AI工具可以用啊！）。我抱著不信邪的心態，決定跟它死磕下去。而這也一直都是我解決問題的態度，因為我曾經聽過一句話，沒有背景跟靠山的人，最大的武器就是培養自己擁有令人恐懼的執行力（因為用事實去打臉嘴砲仔就是爽^^）。
接著後續幾天，我利用幾個晚上的時間，持續和 AI Agent 討論分析->實作->驗證->優化，一週過去後，我在完全沒變動現有硬體架構的條件下，只靠軟體技術優化，就搞出了一個雖不算完美，但可以在720p解析度及15 fps條件下，透過藍芽通道做雙向媒體串流，且達到表現尚且不俗的串流效果！坦白講，效果已經超出我的預期。
在實際眼鏡上使用的效果，跟我們去年花了好幾個月實作、優化，搞出來的那套 RTSP＋WiFi SoftAP 串流架構相比，已經超出87分相似度了！無奈藍芽通道的物理頻寬跟 WiFi 通道頻寬相比，本質上就是輕量級幹重量級，有如街頭89硬剛拳王泰森，不用比就直接下課了！
所以即使720P的條件下可以做到近乎完美，如果硬體沒有什麼升級，那麼上到1080P也是直接沒戲唱了（其實也實際試過了，播放端的畫面頗延遲），畢竟物理天花板就在那邊啊！即使從 HEVC 編碼升級到壓縮率更高的 AV1 編碼，1080P也許能有更流暢的效果，但更上去還有4K、8K呢？
Meta Ray-Ban Display 中文開箱 / 實測影片
以下是透過藍芽串流架構，在市售智慧型手機和夜市撿來的安卓平台智能眼鏡上面，實作720p雙向媒體串流，並透過 Zoom SDK來進行視訊會議的 Demo 效果影片。
實測結果，藍芽串流從480p@15fps一路上到720p@30fps都不是問題（但如果你硬體規格不到位就不用說了），其實就算是1080p，只要將碼率下調、再再強迫編碼器使用更高的壓縮率，也一樣能動，只是播放端的影像畫質會變很爛而已（笑）。不過我們的硬體規格跟 Ray-ban Meta 的本來就不是完全劃上等號，所以也不用多說什麼了。要從87分的克隆度再向上大幅提升，我看只能靠硬體規格升級才能實現了吧！
好比你開一台本田喜美去改裝廠，以三七步立勢跟老闆說：『車子的硬體不要給我亂動，請幫偶刷電腦改出跟 GT 63 S E Performance 一樣性能唷，啾咪～』。有良心和 Sense 的會直接跟你說做不到，無良的大概就是先跟你唬爛，騙你錢加騙你時間，最後再雙手一攤說做不到（你要選哪個？）。
但想到幾年前我在做手勢辨識開發的時候，真的有那種沒 sense 亂入的智障經理，要我做類似的事情。我有良心跟他說做不到，然後他眼見想靠壓榨下屬壓榨出奇蹟來跟上級作秀的機會沒了，就脫下面具翻臉了，開始私底下發一些霸凌訊息＋玩一些賤招想實現他的目的（我看過去幾年，他就是靠這種爛招把底下人一個個搞走的），賤狗真他媽令人作嘔....去呷賽啦！
幸好我這種不怕死的也沒在屌那個懶覺郎，記得一年多前有次我在弄 iOS 相關的東西時，那隻賤狗又在辦公室對我露出既得利益者的嘴臉（沒人提的時候你就說那個東西我之後不管了，突然老闆提起、有人關注了，你就瞬間跳進來頤指氣使，是在哈囉三小？），講了幾句後，突然噴我一句：『你是在秋甚麼？』，結果被我回噴：『有你秋嗎？我在這幹了十年，看你打嘴炮打了十年還能平步青雲，我真的好羨慕你喔～x林娘！』，然後嘴哥就不爽了，身體直覺反應作勢往前，我知道他被激到了，輕鬆的跟他說『想動手嗎？我建議你千萬別動手，不然你今天會直接完蛋！』
嘴哥被我嗆到語無倫次講不出話，事後私底下又跑過來跟我說一堆安慰話語，像什麼『有些事不方便跟你說，之後有機會再跟你說』，還有一句最令我印象深刻的『你自己好好想一想，這個team裡面其實我對你最好耶！』，你媽的B。。。打壓策略失效竟跟我玩起PUA了（當我白癡膩？？過去幾年我是看在情份上，選擇不吭聲被你壓搾而已，說白了當年面試時，從你那78面相我早已預想到這一切）。幸好最終已經擺脫了那個嘴砲仔，良禽擇木而棲這句話，還是有道理的＾＾
接著又想到去年初夏，有個從 Meta 離開去創業的白人小鮮肉帥哥，可能在某秀場上看到我們 demo 的眼鏡功能後，某天跑來公司談合作，想了解應用的技術細節（雖然我覺得一來就說要看source code真的很怪），但是那個智障經理，都還沒談成合作，竟然就直接把不是他寫的、屬於公司資產的代碼，直接毫無保留送人了，其智障加噁心的程度，再次令我刮目相看！當年法國賭神一登場，也就說要驗牌而已，你一上場直接就把底牌對人家梭哈了，你他媽智能不足膩？）
而當時那東西的應用端開發，從頭到尾都跟那個經理沒半點關係，結果厚臉皮的噁心哥第一時間就跳出來搶風頭作秀，想讓人家覺得這東西是他在主導的。但是白人小鮮肉想知道的是技術細節，不是來跟你打哈哈的，那個嘴砲哥當然說不出個所以然，直到我進入會議室，看到小鮮肉完全不理他，我覺得快笑鼠（OS：你那套騙吃騙喝的嘴砲伎倆，在華人圈騙騙外行人也許還行啦，想騙實打實懂技術的老外，你終究只能去旁做當小丑啦～）
唉～也難怪啊，想起當年我還是新人時，某 SW 一姊要離職去蘋果前，跟那個嘴砲低能仔不知道因什麼事鬧翻臉，肚爛到把測站軟體的程式碼全砍了...（不過根據觀察，過去幾年那個嘴砲仔底下的人要離職前，幾乎沒有不跟他鬧翻的，摳連！），當時我已經出差結束返台了，嘴砲哥跑來找我，要我直接重寫一個一樣功能的測站軟體出來，我人在台灣沒踏進產線碰治具，只靠email跟TE往來，就隔空幫他複製出一個能用且驗證過的測站軟體。
還有更早以前，有一位嘴砲哥當時看不順眼的副理要離職前，嘴砲哥開始四處散佈那位副理在大陸出差時的一些私生活風流韻事，我看過一些他傳的對話跟照片，當時我只覺得不以為意，因為也不知道那些東西是真的假的，而且人家私生活怎麼過甘你屌事？你他媽自以為是聖人膩？企甲賽啦！
反正當時我只覺得這嘴砲仔滿恐怖的，今天他會弄那個副理，難保證哪天他不會用這種卑賤手段來弄我（因為他底下的人都跑光了，只能繼續騙一些剛畢業不懂事的新人進來壓榨＋操控）。連當時同梯進來也是他底下的同事，中途離職幾年後又回鍋，也不願意在組織圖上繼續掛他底下（摳連...）。過了這麼多年，早期一些學長離職前跟我說過的話，真的都一一驗證屬實了。
在這件事的差不多時間，當時我們 team 有進來一位頂大學校畢業的新人，記得有次在上海出差時，妹子跑來跟我閒聊，偷偷問我說「誒～那個經理到底是在幹嘛的？」，我回說「喔，他就經理啊，負責安排工作的」，妹子說「我看他根本沒在做什麼事，感覺就是一個在旁邊打嘴炮的！聽其他人說，客人根本沒有在理他」，因為嘴砲仔在當時還是我上級，我還幫他平反了兩句。如果是現在喔，我大概會跟妹子說「對啊，你說的完全正確 Make sense！」。可惜頂大妹也是人間清醒，太快跟那隻賤狗翻臉，試用期一到就被弄走了。。。（後來聽說去了 TSMC）
下圖用來詮釋嘴砲哥的用人哲學超貼切。主題為『上吧～免洗筷奴隸軍團們！』
廢話抒發結束！雖說一個蘿蔔一個坑，但如果有人無意間看見這篇廢文覺得心裡不爽，請不要見坑就亂入唷，因為本篇純屬 ＡＩ創作文，沒有指任何人唷＾＾
下面是透過 RTSP＋WiFi SoftAP 串流架構，做720p雙向視訊會議的 Demo 影片（對照組）
你看兩者的相似度484遠不止87分呢（其實仔細比較還是分得出差別的）？不過這些東西終究都會變成電子垃圾，講白了也沒啥了不起的！
甚至用 H.264 編碼器＋藍芽雙向串流進行視訊會議，也不是問題。因為 HEVC 及 AV1 編碼器（HEVC）雖然壓縮率更好，但是商業使用需要付授權費的樣子。
至於耗電的測試結果，我當時初步拿 S25 手機安裝了眼鏡端的應用，先透過雙向藍芽串流，以 720p 畫質執行視訊會議，執行一小時後，電量從 46% 掉到 31%。接著改用 WiFi＋RTSP 雙向串流，同樣以 720p 畫質執行視訊會議，執行一小時後，電量從 29% 掉到 4%。事實證明，這兩種架構的功耗，還是有差異的（廢話）。
之後也有呢拿真的眼鏡測試過，以 H264硬體編碼＆WiFi＋RTSP 串流模式做 AI 多模態聊天，在我們的眼鏡上，10分鐘大約掉電13－15%不等，以H264硬體編碼＆藍芽串流模式做 AI多模態聊天，10分鐘後大約掉電8－10%不等，這結果足以說明：在測試環境和條件都相同的情況下，做同樣的傳輸工作，藍芽確實會比 WiFi 省電一些（以最小值10分鐘差3%電量差異來說，一小時電量就差了18%，而如果以平均值10分鐘差5%來說，一小時電量就差了30%耶～使ㄍㄟˋ）。
我的認知是，若將軟硬體進一步極致優化後，要在智慧眼鏡跟手機之間，實現高畫質且流暢1080p雙向串流，也根本不是什麼黑科技吧！就像同事說的，Meta 養了一堆個美國頂大畢業的博士，領著高薪，就算他們自己有搞一些算法還是啥的來優化傳輸也完全不足為奇啊！
現階段，透過低功耗的藍芽串流，在智能眼鏡跟手機之間還能搞出啥事？嗯～就像是把手機放口袋裡，然後透過智能眼鏡來執行像是 AI 多模態聊天、即時翻譯、Youtube 直播、視訊會議、以及 Google 和 Meta 都 show 過的戴眼鏡導航等等的一些應用吧！又或者進階一點，像是透過智能眼鏡，結合手勢辨識，來控制智慧家電這類的進階應用場景，應該也不是做不到的事。
作為一名資深軟體從業人員，想起前陣子有新人同事問我：『你覺得 AI 能取代你嗎？』，我告訴他：『你要聽實話的話，我認為完全可以』，事實是，AI 不只可以取代我，還可以取代矽谷那些高薪碼農，更是幾乎能取代所有的白領工作，當然還能打臉那些靠信息差跟打嘴砲混飯吃的人，而這些已經是無庸置疑的事實！
在嵌入式系統開發的領域中，智慧眼鏡始終處於電池續航、散熱效率與無線頻寬這「技術三角」的極限拉鋸戰中。要在極度受限的硬體空間內實現即時影音串流，傳統基於 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 經驗，已為穿戴式裝置在功耗與效能間的平衡，樹立了堅實的架構基準。
