唸出地震預測震度

[bestpika]

🌟想法補充

• 補充說明: 希望可以在警示音播放前唸出地震預測震度

此檔案由 ExpTech.tw 設計製作

[archie0732]

我預計實作這個功能，初步規格與方向如下，歡迎確認是否符合原本需求。

功能範圍

本功能只在以下條件成立時啟用：

• App 位於前景。
• 使用者正在地圖頁的「強震監視器」圖層。
• EEW 即時資料狀態為 live。

App 位於背景、鎖屏或未啟動時不執行 TTS，維持目前的推播通知與警示音行為。

預計行為

收到 EEW 時，使用裝置目前位置與既有 EEW 估算公式計算所在地預估震度，並以類似地牛 Wake Up 的短句播報：

所在地預估震度，四級。
所在地預估震度，五弱。

朗讀完成後才播放原本的警示音。

同一個 EEW 有新報次時：

• 立即中斷正在朗讀的舊報次。
• 改為朗讀最新報次的所在地預估震度。
• 相同 id + serial 的重複資料不重複朗讀。
• 舊報次延遲回傳的完成事件不得播放警示音。
• 只有當下最新報次朗讀完成後才能播放警示音。

離開強震監視器、App 進入背景，或 EEW feed 變成 stale/offline 時，會立即停止朗讀。

如果無法取得所在地，預計退回播報「最大預估震度」；如果 TTS 初始化、語系或朗讀失敗，則略過語音並立即播放警示音，避免延誤警示。

技術方向

• 建立獨立的播報 controller，負責報次去重、中斷、生命週期及警示音順序。
• 建立 SpeechService abstraction：
  • Android 使用系統 TextToSpeech。
  • iOS 使用系統 AVSpeechSynthesizer。
• 使用既有的 estimateLocalShaking() 計算所在地預估震度，不另外實作第二套震度公式。
• 監視器畫面只提供可見狀態與即時 EEW 資料，不直接在 Widget 中管理 TTS。
• 協調前景 EEW 通知，避免通知警示音與 TTS 同時播放或順序相反。
• 所有播報文案走現有 l10n；5弱／5強／6弱／6強 會轉成適合 TTS 的文字，不直接朗讀 5⁻／5⁺ 等符號。

預計測試

• 第一報正常朗讀並在完成後播放警示音。
• 朗讀途中收到新報，舊報立即停止並改讀最新報。
• 重複及亂序報次不重複朗讀。
• 舊報的 completion callback 不會誤播警示音。
• 離開監視器或 App 進入背景時停止朗讀。
• stale/offline 資料不朗讀。
• GPS 或 TTS 不可用時能正確 fallback。
• Android 與 iOS 實機驗證。

[whes1015]

我預計實作這個功能，初步規格與方向如下，歡迎確認是否符合原本需求。

功能範圍

本功能只在以下條件成立時啟用：

* App 位於前景。

* 使用者正在地圖頁的「強震監視器」圖層。

* EEW 即時資料狀態為 live。

App 位於背景、鎖屏或未啟動時不執行 TTS，維持目前的推播通知與警示音行為。

預計行為

收到 EEW 時，使用裝置目前位置與既有 EEW 估算公式計算所在地預估震度，並以類似地牛 Wake Up 的短句播報：

所在地預估震度，四級。
所在地預估震度，五弱。

朗讀完成後才播放原本的警示音。

同一個 EEW 有新報次時：

* 立即中斷正在朗讀的舊報次。

* 改為朗讀最新報次的所在地預估震度。

* 相同 `id + serial` 的重複資料不重複朗讀。

* 舊報次延遲回傳的完成事件不得播放警示音。

* 只有當下最新報次朗讀完成後才能播放警示音。

離開強震監視器、App 進入背景，或 EEW feed 變成 stale/offline 時，會立即停止朗讀。

如果無法取得所在地，預計退回播報「最大預估震度」；如果 TTS 初始化、語系或朗讀失敗，則略過語音並立即播放警示音，避免延誤警示。

技術方向

* 建立獨立的播報 controller，負責報次去重、中斷、生命週期及警示音順序。

* 建立 `SpeechService` abstraction：
  
  * Android 使用系統 `TextToSpeech`。
  * iOS 使用系統 `AVSpeechSynthesizer`。

* 使用既有的 `estimateLocalShaking()` 計算所在地預估震度，不另外實作第二套震度公式。

* 監視器畫面只提供可見狀態與即時 EEW 資料，不直接在 Widget 中管理 TTS。

* 協調前景 EEW 通知，避免通知警示音與 TTS 同時播放或順序相反。

* 所有播報文案走現有 l10n；`5弱／5強／6弱／6強` 會轉成適合 TTS 的文字，不直接朗讀 `5⁻／5⁺` 等符號。

預計測試

* 第一報正常朗讀並在完成後播放警示音。

* 朗讀途中收到新報，舊報立即停止並改讀最新報。

* 重複及亂序報次不重複朗讀。

* 舊報的 completion callback 不會誤播警示音。

* 離開監視器或 App 進入背景時停止朗讀。

* stale/offline 資料不朗讀。

* GPS 或 TTS 不可用時能正確 fallback。

* Android 與 iOS 實機驗證。

這是要在 Client Side 實做 TTS 嗎？這個功能我是有規劃想在 Server Side 做，但可以評估看看。

[archie0732]

