Android Wear 2.0架构存在实时并发症问题(Android Wear 2.0 Architecture issues for realtime complications)

 无论其他安装的应用程序和表面如何，我正在开发一系列我希望拥有的复杂功能。 是的，在某些时候我正在重新发明轮子，但同时我将它用作学习项目。 这也将确保我始终拥有所有可用的复杂功能，并且它们都具有相同的格式和样式，而不是依赖第三方应用程序来单独提供它们。 
 
 该设置可能会导致心率，GPS坐标，小时，分钟，秒，dd / MM日期，dd / MM / yy日期，电池等并发症。 
 
 当我开始编程时，我发现了几个有问题的部分（很可能是因为这是我第一次发展并发症，或者是针对这个问题的Android应用程序的应用程序），因此也是这个问题。 
 
 请注意，这一行为可能特定于华为Watch 2 LTE。 
 
 1）升级间隔推/拉。 
 
 我理解数据提供者的复杂性，他们的唯一责任是将数据提供给任何正在呼叫他们的表盘。 这意味着我们不确定（并且我们依赖于表盘开发人员）了解并发症并相应地请求更新。 这会使一些并发症完全无用，如果不及时更新（例如显示秒）。 也可以留下显示旧数据的并发症（例如旧的GPS坐标，旧的心率bpm）。 好吧，我决定使用AlarmManager实现ProviderUpdateRequester ， 将数据推送到表盘。 问题再次出现，并发症的发生速度应该会更快，就像秒钟一样，因为如果安排太频繁，Android会阻止未决意图。 所以为了解决这个问题，我决定在同一个服务实例中使用Android处理程序，因为下一个主题，这不是一个好主意。 
 
 2）并发症生命周期 
 
 通过调试，我发现在ComplicationProviderService ， onComplicationUpdate ， onComplicationDeactivated执行的ComplicationProviderService对象的实例可能不同。 这意味着这不是一个始终运行的粘性服务（单一实例），但每次更新都会创建一个新的服务实例。 由于繁重的初始化复杂性，这是有问题的：例如GPS或心率监视器需要监听新值，并且可能需要一段时间才能检索第一个值。 而且，对于那些不能依赖于AlarmManager的复杂情况，和/或需要在更新执行之间保持某种状态。 
 
 3）显示感知服务 
 
 为了解决上述问题，假设您的复杂服务具有静态变量，它们在onComplicationDeactivated上初始化，并在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_OFF被广播？ 当环境模式启用时，为什么Intent.ACTION_SCREEN_ON/OFF对称？ 
 
 5）也许并发症不应该用于暴露实时信息？ 
 
 非常感谢 

I'm developing a set of complications that I would like have regardless of the other installed apps and watch faces. Yes, at some point I am reinventing the wheel, but at the same time I am using this as a learning project. This will also ensure that I always have all the complications I use, available and that they all have the same format and style, instead of relying on 3rd party apps to provide them separately.
 
The set will have complications for Heart rate, gps coordinates, hours, minutes, seconds, dd/MM date, dd/MM/yy date, battery, etc. 
 
When I started programing all this I found several problematic pieces (most likely because this is the first time I develop complications, or an app for android wear for that matter) and hence this question. 
 
Note that some of this behavior might be specific to the Huawei Watch 2 LTE.
 
1) Upgrade interval push / pull.
 
I understand complications as data providers, whose only responsibility is to provide the data to whatever watch face is calling them. This means that we are not certain (and we rely on the watch face developer) to know about the complication and request updates accordingly. This turns some complications completely useless if not updated in time (for example display the Seconds). Could also leave to complications displaying old data (for example old GPS coordinates, old heart rate bpm). So ok, I decided to implement ProviderUpdateRequester with the AlarmManager to push data to the watch face. The problem again, is with complications that should happen faster, like seconds, as Android will block pending intents if they are schedule too often. So in order to get around that, I decided to use Android handlers within the same service instance, which turn out to be not a good idea because of the next topic.
 
2) Complication lifecycle
 
By debugging, I found out that the instance of the ComplicationProviderService object that is executing onComplicationActivated, onComplicationUpdate, onComplicationDeactivated can be different. This means that this is not a sticky service (single instance) that will be always running, but every update creates a new instance of the service. This is problematic because of heavy initialization complications: for example GPS, or Heart Rate monitor that need to listen for new values and it might take a while to retrieve the first value. And also, for those complications that can't rely on AlarmManager, and/or need to keep some sort of state between updates executions.
 
3) Display aware service
 
To get around the previous point , let's say you have static variables on your complication service , which are initialized onComplicationActivated and disabled at onComplicationDeactivated. For example, this could be getting a reference for the LocationProvider and starting listening for location updates. This will ensure that each invocation to onComplicationUpdate will not have to perform the heavy/cold initialization and will have access to the most up-to-date data. However, this also means that your logic will executed regardless if onComplicationUpdate is called or not. When in ambient mode (or screen off) the watch face can decide not to update the complication by not calling onComplicationUpdate, but it's not aware of our static logic, nor the ComplicationProviderService has a callback invocation for when the screen goes into ambient mode or turns on/off. This is a problem, because in our example, if the screen is off, we are still going to be listening for GPS coordinates, and most likely draining the battery. Sure, we can deal with this by using a combination of BroadcastReceiver (Intent.ACTION_SCREEN_ON/OFF) and DisplayManager.DisplayListener, but then again, not sure if i'm taking the correct path here, because this will mean that we are now creating services that need to be statically aware of the state of the display.
 
4) Detect screen on/off
 
The BroadcastReceiver for Intent.ACTION_SCREEN_ON/OFF works as expected when ambient mode is disabled, but it doesn't it's enabled. When ambient mode is enabled, Intent.ACTION_SCREEN_OFF is dispatched when going into ambient mode, but Intent.ACTION_SCREEN_ON is not dispatched when coming out of ambient mode. While a bit more complex, this can be accomplished by using DisplayManager.DisplayListener to get updates on the onDisplayChanged callback.
 
TL;RD
 
1) How do you ensure watch faces display your complications in a timely manner to always have correct and most up-to-date information?
 
2) How do you deal heavy/cold initialization of a ComplicationProviderService if everytime onComplicationUpdate is called the service instance is different? 
 
3) Is making a long running service display-aware something crazy to do?
 
4) Technically the screen is still on when in ambient mode, so why is Intent.ACTION_SCREEN_OFF being broadcasted? Why isn't Intent.ACTION_SCREEN_ON/OFF symetrical when ambient mode is enabled?
 
5) Maybe complications shouldn't be use for exposing realtime information?
 
Thanks a lot

原文：https://stackoverflow.com/questions/48137450