无论其他已安装的应用程序和表盘如何，我都在开发一系列我想要的复杂功能。是的，在某些时候我正在重新发明轮子，但同时我将其用作学习项目。这也将确保我始终拥有我使用的所有复杂功能，并且它们都具有相同的格式和样式，而不是依赖 3rd 方应用程序单独提供它们。
该套装将包含心率、gps 坐标、小时、分钟、秒、dd/MM 日期、dd/MM/yy 日期、电池等的并发症。
当我开始对所有这些进行编程时，我发现了几个有问题的部分（很可能是因为这是我第一次开发复杂功能，或者是用于 Android Wear 的应用程序），因此提出了这个问题。
请注意，其中一些行为可能特定于 Huawei Watch 2 LTE。
1）升级间隔推/拉。
我理解数据提供者的复杂性，他们的唯一职责是将数据提供给任何表盘调用它们。这意味着我们不确定（并且我们依赖表盘开发人员）了解复杂性并相应地请求更新。如果不及时更新（例如显示秒），这会使一些复杂性完全无用。也可以留给显示旧数据的并发症（例如旧的 GPS 坐标、旧的心率 bpm）。好吧，我决定ProviderUpdateRequester用AlarmManagerto push来实现数据到表盘。问题再次是应该更快发生的并发症，例如秒，因为如果计划过于频繁，Android 将阻止待处理的意图。因此，为了解决这个问题，我决定在同一个服务实例中使用 Android 处理程序，但由于下一个主题，这不是一个好主意。
2) 并发症生命周期
通过调试，我发现正在执行的对象的实例，，，ComplicationProviderService可以不同。这意味着这不是一个始终运行的粘性服务（单个实例），而是每次更新都会创建一个新的服务实例。这是有问题的，因为初始化复杂度很高：例如 GPS 或心率监测器需要侦听新值，并且可能需要一段时间才能检索到第一个值。而且，对于那些不能依赖 AlarmManager 和/或需要在更新执行之间保持某种状态的复杂情况。onComplicationActivatedonComplicationUpdateonComplicationDeactivated
3) 显示感知服务
为了绕过前一点，假设您的复杂服务上有静态变量，这些变量onComplicationActivated在onComplicationDeactivated. 例如，这可能是获取 LocationProvider 的引用并开始侦听位置更新。这将确保每次调用onComplicationUpdate都不必执行重/冷初始化，并且可以访问最新数据。但是，这也意味着无论是否onComplicationUpdate调用您的逻辑都会执行。当处于环境模式（或屏幕关闭）时，表盘可以通过不调用来决定不更新并发症onComplicationUpdate，但它不知道我们的静态逻辑，也不知道ComplicationProviderService当屏幕进入环境模式或打开/关闭时有一个回调调用。这是一个问题，因为在我们的示例中，如果屏幕关闭，我们仍将监听 GPS 坐标，并且很可能会耗尽电池电量。当然，我们可以通过使用 BroadcastReceiver (Intent.ACTION_SCREEN_ON/OFF) 和 的组合来处理这个问题DisplayManager.DisplayListener，但话又说回来，不确定我是否在这里采取了正确的路径，因为这意味着我们现在正在创建需要的服务静态地了解显示器的状态。
4）检测屏幕开/关
当环境模式被禁用时， BroadcastReceiverforIntent.ACTION_SCREEN_ON/OFF按预期工作，但它没有被启用。启用环境模式Intent.ACTION_SCREEN_OFF时，在进入环境模式时调度，但Intent.ACTION_SCREEN_ON在退出环境模式时不调度。虽然有点复杂，但这可以通过使用DisplayManager.DisplayListener获取onDisplayChanged回调的更新来完成。
TL;RD
1) 您如何确保表盘及时显示您的复杂功能以始终拥有正确和最新的信息？
ComplicationProviderService2）如果每次onComplicationUpdate调用服务实例都不同，你如何处理重/冷初始化？
3) 让长时间运行的服务显示感知是一件疯狂的事情吗？
4) 从技术上讲，在环境模式下屏幕仍然亮着，那么为什么Intent.ACTION_SCREEN_OFF要广播？为什么Intent.ACTION_SCREEN_ON/OFF启用环境模式时不对称？
5）也许并发症不应该用于暴露实时信息？
非常感谢