我把即時歌詞搬到眼前：EvenLyrics 從散步聽歌痛點到 Even G2 智慧眼鏡 HUD 實機同步

我原本以為，這只是一個很單純的週末小工具。

平時傍晚推著嬰兒車出門散步、或者戴著耳機輕快慢跑時，耳際流淌著音樂是我一天中最放鬆的片刻。有時候隨機播放跳出一首旋律極美但記不全歌詞的老歌，或者某一句詞剛好重重撞進心坎裡，心裡總會浮起一股強烈的衝動：「剛才那一句到底唱了什麼？」

但現實生活中的操作卻充滿了摩擦力：掏出手機、指紋解鎖、點開音樂 App、再切換到動態歌詞頁面。這短短幾秒的動作，不僅瞬間打斷了散步的節奏，在室外強光下低頭盯著刺眼的手機螢幕，更讓好不容易建立起來的沉浸感蕩然無存。

如果這時候，我鼻樑上戴著的 Even G2 智慧眼鏡，能像戰鬥機的抬頭顯示器（HUD）一樣——在眼角餘光不干擾前方視野的微光綠字中，安靜浮現正在唱的這一句歌詞，並預覽接下來的下半句，完全不需要低頭，那該有多好？

從這個生活中的真實渴望出發，我和 AI 展開了一段長達數週的結對開發。從最初撞上麥克風收音的效能死胡同，到轉向 Android 系統級媒體廣播，再到親手解決簡體中文被吐槽、現場版搶詞與 G2 韌體渲染崩潰，這篇文章完整記錄了 EvenLyrics 如何從一個生活痛點，蛻變為一副抬頭即見的個人音樂 HUD。

先看目的、成果與證據邊界

這三格是我每次寫個人應用開發時最重要的分界：想解決什麼日常摩擦、實際驗證了什麼工程細節，以及誠實交代目前受限於硬體與系統的邊界。

Even G2 穿戴使用體驗：漂浮在真實視野邊緣的微光歌詞

戴著 Even G2 智慧眼鏡聽歌，到底是什麼樣的感受？

首先是光學顯示的克制感。Even G2 採用單色高對比 Micro-OLED 投影，預設呈現標誌性的極簡綠色光（#00FF66）。這塊虛擬顯示區域並不是大剌剌地擋在視線正中央，而是浮現在視野的自然邊緣。走在人行道上，前方的街景、迎面走來的行人與夕陽餘暉完全清晰可見，但只要眼角餘光微微一瞥，歌詞就安靜地漂浮在空氣中。

為了讓動態歌詞在眼鏡上「好讀卻不搶戲」，我們在 UI 排版上經歷了多輪簡化：

1. 雙行層次閱讀：第一行是大字高亮的「當前正在唱的歌詞」，第二行則是微光淡綠的「下一句預覽」。這種設計讓大腦在跟著旋律走時，既能精準捕捉當前字句，又能對下一段節奏有心理預期。
2. 曲目與時間軸待機頁：在歌曲前奏、間奏或尚未載入歌詞時，HUD 會自動切換為緊湊型曲目卡片，清晰標註歌名、演唱者與播放進度條，絕不在眼角留下無意義的空白或錯誤代碼。
3. 符合人體工學的雙擊手勢退出：跑步或雙手拎著東西時，最怕誤觸手勢被困在 App 裡。EvenLyrics 嚴格遵循官方人機規範，雙擊（Double Tap）鏡腿時會呼叫底層對話框 bridge.shutDownPageContainer(1)，彈出系統級退出確認，操作俐落且不誤觸。

散步時微風吹過，耳機裡音樂輕輕流轉，眼前虛擬微光無聲翻動著字句——那種雙手完全自由、不需要任何手機螢幕亮起的科技浪漫，是只有穿戴式運算才能給予的純粹體驗。

第一個死胡同：為什麼不能用手機麥克風即時辨識？

然而，在抵達這個優雅的體驗之前，我的第一個技術方案差點讓整個專案夭折。

剛開始我和 AI 討論時，最直覺的想法是：「既然市面上有 Shazam、SoundHound 甚至各家音樂軟體的聽歌辨識，那我們讓手機 App 在背景開啟麥克風，實時收音並辨識歌曲不就好了嗎？」

這個方案聽起來很直覺，不需要綁定任何特定播放器，理論上連路過超商放的音樂都能顯示歌詞。但當我們用 Python 寫出原型並上機實測後，現實給了我們一記重重的耳光：