是的，目前這版是 Client-side TTS，使用 Android TextToSpeech／iOS AVSpeechSynthesizer，但範圍刻意限定在 App 前景且使用者正在強震監視器時；背景、鎖屏或 App 未啟動時仍維持現有的 Server push 與通知警示音。

目前採 Client-side 的主要考量是，「所在地預估震度」本來就是 Client 使用裝置最近位置與既有 estimateLocalShaking() 即時計算。直接交給系統 TTS，可以跟著最新報次立即更新及中斷舊播報，也不需要等待個別音檔產生或下載。

不過 Client-side 確實有裝置語音、啟動延遲及語音可用性不一致的缺點；Server-side 則比較容易統一聲音與播報內容。因此我會先把 PR 開成 Draft，讓這兩個方向一起評估，不會先把它當成最終架構。

另外想確認一下，原本規劃的 Server-side 方案是：

1. Server 產生完整音檔或音檔 URL，再由 Client 播放；還是
2. Server 決定播報文字／預估震度，再由 Client 執行 TTS？

兩者對報次更新、所在地估算、離線 fallback 與背景播放限制的影響會不太一樣。如果專案希望統一採 Server-side，我也可以依評估結果在 merge 前調整。

[whes1015]

是的，目前這版是 Client-side TTS，使用 Android TextToSpeech／iOS AVSpeechSynthesizer，但範圍刻意限定在 App 前景且使用者正在強震監視器時；背景、鎖屏或 App 未啟動時仍維持現有的 Server push 與通知警示音。

目前採 Client-side 的主要考量是，「所在地預估震度」本來就是 Client 使用裝置最近位置與既有 estimateLocalShaking() 即時計算。直接交給系統 TTS，可以跟著最新報次立即更新及中斷舊播報，也不需要等待個別音檔產生或下載。

不過 Client-side 確實有裝置語音、啟動延遲及語音可用性不一致的缺點；Server-side 則比較容易統一聲音與播報內容。因此我會先把 PR 開成 Draft，讓這兩個方向一起評估，不會先把它當成最終架構。

另外想確認一下，原本規劃的 Server-side 方案是：

1. Server 產生完整音檔或音檔 URL，再由 Client 播放；還是

2. Server 決定播報文字／預估震度，再由 Client 執行 TTS？

兩者對報次更新、所在地估算、離線 fallback 與背景播放限制的影響會不太一樣。如果專案希望統一採 Server-side，我也可以依評估結果在 merge 前調整。

原本是規劃 Server 產生完整音檔 URL，但想了一下，唸出所在地震度之類取決於用戶當下狀態的內容，確實是 Client Side 比較好，原本的 Server Side 也是規劃給地震報告等...不同用戶統一內容的，所以這件事跟 Server Side 不衝突，可以繼續推進。

[archie0732]

fork 那邊處理好了，這個 PR 也已經改過來。

flutter_tts

ExpTechTW/flutter_tts#1 已合併。內容是移植上游 dlutton/flutter_tts#651（作者 @shivanshu877），用 cherry-pick 保留原作者署名，13 檔案 +62 −26，與該 PR 一字不差。

這個 PR 改了什麼

• 拿掉先前那則 refactor(eew): speak through an app-owned channel —— SpeechPlugin.swift、SpeechChannel.kt 連同兩邊的註冊與 project.pbxproj 的條目全部移除
• pubspec.yaml 改為 git 相依，釘在 fork master 上的合併 commit a9cd6eda
• 「為什麼用 fork」寫在 pubspec.yaml 的註解裡，比照 maplibre_gl 的做法
• 相依的改動併進 feat(eew) 那一則，而不是另開一則 —— 這樣每個 commit 都是自洽的，不會出現「功能在但 iOS 建不起來」的中間狀態
• 補上 ci(android) 那則原本空白的說明
• 已 rebase 到最新的 main

另外你提的語音開關也做好了：「更多 → 通知」多一列，預設開，整列都可以點。關掉時會停掉正在播報的語音並釋放閘門扣住的通知，所以關開關永遠不會延後警報，最壞情況是警報比平常早響。它在 SpeechService 介面之上，底層換成 fork 完全不影響。

現在共 4 則 commit。

需要有人按一下 Approve and run workflows

三個 workflow 都卡在 action_required。

這一輪跟前幾輪不一樣：iOS job 會第一次真的去 clone fork、用 Swift Package Manager 建置。那兩個 Package.swift 到目前為止沒有被任何編譯器看過 —— 我沒有 macOS，只做得到靜態檢查（pluginClass 對得上 Swift 類別、package/product/target 命名與官方 plugin 一致、Sources 底下確實有檔案、plugin 的 iOS 12.0 低於本專案的 15.0）。

所以這輪 CI 就是那份 SPM 改動唯一的實際驗證。如果 iOS 紅了，我會回 fork 修，這邊重新釘 sha。

本機驗過的

• dart analyze lib test：無問題
• tool/check/commits.sh upstream/main..HEAD：4 commits 通過
• layering / storage / l10n / notification_sounds gate 全過
• 測試：test/tool/* 以外全數通過（那 55 個是 Windows Git Bash 的路徑問題，另有一個 semantics_overlay_portal_test 未修改本檔且在 CI 上為綠）
• Android 實機：聽得到朗讀、講完才響、離開就停、快速切換分頁十次不閃退

iOS 的執行期行為（語音真的出得來、audio session 不會蓋掉別的 app）仍然沒人驗過，需要有裝置的人幫忙看一下。