我正在开发一系列复杂功能，无论其他安装的应用程序和表面如何，我都希望这些复杂功能。是的，在某些时候我正在重新发明轮子，但与此同时我将其用作学习项目。这也将确保我始终拥有我使用的所有复杂功能，并且它们都具有相同的格式和样式，而不是依赖第三方应用程序来单独提供它们。
该套装将有心率，gps坐标，小时，分钟，秒，dd / MM日期，dd / MM / yy日期，电池等的并发症。
当我开始对所有这些进行编程时，我发现了几个有问题的部分（很可能是因为这是我第一次出现并发症，或者是针对此问题的Android应用程序）因此这个问题。
请注意，部分此行为可能特定于华为Watch 2 LTE。
1）升级间隔推/拉。
我理解作为数据提供者的复杂性，其唯一的责任是向任何表面调用它们提供数据。这意味着我们不确定（并且我们依赖于表面开发人员）来了解复杂性并相应地请求更新。如果不及时更新，这会使一些并发症完全无用（例如显示秒）。也可能留下显示旧数据的复杂情况（例如旧的GPS坐标，旧的心率bpm）。
好的，我决定将ProviderUpdateRequester与AlarmManager 推送数据一起实施到观察面。问题再次出现，应该更快地发生并发症，比如秒，因为如果安排得太频繁，Android会阻止等待意图。因此，为了解决这个问题，我决定在同一个服务实例中使用Android处理程序，由于下一个主题，结果不是一个好主意。
2）并发症生命周期
通过调试，我发现正在执行ComplicationProviderService，onComplicationActivated，onComplicationUpdate的{{1}}对象的实例可能不同。这意味着这不是一个始终在运行的粘性服务（单个实例），但每次更新都会创建一个新的服务实例。这是有问题的，因为大量的初始化并发症：例如GPS或心率监视器需要监听新值，并且可能需要一段时间来检索第一个值。而且，对于那些不能依赖AlarmManager的复杂化，和/或需要在更新执行之间保持某种状态。
3）显示感知服务
为了解决上一点，假设您的并发症服务上有静态变量，这些变量已初始化onComplicationDeactivated并在onComplicationActivated处被禁用。例如，这可能是获取LocationProvider的引用并开始侦听位置更新。这将确保每次调用onComplicationDeactivated都不必执行繁重/冷启动，并且可以访问最新数据。
但是，这也意味着无论是否调用onComplicationUpdate，您的逻辑都将被执行。
当处于环境模式（或屏幕关闭）时，表面可以决定不通过不调用onComplicationUpdate来更新复杂性，但是它不知道我们的静态逻辑，onComplicationUpdate也没有回调调用屏幕进入环境模式或打开/关闭。这是一个问题，因为在我们的例子中，如果屏幕关闭，我们仍然会听取GPS坐标，并且很可能耗尽电池。
当然，我们可以通过使用BroadcastReceiver（Intent.ACTION_SCREEN_ON / OFF）和ComplicationProviderService的组合来解决这个问题，但话又说回来，不确定我是否采取了正确的路径，因为这意味着我们是现在创建需要静态了解显示状态的服务。
4）开启/关闭屏幕
DisplayManager.DisplayListener的{{1}}在禁用环境模式时按预期工作，但它未启用。启用环境模式时，进入环境模式时会调度BroadcastReceiver，但在退出环境模式时不会调度Intent.ACTION_SCREEN_ON/OFF。虽然有点复杂，但可以使用Intent.ACTION_SCREEN_OFF来获取Intent.ACTION_SCREEN_ON回调的更新。
TL; RD
1）您如何确保表盘及时显示您的复杂情况，以始终获得正确和最新的信息？
2）如果每次DisplayManager.DisplayListener调用服务实例不同，您如何处理onDisplayChanged的重/冷初始化？
3）制作一个长期运行的服务显示器意识到疯狂的事情吗？
4）从技术上讲，屏幕在环境模式下仍处于开启状态，为什么ComplicationProviderService被广播？启用环境模式时，为什么onComplicationUpdate不对称？
5）也许不应该使用并发症来暴露实时信息？
非常感谢
答案 0 :(得分：1)
要解压的几件事：
ProviderUpdateRequester的设计更多（平均不频繁）不定期更新，例如来自聊天应用的消息。ComplicationText.TimeDifferenceBuilder的文档
和ComplicationText.TimeFormatBuilder。对于您的用例，更合适的事情可能是考虑always-on app。用户在特定时间段内将其用于特定目的，因此他们明确同意使用更多电池来跟踪GPS或心率等信息。例如，Wear上的很多正在运行的应用就是这样做的。
我希望这会有所帮助。