• 戶外風切聲與環境雜音是辨識殺手：在安靜的書房裡測試都很完美，但一走到戶外，散步時耳機漏音本來就小，加上迎面而來的風聲、腳步聲與馬路車流，麥克風收到的音訊特徵嚴重失真，辨識失敗率飆高到 60% 以上。
• 致命的運算延遲（Latency）：聽歌辨識必須先錄音 2～3 秒切片、進行傅立葉轉換提取音訊指紋、再發送 HTTP 請求向雲端比對。整套流程走完，最快也要 3 到 5 秒。當眼鏡跳出歌詞時，歌手早就唱到下一小節了，歌詞根本對不上拍子。
• 手機發燙與電量大雪崩：持續霸佔麥克風硬體進行音訊取樣與 DSP 運算，手機放在口袋裡不到半小時就開始明顯發熱，電量更以每小時 15% 的速度急速下滑。

那一刻我深刻意識到：在穿戴運算的生活開發中，永遠不要為了「猜測答案」而浪費運算資源，尤其是當手機作業系統本身明明早就知道答案的時候。

轉向破局：Android MediaSession 系統廣播才是優雅解法

痛定思痛後，我們徹底推翻了麥克風辨識路線，將思考維度轉向 Android 作業系統底層。

在現代智慧型手機上，無論你使用的是 Spotify、KKBOX、YouTube Music 還是 Apple Music，只要音樂在播放，它們都會向系統的 MediaSessionManager 註冊播放狀態，並透過 NotificationListenerService 發送即時播放事件。

這意味著什麼？系統每一毫秒都清清楚楚知道：現在播放的曲名是什麼、歌手是誰、這首歌總長度幾毫秒、以及當前播放進度精確落在第幾秒。

手機音樂 App（Spotify / KKBOX / YouTube Music / Apple Music）
  ↓ （系統標準 MediaSession 事件）
EvenLyrics Android Companion（背景常駐伴侶服務）
  ↓ （本地快取與動態 LRC 毫秒級對齊）
EvenLyrics EvenHub Plugin（手機端 Even App 容器）
  ↓ （藍牙低功耗 BLE 封包）
Even G2 智慧眼鏡（Micro-OLED 單色抬頭顯示）

轉向這套架構後，困擾我們的三個致命問題瞬間迎刃而解：

1. 零麥克風干擾、百分之百精確：不再需要錄音權限，直接從系統獲取乾淨無誤的 Metadata，完全不怕戶外風切聲。
2. 毫秒級時間軸無縫對齊：MediaSession 直接提供時間戳（Timestamp）與播放速率，即使你在耳機上點擊快轉 10 秒或暫停，眼鏡上的歌詞都能以毫秒級精度瞬間重定位。
3. 近乎零耗電的背景常駐：Android Companion 伴侶服務完全處於被動事件驅動（Event-driven）模式，不佔用額外 CPU，即使連續散步聽歌兩小時，手機電量消耗也微乎其微。

繁體中文化與版本防呆：解決簡體中文被吐槽與現場版搶詞

架構通順了，但在實際戴上眼鏡走進日常生活的幾天裡，細節上的魔鬼又浮現了出來。

1. 簡體中文歌詞體驗：OpenCC 3,880 字全管線在地化

接上公共動態歌詞（LRC）資料庫後，我發現許多經典華語歌曲回傳的字串都是簡體中文。例如「听这首歌」、「我们都爱过」。

在手機大螢幕上看簡體字或許還能忍受，但在 Even G2 這種微型單色綠色 Micro-OLED 點陣顯示上，簡體字的字形筆畫顯得格外突兀，也與台灣使用者的閱讀習慣背道而馳。

為了徹底解決這個問題，我們在 Android Companion 伴侶服務中建置了 OpenCC 全管線簡繁轉換模組。我們精選了 3,880 個日常高頻簡繁映射字元，在歌詞抓取回本地快取的第一時間進行全量清洗與繁體化。所有推送到眼鏡鏡片上的字句，全都是乾淨俐落、排版舒適的正體中文。

2. 現場版與翻唱版搶詞：歌曲時長比對權重演算法

另一個惱人的問題是同名歌曲的「版本衝突」。

例如五月天的《溫柔》，在串流平台上有錄音室版、諾亞方舟 Live 版、重新混音版；周杰倫的歌更有無數其他歌手的翻唱版本。如果僅憑歌名與歌手去搜尋歌詞，常常會抓到長度完全不同的版本。最尷尬的情況就是：耳機裡的吉他前奏才放了 10 秒，眼鏡上的歌詞卻已經唱到了第一段主歌。

