Android Wear Step Sensor_android wear os如何获取步数控制器-CSDN博客

本文链接：https://blog.csdn.net/elfxwt_study/article/details/46381325

本文探讨了Android Wear平台上StepCounter与StepDetector传感器的应用，分析了两种传感器的区别及Batching Mode的工作原理，同时提出了实际开发中遇到的问题及可能的解决方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

开启Android wear 之旅，由于公司业务需求，需要研究一下android wear 上的计步器功能，即 Step Counter 和 Step Detector 两个 sensor的使用，同时有关于batching mode的知识。

0 Something about sensor

要使用传感器，在上层应用上需要了解到的几个名词

SensorManager , Sensor, SensorEventListner, SensorEvent

SensorManager :传感器管理者，相信熟悉android开发的你一定对其不陌生，通过系统服务 getSystemService(SENSOR_SERVICE) 便可以得到

Sensor , 通过SensorManager可以得到你想要的Sensor，确定好你的SensorType ， Android 内嵌了十多种传感器，在本博客里需用到 Sensor.TYPE_STEP_COUNTER 和 Sensor.TYPE_STEP_DETECTOR

SensorEventListner: sensor 监听器，里面主要是两个回调函数，onSensorChanged() 和 onAccuracyChange() ，从名字上就可以知道两个函数的意思。一般都是通过 registerListener方法将此三者绑定在一起。

SensorEvent : 作为 Sensor 的事件 Model ,其中包含了很多触发事件的属性，特别是 values数组，对应不同的sensorType 会有不同的value数组值，但是奇怪的是在android developer 官网中没有找到step counter 和 step detector 所对应的value值解释，是归于其中的一类，还是我没有看仔细，望博友们指出。

1 Batching Mode

批处理模式，是android4.4 kitkat 版本之后推出的sensor 模式，意在减少 power consumputation ，其原理在于并不是在传感器sensor监测到事件发生就立即汇报出去，而是将监测到的事件汇集起来，在一定的时间内latency汇报上去，达到批量处理的效果，很显然这样的工作模式，使得sensor 更加低电耗。

同时这个延迟的latency 可以通过参数进行相应的设置，达到可控的状况，使得可以精确的衡量工作状况。sdk sample 中提供了 0(无batching mode 即连续模式 continuous),5s,10s的选择，这个时间是sensor 会上报所记录的event的最大时延，也就是触发 onSensorChanged()的时延。

2 Step Counter and Step Detector

1) Step Detector

作为可以监测步数的sensor之一，detector 具有更高的灵敏性，往往稍微的手表或者手机晃动都可以致使步数增加，通过android sdk 里面提供的sample (BatchStepSensorFragment)可知，该类型的SensorEvent的Value数组只有一个数值，即长度为1，此sensor 具有Batching Mode .

2) Step Counter

Step Counter 应该是被用来进行计步器的真正sensor，推理 google fit 就是用的这个sensor ，它比detector主要有两个不同：一是通过一定的算法对监测到的事件进行了过滤，抵消了一定的false positive ,二是它通过 event.value[0] 记录了从第一次注册以来的所有步数，无论中间unregister 与否，除非是关机reboot ，才会被清零。两个原因使得Step Counter更加适用于计步器的监测。

3 an important issure

在google 文档中描述了batching mode 下的一个问题，就是sensor 只会在cpu awake 状态下才会汇报记录的event，否则就将event存放在sensor 的一个FIFOs硬件空间中，那么问题就来了，如果不在及时的状态下将此空间清空，那势必event会在某一个时刻充满整个meomry ,让sensor 将old event 抛弃，为了不出现这样的情况，就需要另开线程或者service来进行处理，解决方法有这样的一段英文描述，我还没有找到源代码，水平还不够写出解决方案，但是想着不难写，但会存在一些误差，现将英文贴上：（come from http://developer.android.com/about/versions/android-4.4.html ）

However, be aware that the sensor will deliver your app the batched events based on your report latency only while the CPU is awake . Although a hardware sensor that supports batching will continue to collect sensor events while the CPU is asleep, it will not wake the CPU to deliver your app the batched events. When the sensor eventually runs out of its memory for events, it will begin dropping the oldest events in order to save the newest events. You can avoid losing events by waking the device before the sensor fills its memory then call flush() to capture the latest batch of events. To estimate when the memory will be full and should be flushed, call getFifoMaxEventCount() to get the maximum number of sensor events it can save, and divide that number by the rate at which your app desires each event. Use that calculation to set wake alarms with AlarmManager that invoke your Service (which implements the SensorEventListener ) to flush the sensor

其意思在于开启一个线程，并通过 getFifoMaxEventCount() 方法计算出要唤醒系统的时刻，用AlarmManager定时唤醒Service,在通过Servcie 去调用 SensorManager的flush() 方法，该方法会将所有sensor的FIFOs队列空间冲刷。

4 the questions

1）不同app 注册同一个sensor时

本博主要做的是一个简单的计步器功能，但希望可以在android wear上与google fit 保持同步，但是很明显google 自身的app 不会这么简单，博主在一个已经装有google fit 的 android wear 上安装自己的app ,突然想到不同的app 注册到相同的sensor上会不会有干扰，奈何对android 底层的东西还不熟悉，查了很多东西，只获知到两点：一是两个不同频率 batching mode 下的app 注册到一个sensor 上，sensor 会按照低频率的来；二是在framework层上对相同sensor的注册是有一个计数机制，来一个app 对其加1，unregister时，就减1，因此实际上的sensor只有所有的app都unregister之后才不会再工作。知道这个之后，博主就知道为什么自己的app在activity pause()的时候明明已经unregister 了，但是在退出app之后，再次打开app,发现计数值增加了，sensor 依旧起作用。但是还是不明白是否sensor对不同的app 注册，会进行标识，然后对不同的listner 进行触发，从而去回调不同的 onSenerChanged() ,感觉原则上应该是不同的，但FIFOs 肯定是共用的同一个，但是又怎样去保证sensor在report event的时候触发不同的app 呢，需要对framework层上的相关知识再研究。

2）Step Counter 获取total number

依旧是在前面的前提下，正因为每次event.value[0]都是记录了从第一次注册以来的所有步数，因此是不是只要记录了event ,当再次监测到event，不管这中间是否漏掉了，都可以获得较为准确的步数呢，但是在写博时，突然想到系统reboot时，event.value[0]会被置0，从而不能如此简单的认为。

5 conclusion

要了解的东西还有很多，需要更加努力的学习和研究，希望可以在不久的将来可以将上面的问题都弄懂。