Android后台持续计步器实现咨询：加速度传感器与前台服务方案

1. 现有仅在应用前台有效的加速度传感器计步代码，希望改造为后台持续运行的计步功能，且应用重启后能恢复步数统计
2. 担忧前台服务因耗电等原因被系统终止，求最优实现方案
3. 疑问：在onStop()/onPause()中保持传感器运行是否可行，是否仍会被系统终止？

现有计步代码 #

SensorEventListener sel = new SensorEventListener() {
    public void onAccuracyChanged(Sensor sensor, int accuracy) {
    }
    public void onSensorChanged(SensorEvent event) {
        float[] values = event.values;
        float x = values[0];
        float y = values[1];
        float z = values[2];
        // WITHOUT GRAVITY
        double magnitude = Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2) + Math.pow(z, 2));
        // WITH EARTH'S GRAVITY INCLUDED
        // double magnitude = (Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2) + Math.pow(z, 2))) / (SensorManager.GRAVITY_EARTH * SensorManager.GRAVITY_EARTH);
        double magnitudeDelta = magnitude - magnitudePrevious;
        magnitudePrevious = magnitude;

        if (magnitudeDelta > 7) { // adjust the threshold based on your device
            numSteps++;
            Log.d("DELTA:", String.valueOf(magnitudeDelta));
        }
        counter.setText(String.valueOf(numSteps));
    }
};

一、前台服务+持久化：后台计步的可靠方案 #

前台服务是目前Android上保障后台任务持续运行的最稳妥方式，但要做好合规性和功耗优化，才能降低被系统终止的概率：

1. 搭建前台服务基础 #

• 编写继承Service的类，在onCreate()中初始化SensorManager和传感器监听器，绑定加速度传感器
• 核心操作：在onStartCommand()中调用startForeground()，传入通知ID和前台通知（Android 8.0+必须先创建通知渠道）。前台服务会在状态栏常驻通知，系统判定为用户主动需要的服务，不会轻易回收
• 版本适配：Android 12+需申请POST_NOTIFICATIONS权限，且服务必须由用户主动触发启动（比如点击“开始计步”按钮），否则会被系统拦截

2. 迁移并优化计步逻辑 #

• 将原SensorEventListener移至服务中，删除UI相关代码（如counter.setText()），改为将步数持久化到本地——简单场景用SharedPreferences存储累计步数，需详细记录则用Room数据库
• 算法优化：原代码仅靠阈值判断易出现误判，可添加时间窗口过滤（如1秒内只统计一次有效峰值）；更推荐直接使用系统原生Sensor.TYPE_STEP_COUNTER传感器，由系统底层处理计步，功耗更低、准确率更高，无需自行计算加速度

3. 实现应用重启后的步数恢复 #

• 每次步数更新时，立即将最新步数写入本地存储，避免数据丢失
• 应用启动时（如主Activity的onCreate()），读取本地存储的步数并同步到UI展示

4. 降低系统终止风险 #

• 功耗优化：将传感器采样率设置为SensorManager.SENSOR_DELAY_NORMAL，避免不必要的高频采样
• 分版本适配：
  • Android 10+：搭配WorkManager，若服务被系统终止，触发WorkManager重启服务
  • Android 12+：申请FOREGROUND_SERVICE_ACTIVITY_RECOGNITION权限，通知内容需明确告知用户服务用途（避免被用户手动关闭）
  • onStopCommand()返回START_STICKY，让系统在资源充足时自动重启服务

二、关于onStop()/onPause()中保持传感器运行的疑问 #

• 可行性：表面可以实现——不在这两个方法中注销传感器监听器，传感器会继续运行，但这种方式完全不可靠
• 系统终止风险：应用进入后台后会被归类为缓存进程，系统内存不足时会优先回收此类进程，传感器也会随之停止；Android 8.0+的后台限制更严格，后台应用无法持续持有传感器资源，系统会强制停止监听
• 结论：这种方式无法保障后台持续运行，绝对不推荐使用

额外优化建议 #

• 优先使用系统原生Sensor.TYPE_STEP_COUNTER：该传感器由系统持续统计步数，即使应用关闭也不会中断，下次启动可直接读取累计值，功耗远低于自行计算
• 引导用户加入电池优化白名单：告知用户将应用加入电池优化白名单，减少系统因功耗限制终止服务的概率

内容的提问来源于stack exchange，提问作者Peter