android - Android Wear 2.0架构问题带来的实时复杂性

Question

无论是否安装了其他应用程序和表盘，我都在开发一系列复杂的功能。是的，在某些时候，我正在重新发明轮子，但与此同时，我将其用作学习项目。这也将确保我始终拥有自己使用的所有复杂功能，并且它们都具有相同的格式和样式，而不是依赖于第三方应用程序来单独提供它们。

该套件将具有以下方面的并发症：心率，gps坐标，小时，分钟，秒，dd / MM日期，dd / MM / yy日期，电池等。

当我开始对所有这些进行编程时，我发现了几个有问题的部分（很可能是因为这是我第一次开发出复杂性，或者是为此而开发的适用于Android Wear的应用程序），因此出现了这个问题。

请注意，某些行为可能特定于Huawei Watch 2 LTE。

1）升级间隔推/拉。

我了解作为数据提供者的复杂性，其唯一责任是将数据提供给任何表盘调用它们的人。这意味着我们不确定（我们依靠表盘开发人员）了解复杂情况并相应地请求更新。如果不及时更新，这会使一些复杂性完全无用（例如，显示“秒”）。也可能会导致显示旧数据（例如旧GPS坐标，旧心率bpm）的复杂性。
好的，我决定用ProviderUpdateRequester实现AlarmManager将数据推送到表盘。再次出现的问题是复杂性应该更快地发生，例如几秒钟，因为如果过于频繁地调度未完成的意图，Android将阻止它们。因此，为了解决这个问题，我决定在同一服务实例中使用Android处理程序，由于下一个主题，事实证明这不是一个好主意。

2）并发症生命周期

通过调试，我发现执行ComplicationProviderService，onComplicationActivated，onComplicationUpdate的onComplicationDeactivated对象的实例可以不同。这意味着这不是将始终运行的粘性服务（单个实例），但是每次更新都会创建该服务的新实例。这是有问题的，因为初始化工作繁琐：例如GPS或心率监测器需要侦听新值，并且可能需要一段时间才能检索到第一个值。而且，对于那些不能依赖于AlarmManager和/或需要在更新执行之间保持某种状态的复杂性。

3）显示感知服务

为了绕过上一点，我们假设您的复杂服务上有静态变量，这些变量已初始化onComplicationActivated并在onComplicationDeactivated禁用。例如，这可能会获取LocationProvider的参考并开始侦听位置更新。这将确保对onComplicationUpdate的每次调用都不必执行繁重/冷的初始化，并且可以访问最新数据。
但是，这也意味着无论是否调用onComplicationUpdate，您的逻辑都将执行。
在环境模式（或屏幕关闭）下，表盘可以决定不通过不调用onComplicationUpdate来更新复杂性，但是它不了解我们的静态逻辑，ComplicationProviderService也不具有在屏幕进入时的回调调用环境模式或打开/关闭。这是一个问题，因为在我们的示例中，如果屏幕关闭，我们仍将收听GPS坐标，并且很可能会耗尽电池电量。
当然，我们可以通过使用BroadcastReceiver（Intent.ACTION_SCREEN_ON / OFF）和DisplayManager.DisplayListener的组合来处理此问题，但是再一次，不确定我在这里是否采用正确的路径，因为这将意味着我们现在正在创建需要静态了解显示状态的服务。

4）检测屏幕开/关

禁用环境模式时，BroadcastReceiver的Intent.ACTION_SCREEN_ON/OFF会按预期工作，但未启用。启用环境模式后，进入环境模式时将调度Intent.ACTION_SCREEN_OFF，但退出环境模式时将不调度Intent.ACTION_SCREEN_ON。稍微复杂一点，这可以通过使用DisplayManager.DisplayListener在onDisplayChanged回调上获取更新来完成。

TL; RD

1）您如何确保表盘及时显示您的并发症，以始终获得正确和最新的信息？

2）如果每次调用ComplicationProviderService的服务实例都不相同，您如何处理onComplicationUpdate的重/冷初始化？

3）使长时间运行的服务能够感知显示是否有些疯狂？

4）从技术上讲，在环境模式下，屏幕仍处于打开状态，那么为什么要播放Intent.ACTION_SCREEN_OFF？启用环境模式后，为什么Intent.ACTION_SCREEN_ON/OFF不是对称的？

5）也许不应该使用复杂性来公开实时信息？

非常感谢

Answer 1

需要解压缩的几件事：


并发症并非要经常更新（考虑分钟而不是秒），这是为了节省电池。
ProviderUpdateRequester设计用于（通常很少）不定期的更新，例如通过聊天应用程序发送的消息。
时间相关的复杂性-没有这样的“更新”，但是Wear提供了一些方法，使开发人员可以从特定时间开始向上/向下计数，并显示与日期相关的字段（世界时钟，每月的某天），而提供商不发送所有系统更新时间。对于这最后一个，请参考ComplicationText.TimeDifferenceBuilder的文档
和ComplicationText.TimeFormatBuilder。


对于您的用例，可能更适合考虑always-on app。用户在特定时间段内出于特定目的使用它，因此他们明确同意使用更多的电池来跟踪GPS或心率等信息。例如，许多在Wear上运行的应用程序都可以做到这一点。

我希望这有帮助。