实时复杂性的 Android Wear 2.0 架构问题

Question

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

该套装将包含心率、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_OFF，但退出环境模式时不会分派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。

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

我希望这会有所帮助。