概述#
行動系統涵蓋廣泛的形式與應用——從智慧型手機、平板電腦到汽車、飛機等運輸工具。這些系統共享若干獨特的架構特性，使其有別於固定式系統。本章將這些特性歸納為五大面向：能源、網路連線、感測器與致動器、資源、以及生命週期。
能源（Energy）#
行動裝置的能源通常來自電池——容量有限的有限資源。其他行動裝置（如汽車、飛機）依靠發電機供電，其燃料同樣有限。架構師必須關注三個核心議題：監控電源、節流能源使用、以及容忍電力中斷。
監控電源#
大多數筆記型電腦和智慧型手機使用智慧電池（Smart Battery），內建電池管理系統（BMS）可查詢電池目前狀態。行動系統在作業系統核心中包含一個與 BMS 互動的元件，而電池管理器負責定期查詢此元件以取得電池狀態，藉此實現：
- 通知使用者電池電量偏低
- 將裝置切換至省電模式
- 警告應用程式即將關機，使其能準備重新啟動
- 判斷每個應用程式的耗電量
電池隨著老化會改變兩個特性：最大電池容量和最大持續電流。架構師須考慮在可用電力的變化範圍內管理消耗，使裝置仍能維持可接受的效能水準。
電池管理器本身也會消耗 CPU 時間與記憶體，可透過調整查詢間隔來管理其資源消耗。
節流能源使用（Throttling Energy Usage）#
透過終止或降級耗能的系統部分來減少能源使用（對應第 6 章的 Throttle Usage 戰術）。常見手法包括：
- 降低螢幕亮度或刷新率
- 減少處理器的活動核心數或時脈速率
- 降低感測器讀取頻率（例如 GPS 從每幾秒改為每分鐘查詢一次）
- 使用較少的定位資料來源（例如僅使用 GPS 或基地台其中之一）
容忍電力中斷（Tolerating a Loss of Power）#
行動系統應能優雅地容忍電力故障與重新啟動。典型的需求可能是：電力恢復後，系統在 30 秒內回到正常工作模式。這隱含了不同層面的需求：
硬體需求：
- 電源隨時中斷不得造成永久性損壞
- 電腦在獲得足夠電力後能穩健啟動 OS
- OS 在就緒後即排程啟動所需軟體
軟體需求：
- Runtime 可在任何時刻被終止，且不影響永久儲存中的二進位檔、設定與運作資料的完整性
- 應用程式需要策略來處理其停機期間到達的資料
- Runtime 能在故障後啟動，使從系統開機到軟體就緒的時間低於指定期限
網路連線（Network Connectivity）#
行動系統與外部世界的無線通訊是核心架構關注點。無線網路依據操作距離分類：
- 4 公分內：NFC（Near Field Communication），用於門禁卡和非接觸式支付
- 10 公尺內：IEEE 802.15 系列（Bluetooth、Zigbee）
- 100 公尺內：IEEE 802.11 系列（Wi-Fi）
- 數公里內：IEEE 802.16（WiMAX）
- 數公里以上：蜂巢式通訊或衛星通訊
架構師的關注點#
設計通訊和網路連線時，架構師需平衡眾多考量：
- 通訊介面數量：雖然協定眾多且快速演進，但目標應是只包含嚴格必要的介面，以最佳化功耗、散熱和空間分配
- 協定間的切換：裝置可能在使用過程中從一個協定環境移動到另一個（例如從 Wi-Fi 切換到蜂巢式網路），切換應對使用者無縫透明
- 動態選擇協定：當多個協定同時可用時，系統應根據成本、頻寬和功耗動態選擇最適協定
- 可修改性：鑒於協定的快速演進，系統應設計為支援通訊元件的變更或替換
- 頻寬：應分析所需通訊的距離、資料量和延遲要求，以選擇適當的協定
- 間歇性 / 有限 / 無連線：通訊可能在移動中中斷（如穿越隧道）。系統須在連線中斷時維持資料完整性，並在恢復連線後無遺失地繼續運算。應設計降級模式和備援模式
- 安全性：行動裝置特別容易遭受欺騙（Spoofing）、竊聽（Eavesdropping）和中間人攻擊
行動系統必須設計為能優雅地應對有限連線甚至完全無連線的情境，動態提供降級和備援模式。
感測器與致動器（Sensors and Actuators）#
感測器（Sensor）偵測環境的物理特性並將其轉換為電子表示。行動裝置收集環境資料的目的可能是引導自身操作（如無人機的高度計）或回報資料給使用者（如智慧型手機的磁力計）。感測器集線器（Sensor Hub）是一種協處理器，幫助整合不同感測器的資料並進行處理，可從主 CPU 卸載這些工作以節省電力並提升效能。
致動器（Actuator）則相反：接收數位表示並在環境中引發動作，例如汽車的車道維持輔助或智慧型手機的音頻警示。
架構師的關注點#
- 如何根據感測器輸入建立環境的準確表示
- 系統應如何回應該環境表示
- 感測器資料與致動器指令的安全與隱私
- 降級操作：若感測器故障或不可讀，系統應進入降級模式（例如 GPS 在隧道中不可用時，使用航位推算技術估計位置）
感測器堆疊（Sensor Stack）#
感測器堆疊是一組裝置和軟體驅動程式的聯合體，將原始資料轉換為關於環境的有意義資訊。不同平台和領域有各自的感測器堆疊。無論具體分解方式如何，堆疊須實現的功能包括：
- 讀取原始資料：最底層的軟體驅動程式定期讀取感測器。讀取頻率是一個參數，影響處理器負載和表示的準確度
- 資料平滑（Smoothing）：原始資料通常含有大量雜訊。使用移動平均（Moving Average）或卡爾曼濾波器（Kalman Filter）等技術，透過一系列測量值產生比單次讀取更準確的估計
- 資料轉換（Converting）：不同感測器可能以不同格式回報同一現象的資料，轉換器負責將讀數轉換為應用程式有意義的共同格式
- 感測器融合（Sensor Fusion）：結合多個感測器的資料，建構比任何單一感測器更準確、更完整或更可靠的環境表示。例如自動駕駛汽車辨識行人時，必須智慧地結合熱成像儀、雷達、光達（LiDAR）和攝影機的輸入
感測器融合是建構可靠環境表示的關鍵技術——沒有單一感測器能在所有天氣和光線條件下完成複雜的環境感知任務。
資源（Resources）#
行動系統的資源選擇涉及該資源的貢獻度與其體積、重量和成本之間的權衡。由於許多行動系統以百萬計量產且對價格高度敏感，處理器的微小價差乘以數百萬產量可顯著影響獲利。
額外的資源限制#
- 安全考量：具有安全後果的實體資源不得故障或須有備份（如飛機的緊急電源）
- 熱限制：系統自身產生的熱（想像膝上的筆記型電腦）可能影響效能甚至導致故障，環境溫度過高或過低也有影響
- 其他環境因素：溼氣、灰塵、摔落等
架構師的關注點#
將任務分配給電子控制單元（ECU）：較大型的行動系統（如汽車、飛機）有多個不同功率和容量的 ECU。分配考量包括：
- ECU 與功能的匹配度（例如具有 GPU 的 ECU 更適合圖形功能）
- 關鍵性（更強大的 ECU 保留給關鍵功能，如引擎控制器）
- 在車輛中的位置
- 連接性（分散在多個 ECU 的功能必須在同一內部網路上）
- 通訊局部性（密集通訊的元件放在同一 ECU 可改善效能）
- 成本（通常希望最小化部署的 ECU 數量）
將功能卸載到雲端：路線規劃和模式辨識等應用可部分在行動裝置上執行（感測器所在處），部分在雲端執行（擁有更多儲存和更強處理器）。架構師須判斷行動系統是否有足夠算力、是否有足夠連線來卸載功能，以及如何在功能拆分時滿足效能需求
依操作模式關閉功能：未使用的子系統可縮減其資源佔用，讓其他子系統存取更多資源。例如跑車的「賽道模式」會停用舒適懸吊計算，改為啟動扭力分配、煞車力道和離心力計算
資訊顯示策略：與可用的顯示解析度密切相關。在 320x320 的顯示器上進行 GPS 地圖顯示需大量精簡資訊，而 1280x720 則可提供更豐富的資訊。這也是採用 MVC 模式（參見第 13 章）的強烈動機——可根據顯示特性替換 View
生命週期（Life Cycle）#
行動系統的生命週期有一些特殊之處，架構師須將這些因素納入考量。
硬體優先（Hardware First）#
許多行動系統的硬體在軟體設計之前就已選定。主要利害關係人是管理層、銷售部門和監管機構，其關注點通常聚焦在降低風險而非促進品質屬性。
軟體架構師應主動參與早期硬體討論，強調相關的權衡取捨，而非被動等待結果。
測試（Testing）#
行動裝置的測試有若干獨特考量：
- 測試顯示佈局：智慧型手機和平板電腦有各種形狀、尺寸和長寬比。驗證所有裝置上的佈局正確性相當複雜，天真的佈局生成可能在極小顯示器上產生 1x1 像素的控制項或重疊的控制項
- 測試操作邊界情境：
- 應用程式須能承受電池耗盡和系統關機，狀態保存需確保並測試
- UI 通常與功能軟體非同步運作，重現問題的事件序列可能很困難
- 測試資源使用：模擬器可用但測試電池使用量存在局限
- 測試網路切換：確保裝置在多個通訊網路間移動時做出最佳選擇且使用者無感知
對於運輸或工業系統，測試通常在四個層級進行：
- 軟體元件層級：透過單元測試和端對端測試驗證穩定性和正確性
- 功能層級：在模擬環境中與其他元件一起執行，驗證介面和安全併發性
- 裝置層級：部署到目標 ECU 上測試效能和穩定性，使用模擬的外部輸入
- 系統層級：所有裝置、功能和元件組合成完整配置，先在測試實驗室再在測試原型中進行
測試追溯性至關重要：如果在系統層級（步驟 4）發現問題，必須能在所有測試階段中重現和追溯，因為修復需要重新通過所有四個測試層級。
部署更新（Deploying Updates）#
行動裝置的更新可能針對軟體、資料或（較少見的）硬體。部署更新的特殊議題包括：
- 維持資料一致性：消費裝置的升級通常是自動且單向的（無法回滾）。這暗示將資料放在雲端是個好主意，但所有雲端與應用程式的互動都需要測試
- 安全性：架構師需判斷系統的哪些狀態可以安全地支援更新——例如在高速公路上行駛時更新引擎控制軟體是個壞主意。這意味著系統需要感知與更新相關的安全狀態
- 部分系統部署：重新部署整個應用程式會消耗頻寬和時間。應將頻繁變動的部分架構為可以輕鬆更新，這需要特定類型的可修改性（第 8 章）和可部署性（第 5 章）關注
- 可擴展性：行動車輛系統往往有較長的使用壽命。翻新（Retrofitting）——在舊系統中加入新技術——可能因元件壽命結束、更新更好的技術出現、或新增功能而必要
日誌記錄（Logging）#
日誌對於調查和解決已發生或可能發生的事件至關重要。在行動系統中，日誌應卸載到可存取的位置，不受行動系統本身是否可存取的限制。這不僅用於事件處理，也用於對系統使用情況進行各種分析。
本章小結#
- 能源：電池需要監控以判斷剩餘時間和個別應用的使用量；可透過節流控制能源消耗；應用程式應能承受斷電並在電力恢復後無縫重啟
- 連線：涵蓋短距離（Bluetooth）、中距離（Wi-Fi）和長距離（蜂巢式）協定。在協定間切換應無縫，頻寬和成本是選擇協定的考量因素
- 感測器：透過感測器堆疊處理讀數，多個感測器可進行融合以獲得更準確的環境表示。感測器可能隨時間劣化，需要冗餘
- 資源：具有體積、重量和成本的物理特性，設計選擇涉及這些因素的權衡。部分功能可在行動系統和雲端之間拆分
- 生命週期：硬體通常先於軟體選定；測試更為複雜（尤其是 UI 和網路切換）；部署更新須考慮安全性和資料一致性；日誌應卸載到外部可存取的位置