Android Wear 2.0架構問題帶來實時復雜性

Question

無論是否安裝了其他應用程序和表盤，我都在開發一系列復雜的功能。 是的，在某些時候，我正在重新發明輪子，但與此同時，我將其用作學習項目。 這也將確保我始終擁有所使用的所有復雜功能，並且它們都具有相同的格式和樣式，而不是依賴於第三方應用程序來單獨提供它們。

該套件將具有以下方面的並發症：心率，gps坐標，小時，分鍾，秒，dd / MM日期，dd / MM / yy日期，電池等。

當我開始對所有這些進行編程時，我發現了幾個有問題的部分（很可能是因為這是我第一次開發出復雜性，或者是為此而開發的適用於Android Wear的應用程序），因此就產生了這個問題。

請注意，某些行為可能特定於Huawei Watch 2 LTE。

1）升級間隔推/拉。

我了解作為數據提供者的復雜性，其唯一責任是將數據提供給任何表盤調用它們的人。 這意味着我們不確定（我們依靠表盤開發人員）了解復雜情況並相應地請求更新。 如果不及時更新，這會使一些復雜性完全無用（例如，顯示“秒”）。 也可能會導致顯示舊數據（例如舊GPS坐標，舊心率bpm）的復雜性。 好的，我決定使用AlarmManager實現ProviderUpdateRequester ，以將數據推送到表盤。 再次出現的問題是復雜性應該更快地發生，例如幾秒鍾，因為如果過於頻繁地調度未完成的意圖，Android將阻止它們。 因此，為了解決這個問題，我決定在同一服務實例中使用Android處理程序，由於下一個主題，事實證明這不是一個好主意。

2）並發症生命周期

通過調試，我發現正在執行onComplicationActivated ， onComplicationUpdate ， onComplicationDeactivated的ComplicationProviderService對象的實例可以不同。 這意味着這不是將始終運行的粘性服務（單個實例），但是每次更新都會創建該服務的新實例。 這是有問題的，因為初始化工作繁瑣：例如GPS或心率監測器需要偵聽新值，並且可能需要一段時間才能檢索到第一個值。 而且，對於那些不能依賴於AlarmManager和/或需要在更新執行之間保持某種狀態的復雜性。

3）顯示感知服務

為了避開上一點，假設您的復雜服務上有靜態變量，這些變量在onComplicationActivated上初始化，並在onComplicationDeactivated禁用。 例如，這可能會獲取LocationProvider的參考並開始偵聽位置更新。 這將確保對onComplicationUpdate每次調用都不必執行繁重/冷的初始化，並且可以訪問最新數據。 但是，這也意味着無論是否onComplicationUpdate都將執行您的邏輯。 當處於環境模式（或屏幕關閉）時，表盤可以通過不調用onComplicationUpdate來決定不更新並發症，但它不知道我們的靜態邏輯， ComplicationProviderService也不具有在屏幕進入環境模式或打開屏幕時的回調調用。開關。 這是一個問題，因為在我們的示例中，如果屏幕關閉，我們仍將收聽GPS坐標，並且很可能會耗盡電池電量。 當然，我們可以通過使用BroadcastReceiver（Intent.ACTION_SCREEN_ON / OFF）和DisplayManager.DisplayListener的組合來處理此問題，但是再一次，不確定我是否在這里采用正確的路徑，因為這將意味着我們現在正在創建需要靜態了解顯示狀態的服務。

4）檢測屏幕開/關

禁用環境模式時，用於Intent.ACTION_SCREEN_ON/OFF的BroadcastReceiver可以Intent.ACTION_SCREEN_ON/OFF工作，但未啟用它。 啟用環境模式后，進入環境模式時將調度Intent.ACTION_SCREEN_OFF ，但Intent.ACTION_SCREEN_ON環境模式時將不調度Intent.ACTION_SCREEN_ON 。 稍微復雜一點，這可以通過使用DisplayManager.DisplayListener獲取onDisplayChanged回調上的更新來完成。

TL; RD

1）您如何確保表盤及時顯示您的並發症，以始終獲得正確和最新的信息？

2）如果每次onComplicationUpdate服務實例都不同，您如何處理ComplicationProviderService重/冷初始化？

3）使長時間運行的服務能夠感知顯示是否有些瘋狂？

4）從技術上講，在環境模式下屏幕仍處於打開狀態，那么為什么要廣播Intent.ACTION_SCREEN_OFF ？ 啟用環境模式后，為什么Intent.ACTION_SCREEN_ON/OFF ？

5）也許不應該使用復雜性來公開實時信息？

非常感謝

Answer 1

需要解壓縮的幾件事：

• 並發症並非要經常更新（考慮分鍾而不是秒），這是為了節省電池。
• ProviderUpdateRequester設計用於（平均很少）不定期更新，例如通過聊天應用程序發送的消息。
• 時間相關的復雜性-沒有這樣的“更新”，但是Wear提供了一種方法，供開發人員從特定時間開始向上/向下計數，以及顯示與日期相關的字段（世界時鍾，每月的某天），而提供商不發送所有系統更新時間。 對於這最后一個，請參考ComplicationText.TimeDifferenceBuilder和ComplicationText.TimeFormatBuilder文檔。

對於您的用例，考慮始終在線的應用可能是更合適的選擇。 用戶在特定時間段內出於特定目的使用它，因此他們明確同意使用更多的電池來跟蹤GPS或心率等信息。 例如，許多在Wear上運行的應用程序都可以做到這一點。

我希望這有幫助。