问题
UPDATED:
I was able to solve the specific problem I was having by introducing a class-scope static counter and just ignoring ever x number of events. But I'd still like to know what I'm doing wrong re: registering the listener with a hint in microseconds instead of using one of the four given constants.
An Activity in my app is engaging the sensors to obtain the orientation of the device, determine the roll, and utilize it.
I am using
SensorManager.registerListener(SensorEventListener listener, Sensor sensor, int rate)
to register my sensors. From the Android Documentation for this method:
Parameters
[...]
rate
The rate sensor events are delivered at. This is only a hint to the system. Events may be received faster or slower than the specified rate. Usually events are received faster. The value must be one of SENSOR_DELAY_NORMAL, SENSOR_DELAY_UI, SENSOR_DELAY_GAME, or SENSOR_DELAY_FASTEST or, the desired delay between events in microsecond.
If I use one of the 4 predefined constants then the app works fine; however these constants all provide rate hints that are too fast for my needs. I have to send out a UDP packet containing some information with every event change, and the receiving end seems to be getting completely inundated with messages using any of the predefined rates. Using an integer number like 30000 (since the API specifies quantities in microseconds) causes the app to stop reporting sensor events all together.
What am I missing that is preventing me from using my own event rate hints?
回答1:
I'm pretty sure sensor listener rate did what it's supposed to do. In your question you wrote 30000, which is 30 milliseconds. In the doc, it says the rate is usually faster than the hint. So you are doing faster than 30ms. Is it possible that your other network related routines have been going too fast? It may have caused some blocking that lead you to believe sensor reporting is stopped.
In my application I too find the given NORMAL rate too high. Therefore I set a rate to 250000. I also used moving average calculation to smooth the number by 5. I find the resulting behavior close to the iPhone compass.
Nonetheless, I wouldn't suggest that you do network reporting in a sensor listener. It's not supposed to be done this way. You can however, do some simple calculation in the listener and record the value. Then, use a timer like Handler.postDelayed with a high number, to handle network sending among other things.
回答2:
This question was asked in 2011, nevertheless answering it as a lot has changed since then; from API 19 (2013+) onwards, there is a new variant of the registration API, in which you could mention at what interval you would like to receive the sensor readings. From the docs:
boolean registerListener (SensorEventListener listener, Sensor sensor, int samplingPeriodUs, int maxReportLatencyUs) Registers a SensorEventListener for the given sensor at the given sampling frequency and the given maximum reporting latency.
This function is similar to registerListener(SensorEventListener, Sensor, int) but it allows events to stay temporarily in the hardware FIFO (queue) before being delivered. The events can be stored in the hardware FIFO up to maxReportLatencyUs microseconds. Once one of the events in the FIFO needs to be reported, all of the events in the FIFO are reported sequentially. This means that some events will be reported before the maximum reporting latency has elapsed.
来源：https://stackoverflow.com/questions/5873545/custom-sensor-event-rates-dont-seem-to-work-with-sensormanager-registerlisten