Google導航BLoC初探與地雷，SDK啟動那一瞬間
把 Google 的 Navigation SDK 結合到 Flutter 裡這事，唉，其實我一開始還以為不就把地圖搬進來而已嘛——結果完全不是這麼回事。你要做的不只是讓地圖顯示出來，那些瑣碎細節多得嚇人，像什麼權限檢查、位置追蹤，即時更新也不能漏掉。欸，有時候腦袋突然想到還有原生事件、導航點動態產生這種麻煩事，一下子亂七八糟的，好像桌上那堆沒收拾的電線，纏在一起拔都拔不開。啊對，我是不是又扯遠了？反正重點是流程跟底層 SDK 溝通起來很容易整個失控。
然後再說吧，很多人會直接把那些管理邏輯塞進 UI 層，看久了程式碼真的頭痛欲裂——就像早上剛煮完還沒吃的麵線，亂成一坨。BLoC，也就是 Business Logic Component，其實某些場景下真的能減輕一點壓力啦。嗯，它等於是弄個小空間，把複雜度集中丟進去，你只需要用事件控制它，不用每次都管 UI 細節，所以畫面乾淨不少。有時候想想，如果當初早點學這套路應該少掉不少白頭髮。
不過講真的，要拆解出一套「生產環境等級」的 NavigationBloc，大約流程會拉很長：先定義幾種狀態，再處理權限問題，到最後才輪得到導航指引那些東西。有經驗的人大概懂吧？即時更新、路徑費用計算，這些鬼東西在實作時常常因為各種訊號延遲或 SDK 設計差異，花掉快一半時間測試調參。不知道為啥，每次碰新專案順序都要微調一次，上回優先搞權限，這回卻得先整理事件流——怎麼每次都不太一樣？唉，好像永遠湊不到完全順手的一版。
總之啦，只要別妄想一次全包齊搞定，一步一步照 BLoC 慢慢分拆，大多數情境下還算堪用。我不是說百分百穩啦，但對怕維護崩潰的人而言，比起硬塞 UI 至少省力不少。有時候累到發呆，也只能安慰自己：「至少沒有更亂嘛。」
然後再說吧，很多人會直接把那些管理邏輯塞進 UI 層，看久了程式碼真的頭痛欲裂——就像早上剛煮完還沒吃的麵線，亂成一坨。BLoC，也就是 Business Logic Component，其實某些場景下真的能減輕一點壓力啦。嗯，它等於是弄個小空間，把複雜度集中丟進去，你只需要用事件控制它，不用每次都管 UI 細節，所以畫面乾淨不少。有時候想想，如果當初早點學這套路應該少掉不少白頭髮。
不過講真的，要拆解出一套「生產環境等級」的 NavigationBloc，大約流程會拉很長：先定義幾種狀態，再處理權限問題，到最後才輪得到導航指引那些東西。有經驗的人大概懂吧？即時更新、路徑費用計算，這些鬼東西在實作時常常因為各種訊號延遲或 SDK 設計差異，花掉快一半時間測試調參。不知道為啥，每次碰新專案順序都要微調一次，上回優先搞權限，這回卻得先整理事件流——怎麼每次都不太一樣？唉，好像永遠湊不到完全順手的一版。
總之啦，只要別妄想一次全包齊搞定，一步一步照 BLoC 慢慢分拆，大多數情境下還算堪用。我不是說百分百穩啦，但對怕維護崩潰的人而言，比起硬塞 UI 至少省力不少。有時候累到發呆，也只能安慰自己：「至少沒有更亂嘛。」
狀態與事件怎麼玩？型別安全的奇怪重要性
從頭開始，嗯……其實流程沒多難懂啦。就是先把狀態跟事件這些東西弄出來，然後初始化 SDK、設路線、啟動導航，最後還得考慮到抵達目的地要幹嘛。講起來條理分明，可一想到成本問題就有點心煩——唉，有時候真正讓人措手不及的其實是預算超標這種鳥事。明明以為都規劃好了，結果哪天突然跳出個額外費用，心情真的會差。不過也只能聊聊怎麼控管吧，不然總不能一直寄望運氣好。
欸，有點離題了，再拉回來。BLoC 在整個導覽流程裡面，其實很像一根神經線，把各種零碎環節串在一起。流程不特別複雜，大致意思就是：UI 那邊冒出個「我要初始化地圖」或「準備開啟導航」之類的想法（對，就是事件），然後 BLoC 接收到後就去敲 SDK 問一下現在怎樣，再算一算目前狀態，最後再把新狀態包好丟回 UI（像是「載入中」、「路徑準備好了」，偶爾才會掉出個錯誤）。UI 一發現狀態變了，就又跟著重畫一遍畫面。話說有時候看到那些重繪動畫，我都會懷疑是不是自己搞太複雜了。
其實事件和狀態這兩個東西，一般人第一次看大概記不住全部吧。我自己也老是忘，到底誰負責什麼……簡單說啦，「事件」就只是你想做什麼的描述物件，很純粹，沒什麼贅詞。「狀態」則比較安靜，只是忠實反映目前畫面該有的樣子，比如空白、執行中還是卡住那種感覺。有時候我會搞混，到底現在是在處理誰，但多寫幾次應該就順手了？
至於 BLoC 的角色……嗯，它真的不是什麼魔法師，更不像天才指揮家。它頂多像協調員，把 UI 丟進來的訊息和內部計算黏合起來，有點大家輪流傳話那味道而已。有趣的是細節常常被忽略掉——尤其專案初期啊，各種定義都模糊不清，比方說事件到底該長怎樣、狀態又該包哪些資料，每每討論到天昏地暗才慢慢摸索出個頭緒。結果等終於決定好，又突然有人問：「欸，那如果遇到例外呢？」唉，只能繼續補補縫縫補補，就是這樣吧。
欸，有點離題了，再拉回來。BLoC 在整個導覽流程裡面，其實很像一根神經線，把各種零碎環節串在一起。流程不特別複雜，大致意思就是：UI 那邊冒出個「我要初始化地圖」或「準備開啟導航」之類的想法（對，就是事件），然後 BLoC 接收到後就去敲 SDK 問一下現在怎樣，再算一算目前狀態，最後再把新狀態包好丟回 UI（像是「載入中」、「路徑準備好了」，偶爾才會掉出個錯誤）。UI 一發現狀態變了，就又跟著重畫一遍畫面。話說有時候看到那些重繪動畫，我都會懷疑是不是自己搞太複雜了。
其實事件和狀態這兩個東西，一般人第一次看大概記不住全部吧。我自己也老是忘，到底誰負責什麼……簡單說啦，「事件」就只是你想做什麼的描述物件，很純粹，沒什麼贅詞。「狀態」則比較安靜，只是忠實反映目前畫面該有的樣子，比如空白、執行中還是卡住那種感覺。有時候我會搞混，到底現在是在處理誰，但多寫幾次應該就順手了？
至於 BLoC 的角色……嗯，它真的不是什麼魔法師，更不像天才指揮家。它頂多像協調員，把 UI 丟進來的訊息和內部計算黏合起來，有點大家輪流傳話那味道而已。有趣的是細節常常被忽略掉——尤其專案初期啊，各種定義都模糊不清，比方說事件到底該長怎樣、狀態又該包哪些資料，每每討論到天昏地暗才慢慢摸索出個頭緒。結果等終於決定好，又突然有人問：「欸，那如果遇到例外呢？」唉，只能繼續補補縫縫補補，就是這樣吧。
Comparison Table:
| 主題 | 內容 |
|---|---|
| SDK 初始化時機 | 建議在用戶決定開啟導航時再進行初始化，以控制資源成本。 |
| 遠端控制功能 | 使用 Firebase Remote Config 來管理功能開關，確保即時回應運營需求。 |
| 清理資源的重要性 | 在 BLoC 的 close() 中呼叫 cleanup() 以釋放原生端資源，避免記憶體問題。 |
| 預算警示設定 | 在 Google Cloud Console 設定預算警示，以監控開銷並防止意外超支。 |
| 狀態事件管理 | 透過 BLoC 模式將 SDK 回調轉換為應用內可辨識的事件，簡化流程與錯誤處理。 |
初始化迷宮：權限、條款與失敗的多重試煉
一開始要讓路線顯示在畫面上，唉，事情其實比想像中還彎繞。這不是那種「喀」一下按鍵就等結果掉下來的直球過程，而是有點像爬樓梯——每一階都可能卡住，然後忽然又有人回頭問一句「現在好了嗎？」欸，我每次聽到這句話都愣神三秒，明明剛剛才說完流程…啊算了，拉回正題。
流程裡頭，有些環節其實挺依賴用戶自己操作，嗯，就是說順不順利真的難講，有時候七八成能順利跑完，但也常常莫名其妙哪裡就斷掉。天知道是哪根筋不對勁，有時連我也會懷疑是不是漏看什麼細節。呃，好吧。
_onInitializeNavigation 這段程式碼，大致就是負責把所有初始步驟串起來。有點像領隊帶著大家慢慢走，不會直接把所有任務一次丟出去——總得確保眼前的小目標達成才敢往下。說真的，如果中間哪個環節出狀況，好像反而比較容易定位是哪一步沒搞定。我記得有次小錯誤拖了快半小時，其實只是個不起眼的細節，但全局就被攪亂了。所以這樣設計，大概對排查問題還是有點幫助。
整體感覺不是穩穩地自動化流程，比較像邊走邊修、邊問進度那種狀態。如果用戶配合得好，也許流程可以很順暢；但現實裡嘛，總有三四成時間需要人臨場調整、插手救火。唉，每次遇到這種情況，都忍不住想問：到底什麼時候才能完全不用人盯著呢？
流程裡頭，有些環節其實挺依賴用戶自己操作，嗯，就是說順不順利真的難講，有時候七八成能順利跑完，但也常常莫名其妙哪裡就斷掉。天知道是哪根筋不對勁，有時連我也會懷疑是不是漏看什麼細節。呃，好吧。
_onInitializeNavigation 這段程式碼，大致就是負責把所有初始步驟串起來。有點像領隊帶著大家慢慢走，不會直接把所有任務一次丟出去——總得確保眼前的小目標達成才敢往下。說真的，如果中間哪個環節出狀況，好像反而比較容易定位是哪一步沒搞定。我記得有次小錯誤拖了快半小時，其實只是個不起眼的細節，但全局就被攪亂了。所以這樣設計，大概對排查問題還是有點幫助。
整體感覺不是穩穩地自動化流程，比較像邊走邊修、邊問進度那種狀態。如果用戶配合得好，也許流程可以很順暢；但現實裡嘛，總有三四成時間需要人臨場調整、插手救火。唉，每次遇到這種情況，都忍不住想問：到底什麼時候才能完全不用人盯著呢？
路線設定其實不簡單，同點座標為什麼爆炸
一開始進來這個流程，欸，畫面就會先跳出那種「正在載入」的提示，你懂吧？有時候我還沒反應過來，就已經在等了。嗯，像是平常開導航APP前面都要同意一些規則條款，不然按什麼都不給你繼續。其實也不是每次都很耐心去看啦，誰真的會細讀那些東西？但總之如果沒按同意，就整個卡住，只能乾瞪眼。
然後嘛，大部分狀況下還得處理定位權限那種彈窗。不知道為什麼，每次看到這些要求授權的提醒，我心裡都會想：到底給多少權限才夠？唉，有點煩。有時候沒給夠，它直接就擋著不讓走下一步——很多APP都有這毛病。我記得上次試某個新版本，就是卡在定位那邊，一直轉圈。
再說回流程本身，其實正式啟動地圖導航SDK之前，好像還有不少小檢查要過關。有些檢查藏得挺隱晦的，不太容易一下子發現是哪裡出問題。我自己用的時候，有幾次就是因為某個細節沒弄好（可能是什麼設定選項之類），結果一直被擋著不能初始化。嗯，但只要全都順利搞定，那SDK初始化差不多就算大功告成吧。朋友跟我講過，他說等畫面顯示準備完成，再接著設定目的地跟路線——這聽起來簡單，可是偶爾又會冒出莫名其妙的小插曲。
哦對了，有件事情我以前完全沒想到。就是當使用者輸入路徑的時候，如果有幾個停靠點位置完全重複——欸，竟然很容易讓底層導航引擎整個出錯！這種bug，其實肉眼根本難察覺，可是真的發生起來就麻煩大了。我聽工程師聊過，他們想到一招，就是把那些重複坐標微調一丁點，大概比頭髮絲還細好幾倍那種程度，你根本看不見差異。但系統卻能因此分清楚每個停靠點，不容易再卡死不能規劃路線。
安排好所有目的地和中途站之後，其實只要沒有明顯錯誤，看起來整條路線就在螢幕上跑出預覽圖。哎，我有一次光是看預覽就花了十幾分鐘，也不知道在想什麼。如果真的想體驗即時語音導航或其他功能，通常都是等到這一步確認沒問題再按「開始」。但是話說回來，每次切換到原生界面後，好像又冒出不同設定可以調整；各專案負責人提到的做法也五花八門。唔，有時候真懶得每樣都照標準流程走，遇到奇怪地方只能邊用邊修正，看哪裡比較順手吧……
然後嘛，大部分狀況下還得處理定位權限那種彈窗。不知道為什麼，每次看到這些要求授權的提醒，我心裡都會想：到底給多少權限才夠？唉，有點煩。有時候沒給夠，它直接就擋著不讓走下一步——很多APP都有這毛病。我記得上次試某個新版本，就是卡在定位那邊，一直轉圈。
再說回流程本身，其實正式啟動地圖導航SDK之前，好像還有不少小檢查要過關。有些檢查藏得挺隱晦的，不太容易一下子發現是哪裡出問題。我自己用的時候，有幾次就是因為某個細節沒弄好（可能是什麼設定選項之類），結果一直被擋著不能初始化。嗯，但只要全都順利搞定，那SDK初始化差不多就算大功告成吧。朋友跟我講過，他說等畫面顯示準備完成，再接著設定目的地跟路線——這聽起來簡單，可是偶爾又會冒出莫名其妙的小插曲。
哦對了，有件事情我以前完全沒想到。就是當使用者輸入路徑的時候，如果有幾個停靠點位置完全重複——欸，竟然很容易讓底層導航引擎整個出錯！這種bug，其實肉眼根本難察覺，可是真的發生起來就麻煩大了。我聽工程師聊過，他們想到一招，就是把那些重複坐標微調一丁點，大概比頭髮絲還細好幾倍那種程度，你根本看不見差異。但系統卻能因此分清楚每個停靠點，不容易再卡死不能規劃路線。
安排好所有目的地和中途站之後，其實只要沒有明顯錯誤，看起來整條路線就在螢幕上跑出預覽圖。哎，我有一次光是看預覽就花了十幾分鐘，也不知道在想什麼。如果真的想體驗即時語音導航或其他功能，通常都是等到這一步確認沒問題再按「開始」。但是話說回來，每次切換到原生界面後，好像又冒出不同設定可以調整；各專案負責人提到的做法也五花八門。唔，有時候真懶得每樣都照標準流程走，遇到奇怪地方只能邊用邊修正，看哪裡比較順手吧……
開啟導航模式前的小細節和踩過的坑們
欸，說真的，在進入什麼技術細節之前我還是忍不住想先碎念一下。這其實跟程式碼本身沒直接關聯啦，但只要你有在用 Google Navigation SDK，就很難假裝看不到這件事。嗯……說到底就是錢的問題嘛。Google 這東西的價錢，欸，怎麼講，就是它那個收費結構根本不像你去查一般 Google Maps API 那種一目了然。有時候人會誤以為差不多，其實完全不是同一回事喔。
唉，我自己也是頭痛過才學乖。導航 SDK 是高階產品，它基本上就不是「免費玩玩」的那種路線，而且收費邏輯也挺詭異（應該不能直接叫奇怪吧？），總之和大部分市面上的 API 都不同。岔題一下，上次有人問我「活躍使用者」是怎麼算的，老實說我當時腦袋也有點打結——結果查了半天才搞懂：原來他們是每個月活躍使用者來計價，只要某個帳號在當月開啟過相關功能，不管他反覆點幾次，都只算一次。聽起來好像有點佛心？但等到帳單出現，你就知道並沒有。
然後啊，有趣的是……據說官方對於「活躍」這兩個字的定義，有時又會和你的理解落差很大。我自己之前也碰過朋友抱怨，明明覺得沒什麼流量，結果月底數字爆表。可能哪裡被算進去了，也懶得追究細節。不過話說回來，如果你的專案規模再大一點，人數動輒增加十倍、二十倍，那預算膨脹速度絕對比你想像快。所以啦，與其等到最後臨時抓狂，不如一開始就問清楚比較省事。
嗯，好像又扯遠了。不過總結一下，用 Navigation SDK 前真的超級建議你先把收費規則弄明白，再決定要不要全力推廣或正式上線。有些細節甚至最好自己寫信去問官方，比較心安啦。不然到時候臨陣磨槍，到底能不能補救都未必呢…唉，人生就是一直踩雷，一直拆炸彈吧。
唉，我自己也是頭痛過才學乖。導航 SDK 是高階產品，它基本上就不是「免費玩玩」的那種路線，而且收費邏輯也挺詭異（應該不能直接叫奇怪吧？），總之和大部分市面上的 API 都不同。岔題一下，上次有人問我「活躍使用者」是怎麼算的，老實說我當時腦袋也有點打結——結果查了半天才搞懂：原來他們是每個月活躍使用者來計價，只要某個帳號在當月開啟過相關功能，不管他反覆點幾次，都只算一次。聽起來好像有點佛心？但等到帳單出現，你就知道並沒有。
然後啊，有趣的是……據說官方對於「活躍」這兩個字的定義，有時又會和你的理解落差很大。我自己之前也碰過朋友抱怨，明明覺得沒什麼流量，結果月底數字爆表。可能哪裡被算進去了，也懶得追究細節。不過話說回來，如果你的專案規模再大一點，人數動輒增加十倍、二十倍，那預算膨脹速度絕對比你想像快。所以啦，與其等到最後臨時抓狂，不如一開始就問清楚比較省事。
嗯，好像又扯遠了。不過總結一下，用 Navigation SDK 前真的超級建議你先把收費規則弄明白，再決定要不要全力推廣或正式上線。有些細節甚至最好自己寫信去問官方，比較心安啦。不然到時候臨陣磨槍，到底能不能補救都未必呢…唉，人生就是一直踩雷，一直拆炸彈吧。
用錢買教訓？Google導航SDK計費黑洞警語
嗯，說到那個每個月被算進去的活躍人數，其實只要某個用戶在那個月份第一次啟動導航 SDK，就會直接被記一筆。好像——欸我剛才差點忘了，有人特別提過，觸發的地方其實就在 GoogleMapsNavigator.initializeNavigationSession() 這串指令。聽起來很簡單，但現場常有人搞不清楚到底該什麼時候動手。唉，我自己有時也搞亂。
大家不是都說初始化越早越好嗎？可是，經驗告訴我們，好像不要一進地圖頁就立刻全部啟動比較妥當。其實也不是說誰規定啦，只是等用戶真的決定要開導航、準備出門時再開，好像對成本控制比較有幫助。有時候想太多反而卡住，嗯，也許是我自己想太多吧。
另外，有些人還建議，不如乾脆設個遠端開關，用來控管哪些功能給哪些人打開。我那天聽同事說，這種做法既能省資源，又方便隨狀況調整。欸，講到這裡突然想到昨天晚上吃的東西怪怪的——咳，好啦拉回主題，就是加遠端開關這件事，有時真的是救命繩。
但老實說啦，這種規則根本沒有什麼絕對。不一樣團隊、不一樣產品，各自都有自己的步調和優先順序。我還聽過大約一半的案例，到最後流程都得微調一下才能符合需求。所以關於 SDK 初始化到底什麼時候才「對」？大概吧，多數人都選擇延後到確定必要才處理；當然偶爾也有人早早就啟動，只是比例沒那麼高罷了。好吧，其實世界就是這麼亂七八糟，可是資訊還是得傳下去嘛。
大家不是都說初始化越早越好嗎？可是，經驗告訴我們，好像不要一進地圖頁就立刻全部啟動比較妥當。其實也不是說誰規定啦，只是等用戶真的決定要開導航、準備出門時再開，好像對成本控制比較有幫助。有時候想太多反而卡住，嗯，也許是我自己想太多吧。
另外，有些人還建議，不如乾脆設個遠端開關，用來控管哪些功能給哪些人打開。我那天聽同事說，這種做法既能省資源，又方便隨狀況調整。欸，講到這裡突然想到昨天晚上吃的東西怪怪的——咳，好啦拉回主題，就是加遠端開關這件事，有時真的是救命繩。
但老實說啦，這種規則根本沒有什麼絕對。不一樣團隊、不一樣產品，各自都有自己的步調和優先順序。我還聽過大約一半的案例，到最後流程都得微調一下才能符合需求。所以關於 SDK 初始化到底什麼時候才「對」？大概吧，多數人都選擇延後到確定必要才處理；當然偶爾也有人早早就啟動，只是比例沒那麼高罷了。好吧，其實世界就是這麼亂七八糟，可是資訊還是得傳下去嘛。
Native事件亂入：監聽、轉換、BLoC互動秀
有人會說，唉，不如直接用Firebase Remote Config把整個導航功能包起來算了。理由嘛，無非就是怕哪天運營成本莫名其妙飆高，或者遇到什麼突然狀況，好像只要一個「緊急拉閘」的按鈕，就能讓所有人瞬間關掉這功能。重點是還不用發新版耶，這聽起來很誘人對吧？啊不過，我剛剛想到冰箱裡那杯咖啡還沒喝完……呃，扯遠了。反正這種彈性設計在某些情境下確實蠻好用，但你說真的萬無一失嗎？也得看你自己需求怎麼樣。
清理導航流程也是不能鬆懈的啦。有些開發者會在BLoC的close()裡面呼叫GoogleMapsNavigator.cleanup()——據說是為了釋放那些原生端資源，不然積久了，好像就有機會搞出記憶體問題。EndTripEvent那邊記得要繞回去檢查，有沒有確定把清理的步驟跑完。不然我常常自己做一做就忘記細節在哪…嗯，每個團隊管理習慣真的都不同，有時候流程走順了、細節卻默默溜走，很容易漏掉重要環節。
話說回來，你照著上面那些做法，其實也沒誰敢拍胸脯保證百分之百安全。但總歸多留點心眼在遠端設定跟資源釋放上，大致上應該對穩定性有幫助，大概吧。唉，有時候想想，也只能盡力而為不是嗎？
清理導航流程也是不能鬆懈的啦。有些開發者會在BLoC的close()裡面呼叫GoogleMapsNavigator.cleanup()——據說是為了釋放那些原生端資源，不然積久了，好像就有機會搞出記憶體問題。EndTripEvent那邊記得要繞回去檢查，有沒有確定把清理的步驟跑完。不然我常常自己做一做就忘記細節在哪…嗯，每個團隊管理習慣真的都不同，有時候流程走順了、細節卻默默溜走，很容易漏掉重要環節。
話說回來，你照著上面那些做法，其實也沒誰敢拍胸脯保證百分之百安全。但總歸多留點心眼在遠端設定跟資源釋放上，大致上應該對穩定性有幫助，大概吧。唉，有時候想想，也只能盡力而為不是嗎？
抵達點怎麼辦？下一個站還是結束旅程呢
唉，有時候用 Google Cloud 就是會莫名其妙有點焦慮，特別是帳單這玩意兒，好像永遠不知道哪天會突然跳出一個讓人想翻白眼的數字。以前聽朋友抱怨過，然後我就開始好奇，到底怎麼預防這種狀況？噢對啦，在那個 Google Cloud Console 裡面，不知道你有沒有進去過…呃，總之就是在「預算與提醒」那邊（名字我每次都忘），反正意思差不多。只要你去設一下預算警示，其實也不是什麼很高深的設定——就像是在門口擺道柵欄吧。嗯，如果開銷快超標，它就會跳出來提醒你，不至於等到傻傻月底才發現自己破產。
但說真的，就算設了這些自以為萬無一失的防線，有些地方還是得靠自己盯緊一點。我記得官方價格那份文件，好像三不五時會更新欸？啊，我又想到上次看到有人只看部落格結果踩雷。拜託，千萬不要純粹相信網路流言，最好都直接翻官方公告（雖然有時候找半天找不到重點啦）。畢竟政策偶爾就突襲式大改版，你沒跟上腳步，那損失可是自己的喔。
其實如果前面那些動作都有做，大致上用 Google Navigation SDK 這類服務時，心裡應該比較不會毛毛的。不敢拍胸脯說完全沒風險，但和那種什麼準備都沒有的災難比起來，好歹多了一層保障。有時候，多繞幾分鐘、謹慎一點，也許就能躲過某種「怎麼又爆表」的窘境吧。嗯，我是不是又岔題了？啊對，就是小心再小心啦。
但說真的，就算設了這些自以為萬無一失的防線，有些地方還是得靠自己盯緊一點。我記得官方價格那份文件，好像三不五時會更新欸？啊，我又想到上次看到有人只看部落格結果踩雷。拜託，千萬不要純粹相信網路流言，最好都直接翻官方公告（雖然有時候找半天找不到重點啦）。畢竟政策偶爾就突襲式大改版，你沒跟上腳步，那損失可是自己的喔。
其實如果前面那些動作都有做，大致上用 Google Navigation SDK 這類服務時，心裡應該比較不會毛毛的。不敢拍胸脯說完全沒風險，但和那種什麼準備都沒有的災難比起來，好歹多了一層保障。有時候，多繞幾分鐘、謹慎一點，也許就能躲過某種「怎麼又爆表」的窘境吧。嗯，我是不是又岔題了？啊對，就是小心再小心啦。
清理資源，避免記憶體怨念纏身的方法
有時候啦，導航 SDK 那端傳來的事件變化真的是——嗯，怎麼說，有點密集，又不見得每次都能明顯察覺。原生 SDK 在背景裡像是在偷偷摸摸丟出一堆狀態更新，搞得人有點煩躁。不過我們這邊就只能靠類似 BLoC 的模式，把那些 native callback 稍微繞個圈子，再轉成 app 內部好辨認的事件。唉，其實也不知道為什麼不能直接給一次到位，但大概就是各自安好吧。SDK 有時候默默廣播了什麼變化，比如車子快到站，或是剩下距離、預估時間又動了一下，然後我們只好在 Dart 裡加個 listener，一接收到消息就把它丟進 BLoC 的 event 流裡頭去——兩者其實沒真的黏死。嗯，我剛剛是不是講太繞？總之就是獨立運作，各走各路啦。
舉例好了，每次導航遇到停靠點，就像你開車臨時找個加油站或休息站吧，肯定會觸發一連串機制。流程聽起來很規律，其實細節常常卡住人：先要努力從行程資料抓對那個站點（怪哉，有些資料結構設計真奇葩），再跟後端報備「欸，人到了喔」。這步驟做完，如果碰巧已經快跑完所有站，那大致就是該收尾準備回家。不然就得把指針往下一站挪，再通知 SDK 現在的新目的地是哪裡。有時更新目的地會冒出小狀況，也許網速慢爆，或者資料格式突然整組錯掉，只能當場補救，看命了。有沒有辦法完全避免？唉，不太可能。
另外啊，有些比較老練的人有提過，用完那些原生資源記得要清乾淨，要不然用著用著手機自己開始卡頓甚至閃退，也是挺讓人崩潰的事。所以設計上 BLoC 關閉階段特地留了一手，把所有 listener 清掉才算真的結束。但現場測試嘛，也不是每次都零失誤，只能盡量減少殘留垃圾。有時候想想，好像永遠都有魚漏網。
說起來，每一步都彷彿重複差不多的事情，但細節總是能意外蹦出新問題，所以還是要一直保持警覺，不能全憑SOP照本宣科。有些流程乍看單純，其實背後異動複雜極了；尤其多人協作或者長時間跑下去，各種奇怪的小狀況偶爾就會跳出來搗亂。嗯……寫到這邊忽然想到晚餐還沒吃，但還是拉回來，就是這樣啦。
舉例好了，每次導航遇到停靠點，就像你開車臨時找個加油站或休息站吧，肯定會觸發一連串機制。流程聽起來很規律，其實細節常常卡住人：先要努力從行程資料抓對那個站點（怪哉，有些資料結構設計真奇葩），再跟後端報備「欸，人到了喔」。這步驟做完，如果碰巧已經快跑完所有站，那大致就是該收尾準備回家。不然就得把指針往下一站挪，再通知 SDK 現在的新目的地是哪裡。有時更新目的地會冒出小狀況，也許網速慢爆，或者資料格式突然整組錯掉，只能當場補救，看命了。有沒有辦法完全避免？唉，不太可能。
另外啊，有些比較老練的人有提過，用完那些原生資源記得要清乾淨，要不然用著用著手機自己開始卡頓甚至閃退，也是挺讓人崩潰的事。所以設計上 BLoC 關閉階段特地留了一手，把所有 listener 清掉才算真的結束。但現場測試嘛，也不是每次都零失誤，只能盡量減少殘留垃圾。有時候想想，好像永遠都有魚漏網。
說起來，每一步都彷彿重複差不多的事情，但細節總是能意外蹦出新問題，所以還是要一直保持警覺，不能全憑SOP照本宣科。有些流程乍看單純，其實背後異動複雜極了；尤其多人協作或者長時間跑下去，各種奇怪的小狀況偶爾就會跳出來搗亂。嗯……寫到這邊忽然想到晚餐還沒吃，但還是拉回來，就是這樣啦。
BLoC設計帶來的結構爽感與未來擴充餘韻
唉，要說這種即時導航的狀態管理，真的沒想像中簡單啦。裡面藏了不少細微之處，其實每次講到這個，我腦袋都會自動跳去回憶某個專案搞砸的畫面…算了先不提。有人會建議，把所有事件和狀態預先規劃妥當，然後整包邏輯直接塞進一個 BLoC 裡頭，嗯，聽起來好像很合理？但有時又覺得哪裡怪怪的。不過不得不承認，這樣確實方便蠻多——舉例啦，從請權限、處理各種突發狀況，到最後的善後收尾，基本上都能顧及大部分細節。雖然也不是每次都保證百分百順利，有時候還是會出點小岔子，但總體而言，大致常見情境都有涵蓋到。
其實用起來也沒多難啦。UI 端變得清爽很多，就是負責丟事件、等著接收狀態訊息，也不用特別關心底層在玩什麼花樣。有點想岔題一下——你有沒有遇過那種什麼都要親自掌控才安心的人？啊，好像離題了。拉回來，如果有人想測試這一套流程，其實不用真機模擬也行，大概三五成主要測試需求都可以被滿足。
欸，如果哪天突然要搬家（指專案），或是需要重複利用，大部分情況下直接把這一套拿去新專案插進去應該還能跑得動。不過嘛，每個專案總是帶著點自己的小脾氣，有時候免不了還是得補東補西修一下，不然就給你鬧彆扭。但目前看下來，NavigationBloc 這種結構算是挺容易擴充，也比較不會被搞亂吧（至少我自己用感覺如此）。對於那些打算在 Flutter 上做導航經驗設計的人來說，也許這樣的架構會很受歡迎，畢竟不少人願意拿它作為起手式，再往下發揮。如果你最近剛好卡住，不如參考看看？啊，好像廢話太多，就分享到這裡好了，希望多少有派上用場啦。
其實用起來也沒多難啦。UI 端變得清爽很多，就是負責丟事件、等著接收狀態訊息，也不用特別關心底層在玩什麼花樣。有點想岔題一下——你有沒有遇過那種什麼都要親自掌控才安心的人？啊，好像離題了。拉回來，如果有人想測試這一套流程，其實不用真機模擬也行，大概三五成主要測試需求都可以被滿足。
欸，如果哪天突然要搬家（指專案），或是需要重複利用，大部分情況下直接把這一套拿去新專案插進去應該還能跑得動。不過嘛，每個專案總是帶著點自己的小脾氣，有時候免不了還是得補東補西修一下，不然就給你鬧彆扭。但目前看下來，NavigationBloc 這種結構算是挺容易擴充，也比較不會被搞亂吧（至少我自己用感覺如此）。對於那些打算在 Flutter 上做導航經驗設計的人來說，也許這樣的架構會很受歡迎，畢竟不少人願意拿它作為起手式，再往下發揮。如果你最近剛好卡住，不如參考看看？啊，好像廢話太多，就分享到這裡好了，希望多少有派上用場啦。
