最近在做一些實驗性質的東西，記得去年短暫玩過 2023 年底上市的第二代 Ray-Ban Meta 智能眼鏡，雖然它主要還是依賴智慧型手機作為算力中心，但我們對它所使用的串流技術很感興趣，因為聽說他們是用藍芽做串流。
去年曾經有同事隨口問我：「我們的眼鏡做到跟他們一樣你覺得有可能嗎？」，因為我知道我們的硬體規格跟人家的相比並非等號，加上當時有其他事情在搞，所以隨口開玩笑回說：“可是聽說 Meta 有200個人在搞那個眼鏡捏（雖然不知道他們負責搞應用的有幾人），啊我如果一個人可以幹贏他們200人，那我還在這幹嘛？？？（笑）”
也記得更久以前，當我們還在研究那個眼鏡時，常聽到像是：『他們不知道用了什麼黑科技』，這類沒有建設性、不應該從 RD 嘴裡說出來的話，而我也是不以為然。坦白講，以前每次只要聽到某SW嘴砲經理（暫且以H君稱之），沒事就把『黑科技』三個字掛在嘴上，當做無知的遮羞布，我就會感到倒胃口！同樣身為RD，我只覺得 Shame on you！（打嘴炮、作秀搶風頭、噁心帶風向、搞政治操作、把別人做事的成果搶去幫自己抬轎、有鍋直接推給下屬扛、散佈同事私生活謠言，還有職場霸凌，這些你他媽都頂級專業戶，除此之外沒啥洨用了！）
一件理論上可以做到的事情，外行人的認知被信息差，不懂加上沒實作能力去驗證，就什麼都變成黑科技了（多黑？比巴西黑鮑魚還黑嗎？）。反重力技術說不定也非啥黑科技，只是政府不讓你普通老百姓了解罷了。 Ray-ban Meta 的黑科技，講白了就是人家拉個百人團隊在搞那支眼鏡，然後把軟體技能和硬體規格點滿，再加上極致優化後的成果罷了！
當時知道 Ray-Ban Meta 的智慧眼鏡有塞入一個強大的 WiFi 6 晶片在裡面，一開始我猜測會不會有可能是透過 WiFi P2P 或 WiFi SoftAP 的方式去做串流（確實 Meta 的眼鏡，在同步媒體時，會強制要求開啟手機的 WiFi 開關，所以媒體同步應該是靠 WiFi 通道做的），而去年初我也快速做了一個WiFi Direct 架構的 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一路上30fps都不是問題（但如果硬體規格不到位就不用說了）。其實就算是720p，只要將碼率或fps下調，再強迫編碼器使用更高的壓縮率，也一樣能動，只不過播放端的影像畫質會變很爛而已（笑鼠）。而 Meta 的眼鏡厲害的地方，在於他們的產品在串流上，即使不是走 WiFi，也可以做到高畫質和低延遲，而且人家是面向全球市場的產品，要面對的是各種白牌智慧型手機的使用情境呢。
但是我們眼鏡的硬體規格跟 Ray-ban Meta 本來就不是完全劃上等號，所以也不用多說什麼了。要從87分的克隆度再向上大幅提升，我看只能靠硬體部件規格升級，以及上、中、下層的優化才能實現吧。這裡我想到一個叫做 超解析度（Super-Resolution, SR）的東西，它是一種利用深度學習來提升圖像或影片解析度的技術，說不定也是一種實現藍芽高清串流的可行思路。
用 Wireshark 去讀取藍芽 HCI 偵錯紀錄，可以看出在這支眼鏡上，其藍芽的物理鏈路只有 600Kbps 的 throughput，用藍芽做480p@30fps的串流效果還可以，但如果上到720p或更高畫質，會直接跑不動（除非降碼率犧牲畫質或是降fps，但這就失去720p的意義了）。根本的解決之道，是提升物理鏈路容量，例如從下層把只有 600kbps 的物理鏈路，透過 Classic EDR 2M/3M 或 LE 2M PHY + DLE 拉上去，而不是在應用層87硬解。
就像同事說的，Meta 養了一堆美國頂大博士跟高薪碼農，就算他們自己有搞一些算法還是什麼自研的軟體引擎來進行高度客製化或者優化傳輸啥的都不足為奇吧！ 而且人家從下層、中層、上層，再到雲端的直播還是 video call 什麼的，全都是自己的東西，肯定是一條龍在優化的，不會只有靠應用層去優化。
好比你開一台本田喜美去改裝廠，以三七步立勢跟老闆說：『車子的硬體不要給我亂動，請幫偶刷電腦改出跟 GT 63 S E Performance 一樣性能唷，啾咪～』。有良心和 Sense 的會直接跟你說做不到，無良的大概就是先跟你唬爛，騙你錢加騙你時間，最後再雙手一攤說做不到（你要選哪個？）
我的認知是，若將軟硬體進一步客製化＋極致優化後，要在智慧眼鏡跟手機之間，實現流暢的 720p 雙向串流，其實也算不上什麼黑科技吧！
以下是眼鏡端透過藍芽串流到手機，再從手機端 FFMPEG 推流到 Youtube 的 RTMP 服務器，來實現穿戴裝置執行 720p 直播的概念。這都是有一段時間前做的東西了！
但想到幾年前我在做手勢辨識開發的時候，真的有那種沒 sense 亂入的智障經理，要我做類似的事情。我有良心跟他說做不到，然後他眼見想靠
壓榨下屬壓榨出奇蹟來跟上級作秀的機會沒了，
再加上那一年，因為做很多事，更上層的領導把我的考績打很好，然後那個自以為是的低能仔就眼紅了，沒多久就直接脫下面具不演了，開始私底下發一些霸凌訊息＋玩一些賤招想實現他的目的（我看過去幾年，牠就是靠這種爛招把底下人一個個搞走才混到那個位子的），78賤狗真他媽令人作嘔....去呷賽啦！就像卡爾榮格說過的：『當你退一步，不再餵養惡性循環，對方的陰影就會浮現』（太寫實了）
幸好我這種不怕死的也沒在屌那個懶覺郎，一年多前有次我在弄 iOS 相關的東西時，那隻賤狗又在辦公室對我露出既得利益者的嘴臉（沒人提的時候你就說那個東西我之後不管了，突然老闆提起、有人關注了，你就瞬間跳進來頤指氣使，要不要照照鏡子看自己在哈囉三小？）
講了幾句後，那白痴突然噴我一句：『你是在秋甚麼？』、『你現在這是什麼態度？』，結果被我回噴：『有你秋嗎？我在這幹了十年，看你打嘴炮打了十年還能平步青雲，我真的好羨慕你耶～x林娘勒！』，然後那隻賤狗就不爽了，身體自然反應作勢往前一步，我知道他被激到了，輕鬆的跟他說『想動手嗎？我建議你別動手，不然你今天會直接完蛋！』
我接著繼續噴他：『你要跟我講態度喔？啊你要不要先問問自己，我以前對你態度是怎樣的？（賤狗默默地說他知道）啊你要不要自我反省一下我今天為什麼會拿種態度對你？你三年前是怎麼衝康我的，要我一件一件說給你聽嗎？』、『當年你底下其他人，不爽你就直接去拍你桌子，我在你底下幹了N年，連吭一聲都沒對你吭過，結果換來眼紅找我麻煩？依照我的個性，我沒有對你動手，你真的要感謝我了 You know？』（自己看看現在那些00後的新人，哪個會願意讓你用同樣的方式壓榨？你坑得成嗎？），被我一連串狂噴後，那隻賤狗自知理虧啞口無言說不出話。
再來我他媽的過去幾年在你的要求下，幫你下面其他人在產線工作上擦過幾次屁股你自己心中有底，隨便舉個例子，像當年蘋果想搞的那個充電板，你們那個 shit code inside 的垃圾測站 codebase，只有測幾百個測項能動，測幾千個測項就直接把產線 Mac Mini 測到 hang 住死機了（聽當年召我進來的部經理說那測站軟體的架構是你設計的喔？阿不就好棒棒？可憐哪～架構如其人，一副屎樣！）
那個測站的 DRI 不知道搞了多久搞不定問題，最後賤狗跑來請我幫忙，我花了晚上幾個小時在宿舍偵錯，幫你們把問題解決，讓你跟那個 DRI 安全下莊，你可記得？那件破事根本與我無關（幫你把問題解決績效也不算我的，操！），我當年大可冷眼旁觀看笑話的，你可知道？還有更多過去幾年幫你這廢物無償做功德抬轎＋在產線擦屁股的事，我可都記得一清二楚呢！幾年後你他媽的因為眼紅就來私下玩陰的，你要不要照下鏡子看看自己那副逼樣有多噁心？
當年如果我裝死冷眼旁觀，你那個測站就直接停線吧，還測什麼懶覺？出什麼差？（大家可以回家啦～），啊你這個破 leader 也可以下線去吃屎啦！（ps. 當年他媽的是純粹靠對軟體的 sense 跟經驗在解 issue 的，可沒什麼 AI 還是 BI 可以讓你用的時代耶！啊還有更久以前幫這白痴擦屁股的諸多往事就不提了）
隨後我繼續在辦公室把過去幾年他的一些賤操作嗆回給他聽，嘴砲哥開始語無倫次意圖捏造事實辯解，然後又被我回嗆『你他媽別在那邊唬爛，有本事你現在滑出對話紀錄給我看，我如果有傳過哪句你剛講的那些話，我當場跟你下跪道歉啦，x尼媽逼！』
垃圾嘴砲仔最終被我嗆到講不出話，只能一直安慰我冷靜點，事後私底下又跑過來跟我說一堆唬爛話，像什麼『有些事不方便跟你說，之後有機會再慢慢跟你說』（想洗腦我啊？你還是省省吧），還有一句最令我印象深刻的『你自己好好想一想，這個team裡面其實我對你最好耶！』，我心想：你媽的B。。。打壓策略失效竟跟我玩起 PUA了（當我白癡膩？？過去幾年我是看在情份上，選擇不吭聲被你壓搾而已，說白了當年面試時，從你那機掰小人面相，我早已預想到這一切）。幸好最終已經擺脫了那個嘴砲仔，良禽擇木而棲這句話，還是有道理的＾＾
還記得6年多前，嘴砲仔的面具還沒脫掉前，有天跟我說他可能要去別的事業部支援，帶我一起去跟那邊一個他認識的副理聊天，忘了當時在聊什麼事，聊到一半那個腦滿腸肥的副理突然說一句：『沒事，我不喜歡的人已經全部都被我弄走了』。
我當時心想：『你他媽的什麼咖小？一個小主管而已，當公司你家開的啊？』，後來嘴砲仔問我說：『誒～你覺得那個副理人怎樣？你會想跟他合作嗎？』，我回他說：『我覺得他講話很噁心～要我跟他合作喔？我怕有一天他會被我打死耶？』
然後我又想到去年初夏，有個從 Meta 離開去創業的白人小鮮肉，可能在某秀場上看到我們 demo 的眼鏡功能後，某天跑來公司談合作，想了解應用的技術細節（雖然我覺得一來就說要看source code真的很怪，因為那根本不是啥了不起的技術），但是那個智障經理，都還沒談成合作，竟然就直接把不是他寫的、屬於公司資產的代碼，直接毫無保留送人了，其智障加噁心的程度，再次令我刮目相看！當年法國賭神一登場，也就說要驗牌而已，你一上場直接就把底牌對人家梭哈了，你他媽智能不足膩？）
而當時那東西的開發，從頭到尾都跟那個經理沒半點關係，結果厚臉皮的噁心哥第一時間就跳出來搶風頭作秀，想讓人家覺得這東西是他在主導的。但是白人小鮮肉想知道的是技術細節，不是來跟你打哈哈的，那個嘴砲哥當然說不出個所以然，直到我進入會議室，看到小鮮肉完全不理他，我覺得快笑鼠（OS：你那套騙吃騙喝的嘴砲伎倆，在華人圈騙騙外行人也許還行啦，想騙實打實懂技術的老外，你終究只能去旁做當小丑啦～）
唉～也難怪啊，想起當年我還是新人時，某 SW 一姊要離職去蘋果前，跟那個嘴砲低能仔不知道因什麼事鬧翻臉，肚爛到把測站軟體的程式碼全砍了...（不過根據觀察，過去幾年那個嘴砲仔底下的人要離職前，幾乎沒有不跟他鬧翻的，摳連！），然後當年我們還沒有在內部用 Gitlab 備份代碼，當時我已經出差結束準備返台了，嘴砲哥跑來找我，要我幫他直接重寫一個一樣功能的測站軟體，我返台後，人在台灣沒踏進產線碰治具，只靠email跟TE往來，就隔空幫他複製出一個能用且驗證過的測站軟體。
還有更早以前，有一位嘴砲哥當時看不順眼的副理要離職前，嘴砲哥開始四處散佈那位副理在大陸出差時的一些私生活風流韻事，我看過一些他傳的對話跟照片，當時我只覺得不以為意，因為也不知道那些東西是真的假的，而且人家私生活怎麼過甘你屌事？你他媽自以為是聖人膩？企甲賽啦！
反正當時我只覺得這嘴砲仔滿恐怖的，今天他會弄那個副理，難保哪天他不會用這種卑賤手段來弄我（因為他底下的人都跑光了，只能繼續騙一些剛畢業不懂事的新人進來壓榨＋操控）。連當時差不多同梯進來也是掛他底下的我同事，中途離職去附近公司，幾年後又回鍋，也不願意在組織圖上繼續掛牠底下（摳連...）。過了這麼多年，早期一些學長離職前跟我說過的話，真的都一一驗證屬實了。
幾年前這個事業部有一整群人跳去某家陸企，當年他們問我要不要過去時，我曾問當時的資深經理說：『你們怎麼沒找黃某一起去？』，那位經理跟我說：『沒有，我們不喜歡他做事的風格！』，現在回想起來覺得真他媽中肯，行事作風務實派的，大概沒幾個會喜歡那嘴砲仔的風格吧。
在那位副理離職的差不多時間，當時我們 team 有進來一位前四大學校畢業的新人，記得有次在上海出差時，妹子跑來跟我閒聊，偷偷問我說「誒～那個經理到底是在幹嘛的？」，我回說「喔，他就經理啊，負責安排工作的」，妹子說「我看他根本沒在做什麼事，感覺就是一個在旁邊打嘴炮的！聽其他人說，客人根本沒有在理他」，因為嘴砲仔在當時還是我上級，我還幫他平反了兩句。如果是現在喔，我大概會跟她說「對啊，Make sense！You are fuckin absolutely right！」。
可惜頂大妹也是人間清醒，太快跟那隻78賤狗翻臉，試用期一到就被弄走了。。。（後來聽說去了 TSMC）
從相簿裡滑到一張照片，覺得這張圖用來詮釋垃圾嘴砲仔的用人管理哲學超貼切。主題為『上吧～免洗筷奴隸們！幫我抬轎、背鍋，最後再被我出賣，全都是你們的榮幸啦！』
廢文抒發結束！雖說一個蘿蔔一個坑，但如果有人無意間看見這篇廢文覺得不高興，請不要見坑就亂入唷，因為本文純屬 ＡＩ創作嘲諷文，沒有意指任何人唷＾＾
下面是透過 RTSP＋WiFi SoftAP 串流架構，做720p雙向視訊會議的 Demo（對照組）
你看兩者的相似度484遠不止87分呢（但其實仔細比較還是分得出差別的）？不過這些東西終究都會變成電子垃圾，講白了也沒啥了不起的！我想起有句話是這麼說的：『你能複製技術，但你無法複製系統』、『你能買到一個人的操作手冊，但你無法買到他的運氣。而成功的背後，運氣可能是最前面的那個1，努力只是後面的無數個0』
至於耗電的測試結果，我有在實體眼鏡上測試過，以 H264硬體編碼＆WiFi＋RTSP 串流模式做 AI 多模態聊天，在我們的眼鏡上，10分鐘大約掉電13－17%不等，以H264硬體編碼＆藍芽串流模式做 AI多模態聊天，10分鐘後大約掉電6－10%不等，這結果足以說明：在測試環境和條件都相同的情況下，做同樣的傳輸工作，藍芽確實會比 WiFi 省電一些（以最小值10分鐘差3%電量差異來說，一小時電量就差了18%，而如果以保守值10分鐘差5%來說，一小時電量就差30%耶～使ㄍㄟˋ）。
現階段，透過藍芽或 WiFi 串流，在智能眼鏡跟手機之間還能搞出啥噱頭？嗯～像是把手機放口袋裡，然後透過智能眼鏡來執行像是 AI 多模態聊天、即時翻譯、Youtube 直播、視訊會議、以及 Google 和 Meta 都 show 過的戴著眼鏡導航等等這些算不上日常剛需的應用吧！又或者進階一點，像是透過智能眼鏡，結合手勢辨識，來控制智慧家電這類的進階應用場景，應該也不是做不到的事。
作為一名資深軟體從業人員，想起前陣子有新人同事問我：『你覺得 AI 能取代你嗎？』，我告訴他：『你要聽實話的話，我認為完全可以』，事實是，AI 不只可以取代我，還可以取代矽谷那些高薪碼農，更是幾乎能取代所有的白領工作，當然還能打臉那些靠信息差跟打嘴砲混飯吃的人，而這些已經是無庸置疑的事實！
舉個很簡單的例子，十幾年前我剛入職某 team，當時該事業部是在幫蘋果做產品，記得有一段時間去大陸產線出差時，學長姐同事經常在產線辦公室忙到清晨1～2點，我當年還是新人小菜雞，所以也不敢先下班，只能在辦公室像傻逼一樣跟那群人一起待到清晨。
後來我問當年那個嘴砲仔主管：『誒～那些人每天加班到清晨1～2點，到底是在忙什麼洨？是不用睡覺膩？』，嘴哥告訴我因為客人會頻繁變更測項內容，所以他們要配合修改 test plan，然後再跟測站軟體吃的那份檔案做 align。我告訴他：『三小？他們每天加班在處理文書編輯喔？』
後來我從嘴砲仔那邊了解這個工作流程的細節後，我跟我嘴砲仔提案說可以幫他們寫一個 Mac 系統上面的自動化轉換工具，讓他們從 CSV 文件中客人定義的測試規範內容，直接一鍵轉出測站軟體可以吃的檔案，就不用在那邊加班到清晨做這些87活了。最後也實際上做出來（當年寫這個工具好像也沒花多久，我記得弄出雛型並且跟幾個主要測站都串好，也就一兩週的時間），而且這個工具一直在內部被沿用到我們做那個穿戴產品的最末代時期。
如果是現在有 AI 編程的時代，只要把細節需求搞清楚，大概分分鐘就能生出一個一模一樣，甚至更強大更好用的工具了。那你覺得 AI 能不能取代白領呢？我也曾聽同事這樣跟我說：『我們討論後覺得，AI 發展到一定階段，會開始變得智障』，我聽了也不知道要說什麼。
那你們覺得全球那幫一線 AI 領域科研人員，還有矽谷那些頂尖 AI 公司裡的從業員，這群人是把 AI 當成玩具在愚弄全人類？還是真的把 AI 當成是會顛覆人類文明發展的一回事？
撇開老馬、老黃，他們是生意人，可以先不討論，可難道你覺得圖靈獎得主，AI 教父辛頓博士（Geoffrey Hinton），出來公開提倡 AI 的危險性，是在作秀刷存在感嗎？難道你認為辛頓博士的智商跟眼界會不如你們嗎？答案應該很明顯吧？好比如果有人在工業革命時代跟你說：『別傻了，工業發展最終會倒退，人類最終還是會回歸農業社會的～回鄉種田才是王道』，請問站在現代的你會做何感想？（笑）
我現在都是建議學弟別鑽研什麼 coding 了，因為 AI 已經讓它變成了廉價技能（我大概可以用20年的碼農人生對這個觀點負責吧），你應該要學習的是 AI 時代的工具，展現你對 AI 的理解和落地能力。以現在 AI 的發展趨勢看來，工作方式被重新定義是早晚會發生的事，問題從來不是海嘯會不會來，而是海嘯到來時，你有沒有站在高地上！
順帶一提，Google 在 4月初發佈了自家的
本地端模型 Gemma 4，其中一個主打的新功能是『
全能多模態理解（Native Multimodal）』， Gemma 4 不再需要掛載額外的視圖編碼器，它原生支持影像與影片，且原生支持語音辨識與即時翻譯，讓本地端語音交互成為可能。
Gemma 4 的出現宣告了「本地 AI」進入了智能體時代。它不再只是回答問題，而是具備了看、聽、思考並操作工具的能力，且這一切都可以在你的私有硬體上離線完成。
Gemma 4 採用了多樣化的架構來適應不同硬體：
- Effective 2B / 4B (E2B/E4B)：專為手機與 IoT 設備設計，極致輕量。
- 26B MoE (Mixture of Experts)：採用專家混合架構，在效能與速度間取得最佳平衡。
- 31B Dense：最強大的稠密模型，適合高性能工作站，處理複雜推理。
我迅速將 Gemma 4 E4B 模型整合到手機專案中，並且在 Pixel 手機上測試離線圖像推論，實測結果速度相當不錯，平均大概3～5秒可以給出推理結果（但是缺點也是有的）。
在手機上用 Gemma 4 模型做圖像推理，回覆速度大概就像這樣吧（個人覺得跟當年第一代 Gemini Flash 雲端多模態模型的回覆速度差不多吧）
以下是 AI 生成的廢文
在嵌入式系統開發的領域中，智慧眼鏡始終處於電池續航、散熱效率與無線頻寬這「技術三角」的極限拉鋸戰中。要在極度受限的硬體空間內實現即時影音串流，傳統基於 Wi-Fi (RTSP) 的方案雖具備頻寬優勢，卻因高功耗與長達 5 至 15 秒的連線握手時間（DHCP + RTSP Handshake），難以滿足穿戴式裝置「即開即用」的直覺體驗。
借鑒 Ray-Ban Meta 的技術轉向，業界正致力於將串流負載從 Wi-Fi 轉移至藍牙通道。然而，要在物理理論上限僅約 2-3 Mbps 的藍牙頻寬下，穩定輸送 720p 高清畫面，絕非簡單的協議更換。這是一場涉及傳輸層重構、記憶體零拷貝策略與壅塞控制演算法的深度優化革命。
核心技術堆疊：建構高效能傳輸基石
為了突破藍牙傳輸的「天花板」，我們必須捨棄通用的序列埠模擬（RFCOMM），轉向更底層、更高效的技術組合：
- 傳輸層：Bluetooth 5.3 + L2CAP CoC。要求 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 的音質。
底層革命：為什麼選擇 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，更大幅減輕了處理器負擔，為穿戴式設備爭取到寶貴的散熱空間。
Classic EDR 2M/3M vs LE 2M PHY + DLE
| Bluetooth Classic (BR/EDR) | Bluetooth LE |
基礎速率 | BR: 1 Mbps (GFSK) | 1M PHY: 1 Mbps (GFSK) |
增強速率 | EDR 2M: 2 Mbps (π/4-DQPSK) | 2M PHY: 2 Mbps (GFSK) |
更高速率 | EDR 3M: 3 Mbps (8DPSK) | ❌ 無 |
最大 PDU payload | 1021 bytes (3-DH5) | 251 bytes (DLE) |
所以正確的比較是：Classic EDR 2M/3M vs LE 2M PHY + DLE。
核心問題：A2DP 如何影響兩者？
A2DP 是一個 Bluetooth Classic Profile。這意味著：
┌─────────────────────────────────────────────────┐
│ 單一 2.4GHz BT Radio（硬體共用） │
├────────────────────┬────────────────────────────┤
│ Classic 模式 │ LE 模式 │
│ ├─ A2DP 音訊 │ ├─ LE L2CAP CoC 視訊 │
│ └─ (Classic 視訊) │ └─ GATT 控制通道 │
└────────────────────┴────────────────────────────┘
↑ 方案 A: 同模式 ↑ 方案 B: 跨模式
無需切換 需要 mode switching
關鍵差異：同一條 radio 上的排程效率
方案 A：Classic L2CAP CoC 視訊 + A2DP
Radio 時序（每 3.75ms 為一個 TX-RX slot pair）：
|A2DP|Video|Video|Video|A2DP|Video|Video|Video|A2DP|...
└──── 同為 Classic ACL，scheduler 無縫交錯 ────────┘
A2DP 與 Video 都是 Classic ACL 流量
BT controller 的 Classic scheduler 直接在 time slot 層級交錯
零 mode switching 開銷 — 兩者用同一組 radio 參數
Packet 可用 5-slot（3-DH5, EDR 3M），payload 高達 1021 bytes
Classic EDR 3M 吞吐量計算：
項目 | 值 |
5-slot TX-RX pair | 6 slots = 3750 μs |
3-DH5 payload | 1021 bytes |
理論最大 | 1021 / 3750μs × 8 = 2,178 kbps |
A2DP 佔用 (SBC 328kbps + overhead) | ~450 kbps |
視訊可用 | ~1,700 kbps |
Classic EDR 2M 吞吐量計算：
項目 | 值 |
2-DH5 payload | 679 bytes |
理論最大 | 679 / 3750μs × 8 = 1,449 kbps |
A2DP 佔用 | ~450 kbps |
視訊可用 | ~1,000 kbps |
實際場景 | 視訊可用頻寬 |
Classic EDR 3M + RFCOMM + A2DP | ~1,200 - 1,500 kbps |
Classic EDR 2M + RFCOMM + A2DP | ~750 - 900 kbps |
方案 B：LE L2CAP CoC 視訊 + A2DP（跨模式傳輸）
Radio 時序：
|◀ Classic ▶|◀── LE CI ──▶|◀ Classic ▶|◀── LE CI ──▶|
| A2DP pkts | LE L2CAP CoC| A2DP pkts | LE L2CAP CoC|
↑ ↑
mode switch mode switch
~150-300μs ~150-300μs
A2DP 在 Classic 模式，Video 在 LE 模式
Radio 必須在兩種模式間 反覆切換
每次 mode switch 損失 ~150-300μs
LE 的 Connection Interval（CI） 是固定窗口，不像 Classic 可以連續發送
A2DP 的 timing 需求可以 搶佔 LE connection event
LE 2M PHY + DLE 吞吐量計算：
項目 | 值 |
CI = 15ms, 每 CI ~9 封包 | 2,223 bytes/CI |
理論最大（無 A2DP） | ~1,186 kbps |
A2DP 搶佔 radio time (~25%) | -296 kbps |
Mode switching 開銷 (~5-8%) | -71 kbps |
視訊可用 | ~800 - 900 kbps |
直接對比
| Classic EDR 3M | Classic EDR 2M | LE 2M PHY + DLE |
Air data rate | 3 Mbps | 2 Mbps | 2 Mbps |
Max PDU payload | 1021 B | 679 B | 251 B |
傳輸模式 | 連續 slot | 連續 slot | CI 窗口 (15ms) |
A2DP 共存機制 | 同模式排程 | 同模式排程 | 跨模式切換 |
Mode switching 開銷 | 無 | 無 | ~5-8% |
視訊可用（+A2DP） | ~1,200-1,500 kbps | ~750-900 kbps | ~800-900 kbps |
720p HEVC 最大 FPS | 30+ fps | 20-24 fps | 20-24 fps |
結語：從技術重構看未來擴展
透過 L2CAP CoC 的底層重構與全鏈路的動態優化，我們成功在藍牙這個「窄頻通道」上完成了一次高清影音串流的極限壓榨。實測數據顯示，單幀傳輸延遲降低了 2-4 倍，且因系統呼叫次數大幅減少，顯著降低了眼鏡端的 CPU 負載與發熱量。
然而，工程師必須保持理性。面對未來 4K 或 8K 的串流需求，2-3 Mbps 的藍牙頻寬已達物理天花板。屆時，技術路線勢必回歸 Wi-Fi Direct 或採用極低幀率的「快照模式」。但本次 L2CAP 重構所建立的零拷貝與 anti-bufferbloat 經驗，已為穿戴式裝置在功耗與效能間的平衡，樹立了堅實的架構基準。