我們設計了一套歌曲時長（Duration）毫秒級比對與標籤懲罰權重演算法：

• 嚴格時長容忍度：比對音訊總長度，差異在 3 秒以內獲得高權重加分；超過 8 秒大幅扣分；超過 15 秒直接視為不同曲目並剔除。
• 標籤懲罰機制：檢測標題與版本註記，若串流播放的是原版，而候選歌詞帶有 [Live]、[現場]、[Remix] 等標籤，自動施加扣分懲罰。

透過這套演算法，動態歌詞的命中準確率從早期的 72% 飆升至 98% 以上，再也不會出現「歌在唱主歌，眼鏡在跑副歌」的荒謬景象。

G2 韌體防禦：單一原生文字容器與雙擊退出合規

在軟體端邏輯全部理順後，最後的大魔王卻出現在 Even G2 眼鏡的硬體與韌體層面。

單一文字容器原則（containerTotalNum: 1）

在早期版本中，我們很自然地想把畫面模組化：歌名是一個文字容器、播放時間是一個容器、當前歌詞與下一句歌詞又是各自獨立的容器。

結果，在眼鏡實機連線測試不到 5 分鐘，眼鏡螢幕就突然黑屏、甚至 Even OS 藍牙連線直接重置。翻查 Even 官方 SDK 規範與錯誤日誌後，我們才發現：G2 鏡片光學引擎的顯存與渲染管線非常緊湊，頻繁更新多個重疊的原生容器會引發韌體記憶體壓力（Container Fault）。

為此，我們重構了渲染核心，嚴格貫徹官方的「單一原生文字容器」哲學：

• 將 containerTotalNum 強制鎖定為 1；
• 在手機 Plugin 端將標題、進度、當前行與預覽行，精確拼接成單一格式化的多行字串緩衝區；
• 每次歌詞時間軸推進時，只對眼鏡推送一次單一文字更新封包。

重構之後，不僅藍牙傳輸封包量減少了 60%，而且即使連續聽歌 2 小時，眼鏡的 Micro-OLED 依然流暢如初，徹底擺脫了崩潰重啟的噩夢。

雙擊退出對話框合規

在準備上架 EvenHub 官方商店時，官方審核規範明確指出：全螢幕文字應用不可隨意攔截使用者的基礎操作，且必須實作雙擊手勢退出對話框。

我們在手勢處理器中精確對齊了 bridge.shutDownPageContainer(1)，當使用者在右側鏡腿進行 Double Tap 時，系統會主動彈出原生確認對話框，輕點即可退出回主選單。這個細節雖然微小，卻是讓一件個人小工具邁向符合官方商店規格的成熟產品之關鍵一步。

成果、限制與開放邊界：為什麼目前是 Android 獨佔？

回顧整個開發歷程，EvenLyrics 目前已達成的重要里程碑如下：

1. 工程品質：本地測試矩陣包含 27 個測試檔案、137 項單元測試 100% 通過。
2. 實機驗證：已在真實的 Even G2 智慧眼鏡搭配 Android 旗艦手機上，完成涵蓋 Spotify、KKBOX 等多主流串流平台之連續多曲完整驗收。
3. 上架就緒：已編譯產出合規的 evenlyrics-0.2.7.ehpk 套件與 evenlyrics-companion-1.0.1.apk 伴侶服務，目前正提交至 EvenHub 官方商店審查中。

在此，我也必須坦白地向所有讀者交代本專案的技術邊界：為什麼 EvenLyrics 目前只能在 Android 手機上使用，而無法支援 iPhone？

這並不是我們偏心，而是源自 iOS 封閉沙盒架構的硬性限制。蘋果基於隱私保護考量，嚴格禁止任何第三方 App 在背景監聽全域 MPNowPlayingInfoCenter 的媒體播放事件。在 iPhone 上，除非你是該音樂 App 本身，否則任何背景服務都無法拿到 Spotify 當前播放的歌曲名稱與毫秒級進度。

而 Android 的開放生態，則提供了標準且安全的 NotificationListenerService 與 MediaSessionManager 介面，讓伴侶服務能在極低功耗下優雅運作。這也是為什麼在穿戴運算的客製化整合上，Android 至今依然是極客與自造者最自由的試驗場。

生活中的痛點往往很微小，但把它們一個個抓出來、用工程的方法優雅解決，正是自己動手開發最迷人的地方。當傍晚的晚風再次吹起，我戴著眼鏡走在路上，耳邊是喜歡的旋律，眼前是安靜浮現的繁體歌詞——我知道，這一切的調校與折騰，全都值得了。