简体   繁体   English

在IntentService(WakefulIntentService)内部延迟(定时)注销传感器侦听器

[英]Delayed (timed) unregister sensor listener inside IntentService (WakefulIntentService)

I've implemented an IntentService which, using SensorManager , reads data from a heart rate sensor. 我已经实现了一个IntentService ,它使用SensorManager从心率传感器读取数据。

It gets periodically called using AlarmManager and a WakefulBroadcastReceiver and then, upon onSensorChanged , it updates Google Fit data by using Fitness History API, using the time of the onSensorChanged invocation as timestamp. 会使用AlarmManagerWakefulBroadcastReceiver定期调用它,然后在onSensorChanged ,使用onSensorChanged调用的时间作为时间戳,使用Fitness History API更新Google Fit数据。

The IntentService , of course, implements a SensorEventListener and it's implemented as a WakefulIntentService using CommonsWare cwac-wakeful . IntentService当然实现了SensorEventListener并且使用CommonsWare cwac- WakefulIntentService将其实现为WakefulIntentService

What's happening is that sensor reading task takes a very highly variable time and sometimes, onSensorChanged - which I guess works asynchronously once the sensor listener is registered - gets called even minutes later, when the IntentService instance which registered the sensor listener, has already ended and the listener listening (!) is a successive one. 发生的事情是,传感器读取任务需要花费非常多的时间,有时, onSensorChanged (我想一旦注册了传感器侦听器,它就会异步工作),甚至在几分钟后调用,当注册传感器侦听器的IntentService实例已经结束并且侦听器(!)是连续的侦听器。

This translates to a series of data readings overlapping and being inserted into Google Fit without any temporal order with respect to the original timed invocation of the IntentService measuring task. 这将转化为一系列数据读数,这些数据读数重叠并插入到Google Fit中,相对于IntentService测量任务的原始定时调用, IntentService没有任何时间顺序。

Besides, this behaviour also causes an abnormal usage of the battery, since the heart rate sensor uses a couple of very bright leds and - unless unregistered - keeps staying active until, I guess, its hardware timeout. 此外,这种行为还会导致电池的异常使用,因为心率传感器会使用几个非常亮的led,并且-除非未注册,否则会一直保持活动状态,直到我猜想它的硬件超时为止。

I've tried to unregister the sensor listener inside the IntentService by calling a post delayed Runnable after a certain timeout (30 secs), but it's not working. 我试图通过在一定的超时时间(30秒)后调用一个延迟的Runnable来注销IntentService的传感器侦听器,但是它不起作用。

My questions are: 我的问题是:

Is there a way, inside an IntentService or a WakefulIntentService to call the sensor unregisterListener after a certain delay preventing the thread to end, meanwhile? 同时,在IntentServiceWakefulIntentService内部,是否有某种方法可以在阻止线程结束的特定延迟后调用传感器unregisterListener Or to clear the onSensorChanged queue somehow? 还是以某种方式清除onSensorChanged队列?

Alternatively: Is there a way to assign an univoque ID to a sensor listener at the moment of its registration? 或者:有没有一种方法可以在注册时为传感器侦听器分配唯一的ID? This way, inside the onSensorChanged , it would be possible to match the event against its originating IntentService invocation time and it could be - at least - possible to insert the readings in Google Fit with the right temporal order. 这样,在onSensorChanged内部,可以将事件与其原始IntentService调用时间进行匹配,并且至少可以以正确的时间顺序在Google Fit中插入读数。

Thank you in advance. 先感谢您。

I've implemented an IntentService which, using SensorManager, reads data from a heart rate sensor. 我已经实现了一个IntentService,它使用SensorManager从心率传感器读取数据。

IMHO, that is not a proper use of IntentService . 恕我直言,这不是IntentService的正确使用。 IMHO, IntentService is designed for transaction bits of work: disk I/O, database I/O, Web service calls, etc. It is not designed for work of indefinite duration. 恕我直言, IntentService是为事务事务工作而设计的:磁盘I / O,数据库I / O,Web服务调用等。它不是为无限期工作而设计的。

The IntentService, of course, implements a SensorEventListener and it's implemented as a WakefulIntentService using CommonsWare cwac-wakeful. 当然,IntentService实现了SensorEventListener,并且使用CommonsWare cwac-wakeful将其实现为WakefulIntentService。

WakefulIntentService is not designed for doing work indefinitely. WakefulIntentService 并非旨在无限期地工作。

What's happening is that sensor reading task takes a very highly variable time and sometimes, onSensorChanged - which I guess works asynchronously once the sensor listener is registered - gets called even minutes later, when the IntentService instance which registered the sensor listener, has already ended and the listener listening (!) is a successive one. 发生的事情是,传感器读取任务需要花费非常多的时间,有时,onSensorChanged(我想一旦注册了传感器侦听器,它就会异步工作),甚至在几分钟后调用,当注册传感器侦听器的IntentService实例已经结束并且侦听器(!)是连续的侦听器。

In general, there is no guarantee that you will get any sensor readings, as your process can terminate at any time once the service is destroyed. 通常,不能保证您会获得任何传感器读数,因为一旦服务被销毁,您的过程可以随时终止。

Is there a way, inside an IntentService or a WakefulIntentService to call the sensor unregisterListener after a certain delay preventing the thread to end, meanwhile? 同时,在IntentService或WakefulIntentService内部,是否有某种方法可以在阻止线程结束的特定延迟后调用传感器unregisterListener?

Not in any reliable fashion. 没有任何可靠的方式。

Get rid of the WakefulIntentService . 摆脱WakefulIntentService Use a regular Service . 使用常规Service Register for sensor events. 注册传感器事件。 When you get the event(s) that you want, unregister the sensor listener and stopSelf() the service. 当您获得所需的事件时,请注销传感器侦听器并stopSelf()服务。 Along the way, manage your own WakeLock . 在此过程中,管理您自己的WakeLock

Or to clear the onSensorChanged queue somehow? 还是以某种方式清除onSensorChanged队列?

Not that I am aware of. 不是我知道的。

Is there a way to assign an univoque ID to a sensor listener at the moment of its registration? 是否可以在注册时为传感器侦听器分配唯一的ID?

The listener object is already unique. 侦听器对象已经是唯一的。 Why would an ID make it more unique? 为什么ID会变得更加独特?

That being said, you are welcome to put a field in your listener object that has whatever sort of unique value that you like. 就是说,欢迎您在您的侦听器对象中放置一个具有您喜欢的唯一值的字段。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM